From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: subscriptionCheck failures on nightjar |
Date: | 2019-06-27 01:10:49 |
Message-ID: | 21917.1561597849@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | yuzuko | 2019-06-27 02:34:13 | Re: Problem with default partition pruning |
Previous Message | Tsunakawa, Takayuki | 2019-06-27 00:58:51 | RE: Speed up transaction completion faster after many relations are accessed in a transaction |