Re: [HACKERS] pg_basebackup from cascading standby after timeline switch

2012-12-27 Thread Heikki Linnakangas
On 23.12.2012 15:33, Fujii Masao wrote: On Fri, Dec 21, 2012 at 9:54 PM, Heikki Linnakangas hlinnakan...@vmware.com wrote: Yes, this should be backpatched to 9.2. I came up with the attached. In this patch, if '-X stream' is specified in pg_basebackup, the timeline history files are not

Re: [HACKERS] Proposal: Store timestamptz of database creation on pg_database

2012-12-27 Thread Stephen Frost
* Josh Berkus (j...@agliodbs.com) wrote: This information could be extremely useful for forensics, debugging, ETL processes (many of which create tables as part of their processes), etc. I'd say moderately useful at best. Quite a number of things could make the creation dates misleading or

Re: [HACKERS] buffer assertion tripping under repeat pgbench load

2012-12-27 Thread Greg Stark
On Thu, Dec 27, 2012 at 3:17 AM, Tom Lane t...@sss.pgh.pa.us wrote: The thing that this theory has a hard time with is that the buffer's global refcount is zero. If you assume that there's a bit that sometimes randomly goes to 1 when it should be 0, then what I'd expect to typically happen is

[HACKERS] A stab at implementing better password hashing, with mixed results

2012-12-27 Thread Peter Bex
Hello all, A while ago, on pgsql-general, I raised the issue that the password storage employed by postgres is a little weak and promised I'd look into this during the holidays, so here are my findings. Implementing bcrypt instead of md5 is indeed rather straightforward; just move the pgcrypto

Re: [HACKERS] pgcrypto seeding problem when ssl=on

2012-12-27 Thread Marko Kreen
On Sun, Dec 23, 2012 at 9:45 PM, Tom Lane t...@sss.pgh.pa.us wrote: Marko Kreen mark...@gmail.com writes: On Sat, Dec 22, 2012 at 9:20 PM, Tom Lane t...@sss.pgh.pa.us wrote: I'm not thrilled with the suggestion to do RAND_cleanup() after forking though, as that seems like it'll guarantee

Re: [HACKERS] A stab at implementing better password hashing, with mixed results

2012-12-27 Thread Claudio Freire
On Thu, Dec 27, 2012 at 11:46 AM, Peter Bex peter@xs4all.nl wrote: Implementing a more secure challenge-response based algorithm means a change in the client-server protocol. Perhaps something like SCRAM (maybe through SASL) really is the way forward for this, but that seems like quite a

Re: [HACKERS] A stab at implementing better password hashing, with mixed results

2012-12-27 Thread Peter Bex
On Thu, Dec 27, 2012 at 12:31:08PM -0300, Claudio Freire wrote: On Thu, Dec 27, 2012 at 11:46 AM, Peter Bex peter@xs4all.nl wrote: Implementing a more secure challenge-response based algorithm means a change in the client-server protocol. Perhaps something like SCRAM (maybe through

Re: [HACKERS] Proposal: Store timestamptz of database creation on pg_database

2012-12-27 Thread Dimitri Fontaine
Hi, Tom Lane t...@sss.pgh.pa.us writes: This proposal is about add a column datcreated on pg_database to store the timestamp of the database creation. I'm inclined to think that anyone who really needs this should be pointed at event triggers. That feature (if it gets in) will allow people

Re: [HACKERS] buffer assertion tripping under repeat pgbench load

2012-12-27 Thread Tom Lane
Greg Stark st...@mit.edu writes: On Thu, Dec 27, 2012 at 3:17 AM, Tom Lane t...@sss.pgh.pa.us wrote: The thing that this theory has a hard time with is that the buffer's global refcount is zero. If you assume that there's a bit that sometimes randomly goes to 1 when it should be 0, then what

[HACKERS] fix bgworkers in EXEC_BACKEND

2012-12-27 Thread Alvaro Herrera
I committed background workers three weeks ago, claiming it worked on EXEC_BACKEND, and shortly thereafter I discovered that it didn't. I noticed that the problem is the kludge to cause postmaster and children to recompute MaxBackends after shared_preload_libraries is processed; so the minimal

Re: [HACKERS] fix bgworkers in EXEC_BACKEND

2012-12-27 Thread Magnus Hagander
On Thu, Dec 27, 2012 at 6:15 PM, Alvaro Herrera alvhe...@2ndquadrant.com wrote: I committed background workers three weeks ago, claiming it worked on EXEC_BACKEND, and shortly thereafter I discovered that it didn't. I noticed that the problem is the kludge to cause postmaster and children to

Re: [HACKERS] fix bgworkers in EXEC_BACKEND

2012-12-27 Thread Heikki Linnakangas
On 27.12.2012 19:15, Alvaro Herrera wrote: I committed background workers three weeks ago, claiming it worked on EXEC_BACKEND, and shortly thereafter I discovered that it didn't. I noticed that the problem is the kludge to cause postmaster and children to recompute MaxBackends after

Re: [HACKERS] fix bgworkers in EXEC_BACKEND

2012-12-27 Thread Stephen Frost
* Heikki Linnakangas (hlinnakan...@vmware.com) wrote: Thinking about this some more, it might be cleaner to move the responsibility of setting MaxBackends out of guc.c, into postmaster.c. The guc machinery would set max_connections and autovacuum_max_workers as usual, but not try to set

Re: [HACKERS] fix bgworkers in EXEC_BACKEND

2012-12-27 Thread Simon Riggs
On 27 December 2012 18:06, Heikki Linnakangas hlinnakan...@vmware.com wrote: This would have the advantage that MaxBackends would be kept set at zero, until we know the final value. That way it's obvious that you cannot trust the value of MaxBackends in a contrib module preload-function, for

Re: [HACKERS] fix bgworkers in EXEC_BACKEND

2012-12-27 Thread Stephen Frost
Simon, * Simon Riggs (si...@2ndquadrant.com) wrote: I admire your forward thinking on that; yes, that could cause problems. But even then, we would be admitting that nobody now gets a valid value of MaxBackends, which sounds like it might be a problem in itself. I agree that the current

Re: [HACKERS] Event Triggers: adding information

2012-12-27 Thread Simon Riggs
On 21 December 2012 14:48, Robert Haas robertmh...@gmail.com wrote: I predict that if we commit this, it will becomes a never-ending and irrecoverable font of trouble. Event triggers are a new feature with many powerful uses: replication, online upgrade, data transport. New features require

Re: [HACKERS] fix bgworkers in EXEC_BACKEND

2012-12-27 Thread Simon Riggs
On 27 December 2012 18:36, Stephen Frost sfr...@snowman.net wrote: Simon, * Simon Riggs (si...@2ndquadrant.com) wrote: I admire your forward thinking on that; yes, that could cause problems. But even then, we would be admitting that nobody now gets a valid value of MaxBackends, which sounds

Re: [HACKERS] fix bgworkers in EXEC_BACKEND

2012-12-27 Thread Alvaro Herrera
Stephen Frost wrote: * Heikki Linnakangas (hlinnakan...@vmware.com) wrote: Thinking about this some more, it might be cleaner to move the responsibility of setting MaxBackends out of guc.c, into postmaster.c. The guc machinery would set max_connections and autovacuum_max_workers as usual,

Re: [HACKERS] fix bgworkers in EXEC_BACKEND

2012-12-27 Thread Tom Lane
Stephen Frost sfr...@snowman.net writes: Simon, * Simon Riggs (si...@2ndquadrant.com) wrote: I admire your forward thinking on that; yes, that could cause problems. But even then, we would be admitting that nobody now gets a valid value of MaxBackends, which sounds like it might be a problem

Re: [HACKERS] fix bgworkers in EXEC_BACKEND

2012-12-27 Thread Alvaro Herrera
Heikki Linnakangas wrote: Might be cleaner to directly assign the correct value to MaxBackends above, ie. MaxBackends = MaxConnections + newval + 1 + GetNumShmemAttachedBgworkers(). With a comment to remind that it needs to be kept in sync with the other places where that calculation is

Re: [HACKERS] Proposal: Store timestamptz of database creation on pg_database

2012-12-27 Thread Fabrízio de Royes Mello
On Thu, Dec 27, 2012 at 2:13 AM, Tom Lane t...@sss.pgh.pa.us wrote: This has been debated, and rejected, before. I know this discussion... To mention just one problem, are we going to add nonstandard, non-backwards-compatible syntax to every single kind of CREATE to allow pg_dump to

Re: [HACKERS] Proposal: Store timestamptz of database creation on pg_database

2012-12-27 Thread Fabrízio de Royes Mello
On Thu, Dec 27, 2012 at 2:04 PM, Dimitri Fontaine dimi...@2ndquadrant.fr wrote: Tom Lane t...@sss.pgh.pa.us writes: This proposal is about add a column datcreated on pg_database to store the timestamp of the database creation. I'm inclined to think that anyone who really needs this

Re: [HACKERS] fix bgworkers in EXEC_BACKEND

2012-12-27 Thread Andres Freund
On 2012-12-27 20:06:07 +0200, Heikki Linnakangas wrote: On 27.12.2012 19:15, Alvaro Herrera wrote: I committed background workers three weeks ago, claiming it worked on EXEC_BACKEND, and shortly thereafter I discovered that it didn't. I noticed that the problem is the kludge to cause

Re: [HACKERS] fix bgworkers in EXEC_BACKEND

2012-12-27 Thread Tom Lane
Andres Freund and...@2ndquadrant.com writes: I am still worried about the following scenario in the EXEC_BACKEND case: 1) postmaster starts 2) reads config 3) executes _PG_init for shared_preload_libraries 4) library 'abc' gets config value 'abc.num_workers = 2' and registers as many

Re: [HACKERS] fix bgworkers in EXEC_BACKEND

2012-12-27 Thread Andres Freund
On 2012-12-27 18:44:57 -0500, Tom Lane wrote: Andres Freund and...@2ndquadrant.com writes: I am still worried about the following scenario in the EXEC_BACKEND case: 1) postmaster starts 2) reads config 3) executes _PG_init for shared_preload_libraries 4) library 'abc' gets config value

Re: [HACKERS] fix bgworkers in EXEC_BACKEND

2012-12-27 Thread anara...@anarazel.de
Tom Lane t...@sss.pgh.pa.us schrieb: Andres Freund and...@2ndquadrant.com writes: I am still worried about the following scenario in the EXEC_BACKEND case: 1) postmaster starts 2) reads config 3) executes _PG_init for shared_preload_libraries 4) library 'abc' gets config value

Re: [HACKERS] Proposal: Store timestamptz of database creation on pg_database

2012-12-27 Thread Stephen Frost
Dimitri, * Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote: Here's a complete test case that works with my current branch, with a tricky test while at it, of course: Apparently I've managed to miss the tricky case..? Sure, dropping tables, schemas, etc, would have an impact on the values.

Re: [HACKERS] fix bgworkers in EXEC_BACKEND

2012-12-27 Thread Tom Lane
Andres Freund and...@2ndquadrant.com writes: On 2012-12-27 18:44:57 -0500, Tom Lane wrote: This is broken whether it's EXEC_BACKEND or not: you don't get to change anything that determines the number of workers post-startup. num_workers should have been declared PGC_POSTMASTER. Well, the