Re: 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: 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>, "'PostgreSQL-development '" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: What's left?
Date: 2004-01-26 05:49:07
Message-ID: 200401260549.i0Q5n8M10662@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-hackers-win32

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > I think it will very likely rename/unlink will fail because of the file
> > descriptor cache kept by each backend.
>
> Hmm ... you're probably right. Okay, it's a more significant issue than
> I thought.
>
> > I am attaching dir.c from the PeerDirect port. It handles unlink
> > failures by appending the failed file name to a file that is later read
> > and another unlink attempted. Perhaps this is something we can do, and
> > have try unlinks after each checkpoint.
>
> That seems like a possibility. The open files will get closed very soon
> after the delete occurs (as a byproduct of relcache flush), so we don't
> need very much of a delay. Next checkpoint sounds reasonable.

Good. I am glad for the recache closing because we were going to need
something like that.

> > PeerDirect handles rename by just looping. We really can't delay a
> > rename. There is discussion in the Win32 TODO detail that goes over
> > some options, I think.
>
> Do we really have any problem with rename? We don't rename table files.
> The renames I can think of are renaming temp files into place as
> permanent ones, and there would be no open references to such a file.

We do have a problem. It is with cache files read on startup, like
pg_pwd. We can generate the file as temp, but we have to slide it in
while a backend is not reading it. On a busy system, I am not sure how
large a window we will get for the rename. The rename is all
centralized in port/dirmod.c, so we can deal with it there, whatever the
solution.

We also have to do the rename during xact close because we need to hold
locks so we are sure the files are written in the same order that they
modify pg_shadow, waiting a long time for the rename is a serious
problem.

--
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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Glaesemann 2004-01-26 05:52:58 Re: Disaster!
Previous Message Tom Lane 2004-01-26 05:26:24 Re: What's left?

Browse pgsql-hackers-win32 by date

  From Date Subject
Next Message Merlin Moncure 2004-01-26 14:33:37 Re: Microsoft releses Services for Unix
Previous Message Tom Lane 2004-01-26 05:26:24 Re: What's left?