| From: | Mihail Nikalayeu <mihailnikalayeu(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Antonin Houska <ah(at)cybertec(dot)at>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, 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-04-12 14:58:31 |
| Message-ID: | CADzfLwVFtjBN6YFWV5ziZkxyq5_JaCapWPostwEwBTzQg=fPng@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi!
On Sun, Apr 12, 2026 at 4:05 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> I don't think that's as good. The problem is that that way you're only
> detecting the deadlocks once they have materialized (i.e. once repack actually
> does the lock upgrade), rather than cancelling when we know that the problem
> starts. Having sessions pointlessly blocked for many hours is bad.
O, I think I understand you now.
You propose to somehow mark SUEL as "going to become AEL, so, the
deadlock detector should treat it as such".
In that case LOCK TABLE should get some kind of "future deadlock detected".
Yep, that feels much better. I'll try to check that approach tomorrow.
Best regards,
Mikhail.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alexandre Felipe | 2026-04-12 15:01:52 | Re: SLOPE - Planner optimizations on monotonic expressions. |
| Previous Message | Andres Freund | 2026-04-12 14:51:20 | Re: StringInfo fixes, v19 edition. Plus a few oddities |