On 23.12.2012 15:33, Fujii Masao wrote:
On Fri, Dec 21, 2012 at 9:54 PM, Heikki Linnakangas
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 backed up.
Good point.
W
* 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 mislea
On Thu, Dec 27, 2012 at 3:17 AM, Tom Lane 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 that UnpinBuff
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 bl
On Sun, Dec 23, 2012 at 9:45 PM, Tom Lane wrote:
> Marko Kreen writes:
>> On Sat, Dec 22, 2012 at 9:20 PM, Tom Lane wrote:
> >> I'm not thrilled with the suggestion to do RAND_cleanup() after forking
> >> though, as that seems like it'll guarantee that each session starts out
> >> with only a mi
On Thu, Dec 27, 2012 at 11:46 AM, Peter Bex 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 project and it
On Thu, Dec 27, 2012 at 12:31:08PM -0300, Claudio Freire wrote:
> On Thu, Dec 27, 2012 at 11:46 AM, Peter Bex 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
Hi,
Tom Lane 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 writes:
> On Thu, Dec 27, 2012 at 3:17 AM, Tom Lane 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 typicall
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 fix
On Thu, Dec 27, 2012 at 6:15 PM, 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
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 shared_prelo
* 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 Max
On 27 December 2012 18:06, Heikki Linnakangas 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 example,
> which would
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 i
On 21 December 2012 14:48, Robert Haas 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 extra code. To decide
On 27 December 2012 18:36, Stephen Frost 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 like it mi
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 a
Stephen Frost 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 in
>> itsel
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
On Thu, Dec 27, 2012 at 2:13 AM, Tom Lane 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 preserve the creati
On Thu, Dec 27, 2012 at 2:04 PM, Dimitri Fontaine
wrote:
>
>
> Tom Lane 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
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 po
Andres Freund 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 workers
> 5) some time
On 2012-12-27 18:44:57 -0500, Tom Lane wrote:
> Andres Freund 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_w
Tom Lane schrieb:
>Andres Freund 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
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.
Dr
Andres Freund 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 problem is, a shar
28 matches
Mail list logo
