Re: overwriting an existing .so while being used crashes the server process

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: overwriting an existing .so while being used crashes the server process
Дата
Msg-id 1338451752.22408.7.camel@vanquo.pezone.net
обсуждение исходный текст
Ответ на Re: overwriting an existing .so while being used crashes the server process  (Tomas Vondra <tv@fuzzy.cz>)
Список pgsql-bugs
On ons, 2012-05-30 at 23:43 +0200, Tomas Vondra wrote:
> On 30.5.2012 23:19, Tom Lane wrote:
> > I suspect it depends on how you install the new version of the library,
> > too.  I would somewhat expect it to work as you're thinking if the
> > install consists of "rename old file out of the way, copy new file into
> > place, unlink old file" or equivalent.  If you are actually
> > *overwriting* the file in place, a crash does not seem especially
> > surprising --- it would make perfect sense if the kernel expects the
> > file to be usable as backing store for the in-memory image, which is not
> > exactly unreasonable.  IOW, if the in-memory bits we're executing are
> > just an mmap'd image of the .so file, changing the .so file could
> > entirely be expected to lead to a crash.
>
> Aha! That might be the culprit - I've just tested that deleting the olf
> file and copying new version (thus not overwriting it) did not cause a
> crash. Funny.

That's one of the reasons why one normally uses "install" rather than
"cp" to install files.  So this shouldn't be a problem in practice if
people use the provided pgxs infrastructure or something similar.

GNU cp has the --remove-destination option, which should also work for
this purpose.

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: BUG #6668: hashjoin cost problem
Следующее
От: Robert Haas
Дата:
Сообщение: Re: BUG #6650: CPU system time utilization rising few times a day