Re: [HACKERS] What's left?
- From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
- To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
- Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Claudio Natoli <claudio(dot)natoli(at)memetrics(dot)com>, "''Merlin Moncure' '" <merlin(dot)moncure(at)rcsonline(dot)com>, "'pgsql-hackers-win32 '" <pgsql-hackers-win32(at)postgresql(dot)org>
- Subject: Re: [HACKERS] What's left?
- Date: Mon, 26 Jan 2004 20:51:12 -0500 (EST)
- Message-id: <200401270151(dot)i0R1pCo21623(at)candle(dot)pha(dot)pa(dot)us>
Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > In this way, no one ever has the rename file open while we are holding
> > the locks, and we can loop without holding an exclusive lock on
> > pg_shadow, and file writes remain in order.
>
> You're doing this where exactly, and are certain that you are holding no
> locks why exactly? And if you aren't holding a lock, what prevents
> concurrency bugs?
I am looking now at the relcache file, pg_pwd and pg_group. I am sure I
am holding some locks, but not an exclusive lock on e.g. pg_shadow. I am
working on a patch now. I don't expect to eliminate the looping for
rename, but to eliminate holding exclusive locks while doing the rename
to a file actively being read. By using realfile.new, the first rename
is only being done on a file that is never opened, just renamed, which
should be quick.
I can't think of a cleaner solution.
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Home |
Main Index |
Thread Index