Re: "could not reattach to shared memory" captured in buildfarm
От | Magnus Hagander |
---|---|
Тема | Re: "could not reattach to shared memory" captured in buildfarm |
Дата | |
Msg-id | 49FEA758.80605@hagander.net обсуждение исходный текст |
Ответ на | "could not reattach to shared memory" captured in buildfarm (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: "could not reattach to shared memory" captured in buildfarm
Re: "could not reattach to shared memory" captured in buildfarm |
Список | pgsql-hackers |
Tom Lane wrote: > vaquita has an interesting report today: > http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=vaquita&dt=2009-05-01%2020:00:06 > > Partway through the contrib tests, for absolutely no visible reason > whatsoever, connections start to fail with > FATAL: could not reattach to shared memory (key=364, addr=02920000): 487 Note that 487 is "invalid address", and should not have anything to do with the issues Andrew mentioned (which were about the already-exists error). Somebody else mentioned, and IIRC I talked to Dave about this before, that this could be because the address is no longer available. The reason for this could be some kind of race condition in the backends starting - the address is available when the postmaster starts and thus it's used, but when a regular backend starts, the memory is used for something else. One proposed fix is to allocate a fairly large block of memory in the postmaster just before we get the shared memory, and then free it right away. The effect should be to push down the shared memory segment further in the address space. Comments? //Magnus
В списке pgsql-hackers по дате отправления: