Re: Adding REPACK [concurrently]

From: Mihail Nikalayeu <mihailnikalayeu(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Antonin Houska <ah(at)cybertec(dot)at>, Andres Freund <andres(at)anarazel(dot)de>, Srinath Reddy Sadipiralla <srinath2133(at)gmail(dot)com>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Robert Treat <rob(at)xzilla(dot)net>
Subject: Re: Adding REPACK [concurrently]
Date: 2026-06-17 20:10:22
Message-ID: CADzfLwUJe5B4XGL45zxYuWZE7EFTOG9L1tU33iaGxWV2kJC_VA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello, Álvaro!

> Right. I spent some time looking at this patch just before pgconf.dev

Thanks!

> I have to admit I was a bit scared -- that code is really
> non-obvious, and breakage here could mean big trouble in case something
> goes wrong in weird situations.

Another option we may consider for pg19 - is just a simple
local-memory flag: "If I detect a deadlock and I am REPACK - cancel
another, not me".
It doesn't handle all tricky cases, but it deals with the most common
ones and is much easier and less invasive to implement.

It reuses mechanics that were already present (though unused, they
were documented as "for future" in comments).
POC of that approach is here - [0].

Best regards,
Mikhail.

[0]: https://www.postgresql.org/message-id/flat/CADzfLwURKVNQ++Dpi7bjoGfj-8pchDQEVex3eWBx0NCYn6TbDQ(at)mail(dot)gmail(dot)com#bceb18354aa20c130a94b1deedd76fb7

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2026-06-17 20:26:51 Re: Bug in ALTER SUBSCRIPTION ... SERVER / ... CONNECTION with broken old server
Previous Message Alexander Lakhin 2026-06-17 20:00:00 048_vacuum_horizon_floor.pl hangs due to wakeup lost inside LockBufferForCleanup