| 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
| 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 |