Re: subscriptionCheck failures on nightjar

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Thomas Munro <thomas.munro@enterprisedb.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-02-13T19:11:26Z
Lists: pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> I was kinda pondering just open coding it.  I am not yet convinced that
> my idea of just using an open FD isn't the least bad approach for the
> issue at hand.  What precisely is the NFS issue you're concerned about?

I'm not sure that fsync-on-FD after the rename will work, considering that
the issue here is that somebody might've unlinked the file altogether
before we get to doing the fsync.  I don't have a hard time believing that
that might result in a failure report on NFS or similar.  Yeah, it's
hypothetical, but the argument that we need a repeat fsync at all seems
equally hypothetical.

> Right now fsync_fname_ext isn't exposed outside fd.c...

Mmm.  That makes it easier to consider changing its API.

			regards, tom lane


Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Fix "base" snapshot handling in logical decoding