Date: Mon, 23 Jan 2023 17:28:14 -0600
From: Justin Pryzby <pryzby@telsasoft.com>
To: Andres Freund <andres@anarazel.de>
Cc: Thomas Munro <thomas.munro@gmail.com>, vignesh C <vignesh21@gmail.com>,
	pgsql-hackers@lists.postgresql.org,
	Andrew Dunstan <andrew@dunslane.net>, Tom Lane <tgl@sss.pgh.pa.us>
Subject: Re: Cygwin cleanup
Message-ID: <20230123232814.GA13860@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20230113041755.GV9837@telsasoft.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Archived-At: 
 <https://www.postgresql.org/message-id/20230123232814.GA13860%40telsasoft.com>
Precedence: bulk

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