Обсуждение: EXEC_BACKEND + logging_collector=on is broken
Hi, Currently the combination from $subject fails for me with "could not read from backend variables file ...". The origin for that problem seems to be b94ce6e80 which moved RemovePgTempFiles() to after SysLogger_Start(). Unless the syslogger starts up very quickly RemovePgTempFiles() will have deleted the server variables file. I think moving the RemovePgTempFiles() to just above SysLogger_Start() should preserve the faster reporting for pg_ctl intended by b94ce6e80 and fix the startup issue? I'm rather surprised that this hasn't caused more problems. Apparently windows users don't use the logging_collector? Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
On Tue, Jan 13, 2015 at 10:23 AM, Andres Freund <andres@2ndquadrant.com> wrote:
-- Hi,
Currently the combination from $subject fails for me with "could not
read from backend variables file ...".
The origin for that problem seems to be b94ce6e80 which moved
RemovePgTempFiles() to after SysLogger_Start(). Unless the syslogger
starts up very quickly RemovePgTempFiles() will have deleted the server
variables file.
I think moving the RemovePgTempFiles() to just above SysLogger_Start()
should preserve the faster reporting for pg_ctl intended by b94ce6e80
and fix the startup issue?
I'm rather surprised that this hasn't caused more problems. Apparently
windows users don't use the logging_collector?
I haven't looked at the actual code. But AFAIK, logging_collector=on and storing it in pg_log is the default log behaviour for pg on Windows installed by the edb installers afaik. Always has been. Surely we didn't break logging on Windows completely back in 9.2?! Any chance it's working on Windows, just not EXEC_BACKEND on Unix?
(Dave or someone else from the EDB team can probably confirm that this is still the default in the installers?)
EXEC_BACKEND on Windows doesn't actually use a tempfile though, so I'm guessing that's it. It does an anonymous memory mapping (see top of internal_forkexec) out of the swapfile and passes a handle down. And only closes it's own handle once it's been inherited into the subprocess.
I'm pretty sure that means it's not actually broken on Windows.
On 2015-01-13 11:10:06 -0800, Magnus Hagander wrote: > EXEC_BACKEND on Windows doesn't actually use a tempfile though, so I'm > guessing that's it. Ah! Then this really is fairly harmless. Will fix and backpatch anyway, but the number of affected people should be pretty much zero. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
Andres Freund <andres@2ndquadrant.com> writes:
> On 2015-01-13 11:10:06 -0800, Magnus Hagander wrote:
>> EXEC_BACKEND on Windows doesn't actually use a tempfile though, so I'm
>> guessing that's it.
> Ah! Then this really is fairly harmless. Will fix and backpatch anyway,
> but the number of affected people should be pretty much zero.
Agreed. We want this case to work for our own testing purposes, but
it's unlikely to be hurting anybody in the field.
regards, tom lane
On 2015-01-13 20:21:55 +0100, Andres Freund wrote: > On 2015-01-13 11:10:06 -0800, Magnus Hagander wrote: > > EXEC_BACKEND on Windows doesn't actually use a tempfile though, so I'm > > guessing that's it. > > Ah! Then this really is fairly harmless. Will fix and backpatch anyway, > but the number of affected people should be pretty much zero. Done that now. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services