Friday, August 8, 2008

Re: [NOVICE] join group by etc

Ok just a bit more info. Unfortunately DISTINCT ON didnt work after all
(once I started to get some more data into the tables and try different
sorts. Ended up having to select all fields and just use max(field1) etc.
The reason I required this (which I didnt realise at the time) is that
the gui output can be sorted however you like. (and as DISTINCT ON
requires the field to be used as the first sort field it didnt work once
you decided to sort by anything but T1.iTd

The eventual output is:
T1.tOc T2.fId(24) T2.fId(25) T2.fId(26) T2.fId(27) T1.tOd
which when you click on the row brings up the rest of the record.

so whatever records that relate to t1.tId (which could be 4 or 400) are
displayed so the final outcome was

SELECT T1.iId,max(T1.tId),max(T1.toC) as status,max(T1.toD),max(T1.toE),
max(T2.ttC), max(T3.tthD), max(T1.toD) as sort FROM table_one T1 INNER JOIN
table_two T2 ON T1.iId = T2.iId INNER JOIN table_three T3 ON T3.fId =
T2.fId WHERE T1.tId = '9' and T1.toC = 'o' GROUP BY T1.iId ORDER BY sort

Think I have explained that right. Anyway thanks for you help everyone.

Obe, Regina wrote:
>
> Peter,
>
>
>
> For grouping - standard ANSI SQL behavior is that all fields in the
>
> select need to appear in the group by if they are not aggregated.
>
>
>
> I think what you are trying to do is probably closer to PostgreSQL's
>
> DISTINCT ON feature - try the below
>
>
>
> SELECT DISTINCT ON(T1.iId) T1.*, T2.ttC, T3.tthD, toD as sort
>
> FROM table_one T1 INNER JOIN
>
> table_two T2 ON T1.iId = T2.iId INNER JOIN table_three T3 ON T3.fId =
>
> T2.fId WHERE T1.tId = '9' and T1.toC = 'o'
>
> ORDER BY T1.iId, toD asc;
>
>
>
> Hope that helps,
>
> Regina
>
>
>
> -----Original Message-----
>
> From: pgsql-novice-owner@postgresql.org
>
> [mailto:pgsql-novice-owner@postgresql.org] On Behalf Of Peter Jackson
>
> Sent: Friday, August 08, 2008 8:59 AM
>
> To: pgsql
>
> Subject: [NOVICE] join group by etc
>
>
>
> Hi List
>
>
>
> I'm trying to convert some mysql queries to postgres and hitting a
>
> brick wall with the following so was hoping for some hints.
>
>
>
> table_one - iId,tId,toC,toD,toE
>
> table_two - iId,fId,ttC,ttD
>
> table_three - fId,tId,tthC,tthD,tthE,tthF
>
>
>
> table_one data 11,9,o,1218177417,data
>
> table_two data
>
> 11, 24, test1
>
> 11, 25, test2
>
> 11, 26, test4
>
> 11, 27, test6
>
>
>
> table_three data
>
> 24,9,area1,t,y,3
>
> 25,9,area2,t,y,2
>
> 26,9,area3,a,y,1
>
> 27,9,area4,y,y,4
>
>
>
> mysql query
>
>
>
> SELECT T1.*, T2.ttC, T3.tthD, toD as sort FROM table_one T1 INNER JOIN
>
> table_two T2 ON T1.iId = T2.iId INNER JOIN table_three T3 ON T3.fId =
>
> T2.fId WHERE T1.tId = '9' and T1.toC = 'o' GROUP BY T1.iId ORDER BY sort
>
>
>
> asc;
>
>
>
> Which in mysql returns 1 row but fails in pg due to the group by.
>
>
>
> If I add more fields to the group by or remove the group by it returns 4
>
>
>
> rows which is incorrect
>
>
>
> Basically I guess I am asking how I can get the same result in pg
>
> without to much change in the sql.
>
>
>
> Peter J
>
>
>


--
Sent via pgsql-novice mailing list (pgsql-novice@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-novice

[COMMITTERS] npgsql - Npgsql2: Fixed regression where quoting numbers could give

Log Message:
-----------

Fixed regression where quoting numbers could give errors. Now, int2, int4 and int8 aren't quoted anymore.
Thanks Josh Cooley and Mike S for heads up.
See http://pgfoundry.org/forum/message.php?msg_id=1003837 for discussion about this problem.

Modified Files:
--------------
Npgsql2/src/NpgsqlTypes:
NpgsqlTypesHelper.cs (r1.17 -> r1.18)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/npgsql/Npgsql2/src/NpgsqlTypes/NpgsqlTypesHelper.cs.diff?r1=1.17&r2=1.18)
Npgsql2/testsuite/noninteractive/NUnit20:
CommandTests.cs (r1.12 -> r1.13)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/npgsql/Npgsql2/testsuite/noninteractive/NUnit20/CommandTests.cs.diff?r1=1.12&r2=1.13)

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Re: [PERFORM] index scan cost

Tom Lane wrote:
Jeff Frost <jeff@frostconsultingllc.com> writes:   
I have two postgresql servers.  One runs 8.3.1, the other 8.3.3.  On the 8.3.1  machine, the index scans are being planned extremely low cost:     
   
  Index Scan using ix_email_entity_thread on email_entity  (cost=0.00..4.59  rows=1 width=1031) (actual time=0.095..0.120 rows=4 loops=1)     Index Cond: (email_thread = 375629157)     
   
  Index Scan using ix_email_entity_thread on email_entity  (cost=0.00..2218.61  rows=1151 width=931) (actual time=0.094..0.111 rows=4 loops=1)     Index Cond: (email_thread = 375629157)     
 This isn't a "cost" problem, this is a "stats" problem.  Why does the second server think 1151 rows will be returned?  Try comparing the pg_stats entries for the email_thread column on both servers ... seems like they must be significantly different.   
Sorry it took me a while to close the loop on this.  So, the server that had the less desirable plan had actually been analyzed more recently by autovacuum.  When I went back to compare the stats on the faster server, autovacuum had analyzed it and the plan was now more similar.  Adjusting the stats target up for that column helped on both servers though it never did get back as close as before.

--  Jeff Frost, Owner 	<jeff@frostconsultingllc.com> Frost Consulting, LLC 	http://www.frostconsultingllc.com/ Phone: 916-647-6411	FAX: 916-405-4032 

Re: [BUGS] ALTER TABLE name RENAME TO new_name; does not work immediately

Oh, I've forgot to mention that the commands are issued from the
script. When issued by hand there is no problem at all (probably
because I'm a slow typist :-D).

Thank you and regards,

Ondrej Jirman

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

[BUGS] ALTER TABLE name RENAME TO new_name; does not work immediately

Hello,

I don't know if this is expected behaviour or not, but I've found that
this sequence of commands does not work all the time:

ALTER TABLE name RENAME TO new_name;
ALTER TABLE new_name
RENAME COLUMN x TO y;

It usually works with small work_mem and maintenance_work_mem values.
If I increase work_mem and maintenance_work_mem to 256MB it stops
working and prints following error message:

ERROR: relation "new_name" does not exist

It doesn't matter whether the commands are run within the transaction
or not.

I'm running postgresql 8.3.3 on Core 2 Duo with 2GB ram. Actual table
has 700 000 rows. I think the issue might be timing related as I've
managed to "solve" the issue by putting SAVEPOINT between the commands
on one machine. But on other machine this did not help.

I think the issue might be reproducible by creating table with a lot
of rows, setting high work_mem and issuing the commands, but I did not
try to reproduce it this way.

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [HACKERS] For what should pg_stop_backup wait?

Index: src/backend/access/transam/xlog.c
===================================================================
RCS file: /home/sriggs/pg/REPOSITORY/pgsql/src/backend/access/transam/xlog.c,v
retrieving revision 1.316
diff -c -r1.316 xlog.c
*** src/backend/access/transam/xlog.c 13 Jul 2008 20:45:47 -0000 1.316
--- src/backend/access/transam/xlog.c 8 Aug 2008 13:56:40 -0000
***************
*** 1165,1170 ****
--- 1165,1184 ----
/* Retry creation of the .ready file */
if (create_if_missing)
XLogArchiveNotify(xlog);
+ else
+ {
+ char xlogpath[MAXPGPATH];
+
+ snprintf(xlogpath, MAXPGPATH, XLOGDIR "/%s", xlog);
+
+ /*
+ * Check to see if the WAL file has been removed by checkpoint,
+ * which implies it has already been archived, and explains why we
+ * can't see a status file for it.
+ */
+ if (stat(xlogpath, &stat_buf) != 0)
+ return true;
+ }

return false;
}
***************
*** 6721,6735 ****
CleanupBackupHistory();

/*
! * Wait until the history file has been archived. We assume that the
! * alphabetic sorting property of the WAL files ensures the last WAL
! * file is guaranteed archived by the time the history file is archived.
*
* We wait forever, since archive_command is supposed to work and
* we assume the admin wanted his backup to work completely. If you
* don't wish to wait, you can SET statement_timeout = xx;
*
! * If the status file is missing, we assume that is because it was
* set to .ready before we slept, then while asleep it has been set
* to .done and then removed by a concurrent checkpoint.
*/
--- 6735,6748 ----
CleanupBackupHistory();

/*
! * Wait until both the last WAL file filled during backup and the
! * history file have been archived.
*
* We wait forever, since archive_command is supposed to work and
* we assume the admin wanted his backup to work completely. If you
* don't wish to wait, you can SET statement_timeout = xx;
*
! * If the status files are missing, we assume that is because it was
* set to .ready before we slept, then while asleep it has been set
* to .done and then removed by a concurrent checkpoint.
*/
***************
*** 6739,6745 ****
seconds_before_warning = 60;
waits = 0;

! while (!XLogArchiveCheckDone(histfilepath, false))
{
CHECK_FOR_INTERRUPTS();

--- 6752,6759 ----
seconds_before_warning = 60;
waits = 0;

! while (!XLogArchiveCheckDone(histfilepath, false) ||
! !XLogArchiveCheckDone(stopxlogfilename, false))
{
CHECK_FOR_INTERRUPTS();

On Fri, 2008-08-08 at 12:57 +0100, Simon Riggs wrote:

> > Yes, statement_timeout may help. But, I don't want to use it, because the
> > *successful* backup is canceled.
> >
> > How about checking whether the stoppoint was archived by comparing with
> > the last WAL archived. The archiver process can tell the last WAL archived.
> > Or, we can calculate it from the status file.
>
> I think its easier to test whether the stopxlogfilename still exists in
> pg_xlog. If not, we know it has been archived away. We can add that as
> an extra condition inside the loop.
>
> So thinking we should test XLogArchiveCheckDone() for both
> stopxlogfilename and history file and then stat for the stop WAL file:

This seems better.

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support

Re: [NOVICE] join group by etc

Peter Jackson <tasmaniac@iprimus.com.au> writes:
> mysql query

> SELECT T1.*, T2.ttC, T3.tthD, toD as sort FROM table_one T1 INNER JOIN
> table_two T2 ON T1.iId = T2.iId INNER JOIN table_three T3 ON T3.fId =
> T2.fId WHERE T1.tId = '9' and T1.toC = 'o' GROUP BY T1.iId ORDER BY sort
> asc;

> Which in mysql returns 1 row but fails in pg due to the group by.

Egad. *Which* row does it return, and why? Anyone reading the SQL
spec would have to say that this query's behavior is undefined:
there are multiple t2 and t3 rows joining to each T1 row, hence
no principled way to decide which ttC and tthD values to output
for a given T1.iId value.

(One of mysql's more unlovely behaviors is their willingness to
return some randomly-chosen result for underspecified queries.)

regards, tom lane

--
Sent via pgsql-novice mailing list (pgsql-novice@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-novice

Re: [NOVICE] join group by etc

Peter,

For grouping - standard ANSI SQL behavior is that all fields in the
select need to appear in the group by if they are not aggregated.

I think what you are trying to do is probably closer to PostgreSQL's
DISTINCT ON feature - try the below

SELECT DISTINCT ON(T1.iId) T1.*, T2.ttC, T3.tthD, toD as sort
FROM table_one T1 INNER JOIN
table_two T2 ON T1.iId = T2.iId INNER JOIN table_three T3 ON T3.fId =
T2.fId WHERE T1.tId = '9' and T1.toC = 'o'
ORDER BY T1.iId, toD asc;

Hope that helps,
Regina

-----Original Message-----
From: pgsql-novice-owner@postgresql.org
[mailto:pgsql-novice-owner@postgresql.org] On Behalf Of Peter Jackson
Sent: Friday, August 08, 2008 8:59 AM
To: pgsql
Subject: [NOVICE] join group by etc

Hi List

I'm trying to convert some mysql queries to postgres and hitting a
brick wall with the following so was hoping for some hints.

table_one - iId,tId,toC,toD,toE
table_two - iId,fId,ttC,ttD
table_three - fId,tId,tthC,tthD,tthE,tthF

table_one data 11,9,o,1218177417,data
table_two data
11, 24, test1
11, 25, test2
11, 26, test4
11, 27, test6

table_three data
24,9,area1,t,y,3
25,9,area2,t,y,2
26,9,area3,a,y,1
27,9,area4,y,y,4

mysql query

SELECT T1.*, T2.ttC, T3.tthD, toD as sort FROM table_one T1 INNER JOIN
table_two T2 ON T1.iId = T2.iId INNER JOIN table_three T3 ON T3.fId =
T2.fId WHERE T1.tId = '9' and T1.toC = 'o' GROUP BY T1.iId ORDER BY sort

asc;

Which in mysql returns 1 row but fails in pg due to the group by.

If I add more fields to the group by or remove the group by it returns 4

rows which is incorrect

Basically I guess I am asking how I can get the same result in pg
without to much change in the sql.

Peter J

--
Sent via pgsql-novice mailing list (pgsql-novice@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-novice
-----------------------------------------
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.


--
Sent via pgsql-novice mailing list (pgsql-novice@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-novice

Re: [ADMIN] Problems with connection

Στις Friday 08 August 2008 09:21:22 ο/η Курашкин Дмитрий έγραψε:

maybe the listen_addresses in postgresql.conf in Server installation?


--
Achilleas Mantzios

--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Re: [HACKERS] patch: Add columns via CREATE OR REPLACE VIEW

Zeugswetter Andreas OSB sIT <Andreas.Zeugswetter@s-itsolutions.at> writes:
>> If you accept the idea that column identity should be based on column
>> name, then the only two operations that are really necessary are
>> "CREATE OR REPLACE VIEW" and "ALTER VIEW RENAME COLUMN", and it is
>> 100% clear what the semantics of those operations should be.

> +1

It's nice, it's simple, and it's unimplementable. At least not without
huge changes in the representation of stored views, which would likely
lead to failure to follow spec-required behavior in other ways. Other
views are going to refer to the columns of this one by *number*, not
name, and it's not clear to me how you're going to preserve column
number identity with this approach.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [pgsql-jobs] Senior PostgreSQL DBA

Recruiter wrote:
>
>
>
>
> Compensation: Salary (BOE), plus excellent benefits package (PTO, 100%
> employee paid med/dent/vis/RX/life, retirement plan, educational
> allowance, great facilities)
>
>
>
>

"employee paid"? are you sure?

cheers

andrew

--
Sent via pgsql-jobs mailing list (pgsql-jobs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jobs

Re: [BUGS] BUG #4186: set lc_messages does not work

My apologies on this late reply.
The way LC_MESSAGES is handled on windows is much less efficient and faulty.
While ago I started with a patch to fix some of the issues I encountered on
windows and LC_MESSAGES. But I stopped working on that patch because this
problem needed to be fixed on many other places. In Windows, handling
LC_MESSAGES will not work the same way as *nix systems, forcing us to make
ugly workarounds. (as I actually was doing with my patch)

To my opinion, unless we think of a coherent solution for handling
LC_MESSAGES/locale for both *nix and win32 platforms, fixing lc_messages and
locale issues would break more than fixing it.

BTW: The gettext library we are using on win32 is a very old one.

Regards,
Gevik.


> -----Original Message-----
> From: Magnus Hagander [mailto:magnus@hagander.net]
> Sent: Tuesday, August 05, 2008 4:54 PM
> To: Bruce Momjian
> Cc: Tom Lane; Thomas H.; pgsql-bugs@postgresql.org; Gevik Babakhani
> Subject: Re: [BUGS] BUG #4186: set lc_messages does not work
>
> Bruce Momjian wrote:
> > Tom Lane wrote:
> >> Magnus Hagander <magnus@hagander.net> writes:
> >>> Thomas H. wrote:
> >>>> so at least that explains the "changed" behaviour. nevertheless,
> >>>> LC_MESSAGES seems to be defunct - with the "locale"
> folder present,
> >>>> pg always picks the os' language and ignores the
> lc_message value.
> >>> This looks like I can reproduce though, at least on cvs head. Did
> >>> this work for you in previous versions?
> >> Maybe we were using a different build of gettext in the previous
> >> releases, one that didn't look at the same info as the
> current code?
> >>
> >> Anyway the patch mentioned at the start of the thread
> >> http://archives.postgresql.org/pgsql-patches/2008-02/msg00038.php
> >> purports to fix this. It doesn't seem to have gotten reviewed
> >> though.
> >
> > Agreed. Magnus, someone, can we get feedback on the patch
> at this URL?
> >
> >
> http://archives.postgresql.org/pgsql-patches/2008-02/msg00038.php
>
> IIRC, there was further work to be done on the patch before
> it was to be applied, and we held off the review until then.
>
> Gevik - can you comment on this? Where are we, what needs ot
> be done still?
>
> //Magnus
>


--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

[COMMITTERS] pgbouncer - pgbouncer: include userlist.txt in tgz

Log Message:
-----------
include userlist.txt in tgz

Modified Files:
--------------
pgbouncer:
Makefile (r1.24 -> r1.25)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgbouncer/pgbouncer/Makefile.diff?r1=1.24&r2=1.25)
NEWS (r1.30 -> r1.31)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgbouncer/pgbouncer/NEWS.diff?r1=1.30&r2=1.31)

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Re: [GENERAL] Initdb problem on debian mips cobalt: Bus error

Glyn Astill <glynastill@yahoo.co.uk> writes:
>> Okay, so it is indeed the linker's fault. Now try plan
>> (a) --- can you
>> find a more up-to-date toolchain?

> Well I've tried looking in apt, and the latest package is the version I've got, (the toolchain is more than just gcc isn't it though?) is there another way to get a more up to date toolchain?

gcc wasn't the suspected candidate --- the netbsd guys thought it was
as or ld. On my Fedora machine those seem to be part of the binutils
package; dunno how Debian handles it.

regards, tom lane

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[COMMITTERS] pgbouncer - pgbouncer: disable untested SO_ACCEPTFILTER code

Log Message:
-----------
disable untested SO_ACCEPTFILTER code

Modified Files:
--------------
pgbouncer:
NEWS (r1.29 -> r1.30)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgbouncer/pgbouncer/NEWS.diff?r1=1.29&r2=1.30)
pgbouncer/src:
pooler.c (r1.14 -> r1.15)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgbouncer/pgbouncer/src/pooler.c.diff?r1=1.14&r2=1.15)

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] stackbuilder - wizard: Fix poorly thought-out change.

Log Message:
-----------
Fix poorly thought-out change.

Modified Files:
--------------
wizard:
App.cpp (r1.20 -> r1.21)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/stackbuilder/wizard/App.cpp.diff?r1=1.20&r2=1.21)

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[pgeu-general] Reminder: Call for Papers - European PGDay 2008

A quick reminder - the CFP for European PGDay closes on sunday. If you
haven't submitted a paper yet, you still have a chance to do so now! See
original message below for details.

--
Magnus Hagander
PostgreSQL Europe


-------- Original Message --------
Subject: [ANNOUNCE] Call for Papers - European PGDay 2008
Date: Sat, 05 Jul 2008 17:22:32 +0200

Following the phenomenal international success of PGDay 2007, the 2008
event, to be held on October 17th and 18th will include both an Italian
program and a European program running in parallel. This call for papers
is for the European program - expect a separate one for the Italian one.

The conference will once again be held in the beautiful historic
surroundings of the Monash University Prato Centre in Prato, a small
walled town near Florence, Tuscany.

European PGDay 2008 is the main European event about PostgreSQL this
year. If you're doing interesting PostgreSQL work in Europe or
elsewhere, this is your chance to tell people about it! Our goal is to
have a complete track of English talks during the conference, so that at
any given time there will be at least one English and one Italian talk
available to go to.

We are interested in talks about all things related to PostgreSQL, for
example:

* PostgreSQL development projects/efforts
* Solutions built on PostgreSQL
* Migration projects
* Advocacy efforts
* ... and much more ...

For more information, as well as instructions on how to submit a paper,
please visit the PGDay website at:
http://www.pgday.org/en/call4papers


--
Sent via pgeu-general mailing list (pgeu-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgeu-general

[NOVICE] join group by etc

Hi List

I'm trying to convert some mysql queries to postgres and hitting a
brick wall with the following so was hoping for some hints.

table_one - iId,tId,toC,toD,toE
table_two - iId,fId,ttC,ttD
table_three - fId,tId,tthC,tthD,tthE,tthF

table_one data 11,9,o,1218177417,data
table_two data
11, 24, test1
11, 25, test2
11, 26, test4
11, 27, test6

table_three data
24,9,area1,t,y,3
25,9,area2,t,y,2
26,9,area3,a,y,1
27,9,area4,y,y,4

mysql query

SELECT T1.*, T2.ttC, T3.tthD, toD as sort FROM table_one T1 INNER JOIN
table_two T2 ON T1.iId = T2.iId INNER JOIN table_three T3 ON T3.fId =
T2.fId WHERE T1.tId = '9' and T1.toC = 'o' GROUP BY T1.iId ORDER BY sort
asc;

Which in mysql returns 1 row but fails in pg due to the group by.

If I add more fields to the group by or remove the group by it returns 4
rows which is incorrect

Basically I guess I am asking how I can get the same result in pg
without to much change in the sql.

Peter J

--
Sent via pgsql-novice mailing list (pgsql-novice@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-novice

[COMMITTERS] stackbuilder - wizard: Allow targetting of server versions >= to a

Log Message:
-----------
Allow targetting of server versions >= to a specified version

Modified Files:
--------------
wizard:
App.cpp (r1.19 -> r1.20)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/stackbuilder/wizard/App.cpp.diff?r1=1.19&r2=1.20)

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] pgbouncer - pgbouncer: v1.2.3

Log Message:
-----------
v1.2.3

Modified Files:
--------------
pgbouncer:
NEWS (r1.28 -> r1.29)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgbouncer/pgbouncer/NEWS.diff?r1=1.28&r2=1.29)
configure.ac (r1.43 -> r1.44)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgbouncer/pgbouncer/configure.ac.diff?r1=1.43&r2=1.44)
pgbouncer/debian:
changelog (r1.16 -> r1.17)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgbouncer/pgbouncer/debian/changelog.diff?r1=1.16&r2=1.17)

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Re: [BUGS] BUG #4167: When generating UUID using UUID-OSSP module, UUIDs are not unique on Windows

Hi.

Yes,please see.!
http://winpg.jp/~saito/pg_work/OSSP_win32/

Regards,
Hiroshi Saito

>Hi,
>
>any progress on a fix for this bug?
>
>Thanks,
>
>Ismael Ciordia
>
>--
>Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
>To make changes to your subscription:
>http://www.postgresql.org/mailpref/pgsql-bugs

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

[COMMITTERS] pgbouncer - pgbouncer: detect stale pidfile

Log Message:
-----------
detect stale pidfile

Modified Files:
--------------
pgbouncer/src:
main.c (r1.47 -> r1.48)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgbouncer/pgbouncer/src/main.c.diff?r1=1.47&r2=1.48)

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Re: [pgsql-fr-generale] transfert encodage apostrophe typo

William Dode wrote:

> Par contre sur une base il y a eu des saisies venant d'utilisateurs
mac
> pointilleux, il y a donc des apostrophes typo et autre joyausetées.
> Donc, bien que l'apostrophe typo n'existe pas en latin9, il y est
quand
> même enregistré (hex 92). Mais du coup à la conversion en utf8 il est

> n'est pas transformé comme je le souhaiterai.
>
> Est-ce que j'ai une solution sans passer par une appli maison de
> conversion qui reprendrai chaque caractère un par un ?

Oui, spécifier win1252 comme encodage de source, puisqu'il comprend ce
genre de caractères, c'est sa principale différence avec latin1 et
latin9.

--
Daniel
PostgreSQL-powered mail user agent and storage:
http://www.manitou-mail.org

--
Sent via pgsql-fr-generale mailing list (pgsql-fr-generale@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-fr-generale

[HACKERS] Verbosity of Function Return Type Checks

Index: src/pl/plpgsql/src/pl_exec.c
===================================================================
RCS file: /projects/cvsroot/pgsql/src/pl/plpgsql/src/pl_exec.c,v
retrieving revision 1.216
diff -u -r1.216 pl_exec.c
--- src/pl/plpgsql/src/pl_exec.c 16 May 2008 18:34:51 -0000 1.216
+++ src/pl/plpgsql/src/pl_exec.c 8 Aug 2008 11:52:02 -0000
@@ -190,7 +190,7 @@
Oid reqtype, int32 reqtypmod,
bool isnull);
static void exec_init_tuple_store(PLpgSQL_execstate *estate);
-static bool compatible_tupdesc(TupleDesc td1, TupleDesc td2);
+static void validate_tupdesc_compat(TupleDesc td1, TupleDesc td2);
static void exec_set_found(PLpgSQL_execstate *estate, bool state);
static void plpgsql_create_econtext(PLpgSQL_execstate *estate);
static void free_var(PLpgSQL_var *var);
@@ -386,11 +386,12 @@
{
case TYPEFUNC_COMPOSITE:
/* got the expected result rowtype, now check it */
- if (estate.rettupdesc == NULL ||
- !compatible_tupdesc(estate.rettupdesc, tupdesc))
+ if (!estate.rettupdesc)
ereport(ERROR,
(errcode(ERRCODE_DATATYPE_MISMATCH),
- errmsg("returned record type does not match expected record type")));
+ errmsg("returned record type does not match "
+ "expected record type")));
+ validate_tupdesc_compat(tupdesc, estate.rettupdesc);
break;
case TYPEFUNC_RECORD:

@@ -707,11 +708,8 @@
rettup = NULL;
else
{
- if (!compatible_tupdesc(estate.rettupdesc,
- trigdata->tg_relation->rd_att))
- ereport(ERROR,
- (errcode(ERRCODE_DATATYPE_MISMATCH),
- errmsg("returned tuple structure does not match table of trigger event")));
+ validate_tupdesc_compat(trigdata->tg_relation->rd_att,
+ estate.rettupdesc);
/* Copy tuple to upper executor memory */
rettup = SPI_copytuple((HeapTuple) DatumGetPointer(estate.retval));
}
@@ -2202,10 +2200,7 @@
errmsg("record \"%s\" is not assigned yet",
rec->refname),
errdetail("The tuple structure of a not-yet-assigned record is indeterminate.")));
- if (!compatible_tupdesc(tupdesc, rec->tupdesc))
- ereport(ERROR,
- (errcode(ERRCODE_DATATYPE_MISMATCH),
- errmsg("wrong record type supplied in RETURN NEXT")));
+ validate_tupdesc_compat(rec->tupdesc, tupdesc);
tuple = rec->tup;
}
break;
@@ -2311,10 +2306,7 @@
stmt->params);
}

- if (!compatible_tupdesc(estate->rettupdesc, portal->tupDesc))
- ereport(ERROR,
- (errcode(ERRCODE_DATATYPE_MISMATCH),
- errmsg("structure of query does not match function result type")));
+ validate_tupdesc_compat(portal->tupDesc, estate->rettupdesc);

while (true)
{
@@ -5138,23 +5130,32 @@
}

/*
- * Check two tupledescs have matching number and types of attributes
+ * Validates compatibility of supplied TupleDesc's by checking # and type of
+ * available arguments.
*/
-static bool
-compatible_tupdesc(TupleDesc td1, TupleDesc td2)
+static void
+validate_tupdesc_compat(TupleDesc td1, TupleDesc td2)
{
- int i;
+ int i;

if (td1->natts != td2->natts)
- return false;
+ ereport(ERROR,
+ (errcode(ERRCODE_DATATYPE_MISMATCH),
+ errmsg("Number of returned columns (%d) does not match "
+ "expected column count (%d).",
+ td1->natts, td2->natts)));

for (i = 0; i < td1->natts; i++)
- {
if (td1->attrs[i]->atttypid != td2->attrs[i]->atttypid)
- return false;
- }
-
- return true;
+ ereport(ERROR,
+ (errcode(ERRCODE_DATATYPE_MISMATCH),
+ errmsg("Returned record type (%s) does not match "
+ "expected record type (%s) in column %d (%s).",
+ format_type_with_typemod(td1->attrs[i]->atttypid,
+ td1->attrs[i]->atttypmod),
+ format_type_with_typemod(td2->attrs[i]->atttypid,
+ td2->attrs[i]->atttypmod),
+ (1+i), NameStr(td2->attrs[i]->attname))));
}

/* ----------
Hi,

Yesterday I needed to fiddle with PostgreSQL internals to be able to
debug a PL/pgSQL procedure returning a set of records. I attached the
patch I used to increase the verbosity of error messages related with
function return type checks. I'll be appreciated if any developer could
commit this patch (or a similar one) into the core.


Regards.

Re: [HACKERS] For what should pg_stop_backup wait?

On Fri, 2008-08-08 at 11:47 +0900, Fujii Masao wrote:
> On Thu, Aug 7, 2008 at 11:34 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> >

> In this situation, the history file (000000010000000000000004.00000020.backup)
> is behind the stoppoint (000000010000000000000004) in the alphabetic order.
> So, pg_stop_backup should wait for both the stoppoint and the history
> file, I think.

OK, I see that now.

>
> > ! while (!XLogArchiveCheckDone(stopxlogfilename, false))
>
> If a concurrent checkpoint removes the status file before XLogArchiveCheckDone,
> pg_stop_backup continues waiting forever. This is undesirable behavior.

I think it will only get removed by the second checkpoint, not the
first. So the risk of that happening seems almost certainly impossible.
But we'll put in a check just in case.

> Yes, statement_timeout may help. But, I don't want to use it, because the
> *successful* backup is canceled.
>
> How about checking whether the stoppoint was archived by comparing with
> the last WAL archived. The archiver process can tell the last WAL archived.
> Or, we can calculate it from the status file.

I think its easier to test whether the stopxlogfilename still exists in
pg_xlog. If not, we know it has been archived away. We can add that as
an extra condition inside the loop.

So thinking we should test XLogArchiveCheckDone() for both
stopxlogfilename and history file and then stat for the stop WAL file:

BackupHistoryFileName(histfilepath, ThisTimeLineID, _logId, _logSeg,
startpoint.xrecoff % XLogSegSize);

seconds_before_warning = 60;
waits = 0;

while (!XLogArchiveCheckDone(histfilepath, false) ||
!XLogArchiveCheckDone(stopxlogfilename, false))
{
struct stat stat_buf;
char xlogpath[MAXPGPATH];

/*
* Check to see if file has already been archived and WAL file
* removed by a concurrent checkpoint
*/
snprintf(xlogpath, MAXPGPATH, XLOGDIR "/%s", stopxlogfilename);
if (XLogArchiveCheckDone(histfilepath, false) &&
stat(xlogpath, &stat_buf) != 0)
break;

CHECK_FOR_INTERRUPTS();

pg_usleep(1000000L);

if (++waits >= seconds_before_warning)
{
seconds_before_warning *= 2; /* This wraps in >10 years... */
elog(WARNING, "pg_stop_backup() waiting for archive to complete "
"(%d seconds delay)", waits);
}
}


--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[pgsql-fr-generale] transfert encodage apostrophe typo

slt,

Je suis entrain de transférer mes bases de pg7.4 latin9 en pg8.3 utf8.
En règle général pg_dump suffit vu qu'il spécifie l'encodage de la
source. Très bien.

Par contre sur une base il y a eu des saisies venant d'utilisateurs mac
pointilleux, il y a donc des apostrophes typo et autre joyausetées.
Donc, bien que l'apostrophe typo n'existe pas en latin9, il y est quand
même enregistré (hex 92). Mais du coup à la conversion en utf8 il est
n'est pas transformé comme je le souhaiterai.

Est-ce que j'ai une solution sans passer par une appli maison de
conversion qui reprendrai chaque caractère un par un ?

Merci

--
William Dodé - http://flibuste.net
Informaticien Indépendant


--
Sent via pgsql-fr-generale mailing list (pgsql-fr-generale@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-fr-generale

[HACKERS] Oprofile with postgresql

Hi all:

      Recently i do a test of postgresql. To get more information of the functions in PostgreSQL, i use
 
opgprof and opannotate, which are two tools in Oprofile. But i can't work with the tools correctly.

PostgreSQL is compiled with -g option and the errors are like this:

 opgprof error: parse_filename() invalid filename: /var/lib/oprofile/samples/current/{root}/var/lib/oprofile/samples/current/{root}/home/ubuntu/tpcc-uva/bin/tm/{dep}/{anon:[vdso]}/7208.0x7fff7a972000.0x7fff7a974000/CPU_CLK_UNHALTED.90000.0.all.all.all/{dep}/{root}/var/lib/oprofile/samples/current/{root}/home/ubuntu/tpcc-uva/bin/tm/{dep}/{anon:[vdso]}/7208.0x7fff7a972000.0x7fff7a974000/CPU_CLK_UNHALTED.90000.0.all.all.all/{cg}/{root}/usr/bin/oprofiled/CPU_CLK_UNHALTED.90000.0.all.all.all

and opannotate

warning: [heap] (tgid:7302 range:0x8e7000-0xa18000) could not be found.
warning: [vdso] (tgid:7295 range:0x7fff3ddfe000-0x7fff3de00000) could not be found.
warning: [vdso] (tgid:7296 range:0x7fff3ddfe000-0x7fff3de00000) could not be found.
warning: [vdso] (tgid:7297 range:0x7fff3ddfe000-0x7fff3de00000) could not be found.
warning: [vdso] (tgid:7298 range:0x7fff3ddfe000-0x7fff3de00000) could not be found.
warning: [vdso] (tgid:7299 range:0x7fff3ddfe000-0x7fff3de00000) could not be found.
warning: [vdso] (tgid:7300 range:0x7fff3ddfe000-0x7fff3de00000) could not be found.
warning: [vdso] (tgid:7301 range:0x7fff3ddfe000-0x7fff3de00000) could not be found.
warning: [vdso] (tgid:7302 range:0x7fff3ddfe000-0x7fff3de00000) could not be found.
opannotate (warning): unable to open for reading: aset.c
opannotate (warning): unable to open for reading: heaptuple.c
opannotate (warning): unable to open for reading: bufmgr.c
opannotate (warning): unable to open for reading: execQual.c
opannotate (warning): unable to open for reading: list.c
opannotate (warning): unable to open for reading: nbtree.c
opannotate (warning): unable to open for reading: fmgr.c
opannotate (warning): unable to open for reading: catcache.c
opannotate (warning): unable to open for reading: nodeIndexscan.c
opannotate (warning): unable to open for reading: clauses.c
opannotate (warning): unable to open for reading: ri_triggers.c
opannotate (warning): unable to open for reading: lock.c
opannotate (warning): unable to open for reading: planner.c
opannotate (warning): unable to open for reading: selfuncs.c
opannotate (warning): unable to open for reading: postgres.c
opannotate (warning): unable to open for reading: trigger.c
...


if i want to use the two tools on PostgreSQL , what should i do?


                                                    Best wishes

                                                      Yyan

[COMMITTERS] pgbouncer - pgbouncer: allow first libevent test pass on 1.1

Log Message:
-----------
allow first libevent test pass on 1.1

Modified Files:
--------------
pgbouncer:
configure.ac (r1.42 -> r1.43)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgbouncer/pgbouncer/configure.ac.diff?r1=1.42&r2=1.43)

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] stackbuilder - wizard: Add support for detection of server installations

Log Message:
-----------
Add support for detection of server installations on Mac & Linux

Modified Files:
--------------
wizard:
IntroductionPage.cpp (r1.10 -> r1.11)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/stackbuilder/wizard/IntroductionPage.cpp.diff?r1=1.10&r2=1.11)

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] pgbouncer - pgbouncer: glibc requires use of _GNU_SOURCE

Log Message:
-----------
glibc requires use of _GNU_SOURCE

Modified Files:
--------------
pgbouncer/include:
system.h (r1.15 -> r1.16)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgbouncer/pgbouncer/include/system.h.diff?r1=1.15&r2=1.16)

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Re: [BUGS] BUG #4167: When generating UUID using UUID-OSSP module, UUIDs are not unique on Windows

Hi,

any progress on a fix for this bug?

Thanks,

Ismael Ciordia

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [HACKERS] patch: Add columns via CREATE OR REPLACE VIEW

> If you accept the idea that column identity should be based on column
> name, then the only two operations that are really necessary are
> "CREATE OR REPLACE VIEW" and "ALTER VIEW RENAME COLUMN", and it is
> 100% clear what the semantics of those operations should be.

+1

I think this would be an easily useable and understandable concept.
I also fully support Robert's reasoning in his next reply to Tom,
detailing why his patch's provided functionality is acceptable.

Andreas

PS: "alter view" in O does not change the base definition,
it only allows modifying view constraints.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[GENERAL] Re:[GENERAL] restoring one table?

Brian Maguire wrote:
> We need to restore one table from a backup. What is the proper way to do this?
>
> Our backup command looks like this:
>
> pg_dump -C -Fc -S postgresql mydatabase > today.backup.sqlc
>
> I am using PostgreSQL 8.1.
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>
>
>

Use the switch --table=NAME of pg_restore, i.e. something like this:

pg_restore -C -F c S postgresql -d mydatabase --table=your_table -v today.backup.sqlc

Tomas

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Re: [GENERAL] pg_restore fails on Windows

> Tom Tom wrote:
> > Hello,
> >
> > We have a very strange problem when restoring a database on Windows XP.
> > The PG version is 8.1.10
> > The backup was made with the pg_dump on the same machine.
> >
> > pg_restore -F c -h localhost -p 5432 -U postgres -d "configV3" -v
> "c:\Share\POSTGRES.backup"
> > pg_restore: connecting to database for restore
> > Password:
> > pg_restore: creating SCHEMA public
> > pg_restore: creating COMMENT SCHEMA public
> > pg_restore: creating PROCEDURAL LANGUAGE plpgsql
> > pg_restore: creating SEQUENCE hi_value
> > pg_restore: executing SEQUENCE SET hi_value
> > pg_restore: creating TABLE hibconfigelement
> > pg_restore: creating TABLE hibrefconfigbase
> > pg_restore: creating TABLE hibrefconfigreference
> > pg_restore: creating TABLE hibtableattachment
> > pg_restore: creating TABLE hibtableattachmentxmldata
> > pg_restore: creating TABLE hibtableelementversion
> > pg_restore: creating TABLE hibtableelementversionxmldata
> > pg_restore: creating TABLE hibtablerootelement
> > pg_restore: creating TABLE hibtablerootelementxmldata
> > pg_restore: creating TABLE hibtableunversionedelement
> > pg_restore: creating TABLE hibtableunversionedelementxmldata
> > pg_restore: creating TABLE hibtableversionedelement
> > pg_restore: creating TABLE hibtableversionedelementxmldata
> > pg_restore: creating TABLE versionedelement_history
> > pg_restore: creating TABLE versionedelement_refs
> > pg_restore: restoring data for table "hibconfigelement"
> > pg_restore: restoring data for table "hibrefconfigbase"
> > pg_restore: restoring data for table "hibrefconfigreference"
> > pg_restore: restoring data for table "hibtableattachment"
> > pg_restore: restoring data for table "hibtableattachmentxmldata"
> > pg_restore: [archiver (db)] could not execute query: no result from server
> > pg_restore: *** aborted because of error
> >
> > The restore unexpectedly fails on hibtableattachmentxmldata table, which is as
> follows:
> >
> > CREATE TABLE hibtablerootelementxmldata
> > (
> > xmldata_id varchar(255) NOT NULL,
> > xmldata text
> > )
> > WITHOUT OIDS;
> >
> > and contains thousands of rows with text field having even 40MB, encoded in
> UTF8.
> >
> > The database is created as follows:
> >
> > CREATE DATABASE "configV3"
> > WITH OWNER = postgres
> > ENCODING = 'UTF8'
> > TABLESPACE = pg_default;
> >
> >
> > The really strange is that the db restore runs OK on linux (tested on RHEL4,
> PG version 8.1.9).
> > The pg_restore output is _not_ very descriptive but I suspect some dependency
> on OS system libraries (encoding), or maybe it is also related to the size of
> the CLOB field. Anyway we are now effectively without any possibility to backup
> our database, which is VERY serious.
> >
> > Have you ever came across something similar to this?
>
> Check what you have in your server logs (pg_log directory) and the
> eventlog around this time. There is probably a better error message
> available there.
>
> //Magnus
>

Thank you for your hint.
The server logs does not display any errors, except for

2008-08-08 11:14:16 CEST LOG: checkpoints are occurring too frequently (14 seconds apart)
2008-08-08 11:14:16 CEST HINT: Consider increasing the configuration parameter "checkpoint_segments".
2008-08-08 11:14:38 CEST LOG: checkpoints are occurring too frequently (22 seconds apart)
2008-08-08 11:14:38 CEST HINT: Consider increasing the configuration parameter "checkpoint_segments".
2008-08-08 11:14:57 CEST LOG: checkpoints are occurring too frequently (19 seconds apart)
2008-08-08 11:14:57 CEST HINT: Consider increasing the configuration parameter "checkpoint_segments".
2008-08-08 11:15:14 CEST LOG: checkpoints are occurring too frequently (17 seconds apart)
2008-08-08 11:15:14 CEST HINT: Consider increasing the configuration parameter "checkpoint_segments".
2008-08-08 11:15:36 CEST LOG: checkpoints are occurring too frequently (22 seconds apart)
2008-08-08 11:15:36 CEST HINT: Consider increasing the configuration parameter "checkpoint_segments".
2008-08-08 11:15:56 CEST LOG: checkpoints are occurring too frequently (20 seconds apart)
2008-08-08 11:15:56 CEST HINT: Consider increasing the configuration parameter "checkpoint_segments".
2008-08-08 11:16:16 CEST LOG: checkpoints are occurring too frequently (20 seconds apart)
2008-08-08 11:16:16 CEST HINT: Consider increasing the configuration parameter "checkpoint_segments".

The warnings disappeared when the "checkpoint_segments" value was increased to 10. The restore still failed however :(
The Windows eventlogs show no errors, just informational messages about starting/stopping the pg service.

Tomas

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [HACKERS] Parsing of pg_hba.conf and authentication inconsistencies

Stephen Frost wrote:
> Magnus,
>
> * Magnus Hagander (magnus@hagander.net) wrote:
>> I thought of another issue with this. My "grand plan" includes being
>> able to do username mapping (per pg_ident.conf) for other authentication
>> methods than ident. Specifically this would be interesting for all
>> external methods, like gssapi/sspi/kerberos/ldap. I was originally
>> planning to allow each row in pg_hba to specify it's own pg_ident.conf
>> if necessary (so you could map LDAP and GSSAPI differently, for example,
>> or map two different kerberos realms differently). To be able to load
>> these, the postmaster would need to know about them, which means it'd
>> have to parse that data out anyway.
>
> I certainly like the concept of having them be in seperate files.
>
>> The other way to do that is to simply say that all external mapping will
>> use pg_ident.conf, and the only thing you can specify on a per-row basis
>> is "use map: yes or no". This decreases the flexibility, but would not
>> require the postmaster to do the parsing.
>
> I don't think it makes sense to have multiple different auth types using
> the same mappings... For Kerberos, as an example, we should support
> user@REALM as an option for the mapping, but that might not make sense
> for LDAP, which might have cn=User,ou=people,dc=example,dc=com, and
> neither of those really make sense for ident. Mashing all of those
> together would make each auth type supporting the mapping have to search
> through the list trying to make sense of some mappings and throwing away
> others, just ugly all around..

Yeah. I think the question there is just - how likely is it that the
same installation actually uses >1 authentication method. Personally, I
think it's not very uncommon at all, but fact remains that as long as
you only use one of them at a time, using a shared file doesn't matter.


>> What do people think about these? I know Stephen for example really want
>> that feature so - would that restriction make it a lot less useful for you?
>
> If we really wanted to keep it to a single *file*, then I think there
> should be a way to key rows in the pg_hba.conf to sets-of-rows in the
> mapping file. eg: have an option of 'mapkey=xyz' in pg_hba, and then
> 'xyz' as the first column of the mapping file, with it being repeated
> across rows to form that mapping table.

Yuck. Honestly, that seems even uglier :-)


> It wouldn't be very easy/clean to do that w/o breaking the existing
> structure of pg_ident though, which makes me feel like using seperate
> files is probably the way to go.

Yeah, thats my feeling as well. Now, can someone figure out a way to do
that without parsing the file in the postmaster? (And if we do parse it,
there's no point in not storing the parsed version, IMHO). And if not,
the question it comes down to is which is most important - keeping the
parsing away, or being able to do this ;-)


//Magnus

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [GENERAL] Initdb problem on debian mips cobalt: Bus error

>
> Okay, so it is indeed the linker's fault. Now try plan
> (a) --- can you
> find a more up-to-date toolchain?

Well I've tried looking in apt, and the latest package is the version I've got, (the toolchain is more than just gcc isn't it though?) is there another way to get a more up to date toolchain?

Here's what I'm running ont he qube;

glyn@deb:~$ gcc -v
Using built-in specs.
Target: mipsel-linux-gnu
Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --disable-libssp --enable-checking=release mipsel-linux-gnu
Thread model: posix
gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)

And heres what I have on the servers at work;

Way5a:/pgsql/logs# gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-checking=release x86_64-linux-gnu
Thread model: posix
gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)

Same version but different architectures.


__________________________________________________________
Not happy with your email address?.
Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[COMMITTERS] pgbouncer - pgbouncer: Change the makefile to use "$(MAKE)" instead of

Log Message:
-----------
Change the makefile to use "$(MAKE)" instead of "make".

Patch from Jørgen Austvik

Modified Files:
--------------
pgbouncer:
Makefile (r1.23 -> r1.24)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgbouncer/pgbouncer/Makefile.diff?r1=1.23&r2=1.24)

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[pgsql-in-general] Need info on installer

Hi,
Greetings
 
We have developed a software which uses PostgreSQL as well. We are planning to package PostgreSQL along with our software.
Could you send details about creating the PostgreSQL installer? any script?
 
I hope you are using windows instsller to create the postgresql installer. I would like to know how to set the pre-configuration details as you are doing now.
 
It would be great if you reply at the earliest.
 
Thanks
Ram 

Re: [PERFORM] Restoration of datas

dforums wrote:
> COuld you advice me on which restoration method is the faster. To
> upgrade from postgresql 8.1.11 to 8.3.3.

Using the pg_dump from your 8.3 package, dump the database using -Fc to
get a nicely compressed dump. Then use pg_restore to restore it. If you
add a --verbose flag then you will be able to track it.

You might want to set fsync=off while doing the restore. This is safe
since if the machine crashes during restore you just start again. Oh,
and increase work_mem too - there's only going to be one process.

What will take the most time is the creating of indexes etc.

It will take a long time to do a full restore though - you've got 64GB
of data and slow disks.

--
Richard Huxton
Archonet Ltd

--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

Re: [NOVICE] Calling an external command via triggers

am Fri, dem 08.08.2008, um 14:22:43 +0800 mailte Ridvan Lakas ng Bayan S. Baluyos folgendes:
> Hi All,
>
> Is it possible for me to call a certain command in the terminal via a trigger?

Not really. You should better use LISTEN/NOTIFY.
>
> Say for example, after every INSERT in a certain table, I would be calling a
> script `php load.php` ?

What happens if the 'load.php' fails? Rollback the insert?


Andreas
--
Andreas Kretschmer
Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: -> Header)
GnuPG-ID: 0x3FFF606C, privat 0x7F4584DA http://wwwkeys.de.pgp.net

--
Sent via pgsql-novice mailing list (pgsql-novice@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-novice

[PERFORM] Restoration of datas

Hello

Regarding the advice from all, and the performance of postgresql 8.3.3

I'm trying to change the server and to upgrade to 8.3.3

I install postgresql 8.3.3 on a new server for testing. All well!!!

And I run a \i mybackup.sql since yesterday 7pm. This morning the datas
are not insert yet.

COuld you advice me on which restoration method is the faster. To
upgrade from postgresql 8.1.11 to 8.3.3.

Regards

David

--
<http://www.1st-affiliation.fr>

*David Bigand
*Président Directeur Générale*
*51 chemin des moulins
73000 CHAMBERY - FRANCE

Web : htttp://www.1st-affiliation.fr
Email : david@1st-affiliation.com
Tel. : +33 479 696 685
Mob. : +33 666 583 836
Skype : firstaffiliation_support


--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance