Re: Cygwin cleanup

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Justin Pryzby <pryzby(at)telsasoft(dot)com>
Cc: vignesh C <vignesh21(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Andrew Dunstan <andrew(at)dunslane(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>
Subject: Re: Cygwin cleanup
Date: 2023-01-06 11:39:11
Message-ID: CA+hUKGL1kpPwt8DzU7cm_VMOi5mpSKSwCrdJAPDQfr_tg0E=NA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Nov 9, 2022 at 2:04 PM Justin Pryzby <pryzby(at)telsasoft(dot)com> wrote:
> +data_sync_retry = on

Sharing with the list some clues that Justin and I figured out about
what that part is doing. Without it, you get failures like:

PANIC: could not open file "pg_logical/snapshots/0-14FE6B0.snap":
No such file or directory

That's been seen before:

https://www.postgresql.org/message-id/flat/17827.1549866683%40sss.pgh.pa.us

That thread concluded that the operating system must have a non-atomic
rename(), ie a kernel bug. I don't know why Cygwin would display that
behaviour and our native Windows build not; maybe timing, or maybe our
own open() and rename() wrappers for Windows do something important
differently than Cygwin's open() and rename().

On reflection, that seems a bit too flimsy to have in-tree without
more investigation, which I won't have time for myself, so I'm going
to withdraw this entry.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michail Nikolaev 2023-01-06 11:45:40 Re: BUG: Postgres 14 + vacuum_defer_cleanup_age + FOR UPDATE + UPDATE
Previous Message Dean Rasheed 2023-01-06 11:28:10 Re: Improve tab completion for ALTER FUNCTION/PROCEDURE/ROUTINE