Re: [HACKERS] small parallel restore optimization
On Fri, 6 Mar 2009, Guillaume Smet wrote: Date: Fri, 6 Mar 2009 18:58:58 +0100 From: Guillaume Smet To: Tom Lane Cc: Andrew Dunstan , PostgreSQL-development , o...@pyrenet.fr Subject: Re: [HACKERS] small parallel restore optimization On Fri, Mar 6, 2009 at 6:20 PM, Tom Lane wrote: Can you put together even a weakly reproducible test case? Something that only fails every tenth or hundredth time would still help. not sure, none of my tests did fail at the same place. the only thing I could come with is a calloc(1,12) that seems to alloc mem for filename, in that case sdewitte.dmp; so the alloc is not counting the null char at the end. not sure it could explain everything though > It seems that Olivier can reproduce the problem at will on Unixware. I don't know if it's easy to find useful information to debug the problem on this platform though. See http://archives.postgresql.org/pgsql-hackers/2009-03/msg00201.php -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: o...@pyrenet.fr -- Make your life a dream, make your dream a reality. (St Exupery) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_restore -m failing
On Tue, 3 Mar 2009, Andrew Dunstan wrote: Date: Tue, 03 Mar 2009 11:02:35 -0500 From: Andrew Dunstan To: o...@pyrenet.fr Cc: pgsql-hackers list Subject: Re: [HACKERS] pg_restore -m failing o...@pyrenet.fr wrote: hi all, After Andrew corrected the bug I found on pg_restore (-C -m misbehaving one with the other), I played again yesterday. before the end of restore, I get this : pg_restore: launching item 4202 INDEX idx_typeper_actif pg_restore: [custom archiver] could not close archive file: Argument incorrect pg_restore: *** aborted because of error pg_restore: finished item 4202 INDEX idx_typeper_actif pg_restore: [archiver] worker process failed: exit code 1 pg_restore: *** aborted because of error Any idea? this is on unixware That seems very strange. Is it repeatable. it is on unixware 100% of the time, not on linux. I wonder what theincorrect argument was? my guess would be the file desc. Maybe the memory got clobbered somewhere. probably, but I could'nt proove it. Actually, while thinking about this it occurred to me that we are probably wasting a few cycles reopening the archive where we don't need to - it should only be necessary where we are restoring a data member, ISTM. I'll look at that further. take your time! cheers andrew regards -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: o...@pyrenet.fr -- Make your life a dream, make your dream a reality. (St Exupery) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] pg_restore -m failing
hi all, After Andrew corrected the bug I found on pg_restore (-C -m misbehaving one with the other), I played again yesterday. before the end of restore, I get this : pg_restore: launching item 4202 INDEX idx_typeper_actif pg_restore: [custom archiver] could not close archive file: Argument incorrect pg_restore: *** aborted because of error pg_restore: finished item 4202 INDEX idx_typeper_actif pg_restore: [archiver] worker process failed: exit code 1 pg_restore: *** aborted because of error Any idea? this is on unixware -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: o...@pyrenet.fr -- Make your life a dream, make your dream a reality. (St Exupery) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_restore new option -m
On Thu, 19 Feb 2009, Andrew Dunstan wrote: Date: Thu, 19 Feb 2009 21:58:18 -0500 From: Andrew Dunstan To: Tom Lane Cc: o...@pyrenet.fr, pgsql-hackers list Subject: Re: [HACKERS] pg_restore new option -m Tom Lane wrote: o...@pyrenet.fr writes: pg_restore -C -m 4 -d template1 db.dmp gives numerous errors, mostly no such relation at index creation time. You sure you don't get exactly the same without -m? Yeah, I have reproduced this. It's because we reconnect to the wrong db in this case (i.e. to the -d database, not the created one) in the workers and subsequent connects. I've applied a trivial patch to fix it. works like a charm! cheers andrew thanks -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: o...@pyrenet.fr -- Make your life a dream, make your dream a reality. (St Exupery) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_restore new option -m
On Thu, 19 Feb 2009, Tom Lane wrote: Date: Thu, 19 Feb 2009 10:05:32 -0500 From: Tom Lane To: o...@pyrenet.fr Cc: pgsql-hackers list Subject: Re: [HACKERS] pg_restore new option -m o...@pyrenet.fr writes: On Wed, 18 Feb 2009, Tom Lane wrote: You sure you don't get exactly the same without -m? yes! We're going to need to see the test case then. regards, tom lane they were included in the last mail :) -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: o...@pyrenet.fr -- Make your life a dream, make your dream a reality. (St Exupery) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] pg_restore new option -m
hi, i've been testing new -m option of pg_restore with great pleasure. first, let me thank the developpers, it cut restoring time by half. is it normal that -m doesn't cope well with -C? createdb db pg_restore -m 4 -d db db.dmp works like a charm while pg_restore -C -m 4 -d template1 db.dmp gives numerous errors, mostly no such relation at index creation time. TIA -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: o...@pyrenet.fr -- Make your life a dream, make your dream a reality. (St Exupery) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] cvs head initdb hangs on unixware
Tom, On Wed, 10 Dec 2008, Tom Lane wrote: Date: Wed, 10 Dec 2008 12:17:18 -0500 From: Tom Lane To: o...@pyrenet.fr Cc: Heikki Linnakangas , Zdenek Kotala , pgsql-hackers list Subject: Re: [HACKERS] cvs head initdb hangs on unixware o...@pyrenet.fr writes: On Wed, 10 Dec 2008, Heikki Linnakangas wrote: BTW, why does this work on warthog buildfarm member? Different compiler version? it's configured with --enable-debug. Maybe run_build.pl should run twice, onece with --enable-debug once without. No, the standard way to deal with such issues is to set up two buildfarm members. This would be a 100% waste of cycles for gcc-based members anyway, since gcc generates the same code with or without -g. However, for compilers where it makes a difference, it might well be worth having an additional member to test the optimized build. regards, tom lane I understand your concern. Maybe an option --flip-debug that would not be used by gcc owners could help having both tests in 1 run. In the mean time, while preparing my home unixware server to become an other animal, I came on a new optimizer bug in ecpg. To not pollute this close thread, I start a new one. -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: o...@pyrenet.fr -- Make your life a dream, make your dream a reality. (St Exupery) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] cvs head initdb hangs on unixware
On Wed, 10 Dec 2008, Heikki Linnakangas wrote: Date: Wed, 10 Dec 2008 13:00:31 +0200 From: Heikki Linnakangas <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: Tom Lane <[EMAIL PROTECTED]>, Zdenek Kotala <[EMAIL PROTECTED]>, pgsql-hackers list Subject: Re: [HACKERS] cvs head initdb hangs on unixware [EMAIL PROTECTED] wrote: On Tue, 9 Dec 2008, Tom Lane wrote: Hmm. It looks to me like the compiler is getting confused by the interaction between nodeno, leftnodeno, and rightnodeno. Try this patch to see if it gets around it. (This is a tad better anyway since it avoids examining the right child if not needed.) Brillant! You made my day, can't wait for this patch to be committed. I find it pretty scary to work around compiler bugs like this. Who knows what other code it miscompiles. Can you reduce fsm_search_avail into a small stand-alone test program, and file a bug report with the compiler vendor? FWIW, the compiler doesn't miscompîle anything on postgresql, as an heavy user/hoster, I'd know! Let's not start a flame here, SCO compiler is as good or as bad as anyother.. Never saw a problem with gcc, hp-ux, darwin or M$? BTW, why does this work on warthog buildfarm member? Different compiler version? it's configured with --enable-debug. Maybe run_build.pl should run twice, onece with --enable-debug once without. -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] cvs head initdb hangs on unixware
Dear Tom, On Tue, 9 Dec 2008, Tom Lane wrote: Date: Tue, 09 Dec 2008 13:24:21 -0500 From: Tom Lane <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: Zdenek Kotala <[EMAIL PROTECTED]>, Heikki Linnakangas <[EMAIL PROTECTED]>, pgsql-hackers list Subject: Re: [HACKERS] cvs head initdb hangs on unixware [EMAIL PROTECTED] writes: FWIW, I have attached the 2 generated .s. Someone with knowledge of asm may want to have a look.. Hmm. It looks to me like the compiler is getting confused by the interaction between nodeno, leftnodeno, and rightnodeno. Try this patch to see if it gets around it. (This is a tad better anyway since it avoids examining the right child if not needed.) regards, tom lane Brillant! You made my day, can't wait for this patch to be committed. Thanks!!! PS: I wish I had 10% of your knowledge/genius! -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] cvs head initdb hangs on unixware
On Tue, 9 Dec 2008, Tom Lane wrote: Date: Tue, 09 Dec 2008 09:23:06 -0500 From: Tom Lane <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: Heikki Linnakangas <[EMAIL PROTECTED]>, Zdenek Kotala <[EMAIL PROTECTED]>, pgsql-hackers list Subject: Re: [HACKERS] cvs head initdb hangs on unixware [EMAIL PROTECTED] writes: Guess what! with the fprintf .. descending node... in place, everything goes well. The optimizer definitly does something weird along the definition/assignement of leftok/rightok.. Hmm, so the problem is in that second loop. The trick is to pick some reasonably non-ugly code change that makes the problem go away. The first thing I'd try is to get rid of the overly cute optimization int rightnodeno = leftnodeno + 1; and make it just read int rightnodeno = rightchild(nodeno); If that doesn't work, we might try refactoring the code enough to get rid of the goto, but that looks a little bit tedious. regards, tom lane I tried that and moving leftok,rightok declaration outside the loop, and refactor the assignement code of leftok, rightok . nothing worked! Regards, -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] cvs head initdb hangs on unixware
Hi Tom,
On Mon, 8 Dec 2008, Tom Lane wrote:
Date: Mon, 08 Dec 2008 13:15:28 -0500
From: Tom Lane <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: Heikki Linnakangas <[EMAIL PROTECTED]>,
Zdenek Kotala <[EMAIL PROTECTED]>,
pgsql-hackers list
Subject: Re: [HACKERS] cvs head initdb hangs on unixware
[EMAIL PROTECTED] writes:
the infinite loop occurs in fsm_search_avail when called for the 32nd
time.
... which is the first time that the initial test doesn't make it fall
out immediately.
Would you add a couple more printouts, along the line of
nodeno = target;
while (nodeno > 0)
{
+ fprintf(stderr, "ascend at node %d value %d\n",
+ nodeno, fsmpage->fp_nodes[nodeno]);
if (fsmpage->fp_nodes[nodeno] >= minvalue)
break;
/*
* Move to the right, wrapping around on same level if
necessary,
* then climb up.
*/
nodeno = parentof(rightneighbor(nodeno));
}
/*
* We're now at a node with enough free space, somewhere in the middle
of
* the tree. Descend to the bottom, following a path with enough free
* space, preferring to move left if there's a choice.
*/
while (nodeno < NonLeafNodesPerPage)
{
int leftnodeno = leftchild(nodeno);
int rightnodeno = leftnodeno + 1;
bool leftok = (leftnodeno < NodesPerPage) &&
(fsmpage->fp_nodes[leftnodeno] >= minvalue);
bool rightok = (rightnodeno < NodesPerPage) &&
(fsmpage->fp_nodes[rightnodeno] >= minvalue);
+ fprintf(stderr, "descend at node %d value %d, leftnode %d value %d,
rightnode %d value %d\n",
+ nodeno, fsmpage->fp_nodes[nodeno],
+ leftnodeno, fsmpage->fp_nodes[leftnodeno],
+ rightnodeno, fsmpage->fp_nodes[rightnodeno]);
if (leftok)
nodeno = leftnodeno;
else if (rightok)
nodeno = rightnodeno;
else
(I'm assuming we can print possibly-off-the-end array elements without dumping
core; which is bogus in general but I expect we can get away with it
for this purpose.)
Also, we don't really need 94MB of log to convince us it's an
infinite loop ;-)
oops, sorry
regards, tom lane
I first misread your mail, and added only the first fprintf , while I was
uploading a 400M initdb.log, I went back to add the second one.
Guess what! with the fprintf .. descending node... in place, everything
goes well. The optimizer definitly does something weird along the
definition/assignement of leftok/rightok..
--
Olivier PRENANT Tel: +33-5-61-50-97-00 (Work)
15, Chemin des Monges+33-5-61-50-97-01 (Fax)
31190 AUTERIVE +33-6-07-63-80-64 (GSM)
FRANCE Email: [EMAIL PROTECTED]
--
Make your life a dream, make your dream a reality. (St Exupery)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] cvs head initdb hangs on unixware
Dear all, On Mon, 8 Dec 2008, Heikki Linnakangas wrote: Date: Mon, 08 Dec 2008 09:17:52 +0200 From: Heikki Linnakangas <[EMAIL PROTECTED]> To: Tom Lane <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED], Zdenek Kotala <[EMAIL PROTECTED]>, pgsql-hackers list Subject: Re: [HACKERS] cvs head initdb hangs on unixware Tom Lane wrote: [EMAIL PROTECTED] writes: As you can see in attached initdb.log, it seems fsm_search_avail is called repeatedly and args are sort of looping... That's expected, since the system is inserting a lot of tuples successively. Right. I suspect it was in the infinite loop yet. Try to run it for *much* longer (it'll probably take much longer than usual because it's printing all the debug stuff), until it gets stuck looping over the same pages in same relation. the infinite loop occurs in fsm_search_avail when called for the 32nd time. It loops between restart: and goto restart the long (95M) initdb.log can be found at ftp://ftp.pyrenet.fr/private/initdb.log regards, -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] cvs head initdb hangs on unixware
On Thu, 4 Dec 2008, Heikki Linnakangas wrote: Date: Thu, 04 Dec 2008 13:19:15 +0200 From: Heikki Linnakangas <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: Zdenek Kotala <[EMAIL PROTECTED]>, pgsql-hackers list Subject: Re: [HACKERS] cvs head initdb hangs on unixware [EMAIL PROTECTED] wrote: On Wed, 3 Dec 2008, Heikki Linnakangas wrote: Could you zip up the FSM file of that relation (a file called e.g "789_fsm"), and send it over? Or the whole data directory, it shouldn't be that big. you get both. Thanks. Hmm, the FSM pages are full of zeros, as I would expect for a just-created relation. fsm_search_avail should've returned quickly at the top of the function in that case. Can you put a extra printf or something at the top of the function, to print all the arguments? And the value of fsmpage->fp_nodes[0]. BTW, this is an optimizer problem, not anything wrong with the code, but I'd hate to have a -g compiled postmaster in prod :) Yes, so it seems, although I wouldn't be surprised if it turns out to be a bug in the new FSM code either.. As you can see in attached initdb.log, it seems fsm_search_avail is called repeatedly and args are sort of looping... -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery)Running in noclean mode. Mistakes will not be cleaned up. The files belonging to this database system will be owned by user "postgres". This user must also own the server process. The database cluster will be initialized with locale C. The default database encoding has accordingly been set to SQL_ASCII. The default text search configuration will be set to "english". creating directory /home/postgres/pgsql/src/test/regress/./tmp_check/data ... ok creating subdirectories ... ok selecting default max_connections ... 100 selecting default shared_buffers ... 32MB creating configuration files ... ok creating template1 database in /home/postgres/pgsql/src/test/regress/./tmp_check/data/base/1 ... entering fsm_search_avail, minvalue = 6, advancenext = t, exclusive_lock_held =t,fsmpage->fp_nodes[0] = 4 entering fsm_search_avail, minvalue = 6, advancenext = f, exclusive_lock_held =f,fsmpage->fp_nodes[0] = 0 entering fsm_search_avail, minvalue = 6, advancenext = f, exclusive_lock_held =f,fsmpage->fp_nodes[0] = 0 entering fsm_search_avail, minvalue = 6, advancenext = t, exclusive_lock_held =t,fsmpage->fp_nodes[0] = 4 entering fsm_search_avail, minvalue = 6, advancenext = f, exclusive_lock_held =f,fsmpage->fp_nodes[0] = 0 entering fsm_search_avail, minvalue = 6, advancenext = t, exclusive_lock_held =t,fsmpage->fp_nodes[0] = 4 entering fsm_search_avail, minvalue = 6, advancenext = f, exclusive_lock_held =f,fsmpage->fp_nodes[0] = 0 entering fsm_search_avail, minvalue = 6, advancenext = t, exclusive_lock_held =t,fsmpage->fp_nodes[0] = 4 entering fsm_search_avail, minvalue = 6, advancenext = f, exclusive_lock_held =f,fsmpage->fp_nodes[0] = 0 entering fsm_search_avail, minvalue = 6, advancenext = t, exclusive_lock_held =t,fsmpage->fp_nodes[0] = 4 entering fsm_search_avail, minvalue = 6, advancenext = f, exclusive_lock_held =f,fsmpage->fp_nodes[0] = 0 entering fsm_search_avail, minvalue = 6, advancenext = t, exclusive_lock_held =t,fsmpage->fp_nodes[0] = 4 entering fsm_search_avail, minvalue = 6, advancenext = f, exclusive_lock_held =f,fsmpage->fp_nodes[0] = 0 entering fsm_search_avail, minvalue = 6, advancenext = t, exclusive_lock_held =t,fsmpage->fp_nodes[0] = 4 entering fsm_search_avail, minvalue = 6, advancenext = f, exclusive_lock_held =f,fsmpage->fp_nodes[0] = 0 entering fsm_search_avail, minvalue = 6, advancenext = t, exclusive_lock_held =t,fsmpage->fp_nodes[0] = 4 entering fsm_search_avail, minvalue = 6, advancenext = f, exclusive_lock_held =f,fsmpage->fp_nodes[0] = 0 entering fsm_search_avail, minvalue = 6, advancenext = t, exclusive_lock_held =t,fsmpage->fp_nodes[0] = 4 entering fsm_search_avail, minvalue = 6, advancenext = f, exclusive_lock_held =f,fsmpage->fp_nodes[0] = 0 entering fsm_search_avail, minvalue = 6, advancenext = t, exclusive_lock_held =t,fsmpage->fp_nodes[0] = 4 entering fsm_search_avail, minvalue = 6, advancenext = f, exclusive_lock_held =f,fsmpage->fp_nodes[0] = 0 entering fsm_search_avail, minvalue = 6, advancenext = t, exclusive_lock_held =t,fsmpage->fp_nodes[0] = 4 entering fsm_search_avail, minvalue = 6, advancenext = f, exclusive_lock_held =f,fsmpage->fp_nodes[0] = 0 entering fsm_search_avail, minvalue = 6, advancenext = t, exclusive_lock_held =t,fsmpage->fp_nodes[0] = 4 entering fsm_search_avail, minvalue = 6, advancenext = f, exclusive_lock_held =f,fsmpage->fp_nodes[0] = 0 enteri
Re: [HACKERS] cvs head initdb hangs on unixware
On Wed, 3 Dec 2008, Heikki Linnakangas wrote: Date: Wed, 03 Dec 2008 20:29:01 +0200 From: Heikki Linnakangas <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: Zdenek Kotala <[EMAIL PROTECTED]>, pgsql-hackers list Subject: Re: [HACKERS] cvs head initdb hangs on unixware [EMAIL PROTECTED] wrote: On Tue, 2 Dec 2008, Heikki Linnakangas wrote: Date: Tue, 02 Dec 2008 20:47:19 +0200 From: Heikki Linnakangas <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: Zdenek Kotala <[EMAIL PROTECTED]>, pgsql-hackers list Subject: Re: [HACKERS] cvs head initdb hangs on unixware [EMAIL PROTECTED] wrote: Suivi de pile correspondant à p1, Programme postmaster *[0] fsm_rebuild_page( présumé: 0xbd9731a0, 0, 0xbd9731a0) [0x81e6a97] [1] fsm_search_avail( présumé: 0x2, 0x6, 0x1) [0x81e68d9] [2] fsm_set_and_search(0x84b2250, 0, 0, 0x2e, 0x5, 0x6, 0x2e, 0x8047416, 0xb4) [0x81e6385] [3] RecordAndGetPageWithFreeSpace(0x84b2250, 0x2e, 0xa0, 0xb4) [0x81e5a00] [4] RelationGetBufferForTuple( présumé: 0x84b2250, 0xb4, 0) [0x8099b59] [5] heap_insert(0x84b2250, 0x853a338, 0, 0, 0) [0x8097042] [6] simple_heap_insert( présumé: 0x84b2250, 0x853a338, 0x853a310) [0x8097297] [7] InsertOneTuple( présumé: 0xb80, 0x84057b0, 0x8452fb8) [0x80cb210] [8] boot_yyparse( présumé: 0x, 0x3, 0x8047ab8) [0x80c822b] [9] BootstrapModeMain( présumé: 0x66, 0x8454600, 0x4) [0x80ca233] [10] AuxiliaryProcessMain(0x4, 0x8047ab4) [0x80cab3b] [11] main(0x4, 0x8047ab4, 0x8047ac8) [0x8177dce] [12] _start() [0x807ff96] seems interesting! We've had problems already with unixware optimizer, hope this one is fixable! Looking at fsm_rebuild_page, I wonder if the compiler is treating "int" as an unsigned integer? That would cause an infinite loop. No, a simple printf of nodeno shows it starting at 4096 all the way down to 0, starting back at 4096... Hmm, it's probably looping in fsm_search_avail then. In a fresh cluster, there shouldn't be any broken FSM pages that need rebuilding. You're right! I'd like to see what the FSM page in question looks like. Could you try to run initdb with "-d -n" options? I bet you'll get an infinite number of lines like: DEBUG: fixing corrupt FSM block 1, relation 123/456/789 right again! DEBUG: fixing corrupt FSM block 2, relation 1663/1/1255 Could you zip up the FSM file of that relation (a file called e.g "789_fsm"), and send it over? Or the whole data directory, it shouldn't be that big. you get both. BTW, this is an optimizer problem, not anything wrong with the code, but I'd hate to have a -g compiled postmaster in prod :) best regards, -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) 1255_fsm Description: fsm db.tgz Description: data dir -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] cvs head initdb hangs on unixware
On Tue, 2 Dec 2008, Heikki Linnakangas wrote: Date: Tue, 02 Dec 2008 20:47:19 +0200 From: Heikki Linnakangas <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: Zdenek Kotala <[EMAIL PROTECTED]>, pgsql-hackers list Subject: Re: [HACKERS] cvs head initdb hangs on unixware [EMAIL PROTECTED] wrote: Suivi de pile correspondant à p1, Programme postmaster *[0] fsm_rebuild_page( présumé: 0xbd9731a0, 0, 0xbd9731a0) [0x81e6a97] [1] fsm_search_avail( présumé: 0x2, 0x6, 0x1) [0x81e68d9] [2] fsm_set_and_search(0x84b2250, 0, 0, 0x2e, 0x5, 0x6, 0x2e, 0x8047416, 0xb4) [0x81e6385] [3] RecordAndGetPageWithFreeSpace(0x84b2250, 0x2e, 0xa0, 0xb4) [0x81e5a00] [4] RelationGetBufferForTuple( présumé: 0x84b2250, 0xb4, 0) [0x8099b59] [5] heap_insert(0x84b2250, 0x853a338, 0, 0, 0) [0x8097042] [6] simple_heap_insert( présumé: 0x84b2250, 0x853a338, 0x853a310) [0x8097297] [7] InsertOneTuple( présumé: 0xb80, 0x84057b0, 0x8452fb8) [0x80cb210] [8] boot_yyparse( présumé: 0x, 0x3, 0x8047ab8) [0x80c822b] [9] BootstrapModeMain( présumé: 0x66, 0x8454600, 0x4) [0x80ca233] [10] AuxiliaryProcessMain(0x4, 0x8047ab4) [0x80cab3b] [11] main(0x4, 0x8047ab4, 0x8047ac8) [0x8177dce] [12] _start() [0x807ff96] seems interesting! We've had problems already with unixware optimizer, hope this one is fixable! Looking at fsm_rebuild_page, I wonder if the compiler is treating "int" as an unsigned integer? That would cause an infinite loop. No, a simple printf of nodeno shows it starting at 4096 all the way down to 0, starting back at 4096... I wonder if leftchild/rightchild definitions has something to do with it... -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] cvs head initdb hangs on unixware
On Tue, 2 Dec 2008, Zdenek Kotala wrote: Date: Tue, 02 Dec 2008 17:22:25 +0100 From: Zdenek Kotala <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: pgsql-hackers list Subject: Re: [HACKERS] cvs head initdb hangs on unixware Could you generate a core and send a stacktrace? kill SIGABRT should do that. Zdenek Zdenek, On second thought, I tried and got that: Suivi de pile correspondant à p1, Programme postmaster *[0] fsm_rebuild_page( présumé: 0xbd9731a0, 0, 0xbd9731a0) [0x81e6a97] [1] fsm_search_avail( présumé: 0x2, 0x6, 0x1) [0x81e68d9] [2] fsm_set_and_search(0x84b2250, 0, 0, 0x2e, 0x5, 0x6, 0x2e, 0x8047416, 0xb4) [0x81e6385] [3] RecordAndGetPageWithFreeSpace(0x84b2250, 0x2e, 0xa0, 0xb4) [0x81e5a00] [4] RelationGetBufferForTuple( présumé: 0x84b2250, 0xb4, 0) [0x8099b59] [5] heap_insert(0x84b2250, 0x853a338, 0, 0, 0) [0x8097042] [6] simple_heap_insert( présumé: 0x84b2250, 0x853a338, 0x853a310) [0x8097297] [7] InsertOneTuple( présumé: 0xb80, 0x84057b0, 0x8452fb8) [0x80cb210] [8] boot_yyparse( présumé: 0x, 0x3, 0x8047ab8) [0x80c822b] [9] BootstrapModeMain( présumé: 0x66, 0x8454600, 0x4) [0x80ca233] [10] AuxiliaryProcessMain(0x4, 0x8047ab4) [0x80cab3b] [11] main(0x4, 0x8047ab4, 0x8047ac8) [0x8177dce] [12] _start() [0x807ff96] seems interesting! We've had problems already with unixware optimizer, hope this one is fixable! regards [EMAIL PROTECTED] napsal(a): Hi all, cvs head configured without --enable-debug hang in initdb while making check. warthog doesn't exhibit it because it's configured with debug. when it hangs, postmaster takes 100% cpu doing nothing. initdb waits for it while creating template db. According to truss, the last usefull thing postmaster does is writing 8K zeroes to disk. If someone needs an access to a unixware machine, let me know. regards, -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] cvs head initdb hangs on unixware
On Tue, 2 Dec 2008, Zdenek Kotala wrote: Date: Tue, 02 Dec 2008 17:22:25 +0100 From: Zdenek Kotala <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: pgsql-hackers list Subject: Re: [HACKERS] cvs head initdb hangs on unixware Could you generate a core and send a stacktrace? kill SIGABRT should do that. Zdenek Hmm. No point doing it, it's not debug enabled, I'm afraid stack trace won't show us anything usefull. [EMAIL PROTECTED] napsal(a): Hi all, cvs head configured without --enable-debug hang in initdb while making check. warthog doesn't exhibit it because it's configured with debug. when it hangs, postmaster takes 100% cpu doing nothing. initdb waits for it while creating template db. According to truss, the last usefull thing postmaster does is writing 8K zeroes to disk. If someone needs an access to a unixware machine, let me know. regards, -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] cvs head initdb hangs on unixware
Hi all, cvs head configured without --enable-debug hang in initdb while making check. warthog doesn't exhibit it because it's configured with debug. when it hangs, postmaster takes 100% cpu doing nothing. initdb waits for it while creating template db. According to truss, the last usefull thing postmaster does is writing 8K zeroes to disk. If someone needs an access to a unixware machine, let me know. regards, -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] -DCLOBBER_CACHE_ALWAYS build takes far longer than before
On Sun, 20 Apr 2008, Guillaume Smet wrote: > Date: Sun, 20 Apr 2008 16:23:47 +0200 > From: Guillaume Smet <[EMAIL PROTECTED]> > To: pgsql-hackers list , [EMAIL PROTECTED] > Subject: -DCLOBBER_CACHE_ALWAYS build takes far longer than before > > Hi all, > > While working on our network problems to send the full build result to > the buildfarm server, I just saw that a full buildfarm run with > -DCLOBBER_CACHE_ALWAYS option takes nearly 2 hours more than before > (from ~ 5h40 to 7h30). > > This phenomenon has started with this run: > http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=pigeon&dt=2008-04-12%2008:00:02 > > which has taken into account these commits: > pgsql/README 1.35 > pgsql/contrib/ltree/ltree_io.c 1.15 > pgsql/src/backend/parser/parse_type.c 1.95 > pgsql/src/backend/utils/adt/tsquery.c 1.17 > pgsql/src/backend/utils/adt/arrayfuncs.c 1.143 > pgsql/src/backend/utils/adt/geo_ops.c 1.100 > pgsql/src/backend/utils/mmgr/aset.c 1.77 > pgsql/src/port/dirmod.c 1.53 > pgsql/src/include/pg_config_manual.h 1.31 > pgsql/src/include/port.h 1.120 > pgsql/doc/TODO 1.2415 > pgsql/doc/src/FAQ/TODO.html 1.921 > > The additional time is spread like this: > make check: 40 minutes > make installcheck: 34 minutes > make contrib installcheck: 10 minutes > > I don't know if it's normal or not but I thought it's worth > mentioning. The standard build run on the same box isn't affected. > > Olivier, do you have the same behaviour with jaguar? > > Yes I do! -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jaguar is failing
On Sun, 30 Mar 2008, Tom Lane wrote: > Date: Sun, 30 Mar 2008 23:36:24 -0400 > From: Tom Lane <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED], pgsql-hackers list > Subject: Re: [HACKERS] jaguar is failing > > I wrote: > > [EMAIL PROTECTED] writes: > >> The only diff is that jaguar is compiling with -DCLOBBER_CACHE_ALWAYS > >> Is that related? > > > Hmm, that might be the needed clue --- thanks for the reminder. > > Yup, that was it --- was able to duplicate the problem with > -DCLOBBER_CACHE_ALWAYS. So I think jaguar's efforts already paid > for themselves ... > > regards, tom lane > Great! Did you commit a patch already, do you want me to rerun the build? -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jaguar is failing
On Sun, 30 Mar 2008, Tom Lane wrote: > Date: Sun, 30 Mar 2008 15:37:51 -0400 > From: Tom Lane <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Cc: pgsql-hackers list > Subject: Re: [HACKERS] jaguar is failing > > [EMAIL PROTECTED] writes: > > As you can see here: > > http://www.pgbuildfarm.org/cgi-bin/show_history.pl?nm=jaguar&br=HEAD > > Jaguar has been failing for two days while centaur is ok. > > I asked you to look into that yesterday > http://archives.postgresql.org/pgsql-hackers/2008-03/msg01216.php I saw it thid moring in the digest > > The copy of that mail that went directly to you bounced, with an error > suggesting that your mail filtering setup has been broken for more > than a year (you're depending on a blacklist server that ceased > service in Dec 2006). If you want, I'll post the bounce I expect > to get from this. > Found the gulty and fired him :) > > The only diff is that jaguar is compiling with -DCLOBBER_CACHE_ALWAYS > > Is that related? > > Hmm, that might be the needed clue --- thanks for the reminder. > > regards, tom lane > -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] jaguar is failing
As you can see here: http://www.pgbuildfarm.org/cgi-bin/show_history.pl?nm=jaguar&br=HEAD Jaguar has been failing for two days while centaur is ok. The only diff is that jaguar is compiling with -DCLOBBER_CACHE_ALWAYS Is that related? Thought you should know. Regards -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] postgresql.org dns problems
Hi All, Is it me or none of the mirror names can be resolved? ftp.fr.postgresql.org host unknown ftp.fr4.postgresql.org host unknown Regards -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] sun to buy mysql
On Sat, 19 Jan 2008, Jonah H. Harris wrote: > Date: Sat, 19 Jan 2008 10:22:13 -0500 > From: Jonah H. Harris <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Cc: pgsql-hackers list > Subject: Re: [HACKERS] sun to buy mysql > > On Jan 19, 2008 10:01 AM, <[EMAIL PROTECTED]> wrote: > > I'm surprised no one mentioned here that Sun was ready to buy Mysql for $1 > > billion. > > Could it change something for postresql? if yes, what? > > Nobody mentioned it here, because this is the hackers list. It is > mentioned in-depth on -advocacy. > > Oops, sorry for the noise! I should have read it first! -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] sun to buy mysql
Hi all, I'm surprised no one mentioned here that Sun was ready to buy Mysql for $1 billion. Could it change something for postresql? if yes, what? Best regards, -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] convert int to bytea
Hi Gregory On Thu, 29 Nov 2007, Gregory Stark wrote: > Date: Thu, 29 Nov 2007 14:34:57 + > From: Gregory Stark <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Cc: pgsql-hackers list > Subject: Re: convert int to bytea > > <[EMAIL PROTECTED]> writes: > > > select 124::bytea doesn't work > > > > Is there an other way? (preferabily simple :) > > This kind of question would be more appropriate on pgsql-general. > I know, I should subscribe :) > What do you want the resulting bytea to look like? > example : id = 9 , bytea = '\000\000\011' IIRC > -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] convert int to bytea
Hi all, I'm trying to write a trigger that converts integer to bytea. My schema is like this: Create table xx ( id int, ... data bytea); the first 3 bytes of data are the binary representation of id (id is extracted from data by the application) I can occur that id change in that case data has to change too! select 124::bytea doesn't work Is there an other way? (preferabily simple :) Regards -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] Jaguar is up
Hmm, isn't 4h22m a LONG time for it even with clobbered cache? All my tests so far have last less than 2h.. Regards -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) -- Forwarded message -- Date: Thu, 29 Nov 2007 05:00:02 +0100 (CET) From: Cron Daemon <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Cron <[EMAIL PROTECTED]> cd /home/ohp/build-farm && ./run_build.pl --verbose [05:00:02] checking out source ... [05:01:00] checking if build run needed ... [05:01:04] copying source to pgsql.10004 ... [05:01:29] running configure ... [05:01:59] running make ... [05:05:28] running make check ... [06:28:20] running make contrib ... [06:28:44] running make install ... [06:28:49] setting up db cluster ... [06:35:17] starting db ... [06:35:18] running make installcheck ... [08:25:54] restarting db ... [08:25:56] running make PL installcheck ... [08:29:48] restarting db ... [08:29:50] running make contrib install ... [08:29:53] running make contrib installcheck ... [09:08:26] stopping db ... [09:08:27] running make ecpg check ... [09:22:01] OK ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] jaguar is up
On Wed, 28 Nov 2007, Tom Lane wrote: > Date: Wed, 28 Nov 2007 12:45:30 -0500 > From: Tom Lane <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Cc: pgsql-hackers list > Subject: Re: [HACKERS] jaguar is up > > [EMAIL PROTECTED] writes: > > Jaguar is a new animal meant to test specific defines as asked by Tom > > sometime ago. > > > Right now, it compiles and runs with -DCLOBBER_CACHE_ALWAYS > > Cool, how long does it take to run the regression tests? > The whole thing is about 96 Min, did'nt check the exact time of regression tests but it's long on a dual core AMD centos 5.0 sata disk system > > Let me know if you want me to add/change flags > > Awhile back I got burnt by a gap in that testing methodology: > http://archives.postgresql.org/pgsql-committers/2006-12/msg00237.php > > I didn't do anything about it at the time, but now I am tempted to > modify LookupOpclassInfo() so that CLOBBER_CACHE_ALWAYS disables > its internal cache. Any objections? > Nope! > regards, tom lane > Tell me if you want me to set up other tests or change configure param. Best regards -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] jaguar is up
Jaguar is a new animal meant to test specific defines as asked by Tom sometime ago. Right now, it compiles and runs with -DCLOBBER_CACHE_ALWAYS Let me know if you want me to add/change flags Best regards -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] should I worry?
Dear Tom,
On Tue, 6 Nov 2007, Tom Lane wrote:
> Date: Tue, 06 Nov 2007 10:05:58 -0500
> From: Tom Lane <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: Heikki Linnakangas <[EMAIL PROTECTED]>,
> Rick Gigger <[EMAIL PROTECTED]>,
> pgsql-hackers list
> Subject: Re: [HACKERS] should I worry?
>
> [EMAIL PROTECTED] writes:
> > IIUC, I have drop every trigger like this :
>
> > SELECT t.tgname, c.relname, tgconstrname FROM pg_trigger t, pg_class c
> > WHERE t.tgrelid = c.oid AND tgname like 'RI_ConstraintTrigger_%'AND
> > tgconstrname = '';
>
> > and I delete all those ancient foreign key WITHOUT disturbing any others
> > Is that right?
>
> Not necessarily --- are you sure you don't have any real constraints
> named ""?
>
yes
> However, if you do, the DROP TRIGGER command will just fail, so maybe
> you don't need to bother with looking into pg_depend for yourself.
>
> regards, tom lane
>
Thanks to your last sentence, I ended up with the rather crude script
below that works for me (expect a lot of errors)
DBNAME=xxx
for s in `psql -t ${DBNAME} << EOD
SELECT 'DROP TRIGGER "' || t.tgname || '" ON ' || c.relname || ';'
FROM pg_trigger t, pg_class c
WHERE t.tgrelid = c.oid AND tgname like 'RI_ConstraintTrigger_%'
EOD`
do
echo $s
done|psql ${DBNAME}
Could maybe help others like me
What's your opinion?
--
Olivier PRENANT Tel: +33-5-61-50-97-00 (Work)
15, Chemin des Monges+33-5-61-50-97-01 (Fax)
31190 AUTERIVE +33-6-07-63-80-64 (GSM)
FRANCE Email: [EMAIL PROTECTED]
--
Make your life a dream, make your dream a reality. (St Exupery)
---(end of broadcast)---
TIP 6: explain analyze is your friend
Re: [HACKERS] should I worry?
On Tue, 6 Nov 2007, Heikki Linnakangas wrote: > Date: Tue, 06 Nov 2007 13:07:23 + > From: Heikki Linnakangas <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Cc: Tom Lane <[EMAIL PROTECTED]>, Rick Gigger <[EMAIL PROTECTED]>, > pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] should I worry? > > [EMAIL PROTECTED] wrote: > > I'd love to find a query against pg_triggers giving the table name for > > each RI_ConstraintTrigger_xxx. > > SELECT t.tgname, c.relname, tgconstrname FROM pg_trigger t, pg_class c > WHERE t.tgrelid = c.oid AND tgname like 'RI_ConstraintTrigger_%'; > > Thanks! GREAT! IIUC, I have drop every trigger like this : SELECT t.tgname, c.relname, tgconstrname FROM pg_trigger t, pg_class c WHERE t.tgrelid = c.oid AND tgname like 'RI_ConstraintTrigger_%'AND tgconstrname = ''; and I delete all those ancient foreign key WITHOUT disturbing any others Is that right? Regards -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] should I worry?
On Mon, 5 Nov 2007, Tom Lane wrote:
> Date: Mon, 05 Nov 2007 15:53:10 -0500
> From: Tom Lane <[EMAIL PROTECTED]>
> To: Heikki Linnakangas <[EMAIL PROTECTED]>
> Cc: Rick Gigger <[EMAIL PROTECTED]>, [EMAIL PROTECTED],
> pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] should I worry?
>
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> > Rick Gigger wrote:
> >> Doesn't DROP TRIGGER require the name of the trigger? He says they are
> >> unnamed. How then does he drop them?
>
> > They're not really unnamed. pg_dump just replaces the real name with
> > "".
>
> And \d will show the real names of the triggers, so it's not really
> that hard to drop them:
>
> u=# \d t1
> Table "public.t1"
> Column | Type | Modifiers
> +-+---
> f1 | integer | not null
> Indexes:
> "t1_pkey" PRIMARY KEY, btree (f1)
> Triggers:
> "RI_ConstraintTrigger_229629" AFTER DELETE ON t1 FROM t2 NOT DEFERRABLE
> INITIALLY IMMEDIATE FOR EACH ROW EXECUTE PROCEDURE
> "RI_FKey_noaction_del"('', 't2', 't1', 'UNSPECIFIED', 'f2', 'f1')
> "RI_ConstraintTrigger_229630" AFTER UPDATE ON t1 FROM t2 NOT DEFERRABLE
> INITIALLY IMMEDIATE FOR EACH ROW EXECUTE PROCEDURE
> "RI_FKey_noaction_upd"('', 't2', 't1', 'UNSPECIFIED', 'f2', 'f1')
>
> u=# drop trigger "RI_ConstraintTrigger_229629" on t1;
> DROP TRIGGER
>
> I do recall newbies forgetting to double-quote the mixed-case trigger
> names when this came up in times past, though.
>
> regards, tom lane
>
I'd love to find a query against pg_triggers giving the table name for
each RI_ConstraintTrigger_xxx.
That would be quick to delete them all instead of going through all
tables.
Regards,
--
Olivier PRENANT Tel: +33-5-61-50-97-00 (Work)
15, Chemin des Monges+33-5-61-50-97-01 (Fax)
31190 AUTERIVE +33-6-07-63-80-64 (GSM)
FRANCE Email: [EMAIL PROTECTED]
--
Make your life a dream, make your dream a reality. (St Exupery)
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [HACKERS] should I worry?
Hi Tom On Sun, 4 Nov 2007, Tom Lane wrote: > Date: Sun, 04 Nov 2007 19:47:04 -0500 > From: Tom Lane <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Cc: pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] should I worry? > > I wrote: > > Hmm, this is messier than I thought. What evidently has happened is > > that at one time or another, one of the two tables involved in an FK > > relationship has been dropped and re-created. If you'd had proper > > FK constraints the constraints would have gone away cleanly, but with > > these old trigger definitions there was no mechanism to make that > > happen, and so the triggers on the other table remained in place. > > That seems to have happened several times, in fact. After tweaking > ConvertTriggerToFK() to be more verbose and to insist on finding all > three triggers, I get this: > > NOTICE: ignoring incomplete trigger group for constraint "" FOREIGN > KEY perso_competences(pcomp_perso_cod) REFERENCES perso(perso_cod) > DETAIL: Found referencing table's trigger. > NOTICE: ignoring incomplete trigger group for constraint "" FOREIGN > KEY perso_position(ppos_perso_cod) REFERENCES perso(perso_cod) > DETAIL: Found referencing table's trigger. > NOTICE: ignoring incomplete trigger group for constraint "" FOREIGN > KEY objet_position(pobj_obj_cod) REFERENCES objets(obj_cod) > DETAIL: Found referencing table's trigger. > NOTICE: ignoring incomplete trigger group for constraint "" FOREIGN > KEY objet_position(pobj_obj_cod) REFERENCES objets(obj_cod) > DETAIL: Found referenced table's DELETE trigger. > NOTICE: converting trigger group into constraint "" FOREIGN KEY > objet_position(pobj_obj_cod) REFERENCES objets(obj_cod) > DETAIL: Found referenced table's UPDATE trigger. > NOTICE: ignoring incomplete trigger group for constraint "" FOREIGN > KEY perso_objets(perobj_perso_cod) REFERENCES perso(perso_cod) > DETAIL: Found referencing table's trigger. > NOTICE: ignoring incomplete trigger group for constraint "" FOREIGN > KEY perso_objets(perobj_obj_cod) REFERENCES objets(obj_cod) > DETAIL: Found referencing table's trigger. > NOTICE: ignoring incomplete trigger group for constraint "" FOREIGN > KEY perso_objets(perobj_obj_cod) REFERENCES objets(obj_cod) > DETAIL: Found referenced table's DELETE trigger. > NOTICE: converting trigger group into constraint "" FOREIGN KEY > perso_objets(perobj_obj_cod) REFERENCES objets(obj_cod) > DETAIL: Found referenced table's UPDATE trigger. > NOTICE: ignoring incomplete trigger group for constraint "" FOREIGN > KEY messages_dest(dmsg_msg_cod) REFERENCES messages(msg_cod) > DETAIL: Found referencing table's trigger. > NOTICE: ignoring incomplete trigger group for constraint "" FOREIGN > KEY messages_dest(dmsg_msg_cod) REFERENCES messages(msg_cod) > DETAIL: Found referenced table's DELETE trigger. > NOTICE: converting trigger group into constraint "" FOREIGN KEY > messages_dest(dmsg_msg_cod) REFERENCES messages(msg_cod) > DETAIL: Found referenced table's UPDATE trigger. > NOTICE: ignoring incomplete trigger group for constraint "" FOREIGN > KEY messages_dest(dmsg_perso_cod) REFERENCES perso(perso_cod) > DETAIL: Found referencing table's trigger. > NOTICE: ignoring incomplete trigger group for constraint "" FOREIGN > KEY messages_exp(emsg_msg_cod) REFERENCES messages(msg_cod) > DETAIL: Found referencing table's trigger. > NOTICE: ignoring incomplete trigger group for constraint "" FOREIGN > KEY messages_exp(emsg_msg_cod) REFERENCES messages(msg_cod) > DETAIL: Found referenced table's DELETE trigger. > NOTICE: converting trigger group into constraint "" FOREIGN KEY > messages_exp(emsg_msg_cod) REFERENCES messages(msg_cod) > DETAIL: Found referenced table's UPDATE trigger. > NOTICE: ignoring incomplete trigger group for constraint "" FOREIGN > KEY messages_exp(emsg_perso_cod) REFERENCES perso(perso_cod) > DETAIL: Found referencing table's trigger. > NOTICE: ignoring incomplete trigger group for constraint "" FOREIGN > KEY perso_competences(pcomp_perso_cod) REFERENCES perso(perso_cod) > DETAIL: Found referencing table's trigger. > NOTICE: ignoring incomplete trigger group for constraint "" FOREIGN > KEY perso_competences(pcomp_perso_cod) REFERENCES perso(perso_cod) > DETAIL: Found referenced table's DELETE trigger. > NOTICE: ignoring incomplete trigger group for constraint "" FOREIGN > KEY perso_position(ppos_pos_cod) REFERENCES positions(pos_cod) > DETAIL: Found referenced table's DELETE trigger. > NOTICE: ignoring incomplete trigger group for constraint "" FOREIGN > KEY perso_position(ppos_pos_cod) REFERENCES positions(pos_cod) > DETAIL: Found referenced table's UPDATE trigger. > NOTICE: ignoring incomplete trigger group for constraint "" FOREIGN > KEY objet_position(pobj_pos_cod) REFERENCES positions(pos_cod) > DETAIL: Found referenced table's DELETE trigger. > NOTICE: ignoring incomplete trigger group for constraint "" FOREIGN > KEY objet_position(pobj_pos_cod) REFERENCES
Re: [HACKERS] should I worry?
Dear Tom, On Sat, 3 Nov 2007, Tom Lane wrote: > Date: Sat, 03 Nov 2007 21:21:20 -0400 > From: Tom Lane <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Cc: Heikki Linnakangas <[EMAIL PROTECTED]>, > pgsql-hackers list > Subject: Re: [HACKERS] should I worry? > > [EMAIL PROTECTED] writes: > > Is there a query I can use to know all the unamed trigger, delete them and > > recreate with the right sentence? > > I've applied a patch that should persuade the backend to convert the old > CREATE CONSTRAINT TRIGGER commands into proper foreign-key constraints. > I'd suggest applying the patch and re-loading the dump instead of trying > to fix things manually. > > http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/trigger.c.diff?r1=1.219;r2=1.220 > > regards, tom lane > I've tried it and got those logs: Nov 4 16:02:24 sun postgres[12505]: [189-1] NOTICE: ignoring incomplete foreign-key trigger group for constraint "RI_ConstraintTrigger_28974025" on table Nov 4 16:02:24 sun postgres[12505]: [189-2] "perso_competences" Nov 4 16:02:24 sun postgres[12505]: [190-1] NOTICE: ignoring incomplete foreign-key trigger group for constraint "" on table "perso_position" Nov 4 16:02:24 sun postgres[12505]: [191-1] NOTICE: ignoring incomplete foreign-key trigger group for constraint "" on table "objet_position" Nov 4 16:02:24 sun postgres[12505]: [192-1] NOTICE: ignoring incomplete foreign-key trigger group for constraint "" on table "objet_position" Nov 4 16:02:24 sun postgres[12505]: [193-1] NOTICE: converting foreign-key trigger group into constraint "" on table "objet_position" Nov 4 16:02:25 sun postgres[12505]: [194-1] NOTICE: ignoring incomplete foreign-key trigger group for constraint "" on table "perso_objets" Nov 4 16:02:25 sun postgres[12505]: [195-1] NOTICE: ignoring incomplete foreign-key trigger group for constraint "" on table "perso_objets" Nov 4 16:02:25 sun postgres[12505]: [196-1] NOTICE: ignoring incomplete foreign-key trigger group for constraint "" on table "perso_objets" Nov 4 16:02:25 sun postgres[12505]: [197-1] NOTICE: converting foreign-key trigger group into constraint "" on table "perso_objets" Nov 4 16:02:25 sun postgres[12505]: [198-1] NOTICE: ignoring incomplete foreign-key trigger group for constraint "" on table "messages_dest" Nov 4 16:02:25 sun postgres[12505]: [199-1] NOTICE: ignoring incomplete foreign-key trigger group for constraint "" on table "messages_dest" Nov 4 16:02:25 sun postgres[12505]: [200-1] NOTICE: converting foreign-key trigger group into constraint "" on table "messages_dest" Nov 4 16:02:25 sun postfix/smtpd[12751]: connect from 82-32-100-168.cable.ubr01.hawk.blueyonder.co.uk[82.32.100.168] Nov 4 16:02:26 sun postgres[12505]: [201-1] NOTICE: ignoring incomplete foreign-key trigger group for constraint "" on table "messages_dest" Nov 4 16:02:26 sun postgres[12505]: [202-1] NOTICE: ignoring incomplete foreign-key trigger group for constraint "" on table "messages_exp" Nov 4 16:02:26 sun postgres[12505]: [203-1] NOTICE: ignoring incomplete foreign-key trigger group for constraint "" on table "messages_exp" Nov 4 16:02:26 sun postgres[12505]: [204-1] NOTICE: converting foreign-key trigger group into constraint "" on table "messages_exp" Nov 4 16:02:26 sun postgres[12505]: [205-1] NOTICE: ignoring incomplete foreign-key trigger group for constraint "" on table "messages_exp" Nov 4 16:02:26 sun postgres[12505]: [206-1] NOTICE: ignoring incomplete foreign-key trigger group for constraint "RI_ConstraintTrigger_28974598" on table Nov 4 16:02:26 sun postgres[12505]: [206-2] "perso_competences" Nov 4 16:02:26 sun postgres[12505]: [207-1] NOTICE: ignoring incomplete foreign-key trigger group for constraint "RI_ConstraintTrigger_28974610" on table Nov 4 16:02:26 sun postgres[12505]: [207-2] "perso_competences" Nov 4 16:02:26 sun postgres[12505]: [208-1] NOTICE: ignoring incomplete foreign-key trigger group for constraint "" on table "perso_position" Nov 4 16:02:26 sun postgres[12505]: [209-1] NOTICE: converting foreign-key trigger group into constraint "" on table "perso_position" Nov 4 16:02:26 sun postgres[12505]: [210-1] NOTICE: ignoring incomplete foreign-key trigger group for constraint "" on table "objet_position" Nov 4 16:02:26 sun postgres[12505]: [211-1] NOTICE: converting foreign-key trigger group into constraint "" on table "objet_position" Nov 4 16:02:26 sun postgres[12505]: [212-1] NOTICE: ignoring incomplete foreign-key trigger group for constraint "" on table "or_position" Nov 4 16:02:26 sun postgres[12505]: [213-1] NOTICE: converting foreign-key trigger group into constraint "" on table "or_position" Nov 4 16:02:26 sun postgres[12505]: [214-1] NOTICE: ignoring incomplete foreign-key trigger group for constraint "" on table "ligne_evt" Nov 4 16:02:26 sun postgres[12505]: [215-1] NOTICE: converting foreign-key trigger group into constraint ""
Re: [HACKERS] should I worry?
On Sat, 3 Nov 2007, Tom Lane wrote:
> Date: Sat, 03 Nov 2007 12:42:24 -0400
> From: Tom Lane <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: Heikki Linnakangas <[EMAIL PROTECTED]>,
> pgsql-hackers list
> Subject: Re: [HACKERS] should I worry?
>
> [EMAIL PROTECTED] writes:
> > I'm confused, until I have clearence to send the schema, here are pg logs:
>
> > Nov 3 14:44:20 sun postgres[17963]: [189-1] ERROR: trigger ""
> > for relation "objets" already exists
> > Nov 3 14:44:20 sun postgres[17963]: [189-2] STATEMENT: CREATE CONSTRAINT
> > TRIGGER ""
> > Nov 3 14:44:20 sun postgres[17963]: [189-3]AFTER UPDATE ON
> > objets
> > Nov 3 14:44:20 sun postgres[17963]: [189-4]FROM objet_position
> > Nov 3 14:44:20 sun postgres[17963]: [189-5]NOT DEFERRABLE
> > INITIALLY IMMEDIATE
> > Nov 3 14:44:20 sun postgres[17963]: [189-6]FOR EACH ROW
> > Nov 3 14:44:20 sun postgres[17963]: [189-7]EXECUTE PROCEDURE
> > "RI_FKey_noaction_upd"('', 'objet_position', 'objets',
> > 'UNSPECIFIED', 'pobj_obj_cod',
> > Nov 3 14:44:20 sun postgres[17963]: [189-8] 'obj_cod');
>
> These must be hangovers from some truly ancient version of Postgres :-(
Yes, this db is restored on every new version for nearly 5 years now :)
>
> I'd suggest dropping all these triggers and setting up real foreign key
> constraint declarations instead. If there seem to be too many to do it
> manually, you might try contrib/adddepend which used to be included
> with Postgres (between 7.3 and 8.1).
Done see below
>
Actually, I can't even edit the dump 'cause it's 3.5G uncompress, xemacs
gives up at 2G :-(
> Looking into it, I think the reason you're getting bit now is that
> CREATE CONSTRAINT TRIGGER didn't use to insist on a unique trigger name.
> Now it does. But it's way past time for you to get rid of these
> old-style foreign keys anyway.
I've reload the dump on a 8.2.5 then ran adddepend.pl, took a dump and
reloaded it on a 8.3beta2, and have less but still errors.
What do I loose if I leave it as is, I guess I'll miss a few foreign keys,
is there an easy way to know which?
Is there a query I can use to know all the unamed trigger, delete them and
recreate with the right sentence?
>
> regards, tom lane
>
regards,
--
Olivier PRENANT Tel: +33-5-61-50-97-00 (Work)
15, Chemin des Monges+33-5-61-50-97-01 (Fax)
31190 AUTERIVE +33-6-07-63-80-64 (GSM)
FRANCE Email: [EMAIL PROTECTED]
--
Make your life a dream, make your dream a reality. (St Exupery)
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
Re: [HACKERS] should I worry?
Sorry to post on my own post,
I found this (as a little exemple I've got plenty of these)
could that be the culprit and how to correct that?
--
-- Name: RI_ConstraintTrigger_609094000; Type: TRIGGER; Schema: public; Owner:
delain
--
CREATE CONSTRAINT TRIGGER ""
AFTER DELETE ON objets
FROM objet_position
NOT DEFERRABLE INITIALLY IMMEDIATE
FOR EACH ROW
EXECUTE PROCEDURE "RI_FKey_noaction_del"('', 'objet_position',
'objets', 'UNSPECIFIED', 'pobj_obj_cod', 'obj_cod');
--
-- Name: RI_ConstraintTrigger_609094001; Type: TRIGGER; Schema: public; Owner:
delain
--
CREATE CONSTRAINT TRIGGER ""
AFTER UPDATE ON objets
FROM objet_position
NOT DEFERRABLE INITIALLY IMMEDIATE
FOR EACH ROW
EXECUTE PROCEDURE "RI_FKey_noaction_upd"('', 'objet_position',
'objets', 'UNSPECIFIED', 'pobj_obj_cod', 'obj_cod');
This dump was generated by pg_dump 8.3beta1 against a 8.2.5 db
Best regardsb
On Fri, 2 Nov 2007, Heikki Linnakangas wrote:
> Date: Fri, 02 Nov 2007 19:59:03 +
> From: Heikki Linnakangas <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: pgsql-hackers list
> Subject: Re: [HACKERS] should I worry?
>
> [EMAIL PROTECTED] wrote:
> > On Fri, 2 Nov 2007, Heikki Linnakangas wrote:
> >
> >> Date: Fri, 02 Nov 2007 18:11:14 +
> >> From: Heikki Linnakangas <[EMAIL PROTECTED]>
> >> To: [EMAIL PROTECTED]
> >> Cc: pgsql-hackers list
> >> Subject: Re: [HACKERS] should I worry?
> >>
> >> [EMAIL PROTECTED] wrote:
> >>> I'm now testing 8.3beta2 on a relatively big (10G) database.
> >>> I've tried with pg_dymp -Fc/pg_restore and pg_dump/pgsql and get those
> >>> errors:
> >> Could you be a bit more specific? The database you tried to restore to
> >> was empty, right? Can you post the dump file (schema-only)?
> > Yes it was empty, Sorry, I can't post the schema, it belongs to one of my
> > customer...
>
> Maybe you could reduce it to a small self-contained test case, with
> table names changed to protect the innocent?
>
>
--
Olivier PRENANT Tel: +33-5-61-50-97-00 (Work)
15, Chemin des Monges+33-5-61-50-97-01 (Fax)
31190 AUTERIVE +33-6-07-63-80-64 (GSM)
FRANCE Email: [EMAIL PROTECTED]
--
Make your life a dream, make your dream a reality. (St Exupery)
---(end of broadcast)---
TIP 6: explain analyze is your friend
Re: [HACKERS] should I worry?
Hi Tom et all!
Thanks for your mails.
On Fri, 2 Nov 2007, Tom Lane wrote:
> Date: Fri, 02 Nov 2007 16:08:24 -0400
> From: Tom Lane <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: Heikki Linnakangas <[EMAIL PROTECTED]>,
> pgsql-hackers list
> Subject: Re: [HACKERS] should I worry?
>
> [EMAIL PROTECTED] writes:
> > All triggers in the schema are named. So I assume they are triggers for
> > foreign keys.
>
> No, foreign-key triggers always have names too, and they don't look like
> that (they look like RI_ConstraintTrigger_nnn). I cannot find anyplace
> in PG that supplies "" as a default name for a trigger, either.
> So there's something weird about your schema, and we really need to
> see a test case ...
>
I'm confused, until I have clearence to send the schema, here are pg logs:
Nov 3 14:44:20 sun postgres[17963]: [189-1] ERROR: trigger "" for
relation "objets" already exists
Nov 3 14:44:20 sun postgres[17963]: [189-2] STATEMENT: CREATE CONSTRAINT
TRIGGER ""
Nov 3 14:44:20 sun postgres[17963]: [189-3]AFTER UPDATE ON objets
Nov 3 14:44:20 sun postgres[17963]: [189-4]FROM objet_position
Nov 3 14:44:20 sun postgres[17963]: [189-5]NOT DEFERRABLE INITIALLY
IMMEDIATE
Nov 3 14:44:20 sun postgres[17963]: [189-6]FOR EACH ROW
Nov 3 14:44:20 sun postgres[17963]: [189-7]EXECUTE PROCEDURE
"RI_FKey_noaction_upd"('', 'objet_position', 'objets', 'UNSPECIFIED',
'pobj_obj_cod',
Nov 3 14:44:20 sun postgres[17963]: [189-8] 'obj_cod');
Nov 3 14:44:20 sun postgres[17963]: [190-1] ERROR: trigger "" for
relation "perso_objets" already exists
Nov 3 14:44:20 sun postgres[17963]: [190-2] STATEMENT: CREATE CONSTRAINT
TRIGGER ""
Nov 3 14:44:20 sun postgres[17963]: [190-3]AFTER INSERT OR UPDATE ON
perso_objets
Nov 3 14:44:20 sun postgres[17963]: [190-4]FROM objets
Nov 3 14:44:20 sun postgres[17963]: [190-5]NOT DEFERRABLE INITIALLY
IMMEDIATE
Nov 3 14:44:20 sun postgres[17963]: [190-6]FOR EACH ROW
Nov 3 14:44:20 sun postgres[17963]: [190-7]EXECUTE PROCEDURE
"RI_FKey_check_ins"('', 'perso_objets', 'objets', 'UNSPECIFIED',
'perobj_obj_cod', 'obj_cod');
Nov 3 14:44:20 sun postgres[17963]: [191-1] ERROR: trigger "" for
relation "objets" already exists
Nov 3 14:44:20 sun postgres[17963]: [191-2] STATEMENT: CREATE CONSTRAINT
TRIGGER ""
Nov 3 14:44:20 sun postgres[17963]: [191-3]AFTER DELETE ON objets
Nov 3 14:44:20 sun postgres[17963]: [191-4]FROM perso_objets
Nov 3 14:44:20 sun postgres[17963]: [191-5]NOT DEFERRABLE INITIALLY
IMMEDIATE
Nov 3 14:44:20 sun postgres[17963]: [191-6]FOR EACH ROW
Nov 3 14:44:20 sun postgres[17963]: [191-7]EXECUTE PROCEDURE
"RI_FKey_noaction_del"('', 'perso_objets', 'objets', 'UNSPECIFIED',
'perobj_obj_cod',
Nov 3 14:44:20 sun postgres[17963]: [191-8] 'obj_cod');
Nov 3 14:44:20 sun postgres[17963]: [192-1] ERROR: trigger "" for
relation "objets" already exists
Nov 3 14:44:20 sun postgres[17963]: [192-2] STATEMENT: CREATE CONSTRAINT
TRIGGER ""
Nov 3 14:44:20 sun postgres[17963]: [192-3]AFTER UPDATE ON objets
Nov 3 14:44:20 sun postgres[17963]: [192-4]FROM perso_objets
Nov 3 14:44:20 sun postgres[17963]: [192-5]NOT DEFERRABLE INITIALLY
IMMEDIATE
Nov 3 14:44:20 sun postgres[17963]: [192-6]FOR EACH ROW
Nov 3 14:44:20 sun postgres[17963]: [192-7]EXECUTE PROCEDURE
"RI_FKey_noaction_upd"('', 'perso_objets', 'objets', 'UNSPECIFIED',
'perobj_obj_cod',
Nov 3 14:44:20 sun postgres[17963]: [192-8] 'obj_cod');
Nov 3 14:44:20 sun postgres[17963]: [193-1] ERROR: trigger "" for
relation "messages" already exists
Nov 3 14:44:20 sun postgres[17963]: [193-2] STATEMENT: CREATE CONSTRAINT
TRIGGER ""
Nov 3 14:44:20 sun postgres[17963]: [193-3]AFTER UPDATE ON messages
Nov 3 14:44:20 sun postgres[17963]: [193-4]FROM messages_dest
Nov 3 14:44:20 sun postgres[17963]: [193-5]NOT DEFERRABLE INITIALLY
IMMEDIATE
Nov 3 14:44:20 sun postgres[17963]: [193-6]FOR EACH ROW
Nov 3 14:44:20 sun postgres[17963]: [193-7]EXECUTE PROCEDURE
"RI_FKey_noaction_upd"('', 'messages_dest', 'messages', 'UNSPECIFIED',
'dmsg_msg_cod',
Nov 3 14:44:20 sun postgres[17963]: [193-8] 'msg_cod');
Nov 3 14:44:20 sun postgres[17963]: [194-1] ERROR: trigger "" for
relation "messages_dest" already exists
Nov 3 14:44:20 sun postgres[17963]: [194-2] STATEMENT: CREATE CONSTRAINT
TRIGGER ""
Nov 3 14:44:20 sun postgres[17963]: [194-3]AFTER INSERT OR UPDATE ON
messages_dest
Nov 3 14:44:20 sun postgres[17963]: [194-4]FROM perso
Nov 3 14:44:20 sun postgres[17963]: [194-5]NOT DEFERRABLE INITIALLY
IMMEDIATE
Nov 3 14:44:20 sun postgres[17963]: [194-6]FOR EACH ROW
Nov 3 14:44:20 sun postgres[17963]: [194-7]EXECUTE PROCEDURE
"RI_FKey_check_ins"('', 'messages_dest', 'perso', 'UNSPECIFIED',
'dmsg_perso_cod', 'perso_cod');
Nov 3 14:44:20 sun postgres[1796
Re: [HACKERS] should I worry?
On Fri, 2 Nov 2007, Heikki Linnakangas wrote: > Date: Fri, 02 Nov 2007 18:11:14 + > From: Heikki Linnakangas <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Cc: pgsql-hackers list > Subject: Re: [HACKERS] should I worry? > > [EMAIL PROTECTED] wrote: > > I'm now testing 8.3beta2 on a relatively big (10G) database. > > I've tried with pg_dymp -Fc/pg_restore and pg_dump/pgsql and get those > > errors: > > Could you be a bit more specific? The database you tried to restore to > was empty, right? Can you post the dump file (schema-only)? Yes it was empty, Sorry, I can't post the schema, it belongs to one of my customer... All triggers in the schema are named. So I assume they are triggers for foreign keys. It's hard to tell if all foreign keys have been created after restore is complete... > > > I'm also playing with checkpoint logging. What should I see? few buffers > > dump, little write time, little sync time? > > Depends on how much activity there is. If there's a lot of dirty > buffers, a lot of written buffers and long write time is perfectly normal. > > Thanks for the explanation. Regards -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] should I worry?
Hi hackers, I'm now testing 8.3beta2 on a relatively big (10G) database. I've tried with pg_dymp -Fc/pg_restore and pg_dump/pgsql and get those errors: ERROR: trigger "" for relation "objets" already exists ERROR: trigger "" for relation "perso_objets" already exists ERROR: trigger "" for relation "objets" already exists ERROR: trigger "" for relation "objets" already exists ERROR: trigger "" for relation "messages" already exists ERROR: trigger "" for relation "messages_dest" already exists ERROR: trigger "" for relation "messages" already exists ERROR: trigger "" for relation "messages" already exists ERROR: trigger "" for relation "messages_exp" already exists ERROR: trigger "" for relation "positions" already exists ERROR: trigger "" for relation "positions" already exists ERROR: trigger "" for relation "positions" already exists ERROR: trigger "" for relation "positions" already exists ERROR: trigger "" for relation "positions" already exists ERROR: trigger "" for relation "type_evt" already exists ERROR: trigger "" for relation "objet_generique" already exists ERROR: trigger "" for relation "objet_generique" already exists ERROR: trigger "" for relation "objets_caracs" already exists ERROR: trigger "" for relation "competences" already exists ERROR: trigger "" for relation "race_comp" already exists I don't remember having those with beta1 and don't know what to look at. I've tried both 8.2.5 and 8.3beta2 pg_dump. I'm also playing with checkpoint logging. What should I see? few buffers dump, little write time, little sync time? Unrelated, who should I contact to get my password of jaguar in build_farm, this animal has been set up to test with -DCLOBBER_CACHE_ALWAYS and I never received the password. Maybe pgfbuildfarm.org web should include a button to resend account to the owner. Just my 0.01$... Best regards -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Re: [COMMITTERS] pgsql: Fix brain fade in DefineIndex(): it was continuing to access the
Hi Tom and Andrew, On Thu, 30 Aug 2007, Tom Lane wrote: > Date: Thu, 30 Aug 2007 10:04:34 -0400 > From: Tom Lane <[EMAIL PROTECTED]> > To: Andrew Dunstan <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED], PostgreSQL-development > Subject: Re: [HACKERS] Re: [COMMITTERS] pgsql: Fix brain fade in > DefineIndex(): it was continuing to access the > > Andrew Dunstan <[EMAIL PROTECTED]> writes: > > [EMAIL PROTECTED] wrote: > >> I've just configure centaur (CentOS 5) like this. > >> Do you need it for every version (8.1, 8.2) or just HEAD > >> Do you need it just once a week or every run? > >> I can also configure wharthog (unixware) like this if you need... > > > I have no idea - probably just HEAD, but Tom will have a better idea :-) > > HEAD only is enough IMHO. If we find any bugs it should be pretty > obvious whether they need to be back-patched. > > regards, tom lane > While waiting for my application for another animal, I made some tests and was surprised that cluster test failed with an ordering error. Maybe an ORDER BY is missing in the test query. Here's an exerpt of check.log: == creating temporary installation== == initializing database system == == starting postmaster== running on port 55678 with pid 6928 == creating database "regression" == CREATE DATABASE ALTER DATABASE == installing plpgsql == CREATE LANGUAGE == running regression test queries== parallel group (15 tests): text name oid char float4 int2 boolean varchar int8 float8 int4 uuid bit enum numeric boolean ... ok char ... ok name ... ok varchar ... ok text ... ok int2 ... ok int4 ... ok int8 ... ok oid ... ok float4 ... ok float8 ... ok bit ... ok numeric ... ok uuid ... ok enum ... ok test strings ... ok test numerology ... ok parallel group (18 tests): comments path lseg time timetz reltime polygon tinterval box circle abstime tstypes point interval timestamptz timestamp date inet point... ok lseg ... ok box ... ok path ... ok polygon ... ok circle ... ok date ... ok time ... ok timetz ... ok timestamp... ok timestamptz ... ok interval ... ok abstime ... ok reltime ... ok tinterval... ok inet ... ok tstypes ... ok comments ... ok parallel group (5 tests): geometry horology type_sanity oidjoins opr_sanity geometry ... ok horology ... ok oidjoins ... ok type_sanity ... ok opr_sanity ... ok test insert ... ok test create_function_1... ok test create_type ... ok test create_table ... ok test create_function_2... ok parallel group (2 tests): copy copyselect copy ... ok copyselect ... ok parallel group (8 tests): create_operator create_aggregate vacuum drop_if_exists create_misc constraints inherit triggers constraints ... ok triggers ... ok create_misc ... ok create_aggregate ... ok create_operator ... ok inherit ... ok vacuum ... ok drop_if_exists ... ok parallel group (2 tests): create_view create_index create_index ... ok create_view ... ok test sanity_check ... ok test errors ... ok test select ... ok parallel group (20 tests): select_distinct_on btree_index select_into delete select_distinct namespace update hash_index select_having union case random select_implicit prepared_xacts aggregates transactions subselect portals join arrays select_into ... ok select_distinct ... ok select_distinct_on ... ok select_implicit ... ok select_having... ok subselect... ok union... ok case ... ok join ... ok aggregates ... ok transactions ... ok random ... ok portals ... ok arrays ... ok btree_index ... ok hash_index ... ok update ... ok namespace
Re: [HACKERS] Re: [COMMITTERS] pgsql: Fix brain fade in DefineIndex(): it was continuing to access the
Hi Tom On Thu, 30 Aug 2007, Tom Lane wrote: > Date: Thu, 30 Aug 2007 10:04:34 -0400 > From: Tom Lane <[EMAIL PROTECTED]> > To: Andrew Dunstan <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED], PostgreSQL-development > Subject: Re: [HACKERS] Re: [COMMITTERS] pgsql: Fix brain fade in > DefineIndex(): it was continuing to access the > > Andrew Dunstan <[EMAIL PROTECTED]> writes: > > [EMAIL PROTECTED] wrote: > >> I've just configure centaur (CentOS 5) like this. > >> Do you need it for every version (8.1, 8.2) or just HEAD > >> Do you need it just once a week or every run? > >> I can also configure wharthog (unixware) like this if you need... > > > I have no idea - probably just HEAD, but Tom will have a better idea :-) > > HEAD only is enough IMHO. If we find any bugs it should be pretty > obvious whether they need to be back-patched. > Ok, do you need it on unixware? do you need it more than once a week? FYI, centaurc is running make check for 3 hours now and has'nt finished! Regards > regards, tom lane > -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] Re: [COMMITTERS] pgsql: Fix brain fade in DefineIndex(): it was continuing to access the
Hi all, On Tue, 28 Aug 2007, Andrew Dunstan wrote: > Date: Tue, 28 Aug 2007 12:34:46 -0400 > From: Andrew Dunstan <[EMAIL PROTECTED]> > Newsgroups: pgsql.hackers > Subject: Re: [COMMITTERS] pgsql: Fix brain fade in DefineIndex(): it was > continuing to access the > > > > Tom Lane wrote: > > Andrew Dunstan <[EMAIL PROTECTED]> writes: > > > >> Tom Lane wrote: > >> > >>> This particular issue could be implemented just by adding > >>> -DCLOBBER_CACHE_ALWAYS to CFLAGS (or CPPFLAGS if you want to be anal > >>> about it). I suppose that no new buildfarm mechanism is required --- > >>> someone just needs to set up an animal configured that way, and > >>> scheduled to run only maybe once a week or something like that. > >>> > > > > > >> Ah. Ok. That makes sense. How long does such a regression run usually take? > >> > > > > On my x86_64 machine (dual 2.8GHz Xeon EM64T) it's on the order of two > > or three hours --- I haven't timed it carefully, but somewhere along > > there. That's just for the core regression tests, I've never tried > > contrib or PL tests. > > > > It should be a separate animal, and not something that an existing one > > does every-so-often, or we might mistake anything it finds for an > > irreproducible transient failure. Consistent failures on the same > > animal will stand out of the noise, though. > > > > > > > > > I tried this on a little P3 I have lying around: > > [EMAIL PROTECTED] bf]$ ./run_build.pl --test --conf=figeater.conf > Mon Aug 27 17:03:55 2007: buildfarm run for figeater:HEAD starting > [17:03:55] checking out source ... > [17:04:17] checking if build run needed ... > [17:04:18] creating vpath build dir pgsql.11834 ... > [17:04:18] running configure ... > [17:06:06] running make ... > [17:31:14] running make check ... > [00:43:28] running make contrib ... > Branch: HEAD > Stage Contrib failed with status 2 > > > Good thing it failed - goodness only knows how long the extra runs would > have taken :-) > > Does someone have a box with lots of grunt that can spare some cycles > for a few hours once a week or so? I've just configure centaur (CentOS 5) like this. Do you need it for every version (8.1, 8.2) or just HEAD Do you need it just once a week or every run? I can also configure wharthog (unixware) like this if you need... > > cheers > > andrew > > > ---(end of broadcast)--- > TIP 3: Have you checked our extensive FAQ? > >http://www.postgresql.org/docs/faq > > -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Backend memory growing too much
Hi Andrew
On Tue, 17 Jul 2007, Andrew Dunstan wrote:
> Date: Tue, 17 Jul 2007 11:30:43 -0400
> From: Andrew Dunstan <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: pgsql-hackers list
> Subject: Re: [HACKERS] Backend memory growing too much
>
>
>
> [EMAIL PROTECTED] wrote:
> >
> > I don't know much about DBI/DBD but I know sqlgrey uses a lot of
> > prepare/prepare_cached statements.
> >
> >
>
> You can inhibit DBD::Pg from using server side prepares if you need to,
> by executing:
>
> $dbh->{pg_server_prepare} = 0;
>
> (as documented in the excellent DBD::Pg docs).
>
> cheers
>
> andrew
>
Thanks! That made the trick!
I assume this is because sqlgrey prepares statements (always the same) and
neither finish them.
Best regards
--
Olivier PRENANT Tel: +33-5-61-50-97-00 (Work)
15, Chemin des Monges+33-5-61-50-97-01 (Fax)
31190 AUTERIVE +33-6-07-63-80-64 (GSM)
FRANCE Email: [EMAIL PROTECTED]
--
Make your life a dream, make your dream a reality. (St Exupery)
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
[HACKERS] Backend memory growing too much
Hi everyone, I've been using sqlgrey for some time now and I'm very surprised by the memory taken by the backends to which sqlgrey is connected. look at process 4111 and 28108 . They roughly take twice the space the other backend take. Could there be a memory leak? I don't know much about DBI/DBD but I know sqlgrey uses a lot of prepare/prepare_cached statements. What could cause? shared_buffer is 400MB here. TIA -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) 2 S postgres 1610 1604 TS 80 20 0 e6c19540 107480 e6a773cc jun 29 ? 568:26 /databases/pgsql-v8.2/bin/postgres 2 S postgres 2441 1604 TS 80 20 0 e2f17fe0 107714 e33685b0 jun 29 ? 0:13 /databases/pgsql-v8.2/bin/postgres 42 S postgres 1604 1 TS 80 20 0 e6c3dfc0 107418 e69886ec jun 29 ? 8:18 /databases/pgsql-v8.2/bin/postgres 2 S postgres 1611 1604 TS 80 20 0 e6c88500 1737 e6a7723c jun 29 ? 136:30 /databases/pgsql-v8.2/bin/postgres 2 S postgres 2124 1604 TS 80 20 0 e2f17540 108188 e690a230 jun 29 ? 0:01 /databases/pgsql-v8.2/bin/postgres 2 S postgres 4111 1604 TS 80 20 0 ef1db500 256516 f73eb330 jul 15 ? 2:28 /databases/pgsql-v8.2/bin/postgres 2 S postgres 28673 1604 TS 80 20 0 d04aa540 107713 e7efc250 15:10:52 ? 0:00 /databases/pgsql-v8.2/bin/postgres 2 S postgres 28499 1604 TS 80 20 0 d9c7d500 107715 e32e0af0 15:09:31 ? 0:00 /databases/pgsql-v8.2/bin/postgres 2 S postgres 28108 1604 TS 80 20 0 d5171a60 223750 e7efb2c0 23:58:49 ? 2:18 /databases/pgsql-v8.2/bin/postgres 2 S postgres 28256 1604 TS 80 20 0 d1f5daa0 107713 de7f1480 15:06:26 ? 0:00 /databases/pgsql-v8.2/bin/postgres 2 S postgres 26463 1604 TS 80 20 0 df639fc0 107715 de52f1d0 14:40:09 ? 0:01 /databases/pgsql-v8.2/bin/postgres 2 S postgres 26464 1604 TS 80 20 0 d9c7b520 107711 e9acc9f0 14:40:09 ? 0:00 /databases/pgsql-v8.2/bin/postgres 2 S postgres 27972 1604 TS 80 20 0 e6bcdfe0 107711 e6a75dd0 15:01:10 ? 0:00 /databases/pgsql-v8.2/bin/postgres 2 S postgres 28720 1604 TS 80 20 0 dea14540 107713 e34c9c80 15:11:22 ? 0:00 /databases/pgsql-v8.2/bin/postgres ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] little PITR annoyance
Hi Simon, I'll be glad to test it for you when you're ready! Thanks for looking at this issue. Best regards, On Sun, 10 Jun 2007, Simon Riggs wrote: > Date: Sun, 10 Jun 2007 23:55:32 +0100 > From: Simon Riggs <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Cc: pgsql-hackers list > Subject: Re: [HACKERS] little PITR annoyance > > On Sun, 2007-06-10 at 20:48 +0200, [EMAIL PROTECTED] wrote: > > > > > > > My questions was: why don't we start the archiving *BEFORE* postmaster > > > > to > > > > make room. > > > > > > The archiver is executed from the postmaster, so thats not possible. > > > > > I'm aware of that, my point is maybe the archiver doesn't need postmaster > > to be fully operational (responding to db requests) to be started > > > We could investigate where best to put some code, but it wouldn't be > > > executed very frequently. > > I agree, OTOH, the more PITR is used on big busy db to more this may > > happend. > > > > > > Why not just execute the archive_command in a script, replacing > > > the .ready with .done files in archive_status directory when its > > > processed? > > > > > Sure, but if *I* can do it, why can't the system? > > > > What do you think, > > Just looked at the code. Does seem possible to start archiver earlier - > it has no hooks into anything else and doesn't need transactions. > > Starting archiver earlier would not be the only change required, since > recovery could be very short. That will take some thought on how to > resolve. > > I have other things pressing on me now, but I'll add this to my todo, > though I'll be relying on you to test it when I get round to it. > > -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] little PITR annoyance
Hi Simon, Sorry for replying so late... On Fri, 8 Jun 2007, Simon Riggs wrote: > Date: Fri, 08 Jun 2007 20:16:35 +0100 > From: Simon Riggs <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Cc: pgsql-hackers list > Subject: Re: [HACKERS] little PITR annoyance > > Hi Olivier, > > On Fri, 2007-06-08 at 11:41 +0200, [EMAIL PROTECTED] wrote: > > The problem is not with gzip or scp, it is that postmaster refuses to > > start because wal FS is full. > > > My questions was: why don't we start the archiving *BEFORE* postmaster to > > make room. > > The archiver is executed from the postmaster, so thats not possible. > I'm aware of that, my point is maybe the archiver doesn't need postmaster to be fully operational (responding to db requests) to be started > We could investigate where best to put some code, but it wouldn't be > executed very frequently. I agree, OTOH, the more PITR is used on big busy db to more this may happend. > > Why not just execute the archive_command in a script, replacing > the .ready with .done files in archive_status directory when its > processed? > Sure, but if *I* can do it, why can't the system? What do you think, > Best regards, -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] little PITR annoyance
Hi Simon, On Thu, 7 Jun 2007, Simon Riggs wrote: > Date: Thu, 07 Jun 2007 23:10:06 +0100 > From: Simon Riggs <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Cc: pgsql-hackers list > Subject: Re: [HACKERS] little PITR annoyance > > On Thu, 2007-06-07 at 17:01 +0200, [EMAIL PROTECTED] wrote: > > > I've benn biten twice by this one: > > I enabled archiving on both my pgsql servers. > > the archive command was a simple gzip on an nfs mounted dir. > > Now the nfs server crashed. > > Both wal space filled up until postgresql shuts itself down because of no > > more space for WAL. > > That perfectly normal and expected. > > > > What I did'nt expect and don't understand is that postgresql refused to > > start up after the nfs server was up and running until I added some more > > space on the WAL fs although if it had started archiving , > > space would have been there . > > > > I wonder if archiving could start before postgresql at least to make a > > little room for database engine to really start. > > gzip write a new file and then deletes the old, doesn't it? So it must > require space on the xlog drive. > > Does it still fail if you avoid using gzip and just use scp? The problem is not with gzip or scp, it is that postmaster refuses to start because wal FS is full. My questions was: why don't we start the archiving *BEFORE* postmaster to make room. Another related question would be: What if postmaster instead of shutting down in that case, refused connection until archiving is back? Many thanks > > -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] little PITR annoyance
Hi all, I've benn biten twice by this one: I enabled archiving on both my pgsql servers. the archive command was a simple gzip on an nfs mounted dir. Now the nfs server crashed. Both wal space filled up until postgresql shuts itself down because of no more space for WAL. That perfectly normal and expected. What I did'nt expect and don't understand is that postgresql refused to start up after the nfs server was up and running until I added some more space on the WAL fs although if it had started archiving , space would have been there . I wonder if archiving could start before postgresql at least to make a little room for database engine to really start. Hope I'm clear... Thank you for your attention Best Regards -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] misread release notes
Hi Tom, On Tue, 6 Feb 2007, Tom Lane wrote: > Date: Tue, 06 Feb 2007 11:50:56 -0500 > From: Tom Lane <[EMAIL PROTECTED]> > To: ohp@pyrenet.fr > Cc: pgsql-hackers list > Subject: Re: [HACKERS] misread release notes > > ohp@pyrenet.fr writes: > > I read the "fix incorrect permission check in > > information_schema_key_column_usage_view" chapter in HISTORY far too fast > > and fed psql on each database with share/information_schema.sql. > > Too late to stop it! > > What did I do wrong, and how can I go backwards (I imagine %I broke > > something!) > > I don't think you changed anything --- none of the commands say OR REPLACE > so they'd just all fail. Yes but I saw a lot of inserts... > > regards, tom lane > -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: ohp@pyrenet.fr -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] misread release notes
Hi all, Methinks I made a big mistake when swapping from 8.2.1 to 8.2.2 I read the "fix incorrect permission check in information_schema_key_column_usage_view" chapter in HISTORY far too fast and fed psql on each database with share/information_schema.sql. Too late to stop it! What did I do wrong, and how can I go backwards (I imagine %I broke something!) Unrelated, I have problem with conforming string: adding a E is easy in C or PHP but SpamAssassin has this plpgsql function : CREATE OR REPLACE FUNCTION put_tokens(inuserid INTEGER, intokenary BYTEA[], inspam_count INTEGER, inham_count INTEGER, inatime INTEGER) RETURNS VOID AS ' DECLARE _token BYTEA; new_tokens INTEGER := 0; BEGIN for i in array_lower(intokenary, 1) .. array_upper(intokenary, 1) LOOP _token := intokenary[i]; UPDATE bayes_token SET spam_count = greatest_int(spam_count + inspam_count, 0), ham_count = greatest_int(ham_count + inham_count, 0), atime = greatest_int(atime, inatime) WHERE id = inuserid AND token = _token; IF NOT FOUND THEN -- we do not insert negative counts, just return true IF NOT (inspam_count < 0 OR inham_count < 0) THEN INSERT INTO bayes_token (id, token, spam_count, ham_count, atime) VALUES (inuserid, _token, inspam_count, inham_count, inatime); IF FOUND THEN new_tokens := new_tokens + 1; END IF; END IF; END IF; END LOOP; IF new_tokens > 0 AND inatime > 0 THEN UPDATE bayes_vars SET token_count = token_count + new_tokens, newest_token_age = greatest_int(newest_token_age, inatime), oldest_token_age = least_int(oldest_token_age, inatime) WHERE id = inuserid; ELSEIF new_tokens > 0 AND NOT inatime > 0 THEN UPDATE bayes_vars SET token_count = token_count + new_tokens WHERE id = inuserid; ELSEIF NOT new_tokens > 0 AND inatime > 0 THEN UPDATE bayes_vars SET newest_token_age = greatest_int(newest_token_age, inatime), oldest_token_age = least_int(oldest_token_age, inatime) WHERE id = inuserid; END IF; RETURN; END; ' LANGUAGE 'plpgsql'; As you see, token is bytea where do I put the E in the insert query? Keep the good job! Regards -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: ohp@pyrenet.fr -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] libxml on unixware
But wait... it works fine as of HEAD today... Sorry for the noise, will try to --enable-xml on warthog soon. In the mean time, Merry Xmas to all On Sun, 24 Dec 2006 ohp@pyrenet.fr wrote: > Date: Sun, 24 Dec 2006 14:05:21 +0100 (CET) > From: ohp@pyrenet.fr > To: Tom Lane <[EMAIL PROTECTED]> > Cc: pgsql-hackers list > Subject: Re: [HACKERS] libxml on unixware > > Hi Tom, > > It still pass with --enable-debug only, > > So it seems an optimizer problem. > > What's next? > > Best regards > On Sat, 23 Dec 2006, Tom Lane wrote: > > > Date: Sat, 23 Dec 2006 11:31:21 -0500 > > From: Tom Lane <[EMAIL PROTECTED]> > > To: ohp@pyrenet.fr > > Cc: pgsql-hackers list > > Subject: Re: [HACKERS] libxml on unixware > > > > ohp@pyrenet.fr writes: > > > In order to send a back trace, I recompiled with --enable-debug > > > --enable-cassert and regression test is ok! > > > > Oh, that's interesting! Try it with just --enable-debug. > > > > regards, tom lane > > > > -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: ohp@pyrenet.fr -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] libxml on unixware
Hi Tom, It still pass with --enable-debug only, So it seems an optimizer problem. What's next? Best regards On Sat, 23 Dec 2006, Tom Lane wrote: > Date: Sat, 23 Dec 2006 11:31:21 -0500 > From: Tom Lane <[EMAIL PROTECTED]> > To: ohp@pyrenet.fr > Cc: pgsql-hackers list > Subject: Re: [HACKERS] libxml on unixware > > ohp@pyrenet.fr writes: > > In order to send a back trace, I recompiled with --enable-debug > > --enable-cassert and regression test is ok! > > Oh, that's interesting! Try it with just --enable-debug. > > regards, tom lane > -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: ohp@pyrenet.fr -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] libxml on unixware
On Sat, 23 Dec 2006, Andrew Dunstan wrote: > Date: Sat, 23 Dec 2006 11:36:04 -0600 (CST) > From: Andrew Dunstan <[EMAIL PROTECTED]> > To: ohp@pyrenet.fr, pgsql-hackers list > Subject: Re: [HACKERS] libxml on unixware > > Tom Lane wrote: > > ohp@pyrenet.fr writes: > >> In order to send a back trace, I recompiled with --enable-debug > >> --enable-cassert and regression test is ok! > > > > Oh, that's interesting! Try it with just --enable-debug. > > > > Is this one of those compilers where turning debug on turns off optimisation? Yes! As Tom suggested, I will try with just enable debug > > cheers > > andrew > > > > -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: ohp@pyrenet.fr -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
[HACKERS] libxml on unixware
RANCE Email: ohp@pyrenet.fr -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] unixware and --with-ldap
Hi Albe, On Mon, 18 Dec 2006, Albe Laurenz wrote: > Date: Mon, 18 Dec 2006 09:31:35 +0100 > From: Albe Laurenz <[EMAIL PROTECTED]> > To: ohp@pyrenet.fr, Tom Lane <[EMAIL PROTECTED]> > Cc: pgsql-hackers list > Subject: RE: [HACKERS] unixware and --with-ldap > > >>> If libldap_r.so does require the same libs, please add > $EXTRA_LDAP_LIBS > >>> to the 'LDAP_LIBS_FE="-lldap_r"' line as well. > >> > >> Actually, I did that in the patch-as-committed. It seems to me that > >> it's probably harmless even if not needed. > > > > I have tried --with-thread-safety and configure fails on ldap check > > because for some reason CTHREAD_FLAGS (-Kpthread for UW) is missing > > on compile command, although present before that. I can't find why > > You mean PTHREAD_FLAGS, right? > Nope,I mean PTHREAD_CFLAGS witch is defined in src/templates/unixware > If it is present in line 1118, it should also be present in line 1133. > > Can you verify that the part on configure.in between 1065 and 1118, > -Kpthread is correctly set on Unixware? > It is defined, my guts felling is that AC_SUBSTs lines 1470,1471 do something weird. > If not, thread support for Unixware is probebly broken. > It is, because when searching for ldap_r succeeds by forcing PTHREAD_CFLAGS to be used, configure still fails when testing for thread safety compiling src/test/thread/thread_test.c. This fails because unixware's sigwait has only one arg although (according to doc you can see at http://www.pyrenet.fr:8458) it's thread safe... > If yes, something strange is going on. > indeed > Yours, > Laurenz Albe > Best regards -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: ohp@pyrenet.fr -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] unixware and --with-ldap
On Fri, 15 Dec 2006, Tom Lane wrote: > Date: Fri, 15 Dec 2006 10:20:44 -0500 > From: Tom Lane <[EMAIL PROTECTED]> > To: Albe Laurenz <[EMAIL PROTECTED]> > Cc: ohp@pyrenet.fr, pgsql-hackers list > Subject: Re: [HACKERS] unixware and --with-ldap > > "Albe Laurenz" <[EMAIL PROTECTED]> writes: > > You left out the case where --enable_thread_safety is specified. > > ... > > If libldap_r.so does require the same libs, please add $EXTRA_LDAP_LIBS > > to the 'LDAP_LIBS_FE="-lldap_r"' line as well. > > Actually, I did that in the patch-as-committed. It seems to me that > it's probably harmless even if not needed. > > regards, tom lane > I have tried --with-thread-safety and configure fails on ldap check because for some reason CTHREAD_FLAGS (-Kpthread for UW) is missing on compile command, although present before that. I can't find why Best regards -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: ohp@pyrenet.fr -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] unixware and --with-ldap
Hi Albe, Thanks for your remarks On Fri, 15 Dec 2006, Albe Laurenz wrote: > Date: Fri, 15 Dec 2006 09:54:13 +0100 > From: Albe Laurenz <[EMAIL PROTECTED]> > To: ohp@pyrenet.fr, Tom Lane <[EMAIL PROTECTED]> > Cc: pgsql-hackers list > Subject: RE: [HACKERS] unixware and --with-ldap > > > Here's the diff for configure.in that works for me. > > I have a concern about this patch: > I agree > > if test "$enable_thread_safety" = yes; then > > # on some platforms ldap_r fails to link without PTHREAD_LIBS > > AC_CHECK_LIB(ldap_r, ldap_simple_bind, [], > >[AC_MSG_ERROR([library 'ldap_r' is required for > LDAP])], > > ! [$PTHREAD_LIBS]) > > LDAP_LIBS_FE="-lldap_r" > > else > > ! LDAP_LIBS_FE="-lldap" > > fi > > --- 1122,1139 > > if test "$enable_thread_safety" = yes; then > > # on some platforms ldap_r fails to link without PTHREAD_LIBS > > AC_CHECK_LIB(ldap_r, ldap_simple_bind, [], > >[AC_MSG_ERROR([library 'ldap_r' is required for > LDAP])], > > ! [$PTHREAD_LIBS $EXTRA_LDAP_LIBS]) > > LDAP_LIBS_FE="-lldap_r" > > else > > ! LDAP_LIBS_FE="-lldap $EXTRA_LDAP_LIBS" > > fi > > You left out the case where --enable_thread_safety is specified. > In that case, the frontend has to be linked with libldap_r.so > instead of libldap.so. > Yes, this was on purpose, my goal is to try to make a second patch when... > Does libldap_r.so _not_ require any extra libraries for linking? > I don't know, hence the mid-patch > If it does require extra libraries, are they the same as for the > thread-unsafe library (on Linux, that is the case)? > Not sure what you mean > If libldap_r.so does require the same libs, please add $EXTRA_LDAP_LIBS > to the 'LDAP_LIBS_FE="-lldap_r"' line as well. > Will do > If libldap_r.so requires different additional libraries, a second > variable would be in place. > OF course > Could you test compiling with --enable_thread_safety ? > Will do, but keep in mind that --enable_thread_safety doesn't work too well for unixware (see template/Makefile.unixware) However, if someone can help me, I'd love to fix the problem > Yours, > Laurenz Albe > Best regards -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: ohp@pyrenet.fr -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] unixware and --with-ldap
Dear Tom, Thanks for you advice. Here's the diff for configure.in that works for me. Best regards --- *** configure.in.orig jeu déc 14 18:35:27 2006 --- configure.injeu déc 14 18:35:37 2006 *** *** 1122,1137 if test "$with_ldap" = yes ; then _LIBS="$LIBS" if test "$PORTNAME" != "win32"; then ! AC_CHECK_LIB(ldap, ldap_bind, [], [AC_MSG_ERROR([library 'ldap' is required for LDAP])]) ! LDAP_LIBS_BE="-lldap" if test "$enable_thread_safety" = yes; then # on some platforms ldap_r fails to link without PTHREAD_LIBS AC_CHECK_LIB(ldap_r, ldap_simple_bind, [], [AC_MSG_ERROR([library 'ldap_r' is required for LDAP])], ! [$PTHREAD_LIBS]) LDAP_LIBS_FE="-lldap_r" else ! LDAP_LIBS_FE="-lldap" fi else AC_CHECK_LIB(wldap32, ldap_bind, [], [AC_MSG_ERROR([library 'wldap32' is required for LDAP])]) --- 1122,1139 if test "$with_ldap" = yes ; then _LIBS="$LIBS" if test "$PORTNAME" != "win32"; then ! AC_CHECK_LIB(ldap, ldap_bind, [], ! [AC_MSG_ERROR([library 'ldap' is required for LDAP])], ! [$EXTRA_LDAP_LIBS]) ! LDAP_LIBS_BE="-lldap $EXTRA_LDAP_LIBS" if test "$enable_thread_safety" = yes; then # on some platforms ldap_r fails to link without PTHREAD_LIBS AC_CHECK_LIB(ldap_r, ldap_simple_bind, [], [AC_MSG_ERROR([library 'ldap_r' is required for LDAP])], ! [$PTHREAD_LIBS $EXTRA_LDAP_LIBS]) LDAP_LIBS_FE="-lldap_r" else ! LDAP_LIBS_FE="-lldap $EXTRA_LDAP_LIBS" fi else AC_CHECK_LIB(wldap32, ldap_bind, [], [AC_MSG_ERROR([library 'wldap32' is required for LDAP])]) On Mon, 11 Dec 2006, Tom Lane wrote: > Date: Mon, 11 Dec 2006 11:26:14 -0500 > From: Tom Lane <[EMAIL PROTECTED]> > To: Andrew Dunstan <[EMAIL PROTECTED]> > Cc: ohp@pyrenet.fr, pgsql-hackers list > Subject: Re: [HACKERS] unixware and --with-ldap > > Andrew Dunstan <[EMAIL PROTECTED]> writes: > > The right way to do this I think is to put an entry adjusting LIBS in > > src/makefiles/Makefile.unixware, but first it looks like we need to > > propagate the with-ldap switch into src/Makefile.global > > The Makefile is far too late --- this has to be adjusted at configure > time, else configure will conclude that libldap isn't available. > (I assume that Unixware's linker is sane enough that the link test > will fail without the supporting libraries.) > > I'd be inclined to do something like add > > EXTRA_LDAP_LIBS="-llber -lresolv" > > in src/template/unixware, and then in configure.in add this where > needed: > > if test "$with_ldap" = yes ; then > _LIBS="$LIBS" > if test "$PORTNAME" != "win32"; then > AC_CHECK_LIB(ldap, ldap_bind, [$EXTRA_LDAP_LIBS], [AC_MSG_ERROR([library > 'ldap' is required for LDAP])]) > LDAP_LIBS_BE="-lldap $EXTRA_LDAP_LIBS" > if test "$enable_thread_safety" = yes; then > # on some platforms ldap_r fails to link without PTHREAD_LIBS > AC_CHECK_LIB(ldap_r, ldap_simple_bind, [$EXTRA_LDAP_LIBS], > [AC_MSG_ERROR([library 'ldap_r' is required for LDAP])], > [$PTHREAD_LIBS]) > LDAP_LIBS_FE="-lldap_r $EXTRA_LDAP_LIBS" > else > LDAP_LIBS_FE="-lldap $EXTRA_LDAP_LIBS" > fi > else > AC_CHECK_LIB(wldap32, ldap_bind, [], [AC_MSG_ERROR([library 'wldap32' is > required for LDAP])]) > LDAP_LIBS_FE="-lwldap32" > LDAP_LIBS_BE="-lwldap32" > fi > LIBS="$_LIBS" > fi > > I'm not in a position to test that though ... > > regards, tom lane > -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: ohp@pyrenet.fr -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] unixware and --with-ldap
Hi Tom, I was in the process of testing this. But I believe tweaking with configure.in will not help me as I have no way to regenerate configure... Please advise. Best regards, On Tue, 12 Dec 2006, Tom Lane wrote: > Date: Tue, 12 Dec 2006 11:04:08 -0500 > From: Tom Lane <[EMAIL PROTECTED]> > To: Albe Laurenz <[EMAIL PROTECTED]> > Cc: ohp@pyrenet.fr, pgsql-hackers list > Subject: Re: [HACKERS] unixware and --with-ldap > > "Albe Laurenz" <[EMAIL PROTECTED]> writes: > > Shouldn't that be > > AC_CHECK_LIB(ldap_r, ldap_simple_bind, [], > >[AC_MSG_ERROR([library 'ldap_r' is required for > > LDAP])], > >[$PTHREAD_LIBS $EXTRA_LDAP_LIBS]) > > Ooops, of course. Like I said, untested ;-) > > regards, tom lane > -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: ohp@pyrenet.fr -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] unixware and --with-ldap
On Tue, 12 Dec 2006, Albe Laurenz wrote: > Date: Tue, 12 Dec 2006 16:42:50 +0100 > From: Albe Laurenz <[EMAIL PROTECTED]> > To: ohp@pyrenet.fr, pgsql-hackers list , > [EMAIL PROTECTED] > Subject: RE: [HACKERS] unixware and --with-ldap > > Olivier PRENANT wrote: > > > When I swithed to the newest version og pgbuildfarm, I noticed that > > --with-ldap (now by defaut) didn't work on UnixWare. > > > > This is because, on Unixware, ldap needs lber and resolv. > > Is libldap a static library on that system? No > > Or do shared libraries on Unixware generally 'not remember' > the libraries they were linked against (this would be strange). > Hmm Somtimes > Or was libldap not linked against liblber and libresolv? > Dunno! Did'nt do it myself, it comes with the system > Tom Lane suggested to change configure.in like this: > > > AC_CHECK_LIB(ldap_r, ldap_simple_bind, [$EXTRA_LDAP_LIBS], > >[AC_MSG_ERROR([library 'ldap_r' is required for > LDAP])], > >[$PTHREAD_LIBS]) > > Shouldn't that be > > AC_CHECK_LIB(ldap_r, ldap_simple_bind, [], > [AC_MSG_ERROR([library 'ldap_r' is required for > LDAP])], > [$PTHREAD_LIBS $EXTRA_LDAP_LIBS]) > > Yours, > Laurenz Albe > -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: ohp@pyrenet.fr -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] unixware and --with-ldap
Hi Tom, Thanks for your help, I will try it ASAP and report maybe tonighgt CET. Also, Makefile.port needs a little patch that I'll send to. On Mon, 11 Dec 2006, Tom Lane wrote: > Date: Mon, 11 Dec 2006 11:26:14 -0500 > From: Tom Lane <[EMAIL PROTECTED]> > To: Andrew Dunstan <[EMAIL PROTECTED]> > Cc: ohp@pyrenet.fr, pgsql-hackers list > Subject: Re: [HACKERS] unixware and --with-ldap > > Andrew Dunstan <[EMAIL PROTECTED]> writes: > > The right way to do this I think is to put an entry adjusting LIBS in > > src/makefiles/Makefile.unixware, but first it looks like we need to > > propagate the with-ldap switch into src/Makefile.global > > The Makefile is far too late --- this has to be adjusted at configure > time, else configure will conclude that libldap isn't available. > (I assume that Unixware's linker is sane enough that the link test > will fail without the supporting libraries.) > > I'd be inclined to do something like add > > EXTRA_LDAP_LIBS="-llber -lresolv" > > in src/template/unixware, and then in configure.in add this where > needed: > > if test "$with_ldap" = yes ; then > _LIBS="$LIBS" > if test "$PORTNAME" != "win32"; then > AC_CHECK_LIB(ldap, ldap_bind, [$EXTRA_LDAP_LIBS], [AC_MSG_ERROR([library > 'ldap' is required for LDAP])]) > LDAP_LIBS_BE="-lldap $EXTRA_LDAP_LIBS" > if test "$enable_thread_safety" = yes; then > # on some platforms ldap_r fails to link without PTHREAD_LIBS > AC_CHECK_LIB(ldap_r, ldap_simple_bind, [$EXTRA_LDAP_LIBS], > [AC_MSG_ERROR([library 'ldap_r' is required for LDAP])], > [$PTHREAD_LIBS]) > LDAP_LIBS_FE="-lldap_r $EXTRA_LDAP_LIBS" > else > LDAP_LIBS_FE="-lldap $EXTRA_LDAP_LIBS" > fi > else > AC_CHECK_LIB(wldap32, ldap_bind, [], [AC_MSG_ERROR([library 'wldap32' is > required for LDAP])]) > LDAP_LIBS_FE="-lwldap32" > LDAP_LIBS_BE="-lwldap32" > fi > LIBS="$_LIBS" > fi > > I'm not in a position to test that though ... > > regards, tom lane > -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: ohp@pyrenet.fr -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] unixware and --with-ldap
Thanks for replying, You are right but I have no knowedge on howto popagate this to Makefile.unixware. On Mon, 11 Dec 2006, Andrew Dunstan wrote: > Date: Mon, 11 Dec 2006 10:03:04 -0500 > From: Andrew Dunstan <[EMAIL PROTECTED]> > To: ohp@pyrenet.fr > Cc: pgsql-hackers list > Subject: Re: [HACKERS] unixware and --with-ldap > > ohp@pyrenet.fr wrote: > > Hi all, > > > > When I swithed to the newest version og pgbuildfarm, I noticed that > > --with-ldap (now by defaut) didn't work on UnixWare. > > > > This is because, on Unixware, ldap needs lber and resolv. > > > > Not being a configure guru, I made the change bellow locally and that > > works for me. > > Surely, one of you hackers can come up with a better solution! > > > > > > > If you mangle the source tree buildfarm will usually refuse to run. In > any case, we certainly can't hack the configure script - it is > autogenerated. I did'nt touch any thing on buildfarm, I worked on a fresh cvs update... > > The right way to do this I think is to put an entry adjusting LIBS in > src/makefiles/Makefile.unixware, but first it looks like we need to > propagate the with-ldap switch into src/Makefile.global > > cheers > > andrew > -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: ohp@pyrenet.fr -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
[HACKERS] unixware and --with-ldap
Hi all,
When I swithed to the newest version og pgbuildfarm, I noticed that
--with-ldap (now by defaut) didn't work on UnixWare.
This is because, on Unixware, ldap needs lber and resolv.
Not being a configure guru, I made the change bellow locally and that
works for me.
Surely, one of you hackers can come up with a better solution!
*** configure.orig lun déc 11 14:58:55 2006
--- configure lun déc 11 15:22:06 2006
***
*** 17185,17191
echo $ECHO_N "(cached) $ECHO_C" >&6
else
ac_check_lib_save_LIBS=$LIBS
! LIBS="-lldap $LIBS"
cat >conftest.$ac_ext <<_ACEOF
/* confdefs.h. */
_ACEOF
--- 17185,17191
echo $ECHO_N "(cached) $ECHO_C" >&6
else
ac_check_lib_save_LIBS=$LIBS
! LIBS="-lldap -llber -lresolv $LIBS"
cat >conftest.$ac_ext <<_ACEOF
/* confdefs.h. */
_ACEOF
***
*** 17248,17254
#define HAVE_LIBLDAP 1
_ACEOF
! LIBS="-lldap $LIBS"
else
{ { echo "$as_me:$LINENO: error: library 'ldap' is required for LDAP" >&5
--- 17248,17254
#define HAVE_LIBLDAP 1
_ACEOF
! LIBS="-lldap -llber -lresolv $LIBS"
else
{ { echo "$as_me:$LINENO: error: library 'ldap' is required for LDAP" >&5
***
*** 17256,17262
{ (exit 1); exit 1; }; }
fi
! LDAP_LIBS_BE="-lldap"
if test "$enable_thread_safety" = yes; then
# on some platforms ldap_r fails to link without PTHREAD_LIBS
--- 17256,17262
{ (exit 1); exit 1; }; }
fi
! LDAP_LIBS_BE="-lldap -llber -lresolv"
if test "$enable_thread_safety" = yes; then
# on some platforms ldap_r fails to link without PTHREAD_LIBS
***
*** 17339,17345
LDAP_LIBS_FE="-lldap_r"
else
! LDAP_LIBS_FE="-lldap"
fi
else
--- 17339,17345
LDAP_LIBS_FE="-lldap_r"
else
! LDAP_LIBS_FE="-lldap -llber -lresolv"
fi
else
When I have time, I intend to update the SCO FAQ if someone can tell me
what should be in...
Many thanks for the great release!!!
--
Olivier PRENANT Tel: +33-5-61-50-97-00 (Work)
15, Chemin des Monges+33-5-61-50-97-01 (Fax)
31190 AUTERIVE +33-6-07-63-80-64 (GSM)
FRANCE Email: ohp@pyrenet.fr
--
Make your life a dream, make your dream a reality. (St Exupery)
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] wartho failing
Removing #include $(top_srcdir)/contrib/contrib-global.mk in sslinfo Makefile makes the problem go away... Hope it helps On Wed, 6 Sep 2006, Martijn van Oosterhout wrote: > Date: Wed, 6 Sep 2006 13:49:21 +0200 > From: Martijn van Oosterhout > To: ohp@pyrenet.fr > Cc: pgsql-hackers list > Subject: Re: [HACKERS] wartho failing > > On Wed, Sep 06, 2006 at 01:32:53PM +0200, ohp@pyrenet.fr wrote: > > Hi, > > > > Warthog has been failing for the last 12 hours or so on contrib/sslinfo > > > > It seems that readline and termcap should not be linked with. > > > > What can I do to help? > > Classic putting-non-PIC-code-in-a-shared-library error. You can't do > that; for some reason it's picked up the static version of termcap. > > In any case, it shouldn't be using termcap at all. Something in the > makefile is including it obviously... > > Have a nice day, > -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: ohp@pyrenet.fr -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] wartho failing
Hi, Warthog has been failing for the last 12 hours or so on contrib/sslinfo It seems that readline and termcap should not be linked with. What can I do to help? Also, now that beta is approaching, warthog runs his HEAD buikd every 8 hours. Do we need it more often? Regards, -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: ohp@pyrenet.fr -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Warthog failing
Hi Tom, It now works like a charm! Many thanks. Best regards, On Sun, 13 Aug 2006, Tom Lane wrote: > Date: Sun, 13 Aug 2006 14:00:37 -0400 > From: Tom Lane <[EMAIL PROTECTED]> > To: ohp@pyrenet.fr > Cc: pgsql-hackers list > Subject: Re: [HACKERS] Warthog failing > > ohp@pyrenet.fr writes: > > Since last night, Warthog build farm member (unixware) is failing the > > returning regression test. > > Mea culpa --- the regression test was unintentionally displaying > processing-order-dependent behavior, by joining an updated row to > more than one row of another table. Should be fixed now. > > regards, tom lane > -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: ohp@pyrenet.fr -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] Warthog failing
Hi all, Since last night, Warthog build farm member (unixware) is failing the returning regression test. Regression.diffs is : *** ./expected/returning.outSat Aug 12 04:52:06 2006 --- ./results/returning.out Sun Aug 13 14:51:07 2006 *** *** 155,162 WHERE foo.f1 = i.q1 RETURNING *; f1 | f2 | f3 | f4 | q1 | q2 ! -+---+--+--+-+- ! 123 | child | 1998 | 1098 | 123 | 456 (1 row) SELECT * FROM foo; --- 155,162 WHERE foo.f1 = i.q1 RETURNING *; f1 | f2 | f3 | f4 | q1 |q2 ! -+---+--+--+-+-- ! 123 | child | 1998 | 1098 | 123 | 4567890123456789 (1 row) SELECT * FROM foo; *** *** 177,184 WHERE foo.f1 = i.q1 RETURNING *; f1 | f2 | f3 | f4 | q1 | q2 ! -+---+--+--+-+- ! 123 | child | 1998 | 1098 | 123 | 456 (1 row) SELECT * FROM foo; --- 177,184 WHERE foo.f1 = i.q1 RETURNING *; f1 | f2 | f3 | f4 | q1 |q2 ! -+---+--+--+-+-- ! 123 | child | 1998 | 1098 | 123 | 4567890123456789 (1 row) SELECT * FROM foo; == What can I do to help debugging this? TIA -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: ohp@pyrenet.fr -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] pltcl -- solved
Hi Tom, On Tue, 20 Jun 2006, Tom Lane wrote: > Date: Tue, 20 Jun 2006 12:42:24 -0400 > From: Tom Lane <[EMAIL PROTECTED]> > To: ohp@pyrenet.fr > Cc: pgsql-hackers list > Subject: Re: [HACKERS] pltcl -- solved > > ohp@pyrenet.fr writes: > > Just a note that pltcl is now passing regression tests on Unixware. > > For some unexplained reason, it did'nt pass with tcl-8.5 but is ok with > > tcl -8.4.13. > > AFAICT there is no "tcl 8.5" yet; there is an alpha release tcl8.5a4 > which is stated to still be under active feature development. Yes > I installed it locally and pltcl seems to work OK with it, so I'm not > sure what problem you saw. One possibility is that the Tcl folk > recommend against building extensions with a different compiler than > was used to build Tcl ... so if you tried to build pltcl with gcc > against a Tcl compiled with Unixware cc, or vice versa, that might be > the core of the problem. It's not the case. > > Anyway I'm not too concerned about misbehavior with an alpha Tcl release > --- it's as likely to be their bug as ours. > I agree, I'll test it again when tcl 8.5 is out... > regards, tom lane > Best regards -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: ohp@pyrenet.fr -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] pltcl -- solved
Hi all Just a note that pltcl is now passing regression tests on Unixware. For some unexplained reason, it did'nt pass with tcl-8.5 but is ok with tcl -8.4.13. build farm build script updated accordingly. My next try will be python. Regards -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: ohp@pyrenet.fr -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] pl/tcl again.
Hi all,
I'm still fighting with pltcl test that doesn't return the error message
when "elog ERROR "message" is called.
I've played witrh pltcl.c pltcl_error and removed the calls to PG_TRY,
PG_CATCH and PG_ENDTRY to proove that elog it self had a problem...
How can I check what happens in elog?
Each time elog is called with a level of ERROR,FATAL, PG_CATCH runs.
Also here are the server logs for pltcl checks.
It's amazing that the actual error message is in context...
LOG: database system was shut down at 2006-06-19 16:48:47 MET DST
LOG: checkpoint record is at 0/22C6CE0
LOG: redo record is at 0/22C6CE0; undo record is at 0/0; shutdown TRUE
LOG: next transaction ID: 9130; next OID: 38895
LOG: next MultiXactId: 1; next MultiXactOffset: 0
LOG: database system is ready
LOG: transaction ID wrap limit is 1073745208, limited by database "regression"
LOG: transaction ID wrap limit is 1073745208, limited by database "regression"
LOG: transaction ID wrap limit is 1073745208, limited by database "regression"
ERROR: role "regressgroup1" does not exist
ERROR:
CONTEXT: duplicate key '1', 'KEY1-3' for T_pkey2
while executing
"elog ERROR "duplicate key '$NEW(key1)', '$NEW(key2)' for T_pkey2""
invoked from within
"if {$n > 0} {
elog ERROR \
"duplicate key '$NEW(key1)', '$NEW(key2)' for T_pkey2"
}"
(procedure "__PLTcl_proc_38909_trigger_38900" line 32)
invoked from within
"__PLTcl_proc_38909_trigger_38900 pkey2_before 38900 {{} key1 key2 txt}
BEFORE ROW INSERT {key1 1 key2 {KEY1-3 } txt {should fail
..."
ERROR:
CONTEXT: key for t_dta1 not in t_pkey1
while executing
"elog ERROR "key for $GD($planrel) not in $keyrel""
(procedure "__PLTcl_proc_38913_trigger_38902" line 92)
invoked from within
"__PLTcl_proc_38913_trigger_38902 dta1_before 38902 {{} tkey ref1 ref2}
BEFORE ROW INSERT {tkey {trec 4} ref1 1 ref2 {key1-4 }} {}
ref..."
ERROR:
CONTEXT: key for t_dta2 not in t_pkey2
while executing
"elog ERROR "key for $GD($planrel) not in $keyrel""
(procedure "__PLTcl_proc_38913_trigger_38904" line 92)
invoked from within
"__PLTcl_proc_38913_trigger_38904 dta2_before 38904 {{} tkey ref1 ref2}
BEFORE ROW INSERT {tkey {trec 4} ref1 1 ref2 {KEY1-4 }} {}
ref..."
ERROR:
CONTEXT: key '1', 'key1-1 ' referenced by T_dta1
while executing
"elog ERROR "key '$OLD(key1)', '$OLD(key2)' referenced by T_dta1""
invoked from within
"if {$check_old_ref} {
#
# Check for references to OLD
#
set n [spi_execp -count 1 $GD(plan_dta1) [list $OLD(key1)
$OLD(key2)]]
if {$n > 0}..."
(procedure "__PLTcl_proc_38907_trigger_38898" line 79)
invoked from within
"__PLTcl_proc_38907_trigger_38898 pkey1_before 38898 {{} key1 key2 txt}
BEFORE ROW UPDATE {key1 1 key2 {key1-9 } txt {test key
..."
ERROR:
CONTEXT: key '1', 'key1-2 ' referenced by T_dta1
while executing
"elog ERROR "key '$OLD(key1)', '$OLD(key2)' referenced by T_dta1""
invoked from within
"if {$check_old_ref} {
#
# Check for references to OLD
#
set n [spi_execp -count 1 $GD(plan_dta1) [list $OLD(key1)
$OLD(key2)]]
if {$n > 0}..."
(procedure "__PLTcl_proc_38907_trigger_38898" line 79)
invoked from within
"__PLTcl_proc_38907_trigger_38898 pkey1_before 38898 {{} key1 key2 txt}
BEFORE ROW DELETE {} {key1 1 key2 {key1-2 } txt {test key
..."
NOTICE: updated 1 entries in T_dta2 for new key in T_pkey2
NOTICE: deleted 1 entries from T_dta2
--
Olivier PRENANT Tel: +33-5-61-50-97-00 (Work)
15, Chemin des Monges+33-5-61-50-97-01 (Fax)
31190 AUTERIVE +33-6-07-63-80-64 (GSM)
FRANCE Email: ohp@pyrenet.fr
--
Make your life a dream, make your dream a reality. (St Exupery)
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
Re: [HACKERS] pl/tcl regression failed
Hi Tom, I had a look, and don't really know what to do! I played with pltcl.c line 1318, adding a like like elog(LEVEL,UTF_U2E(argv[2])); where LEVEL is WARNING,INFO,ERROR,DEBUG2,LOG,NOTICE so far, WARNING,INFO,NOTICE work fine, not the others... I just don't understand, and don't really know where to go from here. If needed, I can open an account to someone who wants to try. Regards, On Sun, 11 Jun 2006, Tom Lane wrote: > Date: Sun, 11 Jun 2006 15:03:39 -0400 > From: Tom Lane <[EMAIL PROTECTED]> > To: ohp@pyrenet.fr > Cc: pgsql-hackers list > Subject: Re: [HACKERS] pl/tcl regression failed > > ohp@pyrenet.fr writes: > > I have finished buildfarm setup, just waiting for my credentials. > > However, I've install tcl 8.5a and regression tests fail like this: > > ISTM it's just cosmetic, just want to share... > > Not showing the content of error messages is hardly "cosmetic"; it's a > serious loss of functionality. Want to investigate why that's happening? > > regards, tom lane > -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: ohp@pyrenet.fr -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] pl/tcl regression failed
On Sun, 11 Jun 2006, Tom Lane wrote: > Date: Sun, 11 Jun 2006 15:03:39 -0400 > From: Tom Lane <[EMAIL PROTECTED]> > To: ohp@pyrenet.fr > Cc: pgsql-hackers list > Subject: Re: [HACKERS] pl/tcl regression failed > > ohp@pyrenet.fr writes: > > I have finished buildfarm setup, just waiting for my credentials. > > However, I've install tcl 8.5a and regression tests fail like this: > > ISTM it's just cosmetic, just want to share... > > Not showing the content of error messages is hardly "cosmetic"; it's a > serious loss of functionality. Want to investigate why that's happening? > > regards, tom lane > I'm not a tcl expert, but I'll have a look tomorrow.. -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: ohp@pyrenet.fr -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] pl/tcl regression failed
Hi,
I have finished buildfarm setup, just waiting for my credentials.
However, I've install tcl 8.5a and regression tests fail like this:
ISTM it's just cosmetic, just want to share...
gmake[1]: Leaving directory
`/home4/ohp/pgfarmbuild/HEAD/pgsql.24436/src/pl/plperl'
gmake[1]: Entering directory
`/home4/ohp/pgfarmbuild/HEAD/pgsql.24436/src/pl/tcl'
gmake -C ../../../src/test/regress pg_regress
gmake[2]: Entering directory
`/home4/ohp/pgfarmbuild/HEAD/pgsql.24436/src/test/regress'
gmake[2]: `pg_regress' is up to date.
gmake[2]: Leaving directory
`/home4/ohp/pgfarmbuild/HEAD/pgsql.24436/src/test/regress'
/bin/sh ../../../src/test/regress/pg_regress --dbname=pl_regression
--load-language=pltcl pltcl_setup pltcl_queries
(using postmaster on Unix socket, default port)
== dropping database "pl_regression" ==
DROP DATABASE
== creating database "pl_regression" ==
CREATE DATABASE
== dropping regression test user accounts ==
== installing pltcl ==
== running regression test queries==
test pltcl_setup ... ok
test pltcl_queries... FAILED
==
1 of 2 tests failed.
==
The differences that caused some tests to fail can be viewed in the
file `./regression.diffs'. A copy of the test summary that you see
above is saved in the file `./regression.out'.
gmake[1]: *** [installcheck] Error 1
gmake[1]: Leaving directory `/home4/ohp/pgfarmbuild/HEAD/pgsql.24436/src/pl/tcl'
gmake: *** [installcheck] Error 2
= pgsql.24436/src/pl/tcl/regression.diffs ===
*** ./expected/pltcl_queries.outSun Jun 11 19:58:48 2006
--- ./results/pltcl_queries.out Sun Jun 11 20:05:34 2006
***
*** 38,56
insert into T_pkey1 values (1, 'KEY1-3', 'should work');
-- Due to the upper case translation in trigger this must fail
insert into T_pkey2 values (1, 'KEY1-3', 'should fail');
! ERROR: duplicate key '1', 'KEY1-3' for T_pkey2
insert into T_dta1 values ('trec 1', 1, 'key1-1');
insert into T_dta1 values ('trec 2', 1, 'key1-2');
insert into T_dta1 values ('trec 3', 1, 'key1-3');
-- Must fail due to unknown key in T_pkey1
insert into T_dta1 values ('trec 4', 1, 'key1-4');
! ERROR: key for t_dta1 not in t_pkey1
insert into T_dta2 values ('trec 1', 1, 'KEY1-1');
insert into T_dta2 values ('trec 2', 1, 'KEY1-2');
insert into T_dta2 values ('trec 3', 1, 'KEY1-3');
-- Must fail due to unknown key in T_pkey2
insert into T_dta2 values ('trec 4', 1, 'KEY1-4');
! ERROR: key for t_dta2 not in t_pkey2
select * from T_dta1;
tkey| ref1 | ref2
+--+--
--- 38,56
insert into T_pkey1 values (1, 'KEY1-3', 'should work');
-- Due to the upper case translation in trigger this must fail
insert into T_pkey2 values (1, 'KEY1-3', 'should fail');
! ERROR:
insert into T_dta1 values ('trec 1', 1, 'key1-1');
insert into T_dta1 values ('trec 2', 1, 'key1-2');
insert into T_dta1 values ('trec 3', 1, 'key1-3');
-- Must fail due to unknown key in T_pkey1
insert into T_dta1 values ('trec 4', 1, 'key1-4');
! ERROR:
insert into T_dta2 values ('trec 1', 1, 'KEY1-1');
insert into T_dta2 values ('trec 2', 1, 'KEY1-2');
insert into T_dta2 values ('trec 3', 1, 'KEY1-3');
-- Must fail due to unknown key in T_pkey2
insert into T_dta2 values ('trec 4', 1, 'KEY1-4');
! ERROR:
select * from T_dta1;
tkey| ref1 | ref2
+--+--
***
*** 69,78
update T_pkey1 set key2 = 'key2-9' where key1 = 2 and key2 = 'key2-1';
update T_pkey1 set key2 = 'key1-9' where key1 = 1 and key2 = 'key1-1';
! ERROR: key '1', 'key1-1 ' referenced by T_dta1
delete from T_pkey1 where key1 = 2 and key2 = 'key2-2';
delete from T_pkey1 where key1 = 1 and key2 = 'key1-2';
! ERROR: key '1', 'key1-2 ' referenced by T_dta1
update T_pkey2 set key2 = 'KEY2-9' where key1 = 2 and key2 = 'KEY2-1';
update T_pkey2 set key2 = 'KEY1-9' where key1 = 1 and key2 = 'KEY1-1';
NOTICE: updated 1 entries in T_dta2 for new key in T_pkey2
--- 69,78
update T_pkey1 set key2 = 'key2-9' where key1 = 2 and key2 = 'key
Re: [HACKERS] bison version
Yep!
I reverted to 1.875 and it works, I'll be a member of build farm soon for
UnixWare.
On Sun, 11 Jun 2006, Tom Lane wrote:
> Date: Sun, 11 Jun 2006 11:21:20 -0400
> From: Tom Lane <[EMAIL PROTECTED]>
> To: ohp@pyrenet.fr
> Cc: Stefan Kaltenbrunner <[EMAIL PROTECTED]>,
> PostgreSQL-development
> Subject: Re: [HACKERS] bison version
>
> ohp@pyrenet.fr writes:
> > Here's my make.log FWIW...
> > ...
> > gram.y:7074.27-7077.33: warning: useless rule: b_expr: b_expr IS OF '('
> > type_list ')'
> > gram.y:7078.27-7081.33: warning: useless rule: b_expr: b_expr IS NOT OF '('
> > type_list ')'
> > gmake[3]: *** [parse.h] Segmentation Fault (core dumped)
>
> The fact that bison dumps core after emitting all those bogus
> messages suggests to me that you've got a broken copy of bison.
>
> regards, tom lane
>
--
Olivier PRENANT Tel: +33-5-61-50-97-00 (Work)
15, Chemin des Monges+33-5-61-50-97-01 (Fax)
31190 AUTERIVE +33-6-07-63-80-64 (GSM)
FRANCE Email: ohp@pyrenet.fr
--
Make your life a dream, make your dream a reality. (St Exupery)
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] bison version
Hi Stefan, Here's my make.log FWIW... TIA On Sat, 10 Jun 2006, Stefan Kaltenbrunner wrote: > Date: Sat, 10 Jun 2006 21:10:09 +0200 > From: Stefan Kaltenbrunner <[EMAIL PROTECTED]> > To: ohp@pyrenet.fr > Cc: PostgreSQL-development > Subject: Re: [HACKERS] bison version > > ohp@pyrenet.fr wrote: > > Hi, > > > > I'd like to check 2 things: > > > > What's the bison version required to compile gram.y ? > > Trying to set up a build farm machine, it seems I can't compile with bison > > 2.1 ... > > 2.1 should work fine - there are a number of boxes on the buildfarm > running with that version (like sponge the FC5/ppc I own). > What exact problem do you see on your platform ? > > > > > Also where is the documentation page that gives postgresql limits (number > > of column/table max size of col) > > http://www.postgresql.org/docs/faqs.FAQ.html#item4.4 > > > Stefan > -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: ohp@pyrenet.fr ------ Make your life a dream, make your dream a reality. (St Exupery)gmake -C doc all gmake[1]: Entering directory `/home4/ohp/pgfarmbuild/HEAD/pgsql.4903/doc' gmake[1]: Nothing to be done for `all'. gmake[1]: Leaving directory `/home4/ohp/pgfarmbuild/HEAD/pgsql.4903/doc' gmake -C src all gmake[1]: Entering directory `/home4/ohp/pgfarmbuild/HEAD/pgsql.4903/src' gmake -C port all gmake[2]: Entering directory `/home4/ohp/pgfarmbuild/HEAD/pgsql.4903/src/port' ccache cc -O -Kinline -g -I../../src/port -DFRONTEND -I../../src/include -I/usr/local/include -c -o getopt_long.o getopt_long.c UX:cc: WARNING: debugging and optimization mutually exclusive; -O disabled UX:cc: WARNING: debugging and optimization mutually exclusive; -O disabled ccache cc -O -Kinline -g -I../../src/port -DFRONTEND -I../../src/include -I/usr/local/include -c -o copydir.o copydir.c UX:cc: WARNING: debugging and optimization mutually exclusive; -O disabled UX:cc: WARNING: debugging and optimization mutually exclusive; -O disabled ccache cc -O -Kinline -g -I../../src/port -DFRONTEND -I../../src/include -I/usr/local/include -c -o dirmod.o dirmod.c UX:cc: WARNING: debugging and optimization mutually exclusive; -O disabled UX:cc: WARNING: debugging and optimization mutually exclusive; -O disabled ccache cc -O -Kinline -g -I../../src/port -DFRONTEND -I../../src/include -I/usr/local/include -c -o exec.o exec.c UX:cc: WARNING: debugging and optimization mutually exclusive; -O disabled UX:cc: WARNING: debugging and optimization mutually exclusive; -O disabled ccache cc -O -Kinline -g -I../../src/port -DFRONTEND -I../../src/include -I/usr/local/include -c -o noblock.o noblock.c UX:cc: WARNING: debugging and optimization mutually exclusive; -O disabled UX:cc: WARNING: debugging and optimization mutually exclusive; -O disabled echo "#define PGBINDIR \"/home4/ohp/pgfarmbuild/HEAD/inst/bin\"" >pg_config_paths.h echo "#define PGSHAREDIR \"/home4/ohp/pgfarmbuild/HEAD/inst/share/postgresql\"" >>pg_config_paths.h echo "#define SYSCONFDIR \"/home4/ohp/pgfarmbuild/HEAD/inst/etc/postgresql\"" >>pg_config_paths.h echo "#define INCLUDEDIR \"/home4/ohp/pgfarmbuild/HEAD/inst/include\"" >>pg_config_paths.h echo "#define PKGINCLUDEDIR \"/home4/ohp/pgfarmbuild/HEAD/inst/include/postgresql\"" >>pg_config_paths.h echo "#define INCLUDEDIRSERVER \"/home4/ohp/pgfarmbuild/HEAD/inst/include/postgresql/server\"" >>pg_config_paths.h echo "#define LIBDIR \"/home4/ohp/pgfarmbuild/HEAD/inst/lib\"" >>pg_config_paths.h echo "#define PKGLIBDIR \"/home4/ohp/pgfarmbuild/HEAD/inst/lib/postgresql\"" >>pg_config_paths.h echo "#define LOCALEDIR \"\"" >>pg_config_paths.h echo "#define DOCDIR \"/home4/ohp/pgfarmbuild/HEAD/inst/doc/postgresql\"" >>pg_config_paths.h echo "#define MANDIR \"/home4/ohp/pgfarmbuild/HEAD/inst/man\"" >>pg_config_paths.h ccache cc -O -Kinline -g -I../../src/port -DFRONTEND -I../../src/include -I/usr/local/include -c -o path.o path.c UX:cc: WARNING: debugging and optimization mutually exclusive; -O disabled UX:cc: WARNING: debugging and optimization mutually exclusive; -O disabled ccache cc -O -Kinline -g -I../../src/port -DFRONTEND -I../../src/include -I/usr/local/include -c -o pipe.o pipe.c UX:cc: WARNING: debugging and optimization mutually exclusive; -O disabled UX:cc: WARNING: debugging and optimization mutually exclus
[HACKERS] bison version
Hi, I'd like to check 2 things: What's the bison version required to compile gram.y ? Trying to set up a build farm machine, it seems I can't compile with bison 2.1 ... Also where is the documentation page that gives postgresql limits (number of column/table max size of col) Many thanks -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: ohp@pyrenet.fr -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Going for 'all green' buildfarm results
On Fri, 9 Jun 2006 ohp@pyrenet.fr wrote: > Date: Fri, 9 Jun 2006 11:12:07 +0200 > From: ohp@pyrenet.fr > To: Andrew Dunstan <[EMAIL PROTECTED]>, Larry Rosenman > Newsgroups: pgsql.hackers > Subject: Re: Going for 'all green' buildfarm results > > I can take other if that helps. Ooops... takeover :) > > Larry, could you help me in the setup? > > Regards, > On Thu, 8 Jun 2006, Andrew Dunstan wrote: > > > Date: Thu, 08 Jun 2006 10:54:09 -0400 > > From: Andrew Dunstan <[EMAIL PROTECTED]> > > Newsgroups: pgsql.hackers > > Subject: Re: Going for 'all green' buildfarm results > > > > Larry Rosenman wrote: > > > well, the changes didn't help. > > > > > > I've pulled ALL the cronjobs from firefly. > > > > > > consider it dead. > > > > > > Since it is an outlier, it's not useful. > > > > > > > > > > > > > > > > > OK, I am marking firefly as retired. That means we have no coverage for > > Unixware. > > > > cheers > > > > andrew > > > > ---(end of broadcast)--- > > TIP 1: if posting/reading through Usenet, please send an appropriate > >subscribe-nomail command to [EMAIL PROTECTED] so that your > > message can get through to the mailing list cleanly > > > > > > -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: ohp@pyrenet.fr -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Going for 'all green' buildfarm results
I can take other if that helps. Larry, could you help me in the setup? Regards, On Thu, 8 Jun 2006, Andrew Dunstan wrote: > Date: Thu, 08 Jun 2006 10:54:09 -0400 > From: Andrew Dunstan <[EMAIL PROTECTED]> > Newsgroups: pgsql.hackers > Subject: Re: Going for 'all green' buildfarm results > > Larry Rosenman wrote: > > well, the changes didn't help. > > > > I've pulled ALL the cronjobs from firefly. > > > > consider it dead. > > > > Since it is an outlier, it's not useful. > > > > > > > > > > OK, I am marking firefly as retired. That means we have no coverage for > Unixware. > > cheers > > andrew > > ---(end of broadcast)--- > TIP 1: if posting/reading through Usenet, please send an appropriate >subscribe-nomail command to [EMAIL PROTECTED] so that your >message can get through to the mailing list cleanly > > -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: ohp@pyrenet.fr -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] how is that possible
Many thanks for explaining. I learned something today... On Fri, 10 Feb 2006, Stephan Szabo wrote: > Date: Fri, 10 Feb 2006 08:59:51 -0800 (PST) > From: Stephan Szabo <[EMAIL PROTECTED]> > To: ohp@pyrenet.fr > Cc: pgsql-hackers list > Subject: Re: [HACKERS] how is that possible > > > On Fri, 10 Feb 2006 ohp@pyrenet.fr wrote: > > > My understanding is that null or not, there should have been a foreign key > > violation. > > Not as far as I can tell. MATCH (without partial or full) returns true if > any column in the row value constructor is NULL. MATCH FULL returns true > if all columns in the row value constructor are NULL and returns false if > it's a mix of NULLs and non-NULLs. > > -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: ohp@pyrenet.fr -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] how is that possible
My understanding is that null or not, their should have been a foreign key violation. Maybe I misunderstood. On Fri, 10 Feb 2006, Stephan Szabo wrote: > Date: Fri, 10 Feb 2006 06:48:02 -0800 (PST) > From: Stephan Szabo <[EMAIL PROTECTED]> > To: ohp@pyrenet.fr > Cc: pgsql-hackers list > Subject: Re: [HACKERS] how is that possible > > > On Fri, 10 Feb 2006 ohp@pyrenet.fr wrote: > > > After a typo, I've just noticed the following : > > > > ~ 14:58:33: createdb test > > CREATE DATABASE > > ~ 14:58:42: psql test > > Welcome to psql 8.1.2, the PostgreSQL interactive terminal. > > > > Type: \copyright for distribution terms > >\h for help with SQL commands > >\? for help with psql commands > >\g or terminate with semicolon to execute query > >\q to quit > > > > test=# create table t1 (i int primary key); > > NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "t1_pkey" > > for table "t1" > > CREATE TABLE > > test=# create table t2 (i int references t2 1 on deley te cascade on > > update cascade > > ); > > CREATE TABLE > > test=# insert into t2 values (default); > > INSERT 0 1 > > test=# select * from t1; > > i > > --- > > (0 rows) > > > > test=# select * from t2; > > i > > --- > > > > (1 row) > > > > test=# \q > > > > should'nt the insert fail or have I mised something? > > Why do you think it should have failed? It looks okay to me. > > -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: ohp@pyrenet.fr -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] how is that possible
After a typo, I've just noticed the following : ~ 14:58:33: createdb test CREATE DATABASE ~ 14:58:42: psql test Welcome to psql 8.1.2, the PostgreSQL interactive terminal. Type: \copyright for distribution terms \h for help with SQL commands \? for help with psql commands \g or terminate with semicolon to execute query \q to quit test=# create table t1 (i int primary key); NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "t1_pkey" for table "t1" CREATE TABLE test=# create table t2 (i int references t2 1 on deley te cascade on update cascade ); CREATE TABLE test=# insert into t2 values (default); INSERT 0 1 test=# select * from t1; i --- (0 rows) test=# select * from t2; i --- (1 row) test=# \q should'nt the insert fail or have I mised something? postgresql 812 unixware 7.1.4 -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: ohp@pyrenet.fr -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] where is the output
On Wed, 21 Dec 2005, Michael Fuhr wrote:
> Date: Wed, 21 Dec 2005 13:23:24 -0700
> From: Michael Fuhr <[EMAIL PROTECTED]>
> To: ohp@pyrenet.fr
> Cc: pgsql-hackers list
> Subject: Re: [HACKERS] where is the output
>
> On Wed, Dec 21, 2005 at 07:16:28PM +0100, ohp@pyrenet.fr wrote:
> > Not sure it's the right group, but I've spent the afternoon googling and
> > trying on this.
> >
> > In PHP (Apache Module)
>
> pgsql-php might be more appropriate, or possibly a PHP mailing list.
Sure!
But I'd still like to know in that case (the same goes for C I guess)
where stdout is.
Why isn't it connected by default to the input of whatever connected by
dbconnect?
>
> > I try pg_exec("COPY blah TO STDOUT WITH blah");
> > It runs for ever...
> >
> > How can I get the output of COPY in PHP?
>
> At the libpq layer you'd use PQgetCopyData(); the only place I see
> a call to that function in the PHP 5.1.1 source code is in the
> pg_copy_to() function, which is for copying a table into an array.
>
> > Copy_from is not an option because the goal is to get a CSV file.
> > Writing and re-reading a file doesn't seem to be an option either because
> > of safe_mode.
>
> Could you use pg_copy_to() to read the table into an array and write
> each row of the array as CSV? I'm not sure if the following is the
> best way or even entirely correct, but it appears to work in PHP 5.1.1,
> even with safe_mode enabled:
>
> $rows = pg_copy_to($conn, "tablename");
> $fh = fopen("php://output", "w");
> foreach ($rows as $row) {
> fputcsv($fh, explode("\t", rtrim($row)));
> }
> fclose($fh);
>
> According to the PHP documentation fputcsv() is new as of 5.1.0RC1;
> for earlier versions you could probably find a module to generate
> CSV output.
>
>
Thanks for the tip. I found a function that does it!
--
Olivier PRENANT Tel: +33-5-61-50-97-00 (Work)
15, Chemin des Monges+33-5-61-50-97-01 (Fax)
31190 AUTERIVE +33-6-07-63-80-64 (GSM)
FRANCE Email: ohp@pyrenet.fr
--
Make your life a dream, make your dream a reality. (St Exupery)
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
[HACKERS] where is the output
hi all,
Not sure it's the right group, but I've spent the afternoon googling and
trying on this.
In PHP (Apache Module)
I try pg_exec("COPY blah TO STDOUT WITH blah");
It runs for ever...
How can I get the output of COPY in PHP?
Copy_from is not an option because the goal is to get a CSV file.
Writing and re-reading a file doesn't seem to be an option either because
of safe_mode.
Any php gurus out there?
Regards,
--
Olivier PRENANT Tel: +33-5-61-50-97-00 (Work)
15, Chemin des Monges+33-5-61-50-97-01 (Fax)
31190 AUTERIVE +33-6-07-63-80-64 (GSM)
FRANCE Email: ohp@pyrenet.fr
--
Make your life a dream, make your dream a reality. (St Exupery)
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
[HACKERS] timestamp.c
Hi, It seems the timestamp.c patch to getg around the SCO optimizer bug did'nt get in beta1 Is it normal? Regards -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: ohp@pyrenet.fr -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] ALTER INDEX OWNER TO
pg_dump is STILL emiting alter index. ISTM we shou make it a warning AND remove it from pg_dump Regards On Mon, 15 Aug 2005, Tom Lane wrote: > Date: Mon, 15 Aug 2005 09:54:12 -0400 > From: Tom Lane <[EMAIL PROTECTED]> > To: ohp@pyrenet.fr > Cc: pgsql-hackers list > Subject: Re: [HACKERS] ALTER INDEX OWNER TO > > ohp@pyrenet.fr writes: > > It seems that ALTER INDEX foo OWNER TO bar; doesn't work anymore. > > The error is foo is not a table or a view. > > Yeah, I suppressed that alternative a few weeks ago, thinking that it > was not sensible since we don't really support having indexes owned > by anyone except the owner of the parent table. Not sure what to do > about the fact that pg_dump has been emitting it though. Maybe reduce > the error to a warning, and make it a no-op? > > regards, tom lane > > -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: ohp@pyrenet.fr -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] ALTER INDEX OWNER TO
Hi all, It seems that ALTER INDEX foo OWNER TO bar; doesn't work anymore. The error is foo is not a table or a view. That's not a problem per se, but pg_dump continues to issue those commands. This is since a few weeks on CVS. Regards -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: ohp@pyrenet.fr -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] Chocked
Who copied? I've been to mysql site 2 mn ago (did'nt occur since at least 6 months) title says : Mysql: The world most advanced opensource database. Isn't it the title for postgresql? It seems weird for both projects to have the same claim (although it's true for postgreql...) Regards -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: ohp@pyrenet.fr -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] regression failure on latest CVS
In the meantime would'nt it be nice to try to understand what happens and correct it? I'm a bit afraid that 8.1 is not used on unixware because people don't have/want the patch installed. Regards On Tue, 26 Jul 2005, Larry Rosenman wrote: > Date: 26 Jul 2005 08:52:01 -0500 > From: Larry Rosenman > To: ohp@pyrenet.fr > Cc: Tom Lane <[EMAIL PROTECTED]>, > 'pgsql-hackers list' > Subject: Re: [HACKERS] regression failure on latest CVS > > On Jul 26 2005, ohp@pyrenet.fr wrote: > > > On Mon, 25 Jul 2005, Tom Lane wrote: > > > > > FWIW, I just checked that CVS tip works OK for me without these options, > > > with either integer or float timestamps. I don't see any new warnings, > > > either. > > > It could well be that the recent changes have introduced some > > > portability problem in the interval code, but someone's going to have to > > > actually dig for it :-( > > > > > That's my feeling but I have no clue where to start. > > I know this was introduced at the end of last week. > > I'm confident the SCO Compiler guys will get to the bottom of it :) > > They've got all the info they need, as far as I know, as well as > access to my box. > > LER > > > -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: ohp@pyrenet.fr -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] regression failure on latest CVS
On Mon, 25 Jul 2005, Tom Lane wrote: > Date: Mon, 25 Jul 2005 23:26:20 -0400 > From: Tom Lane <[EMAIL PROTECTED]> > To: Larry Rosenman > Cc: ohp@pyrenet.fr, 'pgsql-hackers list' > Subject: Re: [HACKERS] regression failure on latest CVS > > "Larry Rosenman" writes: > > For those following along at home: > > > Removing --enable-cassert and --enable-debug from the options causes > > Firefly to fail. > > FWIW, I just checked that CVS tip works OK for me without these options, > with either integer or float timestamps. I don't see any new warnings, > either. > It could well be that the recent changes have introduced some > portability problem in the interval code, but someone's going to have to > actually dig for it :-( > That's my feeling but I have no clue where to start. I know this was introduced at the end of last week. > regards, tom lane > > -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: ohp@pyrenet.fr -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] regression failure on latest CVS
On Mon, 25 Jul 2005, Larry Rosenman wrote: > Date: 25 Jul 2005 12:47:01 -0500 > From: Larry Rosenman > To: ohp@pyrenet.fr > Cc: pgsql-hackers list > Subject: Re: [HACKERS] regression failure on latest CVS > > On Jul 25 2005, ohp@pyrenet.fr wrote: > > > Hi Larry, > > > > I'm quitge sure you'll see a problem if you remove --enable-debug > > --enable-cassert from your ./configure > > Do we have a clue as to which .c module the compiler/optimizer is (possibly) > screwing up? > According to Bruce, it's in timestamp.c Did you get the same problem? > I have connections in SCO's compiler group > > (They'll want a small test case :( ) > > LER > > > -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: ohp@pyrenet.fr -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] regression failure on latest CVS
Hi Larry, I'm quitge sure you'll see a problem if you remove --enable-debug --enable-cassert from your ./configure This is the problem I have. Regards On Mon, 25 Jul 2005, Larry Rosenman wrote: > Date: 25 Jul 2005 09:00:41 -0500 > From: Larry Rosenman > To: ohp@pyrenet.fr > Cc: pgsql-hackers list > Subject: Re: [HACKERS] regression failure on latest CVS > > On Jul 25 2005, ohp@pyrenet.fr wrote: > > > Sorry to follow up my own post but this is weird. > > > > I've tested again and more closely. > > And intervall check is ok when configured with --enable-debug and fails > > (with the same error) otherwise. > > > > It could be a compiler optimizer bug or the way the code is written. > > Could someone point me to the source file so that I have a look? > > Look at 'firefly' on the pgbuildfarm, and tell me what I need > to change to duplicate your setup. > > LER > > > > > BTW this is still on UnixWare 714 > > > > Regards, > > On Fri, 22 Jul 2005 ohp@pyrenet.fr wrote: > > > > > Date: Fri, 22 Jul 2005 11:28:52 +0200 (MET DST) > > > From: ohp@pyrenet.fr > > > Newsgroups: pgsql.hackers > > > Subject: regressin failure on latest CVS > > > > > > Hi, > > > > > > I tried the latest cvs this morning (07/22 11:00 CET) > > > and interval test fails. > > > Here's the regression.diffs. > > > > > > *** ./expected/interval.out Fri Jul 22 10:32:21 2005 > > > --- ./results/interval.outFri Jul 22 11:07:54 2005 > > > *** > > > *** 217,224 > > > -- updating pg_aggregate.agginitval > > > select avg(f1) from interval_tbl; > > > avg > > > ! - > > > ! @ 4 years 1 mon 10 days 4 hours 18 mins 23 secs > > > (1 row) > > > > > > -- test long interval input > > > --- 217,224 > > > -- updating pg_aggregate.agginitval > > > select avg(f1) from interval_tbl; > > > avg > > > ! > > > ! @ 4 years 1 mon 9 days 4 hours 18 mins 23 secs > > > (1 row) > > > > > > -- test long interval input > > > > > > == > > > > > > Regards > > > > > > > > > -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: ohp@pyrenet.fr -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] regression failure on latest CVS
Sorry to follow up my own post but this is weird. I've tested again and more closely. And intervall check is ok when configured with --enable-debug and fails (with the same error) otherwise. It could be a compiler optimizer bug or the way the code is written. Could someone point me to the source file so that I have a look? BTW this is still on UnixWare 714 Regards, On Fri, 22 Jul 2005 ohp@pyrenet.fr wrote: > Date: Fri, 22 Jul 2005 11:28:52 +0200 (MET DST) > From: ohp@pyrenet.fr > Newsgroups: pgsql.hackers > Subject: regressin failure on latest CVS > > Hi, > > I tried the latest cvs this morning (07/22 11:00 CET) > and interval test fails. > Here's the regression.diffs. > > *** ./expected/interval.out Fri Jul 22 10:32:21 2005 > --- ./results/interval.outFri Jul 22 11:07:54 2005 > *** > *** 217,224 > -- updating pg_aggregate.agginitval > select avg(f1) from interval_tbl; > avg > ! - > ! @ 4 years 1 mon 10 days 4 hours 18 mins 23 secs > (1 row) > > -- test long interval input > --- 217,224 > -- updating pg_aggregate.agginitval > select avg(f1) from interval_tbl; > avg > ! > ! @ 4 years 1 mon 9 days 4 hours 18 mins 23 secs > (1 row) > > -- test long interval input > > == > > Regards > -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: ohp@pyrenet.fr -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] regressin failure on latest CVS
I think the patch is ok now, intervall is not failing anymore as of 18:50 CET. However stats fails. regression.diffs: *** ./expected/stats.outSat Jul 23 17:18:20 2005 --- ./results/stats.out Sat Jul 23 18:55:17 2005 *** *** 53,59 WHERE st.relname='tenk2' AND cl.relname='tenk2'; ?column? | ?column? | ?column? | ?column? --+--+--+-- ! t| t| t| t (1 row) SELECT st.heap_blks_read + st.heap_blks_hit >= pr.heap_blks + cl.relpages, --- 53,59 WHERE st.relname='tenk2' AND cl.relname='tenk2'; ?column? | ?column? | ?column? | ?column? --+--+--+-- ! f| f| t| t (1 row) SELECT st.heap_blks_read + st.heap_blks_hit >= pr.heap_blks + cl.relpages, *** *** 62,68 WHERE st.relname='tenk2' AND cl.relname='tenk2'; ?column? | ?column? --+-- ! t| t (1 row) -- End of Stats Test --- 62,68 WHERE st.relname='tenk2' AND cl.relname='tenk2'; ?column? | ?column? --+-- ! f| t (1 row) -- End of Stats Test == On Sat, 23 Jul 2005, Bruce Momjian wrote: > Date: Sat, 23 Jul 2005 11:36:43 -0400 (EDT) > From: Bruce Momjian > To: ohp@pyrenet.fr > Cc: Rocco Altier <[EMAIL PROTECTED]>, > Michael Glaesemann <[EMAIL PROTECTED]>, pgsql-patches@postgresql.org, > pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] regressin failure on latest CVS > > ohp@pyrenet.fr wrote: > > I just checked latest CVS (5 mn ago) the problem is still the same, > > BTW, this is on Unixware 714 and no --enable-integer-datetime > > Do you have the latest patch included int that version of CVS? > Anonymous CVS has a delay, and what was the problem you were seeing, the > rounding or the day - 1 result? > > --- > > > > > > Regards > > On Sat, 23 Jul 2005, Rocco Altier wrote: > > > > > Date: Sat, 23 Jul 2005 11:15:44 -0400 > > > From: Rocco Altier <[EMAIL PROTECTED]> > > > To: Bruce Momjian > > > Cc: Michael Glaesemann <[EMAIL PROTECTED]>, pgsql-patches@postgresql.org, > > > pgsql-hackers@postgresql.org, ohp@pyrenet.fr > > > Subject: RE: [HACKERS] regressin failure on latest CVS > > > > > > This still does not fix the problem. > > > > > > I had done my patch to try to mimic the way 8.0 had handled the math > > > with the remainders, but to carry it over another bucket (day). > > > > > > The problem that I see is that we are taking day_remainder and > > > multiplying by USECS_PER_DAY. Which is a double * int64, thus there is > > > the precision loss there. > > > > > > I think initial division by the factor can't be helped, but repeatedly > > > doing more floating point math on with it is causing the rounding error. > > > > > > Thanks, > > > -rocco > > > > > > > -Original Message- > > > > From: Bruce Momjian [mailto:[EMAIL PROTECTED] > > > > Sent: Saturday, July 23, 2005 10:54 AM > > > > To: Rocco Altier > > > > Cc: Michael Glaesemann; pgsql-patches@postgresql.org; > > > > pgsql-hackers@postgresql.org; ohp@pyrenet.fr > > > > Subject: Re: [HACKERS] regressin failure on latest CVS > > > > > > > > > > > > Rocco Altier wrote: > > > > > This patch fixes the interval regression on my AIX box > > > > (kookaburra) by > > > > > only doing integer math on the interval, instead of > > > > float/double math. > > > > > > > > > > I think this is the correct way to handle this, since it's > > > > an integer > > > > > data type. > > > > > > > > > > I don't know if it will fix Olivier's problem, since I > > > > wasn't able to > > > > > reproduce it. > > > > > > > > > > > > > I have changed the way I compute the remainder values --- instead of > > > > using multiplication, I use division and then subtraction. > > > > This should > > > > fix your rounding problem. Looking at your fix, I don't see > > > > how adding > > > > USECS changes things because the factor is already a float, > > > > but I think > > > > the problem was more the way I was
Re: [HACKERS] regressin failure on latest CVS
On Sat, 23 Jul 2005, Bruce Momjian wrote: > Date: Sat, 23 Jul 2005 11:36:43 -0400 (EDT) > From: Bruce Momjian > To: ohp@pyrenet.fr > Cc: Rocco Altier <[EMAIL PROTECTED]>, > Michael Glaesemann <[EMAIL PROTECTED]>, pgsql-patches@postgresql.org, > pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] regressin failure on latest CVS > > ohp@pyrenet.fr wrote: > > I just checked latest CVS (5 mn ago) the problem is still the same, > > BTW, this is on Unixware 714 and no --enable-integer-datetime > > Do you have the latest patch included int that version of CVS? > Anonymous CVS has a delay, and what was the problem you were seeing, the > rounding or the day - 1 result? > I was seeing (and still see) the day -1 result. However, if I ./configure --with-integer-datetimes I see the rounding of the day. > --- > > > > > > Regards > > On Sat, 23 Jul 2005, Rocco Altier wrote: > > > > > Date: Sat, 23 Jul 2005 11:15:44 -0400 > > > From: Rocco Altier <[EMAIL PROTECTED]> > > > To: Bruce Momjian > > > Cc: Michael Glaesemann <[EMAIL PROTECTED]>, pgsql-patches@postgresql.org, > > > pgsql-hackers@postgresql.org, ohp@pyrenet.fr > > > Subject: RE: [HACKERS] regressin failure on latest CVS > > > > > > This still does not fix the problem. > > > > > > I had done my patch to try to mimic the way 8.0 had handled the math > > > with the remainders, but to carry it over another bucket (day). > > > > > > The problem that I see is that we are taking day_remainder and > > > multiplying by USECS_PER_DAY. Which is a double * int64, thus there is > > > the precision loss there. > > > > > > I think initial division by the factor can't be helped, but repeatedly > > > doing more floating point math on with it is causing the rounding error. > > > > > > Thanks, > > > -rocco > > > > > > > -Original Message- > > > > From: Bruce Momjian [mailto:[EMAIL PROTECTED] > > > > Sent: Saturday, July 23, 2005 10:54 AM > > > > To: Rocco Altier > > > > Cc: Michael Glaesemann; pgsql-patches@postgresql.org; > > > > pgsql-hackers@postgresql.org; ohp@pyrenet.fr > > > > Subject: Re: [HACKERS] regressin failure on latest CVS > > > > > > > > > > > > Rocco Altier wrote: > > > > > This patch fixes the interval regression on my AIX box > > > > (kookaburra) by > > > > > only doing integer math on the interval, instead of > > > > float/double math. > > > > > > > > > > I think this is the correct way to handle this, since it's > > > > an integer > > > > > data type. > > > > > > > > > > I don't know if it will fix Olivier's problem, since I > > > > wasn't able to > > > > > reproduce it. > > > > > > > > > > > > > I have changed the way I compute the remainder values --- instead of > > > > using multiplication, I use division and then subtraction. > > > > This should > > > > fix your rounding problem. Looking at your fix, I don't see > > > > how adding > > > > USECS changes things because the factor is already a float, > > > > but I think > > > > the problem was more the way I was computing the remainders. > > > > > > > > Patch attached --- let me know if it does not fix your problem. > > > > > > > > -- > > > > > > > > > > > > > -- > > Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) > > 15, Chemin des Monges+33-5-61-50-97-01 (Fax) > > 31190 AUTERIVE +33-6-07-63-80-64 (GSM) > > FRANCE Email: ohp@pyrenet.fr > > -- > > Make your life a dream, make your dream a reality. (St Exupery) > > > > ---(end of broadcast)--- > > TIP 6: explain analyze is your friend > > > > -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: ohp@pyrenet.fr -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] regressin failure on latest CVS
I just checked latest CVS (5 mn ago) the problem is still the same, BTW, this is on Unixware 714 and no --enable-integer-datetime Regards On Sat, 23 Jul 2005, Rocco Altier wrote: > Date: Sat, 23 Jul 2005 11:15:44 -0400 > From: Rocco Altier <[EMAIL PROTECTED]> > To: Bruce Momjian > Cc: Michael Glaesemann <[EMAIL PROTECTED]>, pgsql-patches@postgresql.org, > pgsql-hackers@postgresql.org, ohp@pyrenet.fr > Subject: RE: [HACKERS] regressin failure on latest CVS > > This still does not fix the problem. > > I had done my patch to try to mimic the way 8.0 had handled the math > with the remainders, but to carry it over another bucket (day). > > The problem that I see is that we are taking day_remainder and > multiplying by USECS_PER_DAY. Which is a double * int64, thus there is > the precision loss there. > > I think initial division by the factor can't be helped, but repeatedly > doing more floating point math on with it is causing the rounding error. > > Thanks, > -rocco > > > -Original Message- > > From: Bruce Momjian [mailto:[EMAIL PROTECTED] > > Sent: Saturday, July 23, 2005 10:54 AM > > To: Rocco Altier > > Cc: Michael Glaesemann; pgsql-patches@postgresql.org; > > pgsql-hackers@postgresql.org; ohp@pyrenet.fr > > Subject: Re: [HACKERS] regressin failure on latest CVS > > > > > > Rocco Altier wrote: > > > This patch fixes the interval regression on my AIX box > > (kookaburra) by > > > only doing integer math on the interval, instead of > > float/double math. > > > > > > I think this is the correct way to handle this, since it's > > an integer > > > data type. > > > > > > I don't know if it will fix Olivier's problem, since I > > wasn't able to > > > reproduce it. > > > > > > > I have changed the way I compute the remainder values --- instead of > > using multiplication, I use division and then subtraction. > > This should > > fix your rounding problem. Looking at your fix, I don't see > > how adding > > USECS changes things because the factor is already a float, > > but I think > > the problem was more the way I was computing the remainders. > > > > Patch attached --- let me know if it does not fix your problem. > > > > -- > > > -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: ohp@pyrenet.fr -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] regressin failure on latest CVS
Hi, I tried the latest cvs this morning (07/22 11:00 CET) and interval test fails. Here's the regression.diffs. *** ./expected/interval.out Fri Jul 22 10:32:21 2005 --- ./results/interval.out Fri Jul 22 11:07:54 2005 *** *** 217,224 -- updating pg_aggregate.agginitval select avg(f1) from interval_tbl; avg ! - ! @ 4 years 1 mon 10 days 4 hours 18 mins 23 secs (1 row) -- test long interval input --- 217,224 -- updating pg_aggregate.agginitval select avg(f1) from interval_tbl; avg ! ! @ 4 years 1 mon 9 days 4 hours 18 mins 23 secs (1 row) -- test long interval input == Regards -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: ohp@pyrenet.fr -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] problemsafter crash
Hi Tom, The problem was worse then that: there were actually twice the same row in the table, delete those twins helped. One of my customer suffered the same problem in 2 of his tables and even the OID was the same! how can that be possible? again, deleting those rows helped On Tue, 8 Feb 2005, Tom Lane wrote: > Date: Tue, 08 Feb 2005 10:40:33 -0500 > From: Tom Lane <[EMAIL PROTECTED]> > To: ohp@pyrenet.fr > Cc: pgsql-hackers list > Subject: Re: [HACKERS] problemsafter crash > > ohp@pyrenet.fr writes: > > I had a crash last night and since while vacuuming databases (either full > > or lazy) I get this error: > > > duplcate key violates unique cnstraint "pg_statistic_relid_att_index" > > Reindexing pg_statistic would probably make that go away ... > > regards, tom lane > -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 6, Chemin d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: ohp@pyrenet.fr -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] problemsafter crash
Hi everyone, I had a crash last night and since while vacuuming databases (either full or lazy) I get this error: duplcate key violates unique cnstraint "pg_statistic_relid_att_index" this is 7.4.6 on unixware. How bad is this? TIA -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 6, Chemin d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: ohp@pyrenet.fr -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] Where are the docs
Hi all, Happy new year. I wanted to re-read the 8.0 docs but I can't find them on the (new) site. Can any one tell me where to look? Also it seems pg is down for techdocs. -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 6, Chemin d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: ohp@pyrenet.fr -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
