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.
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 |