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

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Abhijit Menon-Sen <ams(at)2ndQuadrant(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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 10:53:42
Message-ID: 20150526105342.GW26667@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* Abhijit Menon-Sen (ams(at)2ndQuadrant(dot)com) wrote:
> At 2015-05-26 03:54:51 +0200, andres(at)anarazel(dot)de wrote:
> > Another thing is whether we should handle a recursive symlink in
> > pgdata? I personally think not, but...
>
> I think not too.

Yikes.. That's definitely the kind of thing that's why I worry about
the whole 'fsync everything' idea- what if I symlink to /? I've
certainly done that before from my home directory for ease of use and I
imagine there are people out there who have similar setups where they
sftp as the PG user and use the symlink to more easily navigate
somewhere else. We have to realize that, on at least some systems,
PGDATA could be the postgres user's home directory too. That's not the
case on Debian-based systems today, but I think it might have been
before Debian had the multi-cluster tooling.

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

Thanks!

Stephen

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Uriy Zhuravlev 2015-05-26 11:58:22 Selectivity estimation for intarray with @@
Previous Message Simon Riggs 2015-05-26 10:32:08 Re: Order of columns in query is important?!