Re: [PATCH v1] Fix propagation of indimmediate flag in index_create_copy

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Nitin Motiani <nitinmotiani(at)google(dot)com>
Cc: Álvaro Herrera <alvherre(at)kurilemu(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [PATCH v1] Fix propagation of indimmediate flag in index_create_copy
Date: 2026-07-28 02:08:03
Message-ID: amgPA_s6bXdq2x5u@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jul 27, 2026 at 04:47:00PM +0900, Michael Paquier wrote:
> Attached is my result, that I intend to backpatch. Test is for v17~.
> No time to edit the commit message yet, sorry, I get that it is
> confusing with the new flag name. :p

And done as 74276e685dd0.

You may note that I have used the word "tentatively" regarding the
backport of the test. In v17~v19, injection point waits depend on
condition variables, that depend on DSMs, that have a dependency with
cleanup actions not happening correctly outside of transaction
contexts as far as I know. We're dealing with a wait/wakeup and not
an ERROR, which should be fine at the end, just mentioning in
passing.. Injpoint waits depend on atomics on HEAD, which is more
portable, hence not an issue if one has the idea to do waits outside
of a transaction.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jacob Brazeal 2026-07-28 02:09:38 a large LIMIT makes some sorts slower
Previous Message Amit Kapila 2026-07-28 02:04:17 Re: [DESIGN] Soft DROP TABLE, recoverable drops for PostgreSQL