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 →
-
Fix "base" snapshot handling in logical decoding
- f49a80c481f7 11.0 cited