Re: fsync-pgdata-on-recovery tries to write to more files than previously - Mailing list pgsql-hackers

From Tom Lane
Subject Re: fsync-pgdata-on-recovery tries to write to more files than previously
Date
Msg-id 5740.1432849036@sss.pgh.pa.us
Whole thread Raw
In response to Re: fsync-pgdata-on-recovery tries to write to more files than previously  (Abhijit Menon-Sen <ams@2ndQuadrant.com>)
Responses Re: fsync-pgdata-on-recovery tries to write to more files than previously
Re: fsync-pgdata-on-recovery tries to write to more files than previously
List pgsql-hackers
Abhijit Menon-Sen <ams@2ndQuadrant.com> writes:
> Here's an updated patch for the fsync problem(s).

I've committed this after some mostly-cosmetic rearrangements.

> 4. As a partial aside, why does fsync_fname use OpenTransientFile? It
>    looks like it should use BasicOpenFile as pre_sync_fname does. We
>    close the fd immediately after calling fsync anyway. Or is there
>    some reason I'm missing that we should use OpenTransientFile in
>    pre_sync_fname too?

pre_sync_fname is the one that is wrong IMO.  Using BasicOpenFile just
creates an opportunity for problems; that function should get called
from as few places as possible.

> 5. I made walktblspc_entries use stat() instead of lstat(), so that we
>    can handle symlinks and directories the same way. Note that we won't
>    continue to follow links inside the sub-directories because we use
>    walkdir instead of recursing.

Given that, walktblspc_entries was 99% duplicate, so I folded it into
walkdir with a process_symlinks boolean.

I have to leave shortly, so I'll look at the initdb cleanup tomorrow.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: Re: PGCon hacker lounge
Next
From: Peter Geoghegan
Date:
Subject: Re: Free indexed_tlist memory explicitly within set_plan_refs()