Skip site navigation (1) Skip section navigation (2)

Re: backend crash following load command

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Martijn van Oosterhout <kleptog(at)svana(dot)org>
Cc: Merlin Moncure <mmoncure(at)gmail(dot)com>, PgSQL General <pgsql-general(at)postgresql(dot)org>
Subject: Re: backend crash following load command
Date: 2006-11-28 22:05:40
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-general
Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> Hmm? To upgrade you merely need to delete the old one and
> install the new one, there's no need to preserve the inode. The mmap()
> is private, but no, Linux does not keep a backup copy of the shared
> library if you overwrite it. The behaviour of overwriting the backing
> store of a private mapping is explicitly undefined.

Right, but isn't "cp -f" doing exactly that --- deleting the old one and
installing the new one?

[ experiments a bit... ]  Oh, that's interesting.  I was under the
impression that "cp -f" would always unlink the target file, but
on my machine (reasonably up-to-date Fedora 5, x86_64), this happens
only if it can't do open("foo", O_WRONLY|O_TRUNC).  If the existing
file is overwritable then there is no difference between cp and cp -f
... and *both* crash the backend.  If I "chmod -w" the .so file so that
cp -f is forced to unlink it first, then the backend does not crash!

This is at variance with what Merlin reported --- so I'm asking again
just what platform he's on.  He might want to strace cp to see whether
it's doing an unlink or not in his scenario.

Anyway, on my machine, the behavior is consistent with Martijn's theory.
I suspect the kernel is effectively unmapping the .so when the
overwrite occurs, and then dlsym() naturally SIGSEGV's while trying to
look into the mapped area.  If so, the early-PG_fini-lookup approach
wouldn't really fix anything.

The best solution for Merlin is probably to do "rm" then "cp" to install
a new version of the .so, instead of relying on "cp -f" to do it safely.

			regards, tom lane

In response to


pgsql-general by date

Next:From: Daniel SerodioDate: 2006-11-28 22:13:49
Subject: Re: Question about encoding
Previous:From: Scott RibeDate: 2006-11-28 21:58:01
Subject: Re: NULLs ;-)

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group