| From: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: subscriptionCheck failures on nightjar |
| Date: | 2019-02-13 11:55:59 |
| Message-ID: | CAEepm=1pbie9C_PtojGum7qXAAU1hB8JtA6v_9dQFPgay3PcZg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Feb 11, 2019 at 7:31 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 2019-02-10 23:55:58.798 EST [40728] sub1 PANIC: could not open file "pg_logical/snapshots/0-160B578.snap": No such file or directory
<pokes at totally unfamiliar code>
They get atomically renamed into place, which seems kosher even if
snapshots for the same LSN are created concurrently by different
backends (and tracing syscalls confirms that that does occasionally
happen). It's hard to believe that nightjar's rename() ceased to be
atomic a couple of months ago. It looks like the only way for files
to get unlinked after that is by CheckPointSnapBuild() deciding they
are too old.
Hmm. Could this be relevant, and cause a well timed checkpoint to
unlink files too soon?
2019-02-12 21:52:58.304 EST [22922] WARNING: out of logical
replication worker slots
--
Thomas Munro
http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Meskes | 2019-02-13 12:08:31 | Re: [PROPOSAL]a new data type 'bytea' for ECPG |
| Previous Message | Peter Eisentraut | 2019-02-13 11:19:18 | Re: more unconstify use |