Horton

Re: BUG #16039: PANIC when activating replication slots in Postgres 12.0 64bit under Windows

Andres Freund <andres@anarazel.de>

View thread
From: Andres Freund <andres@anarazel.de>
To: buschmann@nidsa.net, pgsql-bugs@lists.postgresql.org, Michael Paquier <michael.paquier@gmail.com>
Date: 2019-10-04T20:49:29Z
Lists: pgsql-bugs

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Flush logical mapping files with fd opened for read/write at checkpoint

  2. Use a fd opened for read/write when syncing slots during startup, take 2.

  3. Tighten use of OpenTransientFile and CloseTransientFile

  4. Use a fd opened for read/write when syncing slots during startup.

Hi Hans,

On 2019-10-04 13:06:05 -0700, Andres Freund wrote:
> On 2019-10-04 19:28:28 +0000, PG Bug reporting form wrote:
> > CPS PRD 2019-10-04 19:10:07 CEST  XX000  2:> PANIC:  could not fsync file
> > "pg_replslot/sam_repli_3/state": Bad file descriptor
> > CPS PRD 2019-10-04 19:10:07 CEST  00000  6:> LOG:  startup process (PID
> > 4028) was terminated by exception 0xC0000409

Thanks again for the report! I've committed the fix. Unfortunately,
unless you can compile yourself, you'll have to wait until the next
minor release for the fix.  Given this is the .0 release of 12, and that
we already have a number of bugs to fix, I'm sure that won't be too far
away however.

If you want to work around the problem, you can, but it's not entirely
unproblematic: If, just when restarting, you set fsync to false, you'll
avoid the problem. But then you'd have to immediately re-enable
afterwards, and there's still a small data loss window.  If however all
you want is to continue testing, fsync=off might be a reasonable
workaround.

Greetings,

Andres Freund