Re: subscriptionCheck failures on nightjar - Mailing list pgsql-hackers

From Tom Lane
Subject Re: subscriptionCheck failures on nightjar
Date
Msg-id 21917.1561597849@sss.pgh.pa.us
Whole thread Raw
In response to Re: subscriptionCheck failures on nightjar  (Andres Freund <andres@anarazel.de>)
Responses Re: subscriptionCheck failures on nightjar
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2019-02-14 09:52:33 +1300, Thomas Munro wrote:
>> Just to make sure I understand: it's OK for the file not to be there
>> when we try to fsync it by name, because a concurrent checkpoint can
>> remove it, having determined that we don't need it anymore?  In other
>> words, we really needed either missing_ok=true semantics, or to use
>> the fd we already had instead of the name?

> I'm not yet sure that that's actually something that's supposed to
> happen, I got to spend some time analysing how this actually
> happens. Normally the contents of the slot should actually prevent it
> from being removed (as they're newer than
> ReplicationSlotsComputeLogicalRestartLSN()). I kind of wonder if that's
> a bug in the drop logic in newer releases.

My animal dromedary just reproduced this failure, which we've previously
only seen on nightjar.

https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=dromedary&dt=2019-06-26%2023%3A57%3A45

            regards, tom lane



pgsql-hackers by date:

Previous
From: "Tsunakawa, Takayuki"
Date:
Subject: RE: Speed up transaction completion faster after many relations areaccessed in a transaction
Next
From: yuzuko
Date:
Subject: Re: Problem with default partition pruning