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
* 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
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
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
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
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
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
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
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
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
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
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
* 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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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.
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
28 matches
Mail list logo
