From: Justin Pryzby <pryzby@telsasoft.com>
To: Andres Freund <andres@anarazel.de>
Cc: Thomas Munro <thomas.munro@gmail.com>
Cc: vignesh C <vignesh21@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org, Andrew Dunstan <andrew@dunslane.net>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Subject: Re: Cygwin cleanup
Date: Mon, 23 Jan 2023 17:28:14 -0600
Message-ID: <20230123232814.GA13860@telsasoft.com> (raw)
In-Reply-To: <20230113041755.GV9837@telsasoft.com>
References: <20221021034040.GT16921@telsasoft.com>
<20221109010437.GK3775@telsasoft.com>
<CALDaNm1QADWDvb3bUBWq2YGX=bN3jj1hVorjNR9Y07-h0M-a1g@mail.gmail.com>
<20230103142537.GM1153@telsasoft.com>
<CA+hUKG+Q6DU4Ov9LrvUyDcF3oHS4KMRVSKmVGaeePq-kOyG9gA@mail.gmail.com>
<CA+hUKGJ6nGVhsGCECtWQMmPMqaAJUJcdp+cDrBjd9=0Mv8xdTw@mail.gmail.com>
<CA+hUKGL1kpPwt8DzU7cm_VMOi5mpSKSwCrdJAPDQfr_tg0E=NA@mail.gmail.com>
<20230112043949.GQ9837@telsasoft.com>
<20230113024354.3q4aigbf4fyh2igg@awork3.anarazel.de>
<20230113041755.GV9837@telsasoft.com>
On Thu, Jan 12, 2023 at 10:17:55PM -0600, Justin Pryzby wrote:
> On Thu, Jan 12, 2023 at 06:43:54PM -0800, Andres Freund wrote:
> > > It looks like logical decoding may be the "most wrong" place that
> > > wal_sync_method is being used, so maybe my change is reasonable to
> > > consider, and not just a workaround.
> >
> > I don't follow. What does using fsync_fname() vs fsync_fname_ext() have to do
> > with pg_fsync() using wal_sync_method? fsync_fname() is just a wrapper around
> > fsync_fname_ext(). Both end up in pg_fsync().
>
> My patch used fsync_fname_ext() which would cause an ERROR rather than a
> PANIC when failing to fsync the logical decoding pathname.
>
> > Are you actually proposing that we don't PANIC after an fsync for the category
> > of files that you list here, even with data_sync_retry set?
>
> Yes, but I'm referring only to my change to SnapBuildSerialize().
>
> The rest of the verbage was me trying to figure out the
> history/evolution of pg_fsync usage.
Also note the existing comment (originating from Thomas' "fsync-gate"
commit, which introduced data_sync_retry):
+ * It's safe to just ERROR on fsync() here because we'll retry the whole
+ * operation including the writes.
Also, it seems to work fine if one calls pg_fsync() again, rather than
calling fsync_fname(), which re-opens the file.
It also seems to work fine if one omits the initial call to
fsync_fname("pg_logical/snapshots", true);
Since SnapBuildSerialize() isn't atomic (the system could crash at any
point), I'm not seeing why these wouldn't be adequately safe. But also
hoping Thomas will comment on that.
--
Justin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: pryzby@telsasoft.com, andres@anarazel.de, thomas.munro@gmail.com, vignesh21@gmail.com, andrew@dunslane.net, tgl@sss.pgh.pa.us
Subject: Re: Cygwin cleanup
In-Reply-To: <20230123232814.GA13860@telsasoft.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox