| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Jeff Davis <pgsql(at)j-davis(dot)com>, Alexander Lakhin <exclusion(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Is this a problem in GenericXLogFinish()? |
| Date: | 2023-10-30 13:43:02 |
| Message-ID: | CA+TgmobnfQ_JVSHY5Er3U2k9Uq-gr=XCoi_mbQuWCp=5Bhd-WQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, Oct 28, 2023 at 6:15 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> > Hmm. So my question is: do we need the cleanup lock on the write
> > buffer even if there are no tuples, and even if primary bucket and the
> > write bucket are the same?
>
> Yes, we need it to exclude any concurrent in-progress scans that could
> return incorrect tuples during bucket squeeze operation.
Amit, thanks for weighing in, but I'm not convinced. I thought we only
ever used a cleanup lock on the main bucket page to guard against
concurrent scans. Here you seem to be saying that we need a cleanup
lock on some page that may be an overflow page somewhere in the middle
of the chain, and that doesn't seem right to me.
So ... are you sure? If yes, can you provide any more detailed justification?
--
Robert Haas
EDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Aleksander Alekseev | 2023-10-30 13:47:14 | Re: Explicitly skip TAP tests under Meson if disabled |
| Previous Message | Robert Haas | 2023-10-30 13:40:11 | Re: POC, WIP: OR-clause support for indexes |