Bruce Momjian wrote:
Actually, this is the current state of this issue.
Right, please comment on this. To recall, it uses shared memory for a
switch to next logfile name flag, which can't cause harm in case of
shmem corruption, and a postmaster opened filehandle (kept open) to a
dummy file
Actually, this is the current state of this issue.
---
Andreas Pflug wrote:
Tom Lane wrote:
Andreas Pflug [EMAIL PROTECTED] writes:
Answering my own question, the distribution of the current logfile
name could
Andreas Pflug wrote:
Andreas Pflug wrote:
We agreed long ago that the
postmaster should never depend on the correctness of any shared memory
data structure; but this patch would make it do so.
I understand that, so what's the suggested way to store data common
for all backends?
Answering my
Andreas Pflug [EMAIL PROTECTED] writes:
Answering my own question, the distribution of the current logfile
name could be done trough a file handle.
would you mind commenting on my suggestion so I can continue on that topic?
There is no portable way to redistribute a file handle.
Tom Lane wrote:
Andreas Pflug [EMAIL PROTECTED] writes:
Answering my own question, the distribution of the current logfile
name could be done trough a file handle.
would you mind commenting on my suggestion so I can continue on that topic?
There is no portable way to
Tom doesn't like returning the server's logfile using a pgsql function
unless logfile rotation is implemented, so here it is.
This proposal doesn't include a daemon that triggers pg_logfile_rotate
when appropriate (timestamp and/or length dependent), pg_autovacuum
might be a good place to do
Andreas Pflug [EMAIL PROTECTED] writes:
Tom doesn't like returning the server's logfile using a pgsql function
unless logfile rotation is implemented, so here it is.
I'll repeat what I said in response to your other posting:
This uses a shared memory area with no lock, which seems a bad
Tom Lane wrote:
I'll repeat what I said in response to your other posting:
Hm? I never posted something with shared mem usage before, what do you mean?
This uses a shared memory area with no lock, which seems a bad design;
AFAICS there should be no lock necessary.
We agreed long ago that
Andreas Pflug wrote:
We agreed long ago that the
postmaster should never depend on the correctness of any shared memory
data structure; but this patch would make it do so.
I understand that, so what's the suggested way to store data common
for all backends?
Answering my own question, the