Re: fsync-pgdata-on-recovery tries to write to more files than previously

From: Abhijit Menon-Sen <ams(at)2ndQuadrant(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stephen Frost <sfrost(at)snowman(dot)net>, Christoph Berg <myon(at)debian(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: fsync-pgdata-on-recovery tries to write to more files than previously
Date: 2015-05-26 04:56:35
Message-ID: 20150526045635.GA20076@toroid.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At 2015-05-26 03:54:51 +0200, andres(at)anarazel(dot)de wrote:
>
> Say a symlink goes to a binary, which is currently being executed:
> ETXTBSY. Or the file is in a readonly filesystem: EROFS. So we'd
> need to ignore a lot of errors, possibly ignoring valid ones.

Right. That's why I started out by being conservative and following only
the "expected" symlinks in pg_tblspc (as other parts of the code do).

> Another thing is whether we should handle a recursive symlink in
> pgdata? I personally think not, but...

I think not too.

> It's also not just as simple as making fsync_fname fail gracefully
> upon EACCESS - the opendir() could fail just as well.

I'll post a proposed patch shortly.

-- Abhijit

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2015-05-26 05:31:23 Re: fsync bug faq for publication?
Previous Message Josh Berkus 2015-05-26 03:52:58 fsync bug faq for publication?