[HACKERS] Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL

2010-02-09 Thread Heikki Linnakangas
Fujii Masao wrote: > As I pointed out previously, the standby might restore a partially-filled > WAL file that is being archived by the primary, and cause a FATAL error. > And this happened in my box when I was testing the SR. > > sby [20088] FATAL: archive file "00010087" has >

[HACKERS] Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL

2010-02-09 Thread Fujii Masao
On Thu, Jan 28, 2010 at 12:27 AM, Heikki Linnakangas wrote: > Log Message: > --- > Make standby server continuously retry restoring the next WAL segment with > restore_command, if the connection to the primary server is lost. This > ensures that the standby can recover automatically, if th

[HACKERS] pg_restore --single-transaction and --clean

2010-02-09 Thread Takahiro Itagaki
As another glitch in pg_restore, a combination of options --single-transaction and --clean raises errors if we restore data into an empty database. The reason is pg_restore uses DROP . The cleanup command fails if the target object doesn't exist. Is it a TODO item to replace "DROP" into "DROP IF E

Re: [HACKERS] TRUNCATE+COPY optimization and --jobs=1 in pg_restore

2010-02-09 Thread Takahiro Itagaki
Andrew Dunstan wrote: > Takahiro-san is suggesting there is a case for doing the optimisation in > non-parallel mode. But if we do that, is there still a case for > --single-transaction? I think --single-transaction is useful to restore data into non-empty databases. A normal restore ignores

Re: [HACKERS] TRUNCATE+COPY optimization and --jobs=1 in pg_restore

2010-02-09 Thread Tom Lane
Andrew Dunstan writes: > Tom Lane wrote: >> The code is only trying to substitute for something you can't have >> in parallel restore, ie --single-transaction. > Exactly. IIRC that's why --single-transaction was introduced in the > first place. To me, --single-transaction is mostly there for pe

Re: [HACKERS] TRUNCATE+COPY optimization and --jobs=1 in pg_restore

2010-02-09 Thread Andrew Dunstan
Tom Lane wrote: Takahiro Itagaki writes: We have an optimization to bulkload date in pg_restore, but the code only works in parallel restore (--jobs >= 2). Why don't we do the same optimization in the serial restore (--jobs = 1) ? The code is only trying to substitute for something

Re: [HACKERS] TRUNCATE+COPY optimization and --jobs=1 in pg_restore

2010-02-09 Thread Takahiro Itagaki
Tom Lane wrote: > Takahiro Itagaki writes: > > We have an optimization to bulkload date in pg_restore, but the code > > only works in parallel restore (--jobs >= 2). Why don't we do the > > same optimization in the serial restore (--jobs = 1) ? > > The code is only trying to substitute for som

Re: [HACKERS] Some belated patch review for "Buffers" explain analyze patch

2010-02-09 Thread Robert Haas
On Tue, Feb 9, 2010 at 10:51 PM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Feb 9, 2010 at 8:18 PM, Tom Lane wrote: >>> ... I wouldn't object to adding a "total time" field to the >>> machine-readable formats. > >> One possibility we discussed previously is to add some decimal places >> to

Re: [HACKERS] CVS checkout source code for different branches

2010-02-09 Thread Andrew Dunstan
M Z wrote: Final, I tried: $ cvs -z3 -d :pserver:anoncvs:passw...@anoncvs.postgresql.org:/projects/cvsroot co -r REL8_3_STABLE -P pgsql Checked file configure.in . Around line 20, there is line: AC_INIT([PostgreSQL], [8.3.9], [pgsql-b...@postgresql.org

Re: [HACKERS] Some belated patch review for "Buffers" explain analyze patch

2010-02-09 Thread Tom Lane
Robert Haas writes: > On Tue, Feb 9, 2010 at 8:18 PM, Tom Lane wrote: >> ... I wouldn't object to adding a "total time" field to the >> machine-readable formats. > One possibility we discussed previously is to add some decimal places > to the relevant values when nloops > 1. Hmm, I must've miss

Re: [HACKERS] [CFReview] Red-Black Tree

2010-02-09 Thread Robert Haas
2010/2/9 Teodor Sigaev : >>> Good idea, implemented. >> >> Hmm.  I think your implementation is prone to overflow in two places - >> both when computing step, and also when stepping through the array. > > Pls, point me, I don't see that > !       step |= (step >>  1); > !       step |= (step >>  2)

Re: [HACKERS] CVS checkout source code for different branches

2010-02-09 Thread M Z
Thanks Robert, Your reply helps a lot. Just right after sending post, I found the way to list all branches in the CVS server. Best, M Z On Tue, Feb 9, 2010 at 10:43 PM, Robert Haas wrote: > On Tue, Feb 9, 2010 at 10:35 PM, M Z wrote: > > Final, I tried: > > > > $ cvs -z3 -d > > :pserver:anonc

Re: [HACKERS] TRUNCATE+COPY optimization and --jobs=1 in pg_restore

2010-02-09 Thread Tom Lane
Takahiro Itagaki writes: > We have an optimization to bulkload date in pg_restore, but the code > only works in parallel restore (--jobs >= 2). Why don't we do the > same optimization in the serial restore (--jobs = 1) ? The code is only trying to substitute for something you can't have in parall

Re: [HACKERS] CVS checkout source code for different branches

2010-02-09 Thread Robert Haas
On Tue, Feb 9, 2010 at 10:35 PM, M Z wrote: > Final, I tried: > > $ cvs -z3 -d > :pserver:anoncvs:passw...@anoncvs.postgresql.org:/projects/cvsroot co -r > REL8_3_STABLE -P pgsql > > Checked file configure.in. Around line 20, there is line: >  AC_INIT([PostgreSQL], [8.3.9], [pgsql-b...@postgresql.

Re: [HACKERS] Some belated patch review for "Buffers" explain analyze patch

2010-02-09 Thread Robert Haas
On Tue, Feb 9, 2010 at 8:18 PM, Tom Lane wrote: >> Perhaps instead of looking to change the "actual" times we should look >> at a way to include total time spent in each node. > > You can already get that by multiplying the displayed total time by the > number of loops.  Robert does have a point t

Re: [HACKERS] CVS checkout source code for different branches

2010-02-09 Thread M Z
Final, I tried: $ cvs -z3 -d :pserver:anoncvs:passw...@anoncvs.postgresql.org:/projects/cvsroot co -r REL8_3_STABLE -P pgsql Checked file configure.in. Around line 20, there is line: AC_INIT([PostgreSQL], [8.3.9], [pgsql-b...@postgresql.org]) Not sure that indicates version 8.3.9? But still, i

[HACKERS] TRUNCATE+COPY optimization and --jobs=1 in pg_restore

2010-02-09 Thread Takahiro Itagaki
We have an optimization to bulkload date in pg_restore, but the code only works in parallel restore (--jobs >= 2). Why don't we do the same optimization in the serial restore (--jobs = 1) ? We checks is_parallel to decide to use BEGIN-TRUNCATE-COPY: if (is_parallel && te->created) but we can a

Re: [HACKERS] CVS checkout source code for different branches

2010-02-09 Thread M Z
Hi Andrew and all, I am still struggling with the branch repositories. I tried to checkout from branch repositories but got error no such repositories: $ cvs -z3 -d :pserver:anoncvs:passw...@anoncvs.postgresql.org:/projects/REL8_4_STABLE co -P pgsql /projects/REL8_4_STABLE: no such repository

Re: [HACKERS] Largeobject Access Controls (r2460)

2010-02-09 Thread Takahiro Itagaki
KaiGai Kohei wrote: > The attached patch fixed up the cleanup query as follows: > + appendPQExpBuffer(dquery, > + "SELECT pg_catalog.lo_unlink(oid) " > + "FROM pg_catalog.pg_largeobject_metadata " > + "WHERE oid = %s;\n", binfo->dobj.

[HACKERS] psql tab-completion for new syntax

2010-02-09 Thread Takahiro Itagaki
We've added some new syntax in HEAD, but psql tab-completion is out of sync. Here is a patch to support the following syntax in tab-completion: - top-level DO - ALTER TABLE/INDEX/TABLESPACE SET/RESET with options - ALTER TABLE ALTER COLUMN SET/RESET with options - CREATE TRIGGER wi

Re: [HACKERS] psql tab completion for DO blocks

2010-02-09 Thread Takahiro Itagaki
Bruce Momjian wrote: > Where are we on this patch? We should at least implement the completion > for 'LANGUAGE' in 'DO', and use the existing pg_language query for > completion. I am attaching a patch that does exactly this. I don't think we need the patch except adding DO to the top-level sq

Re: [HACKERS] Listen / Notify - what to do when the queue is full

2010-02-09 Thread Tom Lane
Alvaro Herrera writes: > Andrew Dunstan wrote: >> True. It's a workaround, but I think it's acceptable at this stage. >> We need to get some experience with this facility before we can >> refine it. > Hmm? If we decide now that it's not going to have encoding conversion, > we won't able to chang

Re: [HACKERS] Listen / Notify - what to do when the queue is full

2010-02-09 Thread Alvaro Herrera
Andrew Dunstan wrote: > > > Tom Lane wrote: > >Andrew Dunstan writes: > >>Jeff Davis wrote: > >>>So, I think ASCII is the natural choice here. > > > >>It's not worth hanging up this facility over this issue, ISTM. > >>If we want something more that ASCII then a base64 or hex > >>encoded string c

Re: [HACKERS] Listen / Notify - what to do when the queue is full

2010-02-09 Thread Andrew Dunstan
Tom Lane wrote: Andrew Dunstan writes: Jeff Davis wrote: So, I think ASCII is the natural choice here. It's not worth hanging up this facility over this issue, ISTM. If we want something more that ASCII then a base64 or hex encoded string could possibly meet the need in

Re: [HACKERS] Listen / Notify - what to do when the queue is full

2010-02-09 Thread Tom Lane
Andrew Dunstan writes: > Jeff Davis wrote: >> So, I think ASCII is the natural choice here. > It's not worth hanging up this facility over this issue, ISTM. If we > want something more that ASCII then a base64 or hex encoded string could > possibly meet the need in the first instance. Yeah, th

Re: [HACKERS] Writeable CTEs and empty relations

2010-02-09 Thread Tom Lane
Marko Tiikkaja writes: > On 2010-02-10 02:19 +0200, Tom Lane wrote: >> You still haven't explained why it's a good idea to change the snapshot >> after the executor has started. Right at the moment I'm prepared to >> reject the patch on that ground alone. > The patch only touches the snapshot's

Re: [HACKERS] Some belated patch review for "Buffers" explain analyze patch

2010-02-09 Thread Tom Lane
Greg Stark writes: > On Wed, Feb 10, 2010 at 12:32 AM, Tom Lane wrote: >> The reason that EXPLAIN prints things the way it does is so that actual >> costs/times are comparable to estimated costs. > Oh, that was a thought I had along the way but forgot to mention in my > email: since the buffer u

Re: [HACKERS] TCP keepalive support for libpq

2010-02-09 Thread Fujii Masao
On Tue, Feb 9, 2010 at 11:34 PM, Andrew Chernow wrote: > If you really want libpq to manage this, I think you need to expose the > probe interval and timeouts. Agreed. Previously I was making the patch that exposes them as conninfo options so that the standby can detect a network outage ASAP in

Re: [HACKERS] Listen / Notify - what to do when the queue is full

2010-02-09 Thread Andrew Dunstan
Jeff Davis wrote: Also, the query starts out as text, so we need a way to interpret the text in an encoding-independent way. So, I think ASCII is the natural choice here. It's not worth hanging up this facility over this issue, ISTM. If we want something more that ASCII then a base64 o

Re: [HACKERS] Some belated patch review for "Buffers" explain analyze patch

2010-02-09 Thread Greg Stark
On Wed, Feb 10, 2010 at 12:32 AM, Tom Lane wrote: > The reason that EXPLAIN prints things the way it does is so that actual > costs/times are comparable to estimated costs. Oh, that was a thought I had along the way but forgot to mention in my email: since the buffer usage isn't related to the co

Re: [HACKERS] Avoiding bad prepared-statement plans.

2010-02-09 Thread Kris Jurka
On Tue, 9 Feb 2010, Mark Mielke wrote: In a current commercial app we have that uses JDBC and prepared plans for just about everything, it regularly ends up with execution times of 30+ milliseconds when a complete plan + execute would take less than 1 millisecond. PostgreSQL planning is pr

Re: [HACKERS] Largeobject Access Controls (r2460)

2010-02-09 Thread KaiGai Kohei
(2010/02/09 21:18), KaiGai Kohei wrote: > (2010/02/09 20:16), Takahiro Itagaki wrote: >> >> KaiGai Kohei wrote: >> I don't think this is necessarily a good idea. We might decide to treat both things separately in the future and it having them represented separately in the dump would

Re: [HACKERS] Some belated patch review for "Buffers" explain analyze patch

2010-02-09 Thread Tom Lane
Robert Haas writes: > On Tue, Feb 9, 2010 at 6:33 PM, Tom Lane wrote: >> Not in the least.  Fixing EXPLAIN to consistently print totals would >> involve changes in (at least) the treatment of estimated costs, and very >> possibly some changes in the Instrumentation support as well. > As far as I

Re: [HACKERS] Listen / Notify - what to do when the queue is full

2010-02-09 Thread Jeff Davis
On Tue, 2010-02-09 at 19:02 -0500, Andrew Chernow wrote: > Wouldn't binary payloads be an alternative? NOTE: I may have missed this > discussion. Sorry if it has already been covered. The Notify struct has a "char *" field, which can't hold embedded NULL bytes, so it can't really be binary. But

Re: [HACKERS] Writeable CTEs and empty relations

2010-02-09 Thread Marko Tiikkaja
On 2010-02-10 02:19 +0200, Tom Lane wrote: > Marko Tiikkaja writes: >> Does this sound completely unacceptable? > > You still haven't explained why it's a good idea to change the snapshot > after the executor has started. Right at the moment I'm prepared to > reject the patch on that ground alon

Re: [HACKERS] Writeable CTEs and empty relations

2010-02-09 Thread Tom Lane
Marko Tiikkaja writes: > On 2010-02-08 21:30 +0200, I wrote: >> This doesn't exactly work anymore since we modify the snapshot after >> calling ExecInitScan(). I'm not really familiar with this part of the >> code, so I'm asking: is there a simple enough way around this? Would >> updating scan->

Re: [HACKERS] Some belated patch review for "Buffers" explain analyze patch

2010-02-09 Thread Robert Haas
On Tue, Feb 9, 2010 at 6:33 PM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Feb 9, 2010 at 5:41 PM, Tom Lane wrote: >>> A more important point is that it would be a nontrivial change, both as >>> to code and documentation, and it's too late for such in 9.0.  So what >>> we ought to be confi

Re: [HACKERS] Listen / Notify - what to do when the queue is full

2010-02-09 Thread Andrew Chernow
Jeff Davis wrote: On Tue, 2010-02-09 at 16:51 -0500, Tom Lane wrote: Limiting NOTIFY payloads to 7-bit would definitely avoid the issue. The question is if that's more of a pain than a benefit. I don't see any alternative. If one backend sends a NOTIFY payload that Wouldn't binary payloads b

Re: [HACKERS] Some belated patch review for "Buffers" explain analyze patch

2010-02-09 Thread Greg Stark
On Tue, Feb 9, 2010 at 10:42 PM, Robert Haas wrote: >> A more important point is that it would be a nontrivial change, both as >> to code and documentation, and it's too late for such in 9.0.  So what >> we ought to be confining the discussion to right now is what 9.0 should >> print here. > > It'

Re: [HACKERS] Some belated patch review for "Buffers" explain analyze patch

2010-02-09 Thread Tom Lane
Robert Haas writes: > On Tue, Feb 9, 2010 at 5:41 PM, Tom Lane wrote: >> A more important point is that it would be a nontrivial change, both as >> to code and documentation, and it's too late for such in 9.0.  So what >> we ought to be confining the discussion to right now is what 9.0 should >>

[HACKERS] log_error_verbosity placement

2010-02-09 Thread Bruce Momjian
I just realized that log_error_verbosity is in the wrong section in postgresql.conf and in our manual. It is listed under "When to log" when in fact it should be in the "What to log" section. I also added documentation of what "terse" mode actually does. I added "verbosity" information a few wee

Re: [HACKERS] Listen / Notify - what to do when the queue is full

2010-02-09 Thread Jeff Davis
On Tue, 2010-02-09 at 16:51 -0500, Tom Lane wrote: > Limiting NOTIFY payloads to 7-bit would definitely avoid the issue. > The question is if that's more of a pain than a benefit. I don't see any alternative. If one backend sends a NOTIFY payload that contains a non-ASCII character, there's a risk

Re: [HACKERS] Writeable CTEs and empty relations

2010-02-09 Thread Marko Tiikkaja
On 2010-02-08 21:30 +0200, I wrote: > This doesn't exactly work anymore since we modify the snapshot after > calling ExecInitScan(). I'm not really familiar with this part of the > code, so I'm asking: is there a simple enough way around this? Would > updating scan->rs_nblocks before scanning the

Re: [HACKERS] Some belated patch review for "Buffers" explain analyze patch

2010-02-09 Thread Robert Haas
On Tue, Feb 9, 2010 at 5:41 PM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Feb 9, 2010 at 5:07 PM, Tom Lane wrote: >>> Well, if you want to put forward a proposal to get rid of that approach >>> entirely, go ahead.  But it doesn't seem like a good idea to me for >>> EXPLAIN to print some n

Re: [HACKERS] Some belated patch review for "Buffers" explain analyze patch

2010-02-09 Thread Tom Lane
Robert Haas writes: > On Tue, Feb 9, 2010 at 5:07 PM, Tom Lane wrote: >> Well, if you want to put forward a proposal to get rid of that approach >> entirely, go ahead.  But it doesn't seem like a good idea to me for >> EXPLAIN to print some numbers according to one viewpoint and some >> according

Re: [HACKERS] Writeable CTEs patch

2010-02-09 Thread Robert Haas
On Tue, Feb 9, 2010 at 3:13 PM, Marko Tiikkaja wrote: > On 2010-02-08 18:42 +0200, Robert Haas wrote: >> On Thu, Feb 4, 2010 at 11:57 AM, Marko Tiikkaja >> wrote: >>> Here's an updated patch.  Only changes from the previous patch are >>> fixing the above issue and a regression test for it. >> >>

Re: [HACKERS] About psycopg2 (by its author)

2010-02-09 Thread Greg Smith
Federico Di Gregorio wrote: First of all let me say that from such incredible hackers as the PostgreSQL people I'd have expected the ability to find my email address and maybe keep me or (even better) the psycopg mailing list in CC. That would have avoided a lot of confusion both on the license a

Re: [HACKERS] Listen / Notify - what to do when the queue is full

2010-02-09 Thread Robert Haas
On Tue, Feb 9, 2010 at 4:51 PM, Tom Lane wrote: > Jeff Davis writes: >> Looking at the documentation, it appears that all of the server >> encodings represent 7-bit ascii characters using the same 7-bit ascii >> representation. Is that true? > > Correct.  We only support ASCII-superset encodings,

Re: [HACKERS] Some belated patch review for "Buffers" explain analyze patch

2010-02-09 Thread Robert Haas
On Tue, Feb 9, 2010 at 5:07 PM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Feb 9, 2010 at 3:26 PM, Josh Berkus wrote: >>> I'd prefer to have the average; it's very confusing to have an explain >>> row which has the cost per iteration, but the buffer usage per node. > >> The cost per iterat

Re: [HACKERS] Avoiding bad prepared-statement plans.

2010-02-09 Thread Dimitri Fontaine
Jeroen Vermeulen writes: > I think we should be careful not to over-think this. Planning isn't *that* > costly, so apply Amdahl's Law liberally. I'm proposing some easy things we > could do without adding much overhead or maintenance burden; I've been > assuming that getting intimate with the pl

Re: [HACKERS] Some belated patch review for "Buffers" explain analyze patch

2010-02-09 Thread Tom Lane
Robert Haas writes: > On Tue, Feb 9, 2010 at 3:26 PM, Josh Berkus wrote: >> I'd prefer to have the average; it's very confusing to have an explain >> row which has the cost per iteration, but the buffer usage per node. > The cost per iteration thing is IMO one of the most confusing parts of > th

Re: [HACKERS] [GENERAL] ERROR: could not load library "...": Exec format error

2010-02-09 Thread Boszormenyi Zoltan
Boszormenyi Zoltan írta: > Korry Douglas írta: > >>> I have the $SUBJECT problem loading my own >>> module in PostgreSQL. The server is HP-UX/ia64, >>> PostgeSQL 8.4.2 was compiled with HP CC. >>> pl/PgSQL can be loaded fine. >>> >>> ...:/usr/local/pgsql/pgsql-cc-8.4/lib# ldd odbclink.so >>>

Re: [HACKERS] Some belated patch review for "Buffers" explain analyze patch

2010-02-09 Thread Tom Lane
Greg Stark writes: > I already have a patch to do this but it's a bit grotty -- do we want > to have a generic format string in snprintf in case we need it > somewhere else other than explain.c? No. Custom format specifiers that take arguments will confuse the heck out of gcc's format-checking w

Re: [HACKERS] Some belated patch review for "Buffers" explain analyze patch

2010-02-09 Thread Robert Haas
On Tue, Feb 9, 2010 at 3:26 PM, Josh Berkus wrote: > On 2/9/10 11:50 AM, Greg Stark wrote: >> Secondly, I think it's printing the total buffer usage for that node >> across the whole query -- not the average per iteration. I agree that >> the average is probably more confusing but it's what we do

Re: [HACKERS] Listen / Notify - what to do when the queue is full

2010-02-09 Thread Tom Lane
Jeff Davis writes: > Looking at the documentation, it appears that all of the server > encodings represent 7-bit ascii characters using the same 7-bit ascii > representation. Is that true? Correct. We only support ASCII-superset encodings, both for frontend and backend. Limiting NOTIFY payloads

Re: [HACKERS] Listen / Notify - what to do when the queue is full

2010-02-09 Thread Jeff Davis
On Mon, 2010-02-08 at 22:13 -0800, Jeff Davis wrote: > I would like to support encoded text, but I think there are other > problems. For instance, what if one server has a client_encoding that > doesn't support some of the glyphs being sent by the notifying backend? > Then we have a mess, because w

Re: [HACKERS] [PATCH] "could not reattach to shared memory" on Windows

2010-02-09 Thread Etienne Dube
Magnus Hagander wrote: IIRC, we've had zero reports on whether the patch worked at all on 8.2 in an environment where the problem actually existed. So yes, some testing and feedback would be much apprecaited. //Magnus Thanks for your quick reply. We upgraded to Service Pack 2 and it solved

Re: [HACKERS] Some belated patch review for "Buffers" explain analyze patch

2010-02-09 Thread Josh Berkus
On 2/9/10 11:50 AM, Greg Stark wrote: > Secondly, I think it's printing the total buffer usage for that node > across the whole query -- not the average per iteration. I agree that > the average is probably more confusing but it's what we do for every > other stat. Do we want to be consistent? Call

Re: [HACKERS] CreateFakeRelcacheEntry versus Hot Standby

2010-02-09 Thread Tom Lane
Heikki Linnakangas writes: > I started looking at the callers of CreateFakeRelcacheEntry to see if > any of them actually take a lock on the Relation. It seems not, so maybe > we should just set those to InvalidOid, and add an > Assert(OidIsValid(dbId) && OidIsValid(relId)) to LockAcquire() to ens

Re: [HACKERS] Writeable CTEs patch

2010-02-09 Thread Marko Tiikkaja
On 2010-02-08 18:42 +0200, Robert Haas wrote: > On Thu, Feb 4, 2010 at 11:57 AM, Marko Tiikkaja > wrote: >> Here's an updated patch. Only changes from the previous patch are >> fixing the above issue and a regression test for it. > > - I'm not sure that canSetTag is the right name for the additi

Re: [HACKERS] CreateFakeRelcacheEntry versus Hot Standby

2010-02-09 Thread Heikki Linnakangas
Tom Lane wrote: > I was rather surprised to find this code still present: > > /* >* We set up the lockRelId in case anything tries to lock the dummy >* relation. Note that this is fairly bogus since relNode may be >* different from the relation's OID. It shouldn't r

[HACKERS] Some belated patch review for "Buffers" explain analyze patch

2010-02-09 Thread Greg Stark
I was recently experimenting with explain analyze and I realized there are two things arguably wrong with the "Buffers" output in explain analyze: Firstly, it's printing out a number of buffers. We spent a lot of effort making all GUC variables use units of memory like "kB" and "MB" so the user sh

Re: [HACKERS] Why doesn't smgr_redo truncate the VM fork too?

2010-02-09 Thread Heikki Linnakangas
Tom Lane wrote: > Heikki Linnakangas writes: >> Tom Lane wrote: >>> Seems inconsistent ... > >> Indeed. Seems like an oversight. > > OK, will fix since I'm fooling with that code anyway. Thanks. While we're at it, the comment above visibilitymap_truncate() has a copy-pasto in it (it claims the

Re: [HACKERS] Why doesn't smgr_redo truncate the VM fork too?

2010-02-09 Thread Tom Lane
Heikki Linnakangas writes: > Tom Lane wrote: >> Seems inconsistent ... > Indeed. Seems like an oversight. OK, will fix since I'm fooling with that code anyway. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to yo

Re: [HACKERS] Why doesn't smgr_redo truncate the VM fork too?

2010-02-09 Thread Heikki Linnakangas
Tom Lane wrote: > Seems inconsistent ... Indeed. Seems like an oversight. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-ha

[HACKERS] Why doesn't smgr_redo truncate the VM fork too?

2010-02-09 Thread Tom Lane
Seems inconsistent ... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] CreateFakeRelcacheEntry versus Hot Standby

2010-02-09 Thread Tom Lane
I was rather surprised to find this code still present: /* * We set up the lockRelId in case anything tries to lock the dummy * relation. Note that this is fairly bogus since relNode may be * different from the relation's OID. It shouldn't really matter though

Re: [HACKERS] bugfix - VIP: variadic function ignore strict flag

2010-02-09 Thread Pavel Stehule
2010/2/9 Tom Lane : > Pavel Stehule writes: >> 2010/2/9 Tom Lane : >>> So what?  "variadic any" is different in a lot of ways. > >> implementation is different, but from users perspective there can not >> be differences. I am not sure. From my programmer's view is all ok. >> But I believe so from

Re: [HACKERS] bugfix - VIP: variadic function ignore strict flag

2010-02-09 Thread Tom Lane
Pavel Stehule writes: > 2010/2/9 Tom Lane : >> So what?  "variadic any" is different in a lot of ways. > implementation is different, but from users perspective there can not > be differences. I am not sure. From my programmer's view is all ok. > But I believe so from customer view, there can be

Re: [HACKERS] bugfix - VIP: variadic function ignore strict flag

2010-02-09 Thread Pavel Stehule
2010/2/9 Tom Lane : > Pavel Stehule writes: >> 2010/2/9 Tom Lane : >>> I don't think this is right at all. > >> yes, this isn't clear. My arguments for change: > >> a) the behave depends on types - "any" is different than others. > > So what?  "variadic any" is different in a lot of ways. > imple

Re: [HACKERS] bugfix - VIP: variadic function ignore strict flag

2010-02-09 Thread Tom Lane
Pavel Stehule writes: > 2010/2/9 Tom Lane : >> I don't think this is right at all. > yes, this isn't clear. My arguments for change: > a) the behave depends on types - "any" is different than others. So what? "variadic any" is different in a lot of ways. > b) optimization over fmgr doesn't wo

Re: [HACKERS] Confusion over Python drivers

2010-02-09 Thread Chris Browne
kevina...@hotmail.com (Kevin Ar18) writes: > Of course all of this is from the perspective of Python users. Of > course, you have your own features that you want from your end (from > PostgreSQL's perspective). Perhaps this info would help you to know > which avenue to pursue. No, those seem lik

Re: [HACKERS] Avoiding bad prepared-statement plans.

2010-02-09 Thread Tom Lane
Robert Haas writes: > On Tue, Feb 9, 2010 at 7:08 AM, Jeroen Vermeulen wrote: >> Periodically re-plan prepared statements on EXECUTE.  This is also a chance >> for queries that were being re-planned every time to go back to a generic >> plan. > The most common problem here seems to be that (some

Re: [HACKERS] [CFReview] Red-Black Tree

2010-02-09 Thread Oleg Bartunov
On Mon, 8 Feb 2010, Tom Lane wrote: Robert Haas writes: On Mon, Feb 8, 2010 at 3:05 PM, Alvaro Herrera wrote: It seems a bit strange to have all the rb_free_recursive support and not use it anywhere ... and a freefunc callback even, whose only caller seems to set as null currently. ═Hmm, eve

Re: [HACKERS] Streaming replication in docs

2010-02-09 Thread Heikki Linnakangas
Thom Brown wrote: > On 9 February 2010 01:57, Fujii Masao wrote: >> The attached patch changes the layout according to your suggestion >> (but with a small modification). Here is the new layout: >> >> --- >> Chapter 24. Backup and Restore >> 24.1. SQL Dump >>24.1.1.

Re: [HACKERS] bugfix - VIP: variadic function ignore strict flag

2010-02-09 Thread Pavel Stehule
2010/2/9 Tom Lane : > Pavel Stehule writes: >> +             /* >> +              * If function has variadic argument, skip calling >> +              * when variadic array contains NULL values. >> +              */ > > I don't think this is right at all.  The strict check ought to apply to > the a

Re: [HACKERS] Avoiding bad prepared-statement plans.

2010-02-09 Thread Robert Haas
On Tue, Feb 9, 2010 at 7:08 AM, Jeroen Vermeulen wrote: > = Projected-cost threshold = > > If a prepared statement takes parameters, and the generic plan has a high > projected cost, re-plan each EXECUTE individually with all its parameter > values bound.  It may or may not help, but unless the pl

Re: I: [HACKERS] About "Our CLUSTER implementation is pessimal" patch

2010-02-09 Thread Josh Kupershmidt
On Tue, Feb 9, 2010 at 5:49 AM, Leonardo F wrote: > Not even a comment? As I said, performance results on my system > were very good > Hi Leonardo, Perhaps you could supply a .sql file containing a testcase illustrating the performance benefits you tested with your patch -- as I understand,

Re: [HACKERS] buildfarm breakage

2010-02-09 Thread Magnus Hagander
On Tue, Feb 9, 2010 at 17:11, Tom Lane wrote: > Magnus Hagander writes: >> Here's a patch that "fixes" this. I put it locally for the radius >> authentication for now, since we don't use this anywhere else. Should >> we put this in /port/ somewhere, or is this good for now? > > How about dropping

Re: [HACKERS] bugfix - VIP: variadic function ignore strict flag

2010-02-09 Thread Tom Lane
Pavel Stehule writes: > + /* > + * If function has variadic argument, skip calling > + * when variadic array contains NULL values. > + */ I don't think this is right at all. The strict check ought to apply to the array argument as a whole.

Re: [HACKERS] buildfarm breakage

2010-02-09 Thread Tom Lane
Magnus Hagander writes: > Here's a patch that "fixes" this. I put it locally for the radius > authentication for now, since we don't use this anywhere else. Should > we put this in /port/ somewhere, or is this good for now? How about dropping it in src/backend/port/win32/mingwcompat.c ? The adva

[HACKERS] bugfix - VIP: variadic function ignore strict flag

2010-02-09 Thread Pavel Stehule
Hello, I am returning back to message http://archives.postgresql.org/pgsql-general/2010-02/msg00119.php Our implementation of variadic parameters missing correct handling test on NULL, and test on non constant value. This patch add correct tests for variadic parameters. Probably Gen_fmgrtab.pl h

Re: [HACKERS] Pathological regexp match

2010-02-09 Thread Joachim Wieland
On Mon, Feb 8, 2010 at 6:07 PM, David E. Wheeler wrote: > On Feb 8, 2010, at 5:15 AM, Magnus Hagander wrote: > >> The text is about 180Kb. PostgreSQL takes ~40 seconds without the >> patch, ~36 seconds with it, to extract the match from it. Perl takes >> 0.016 seconds. > > Obviously we need to sup

Re: [HACKERS] About psycopg2 (by its author)

2010-02-09 Thread Kevin Grittner
[Resending; I accidentally failed to copy the list.] Federico Di Gregorio wrote: > the logical choice is plain LGPL3. I am open to motivated > suggestions about other licenses but I'll ignore such crap as "BSD > is more open than LGPL". Well, I don't know about "more open", but I find the Pos

Re: [HACKERS] buildfarm breakage

2010-02-09 Thread Magnus Hagander
On Tue, Feb 9, 2010 at 13:52, Magnus Hagander wrote: > On Tue, Feb 9, 2010 at 02:20, Tom Lane wrote: >> Andrew Dunstan writes: >>> Mingw builds are missing in6addr_any in backend/libpq/auth.c, added by a >>> recent RADIUS support fix. Looks like we might need to include win32.h >>> in there. >>

Re: [HACKERS] Avoiding bad prepared-statement plans.

2010-02-09 Thread Mark Mielke
On 02/09/2010 08:46 AM, Jeroen Vermeulen wrote: This sounds like a really nice to have feature. Maybe it'd also be possible to skip replanning between executes if the current bound values are 'indexwise-equivalent' to the values used at previous planning, i.e. nothing in the statistics indicate

Re: [HACKERS] Avoiding bad prepared-statement plans.

2010-02-09 Thread Richard Huxton
On 09/02/10 14:25, Jeroen Vermeulen wrote: Richard Huxton wrote: = Actual-cost threshold = Also stop using the generic plan if the statement takes a long time to run in practice. Do you mean: 1. Rollback the current query and start again 2. Mark the plan as a bad one and plan again next exec

Re: [HACKERS] About psycopg2 (by its author)

2010-02-09 Thread Magnus Hagander
On Tue, Feb 9, 2010 at 15:28, Federico Di Gregorio wrote: > On 09/02/2010 15:22, Dave Page wrote: >> On Tue, Feb 9, 2010 at 1:56 PM, Federico Di Gregorio wrote: >>> Btw, I was >>> at FOSDEM as probably other PostgreSQL people were and all this could >>> have been discussed while drinking a couple

Re: [HACKERS] TCP keepalive support for libpq

2010-02-09 Thread Andrew Chernow
Tollef Fog Heen wrote: (please Cc me on replies, I am not subscribed) Hi, libpq currently does not use TCP keepalives. This is a problem in our case where we have some clients waiting for notifies and then the connection is dropped on the server side. The client never gets the FIN and thinks

Re: [HACKERS] Avoiding bad prepared-statement plans.

2010-02-09 Thread Jeroen Vermeulen
Andres Freund wrote: = Actual-cost threshold = Also stop using the generic plan if the statement takes a long time to run in practice. Statistics may have gone bad. It could also be a one-off due to a load peak or something, but that's handled by: That is not that easy. It means that you ha

Re: [HACKERS] About psycopg2 (by its author)

2010-02-09 Thread Federico Di Gregorio
On 09/02/2010 15:22, Dave Page wrote: > On Tue, Feb 9, 2010 at 1:56 PM, Federico Di Gregorio wrote: >> Btw, I was >> at FOSDEM as probably other PostgreSQL people were and all this could >> have been discussed while drinking a couple of beers if only someone >> cared to contact me. > > Hmm, I res

Re: [HACKERS] Avoiding bad prepared-statement plans.

2010-02-09 Thread Jeroen Vermeulen
Richard Huxton wrote: = Actual-cost threshold = Also stop using the generic plan if the statement takes a long time to run in practice. Do you mean: 1. Rollback the current query and start again 2. Mark the plan as a bad one and plan again next execute If you can figure out how to do #1 then

Re: [HACKERS] About psycopg2 (by its author)

2010-02-09 Thread Dave Page
On Tue, Feb 9, 2010 at 1:56 PM, Federico Di Gregorio wrote: > Btw, I was > at FOSDEM as probably other PostgreSQL people were and all this could > have been discussed while drinking a couple of beers if only someone > cared to contact me. Hmm, I resent that. As one of the people at FOSDEM a) I ha

Re: [HACKERS] [CFReview] Red-Black Tree

2010-02-09 Thread Teodor Sigaev
Good idea, implemented. Hmm. I think your implementation is prone to overflow in two places - both when computing step, and also when stepping through the array. Pls, point me, I don't see that ! step |= (step >> 1); ! step |= (step >> 2); ! step |= (step >> 4); ! s

Re: [HACKERS] TCP keepalive support for libpq

2010-02-09 Thread Tollef Fog Heen
]] Magnus Hagander | Seems reasonable to add this. Are there any scenarios where this can | cause trouble, that would be fixed by having the ability to select | non-standard behavior? Well, it might be unwanted if you're on a pay-per-bit connection such as 3G, but in this case, it just makes the

Re: [HACKERS] Avoiding bad prepared-statement plans.

2010-02-09 Thread Andres Freund
On Tuesday 09 February 2010 13:08:54 Jeroen Vermeulen wrote: > I've been discussing this with Josh, Heikki, and Peter E. over the past > few weeks. > > As Peter observed years ago, prepared statements can perform badly > because their plans are overly generic. Also, statistics change and > someti

[HACKERS] About psycopg2 (by its author)

2010-02-09 Thread Federico Di Gregorio
First of all let me say that from such incredible hackers as the PostgreSQL people I'd have expected the ability to find my email address and maybe keep me or (even better) the psycopg mailing list in CC. That would have avoided a lot of confusion both on the license and the status of psycopg2. If

Re: [HACKERS] [CFReview] Red-Black Tree

2010-02-09 Thread Alvaro Herrera
Robert Haas escribió: > On Mon, Feb 8, 2010 at 3:05 PM, Alvaro Herrera > wrote: > > How do we now that it works? > > Visual inspection? It's not very complicated. Well, that works if you assume the trivial/usual malloc/free coding style, but it fails in the hypothetical scenario I described ea

Re: [HACKERS] Avoiding bad prepared-statement plans.

2010-02-09 Thread Yeb Havinga
Jeroen Vermeulen wrote: I've been discussing this with Josh, Heikki, and Peter E. over the past few weeks. Is this searchable in the archives? I'm interested in ideas discussed. If a prepared statement takes parameters, and the generic plan has a high projected cost, re-plan each EXECUTE indivi

Re: [HACKERS] Avoiding bad prepared-statement plans.

2010-02-09 Thread Richard Huxton
On 09/02/10 12:08, Jeroen Vermeulen wrote: = Projected-cost threshold = [snip - this is the simple bit. Sounds very sensible. ] = Actual-cost threshold = Also stop using the generic plan if the statement takes a long time to run in practice. Do you mean: 1. Rollback the current query and

  1   2   >