From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, 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-28 10:15:13 |
Message-ID: | CAA4eK1+5jacq3g-fcVM2VTKt72SerQ5XuGV5rcrVNG1q7Shr+A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Oct 27, 2023 at 5:45 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Thu, Oct 26, 2023 at 09:40:09AM -0400, Robert Haas wrote:
> > Because of this, it is possible for bucketbuf, prevbuf, and wbuf to be
> > the same (your first scenario) but the second scenario you mention
> > (nextbuf == wbuf) should be impossible.
>
> Okay..
>
> > It seems to me that maybe we shouldn't even be registering wbuf or
> > doing anything at all to it if there are no tuples that need moving.
> > That would also require some adjustment of the redo routine.
>
> 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.
--
With Regards,
Amit Kapila.
From | Date | Subject | |
---|---|---|---|
Next Message | jian he | 2023-10-28 10:38:16 | Re: Issues with Information_schema.views |
Previous Message | Erki Eessaar | 2023-10-28 09:27:33 | Issues with Information_schema.views |