| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com> |
| Cc: | Alexander Lakhin <exclusion(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org, Alexandre Felipe <o(dot)alexandre(dot)felipe(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Peter Eisentraut <peter(at)eisentraut(dot)org> |
| Subject: | Re: BUG #19687: ALTER SEQUENCE provokes error XX001 could not read blocks |
| Date: | 2026-09-24 01:19:58 |
| Message-ID: | arR6vutn730-lQ84@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Thu, Sep 24, 2026 at 01:09:12AM +0530, Ayush Tiwari wrote:
> I don't have much background on the lock levels needed here, but taking
> AccessExclusiveLock upfront seems reasonable given the storage replacement.
> I'm less sure whether it's too strong for cases like OWNED BY.
> [I've sent a diff upthread, can add a patch if that's the right way to go]
>
> Cc'ing Andres, Michael and Peter, who were involved in the original
> sequence locking and transactional changes. Does this approach make
> sense, or am I missing something here?
Where do you mean to add this extra level of locking?
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | shihao zhong | 2026-09-24 02:43:58 | Re: BUG #19705: One NaN box makes a BRIN box_inclusion_ops index omit unrelated rows |
| Previous Message | shihao zhong | 2026-09-24 01:02:29 | Re: BUG #19708: Hash Join becomes about 300x slower with higher work_mem |