On Mon, 2009-12-07 at 19:21 -0500, Tom Lane wrote:
> Simon Riggs writes:
> > On Mon, 2009-12-07 at 19:07 +0200, Heikki Linnakangas wrote:
> >> Why not just follow the example of postresql.conf?
>
> > Much better idea.
>
> Rather than reinventing all the infrastructure associated with GUCs,
> may
Simon Riggs writes:
> On Mon, 2009-12-07 at 19:07 +0200, Heikki Linnakangas wrote:
>> Why not just follow the example of postresql.conf?
> Much better idea.
Rather than reinventing all the infrastructure associated with GUCs,
maybe we should just make the recovery parameters *be* GUCs. At least
On Mon, 2009-12-07 at 19:07 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > How does this sound?
> >
> > At startup we will delete recovery.conf.running, if it exists.
> > At startup recovery.conf will be copied to recovery.conf.running, which
> > will be the file read by any additional
Simon Riggs wrote:
> How does this sound?
>
> At startup we will delete recovery.conf.running, if it exists.
> At startup recovery.conf will be copied to recovery.conf.running, which
> will be the file read by any additional processes that read
> recovery.conf during this execution. The permission
On Mon, 2009-12-07 at 19:26 +0900, Fujii Masao wrote:
> On Mon, Dec 7, 2009 at 5:28 PM, Simon Riggs wrote:
> > If you really think that changing the file is a possibility between
> > processes reading them, then I would just take a full temp copy of the
> > file, read it in postmaster, read it in
On Mon, Dec 7, 2009 at 5:28 PM, Simon Riggs wrote:
> If you really think that changing the file is a possibility between
> processes reading them, then I would just take a full temp copy of the
> file, read it in postmaster, read it in startup, then delete temp file.
This seems more robust becaus
Simon Riggs wrote:
> On Mon, 2009-12-07 at 10:13 +0200, Heikki Linnakangas wrote:
>> Reading the file separately in each process would cause trouble with
>> PGC_POSTMASTER params. All backends must agree on their values.
>
> Looking at the parameters in recovery.conf I don't believe they would
> c
On Mon, 2009-12-07 at 10:13 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > What postgresql.conf already does is read file separately in each
> > process, so no data passing.
>
> No it doesn't. Postmaster reads the file once, and backends inherit the
> values at fork(). In EXEC_BACKEND c
Simon Riggs wrote:
> What postgresql.conf already does is read file separately in each
> process, so no data passing.
No it doesn't. Postmaster reads the file once, and backends inherit the
values at fork(). In EXEC_BACKEND case, postmaster writes all the
non-default values to a separate file, whi
On Mon, 2009-12-07 at 13:03 +0900, Fujii Masao wrote:
> On Sun, Dec 6, 2009 at 2:49 AM, Simon Riggs wrote:
> > Proposal is to split out the couple of lines in
> > readRecoveryCommandFile() that set important state and make it read in
> > an option block that can be used by caller. It would then be
On Sun, Dec 6, 2009 at 2:49 AM, Simon Riggs wrote:
> Proposal is to split out the couple of lines in
> readRecoveryCommandFile() that set important state and make it read in
> an option block that can be used by caller. It would then be called by
> both postmaster (earlier in startup) and again la
On Sat, 2009-12-05 at 15:43 -0500, Tom Lane wrote:
> Simon Riggs writes:
> > I'm planning to read recovery.conf earlier in the startup process, so we
> > can make a few things more "recovery aware". It's a nice-to-have only.
>
> Say what? It's read at the beginning already.
Before the beginning
Simon Riggs writes:
> I'm planning to read recovery.conf earlier in the startup process, so we
> can make a few things more "recovery aware". It's a nice-to-have only.
Say what? It's read at the beginning already.
regards, tom lane
--
Sent via pgsql-hackers mailing lis
I'm planning to read recovery.conf earlier in the startup process, so we
can make a few things more "recovery aware". It's a nice-to-have only.
This won't be part of the HS patch though.
Proposal is to split out the couple of lines in
readRecoveryCommandFile() that set important state and make i
14 matches
Mail list logo
