From: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> |
---|---|
To: | tgl(at)sss(dot)pgh(dot)pa(dot)us |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] TODO item |
Date: | 2000-02-07 12:28:56 |
Message-ID: | 20000207212856U.t-ishii@sra.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> 1. It doesn't guarantee that the right files are fsync'd. It would
> in fact fsync whichever files happen to be using the same kernel
> file descriptor numbers at the close of the transaction as the ones
> you really wanted to fsync were using at the time fsync was requested.
Right. If a VFD is reused, the fd would not point to the same file
anymore.
> You could possibly fix #1 by logging fsync requests at the vfd level;
> then, whenever a vfd is closed to free up a kernel fd, check the fsync
> flag and execute the pending fsync before closing the file. You could
> possibly fix #2 by having transaction commit invoke the pg_fsync_pending
> scan before it updates pg_log (and then fsyncing pg_log itself again
> after).
I do not understand #2. I call pg_fsync_pending twice in
RecordTransactionCommit, one is after FlushBufferPool, and the other
is after TansactionIdCommit and FlushBufferPool. Or am I missing
something?
> What would still need to be thought about is whether this scheme
> preserves the ordering guarantee when a group of concurrent backends
> is considered, rather than one backend in isolation. (I believe that
> fsync() will apply to all dirty kernel buffers for a file, not just
> those dirtied by the requesting process, so each backend's fsyncs can
> affect the order in which other backends' writes hit the disk.)
> Offhand I do not see any problems there, but it's the kind of thing
> that requires more than offhand thought...
I thought about that too. If the ordering was that important, a
database managed by backends with -F on could be seriously
corrupted. I've never heard of such disasters caused by -F. So my
conclusion was that it's safe or I had been so lucky. Note that I'm
not talking about pg_log vs. relations but the ordering among
relations.
BTW, Hiroshi has noticed me an excellent point #3:
>Session-1
>begin;
>update A ...;
>
>Session-2
>begin;
>select * fromB ..;
> There's no PostgreSQL shared buffer available.
> This backend has to force the flush of a free buffer
> page. Unfortunately the page was dirtied by the
> above operation of Session-1 and calls pg_fsync()
> for the table A. However fsync() is postponed until
> commit of this backend.
>
>Session-1
>commit;
> There's no dirty buffer page for the table A.
> So pg_fsync() isn't called for the table A.
Seems there's no easy solution for this. Maybe now is the time to give
up my idea...
--
Tatsuo Ishii
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Mount | 2000-02-07 12:29:52 | RE: [HACKERS] New Globe |
Previous Message | Malcolm Beattie | 2000-02-07 12:24:48 | Re: [HACKERS] Need confirmation of "Posix time standard" on FreeBSD |