Feedback-ID: i0fe9450f:Fastmail
Date: Mon, 1 Sep 2025 09:16:42 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Mihail Nikalayeu <mihailnikalayeu@gmail.com>
Cc: Antonin Houska <ah@cybertec.at>,
	Alvaro Herrera <alvherre@alvh.no-ip.org>,
	Fujii Masao <masao.fujii@gmail.com>, Robert Treat <rob@xzilla.net>,
	Pg Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Adding REPACK [concurrently]
Message-ID: <aLTl6mYK7exHnqUJ@paquier.xyz>
References: <21931.1756136535@localhost>
 <CADzfLwWPihwPM=e=EJ_U5niqDdVyq9pS30ZNxwZ8f_yXyikooQ@mail.gmail.com>
 <24483.1756142534@localhost>
 <CADzfLwUqyOmpkLmciecBy4aBN1sohQVZ2Hgc6m-tjSUqDRHwyQ@mail.gmail.com>
 <4790.1756197960@localhost>
 <CADzfLwV+80MfPM=MC5y3nA34djUWuYU6YKcZUO8JjD7_8p7nkg@mail.gmail.com>
 <29527.1756215093@localhost>
 <CADzfLwW3XAFKYkBY7Jktf_rETzcqMj20GXgjESqu+WEoeEMkog@mail.gmail.com>
 <6931.1756275367@localhost>
 <CADzfLwUYc+9X44r=kf8RmivD_z4xs0MyoZBiE-TsBZrppq64sA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="T9gKxy12nYPXt7rf"
Content-Disposition: inline
In-Reply-To: 
 <CADzfLwUYc+9X44r=kf8RmivD_z4xs0MyoZBiE-TsBZrppq64sA@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/aLTl6mYK7exHnqUJ%40paquier.xyz>
Precedence: bulk


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

On Wed, Aug 27, 2025 at 10:22:24AM +0200, Mihail Nikalayeu wrote:
> That worries me - it is not the behaviour someone expects from a
> database by default. At least the warning should be much more visible
> and obvious.
> I think most of user will expect the same guarantees as [CREATE|RE]
> INDEX CONCURRENTLY provides.

Having a unified path for the handling of the waits and the locking
sounds to me like a pretty good argument in favor of a basic
implementation.

In my experience, users do not really care about the time it takes to
complete a operation involving CONCURRENTLY if we allow concurrent
reads and writes in parallel of it.  I have not looked at the proposal
in details, but before trying a more folkloric MVCC approach, relying
on basics that we know have been working for some time seems like a
good and sufficient initial step in terms of handling the waits and
the locks with table AMs (aka heap or something else).

Just my 2c.
--
Michael

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

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

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmi05eoACgkQnvQgOdby
QH1pnA//dqPmw8Eam1CYKSVIRkZtkZvYmbtLI48T6yp38vJvsPQk3MLdCkwHZcRE
IgDyT5vKN/m4P+2rldBoWubV6Zf5Ov9+t1/WTCNuwep1wvXGEkS0eW2jsSINIDJO
Qt3ZMNc3NEc6Lui8Cj3Q5LXs7iQByVwwEpDZQI+figlfLa5fs2I/EeU1UVRaZV8k
YSQpgD+6G5eZ4MNDL9eqEfC9IFuxh6Pcu5o0oFFodCpZTwL1kX1NGonBiw0jFRL8
6K60m7mwY1d0D/K3FQ8WWnp1B+xEk2+siFbVS/I5mzeB4fL3++RiUUrPrFTwuBxf
htXlYT4zNGZI5t37WkK8j11hZb0F/SpWgC+fqnvjAqHgysdOC0eQubl9vRM9s9Mt
A9+A49uvqRtV8FHQnepZ7iq9lBGhtZiuJELpwUSairDG0ST9ROgQHcIhHAtMxYSZ
3YBlj7LCb//27hUHGiGfjUMaeEnwLMldNNDBWIeva8cFg0ELqF8Zm0zZ5pREKTs0
REGTMpbcf7gMFEHn0oQYEra0Cs+/JceX0G1sIU89+ueXNM2vbbwcLFlpGOnEUfsI
yGJtXvMU4s30idjjvQvqnv/wedNdf9J83rK1DV/36BcOk5RutIeP+L7RXxR4rAo0
SGm80FDBYjxRQMT+eiuJnRN014vwdFNuDXNOF6/eQGfKyNb7WTo=
=hbS9
-----END PGP SIGNATURE-----

--T9gKxy12nYPXt7rf--