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

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Tomas Vondra <tv(at)fuzzy(dot)cz>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: overwriting an existing .so while being used crashes the server process
Date: 2012-05-31 08:09:12
Message-ID: 1338451752.22408.7.camel@vanquo.pezone.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Robert Haas 2012-05-31 14:53:51 Re: BUG #6650: CPU system time utilization rising few times a day
Previous Message ByGlow 2012-05-31 07:34:51 BUG #6670: Translate small SQL from 8.0 ti 7.3