Re: BUG #15804: Assertion failure when using logging_collector withEXEC_BACKEND
От | Michael Paquier |
---|---|
Тема | Re: BUG #15804: Assertion failure when using logging_collector withEXEC_BACKEND |
Дата | |
Msg-id | 20190516060628.GE1415@paquier.xyz обсуждение исходный текст |
Ответ на | Re: BUG #15804: Assertion failure when using logging_collector with EXEC_BACKEND (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #15804: Assertion failure when using logging_collector withEXEC_BACKEND
|
Список | pgsql-bugs |
On Thu, May 16, 2019 at 12:51:34AM -0400, Tom Lane wrote: > Hm, should we separate the cleanup of the root pgsql_tmp/ from the rest of > what RemovePgTempFiles does? I'm still feeling like we should be trying > to launch the syslogger as soon as possible. Indeed, this should be safe, the syslogger is not going to touch any of the other temp files anyway. If we begin to do that, we had better update the comments at the top of RemovePgTempFiles()'s call, and expose RemovePgTempFilesInDir(). Anyway, I have to admit that I am not really enthusiastic about relaxing the assertions for the win32 and the sysv interfaces, and do that inconsistently on top of it. As far as my first investigations have gone, assertions in pgwin32_ReserveSharedMemoryRegion() and PGSharedMemoryReAttach():sysv_shmem.c would need relaxing, but we rely on that since a7e5878, which is quite some time ago. And, actually, the failure for pgwin32_ReserveSharedMemoryRegion() should never happen at all, because we need to call reset_shared() before starting the syslogger as well, no? If we want to be able to log the creation socket messages with the logging collector, it seems to me that we would need first to remove the dependency with the port number in PGSharedMemoryCreate() to find a free IPC key. Thoughts? -- Michael
Вложения
В списке pgsql-bugs по дате отправления: