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 | 20190521044512.GD1921@paquier.xyz обсуждение исходный текст |
Ответ на | Re: BUG #15804: Assertion failure when using logging_collector with EXEC_BACKEND (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-bugs |
On Mon, May 20, 2019 at 11:01:05AM -0400, Tom Lane wrote: > In other words, the right way to think about this is less "move > syslogger launch to earlier" and more "move port opening to later". > I did some cursory testing of that idea with the attached patch, > which simply relocates the port opening logic to below where > syslogger start is (though "git diff" insists on presenting it > differently :-(). I also moved and recommented the emission > of the "starting ..." log entry. It works under EXEC_BACKEND, > but I'm not fool enough to believe that that proves it works > under Windows :-(. I can see what you have done, no worries. > One issue with this is that we can't be sure we have sole control > of the postmaster port number at the time we create shmem. Couldn't that also be a problem for some users? This means that there is a window where the port won't be opened but the external PID file can be found. Some tools could be broken as an effect of that. > Hence, to avoid undesirable conflicts of shmem, we should change > things to base the shmem key on the datadir's ID not the port > number, as was already speculated about in > https://postgr.es/m/16908.1557521200@sss.pgh.pa.us This would be actually nice to change as you suggest. > Another point is that we want to be sure this doesn't change > the order in which lockfiles are released at shutdown. That > seems OK (I confirmed by strace'ing that the postmaster's > final syscalls are still done in the same order) but it could > use some additional eyeballs on it. > > There may be some other reorderings that would be a good idea. > In particular I'm thinking that the CreateOptsFile call should > be pushed down, so that it doesn't get written until we know > that the port number is OK. Is this thread a good place to discuss all those changes by the way? After all the recent activity in this area, a new thread and a discussion for v13 would be I think appropriate. I would rather not play with the devil for v12. -- Michael
Вложения
В списке pgsql-bugs по дате отправления: