public inbox for [email protected]  

help / color / mirror / Atom feed

From: Andres Freund <[email protected]>
To: Tom Lane <[email protected]>
Cc: Thomas Munro <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: subscriptionCheck failures on nightjar
Date: Wed, 13 Feb 2019 10:33:03 -0800
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<CAEepm=1pbie9C_PtojGum7qXAAU1hB8JtA6v_9dQFPgay3PcZg@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>

Hi,

On 2019-02-13 13:24:03 -0500, Tom Lane wrote:
> Andres Freund <[email protected]> writes:
> > On 2019-02-13 12:59:19 -0500, Tom Lane wrote:
> >> Perhaps more to the point, the way this was coded, the PANIC applies
> >> to open() failures in fsync_fname_ext() not just fsync() failures;
> >> that's painting with too broad a brush isn't it?
> 
> > That indeed seems wrong. Thomas?  I'm not quite sure how to best fix
> > this though - I guess we could rename fsync_fname_ext's eleval parameter
> > to fsync_failure_elevel? It's not visible outside fd.c, so that'd not be
> > to bad?
> 
> Perhaps fsync_fname() should pass the elevel through as-is, and
> then fsync_fname_ext() apply the data_sync_elevel() promotion only
> to the fsync() call not the open()?  I'm not sure.

Yea, that's probably not a bad plan. It'd address your:

> The bigger picture here is that there are probably some call sites where
> PANIC on open() failure is appropriate too.  So having fsync_fname[_ext]
> deciding what to do on its own is likely to be inadequate.

Seems to me we ought to do this regardless of the bug discussed
here. But we'd nee dto be careful that we'd take the "more severe" error
between the passed in elevel and data_sync_elevel(). Otherwise we'd end
up downgrading errors...


> If we fix this by allowing ENOENT to not be an error in this particular
> call case, that's going to involve an fsync_fname_ext API change anyway...

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?

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

Greetings,

Andres Freund

view thread (44+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected]
  Subject: Re: subscriptionCheck failures on nightjar
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox