Feedback-ID: i0fe9450f:Fastmail
Date: Fri, 20 Dec 2024 11:53:43 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Thomas Munro <thomas.munro@gmail.com>,
	Heikki Linnakangas <hlinnaka@iki.fi>,
	Alexander Lakhin <exclusion@gmail.com>,
	Tom Lane <tgl@sss.pgh.pa.us>,
	Laurenz Albe <laurenz.albe@cybertec.at>, rootcause000@gmail.com,
	pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18146: Rows reappearing in Tables after Auto-Vacuum Failure
 in PostgreSQL on Windows
Message-ID: <Z2TcN-ypscC4Jomj@paquier.xyz>
References: <8e499d50-09ac-479a-b5b2-8a8bca83d057@iki.fi>
 <00477c52-3a35-4621-b80b-58a5a48b113f@iki.fi>
 <CA+hUKG+g8ydXzSnHQPtNhmwNhn8A-FborSZGSLg62tivaugP0g@mail.gmail.com>
 <Zt6h7y308oXttagv@paquier.xyz>
 <CA+hUKGKvb3Dxs1NrfW4_cDZ7LMw4inSMqET5wceswnetWUZVqA@mail.gmail.com>
 <CA+hUKGK+tzjU-vqLr_zA8REzPUyiKNmpxk32Jw5AFR0DZNaXfg@mail.gmail.com>
 <ZyCTXqPG_uGvLJtZ@paquier.xyz>
 <CA+TgmobP2AEjS5qzfEVGugfQw1H+7DF283udewzTDPO3-2G-Kg@mail.gmail.com>
 <CA+hUKGJSOEZWx9zRFFfOfDj9zbVmMbWKRq+ZzMCXftHcO1UYQQ@mail.gmail.com>
 <CA+TgmoZj9dJhHQokHioXB8dyDZz5gjzyg7SbUrG=At-uShq7yA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="u3S9DklGmemkCZWK"
Content-Disposition: inline
In-Reply-To: 
 <CA+TgmoZj9dJhHQokHioXB8dyDZz5gjzyg7SbUrG=At-uShq7yA@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/Z2TcN-ypscC4Jomj%40paquier.xyz>
Precedence: bulk


--u3S9DklGmemkCZWK
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Thu, Dec 19, 2024 at 10:44:05AM -0500, Robert Haas wrote:
> I think mostly my thought was that if we could remove smgrtruncate()
> entirely in favor of smgrtruncatefrom(), or just keep it called
> smgrtruncate() but add a mandatory additional argument, that would be
> less error-prone than having two versions between which future hackers
> must pick.

Hmm.  Indeed.  As a HEAD change, keeping only a smgrtruncate() is
tempting as it creates a parallel with md.c.  I am not completely sure
how to make all that leaner with the smgrnblocks() calls that save the
old number of blocks for each fork.  But perhaps Thomas has a fancy
idea if it comes down to that, and it could always be done later.
--
Michael

--u3S9DklGmemkCZWK
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmdk3DcACgkQnvQgOdby
QH3QIhAAp8IXblNVoAYxHdtOhemK898SPb1hg3GthTriTxWszeia48jqOYLgSObe
WnotL2GSGbB8RAFi76wslMXMlF+8zITvWcPM9T7Z9Z8k/fdsXtToKyf7qq8JiVak
LdPBtZj5wXoKb3Cnl5XXQ+WKqwJPHDn/0T9BmdnLv5eu42Ahu6Sraf+s20nvxAN6
wX1UcXbLMNsZwkeWIoFTvj+pxsFPypXbwXw7wd51QfsmPVY5yQ3WHJQlx0pmHFib
41Jez/vT41UlRMAaH7FKCt695IWDvUw477HZXNRM6RfLjdOTM6n+nK+zRAvSgtB5
II1sD82oP6JcROgV7qHwr5dZcVEycwGBS2onHqa62vTsys0fSnuRlKKgeRxOrrb3
CCH81kgwSWVWiAKKjRYsupCFtelg4NHp04DwNtg2o4hoj9QIqj6tvB5J+UHl+5TG
TvR5GH2wPcLGypaC4I3d1OmaUd3NSr5LCXbEU03GUGjEAWL9fM41HRsFqMnRaCQq
e6jGjOEfNAB+BeNC7yGlefaEqQs/NXrFhrfAMrc/3hehGFaB0t6Y18D7Fz088eHy
cCwH7f/T1S39TGtSgqdJUF8dIciUsBIlAX91zp2pPQeEtJ0Q160WKC6u14ZqGEZo
siYlIqJxUve4hoEaLmAG8CywPihuVLjNxnDCtdtvmuSDVRYSgSc=
=0Q29
-----END PGP SIGNATURE-----

--u3S9DklGmemkCZWK--