Re: The documentation for READ COMMITTED may be incomplete or wrong

Hi Tom, > Done that way. I chose to replace the tuple_table field, because > it was in a convenient spot and it seemed like the field least > likely to have any outside code referencing it. Many thanks! If it's not too much trouble could you please recommend good entry points to learn more abou

Re: The documentation for READ COMMITTED may be incomplete or wrong

Amit Langote writes: > On Fri, May 19, 2023 at 8:57 AM Tom Lane wrote: >> What I'm thinking about doing to back-patch this is to replace >> one of the pointer fields in EPQState with a pointer to a >> subsidiary palloc'd structure, where we can put the new fields >> along with the cannibalized ol

Re: The documentation for READ COMMITTED may be incomplete or wrong

Amit Langote writes: > On Fri, May 19, 2023 at 8:57 AM Tom Lane wrote: > +* Initialize per-relation EPQ tuple states. Result relations, if any, > +* get marked as blocked; others as not-fetched. > Would it be helpful to clarify that "blocked" means blocked for a > given EvalPlanQual() c

Re: The documentation for READ COMMITTED may be incomplete or wrong

Thanks for the patch. On Fri, May 19, 2023 at 8:57 AM Tom Lane wrote: > I wrote: > > Debian Code Search doesn't know of any outside code touching > > relsubs_done, so I think we are safe in dropping that code in > > ExecScanReScan. It seems quite pointless anyway considering > > that up to now,

Re: The documentation for READ COMMITTED may be incomplete or wrong

Hi, > The attached v2 mechanizes that using two bool arrays. I tested the patch on several combinations of operating systems (LInux, MacOS) and architectures (x64, RISC-V) available to me at the moment, with both Meson and Autotools. Also I made sure eval-plan-qual.spec fails when the C code is

Re: The documentation for READ COMMITTED may be incomplete or wrong

I wrote: > Debian Code Search doesn't know of any outside code touching > relsubs_done, so I think we are safe in dropping that code in > ExecScanReScan. It seems quite pointless anyway considering > that up to now, EvalPlanQualBegin has always zeroed the whole > array. Oh, belay that. What I'd

Re: The documentation for READ COMMITTED may be incomplete or wrong

Nathan Bossart writes: > On Thu, May 18, 2023 at 04:03:36PM -0400, Tom Lane wrote: >> What we need to do, I think, is set epqstate->relsubs_done[] for >> all target relations except the one we are stuffing a tuple into. > This seems generally reasonable to me. Here's a draft patch for this. I t

Re: The documentation for READ COMMITTED may be incomplete or wrong

On Thu, May 18, 2023 at 04:03:36PM -0400, Tom Lane wrote: > Yeah. I see the problem: when starting up an EPQ recheck, we stuff > the tuple-to-test into the epqstate->relsubs_slot[] entry for the > relation it came from, but we do nothing to the EPQ state for the > other target relations, which all

Re: The documentation for READ COMMITTED may be incomplete or wrong

Nathan Bossart writes: > On Thu, May 18, 2023 at 11:22:54AM -0400, Tom Lane wrote: >> Ugh. Bisecting says it broke at >> commit 86dc90056dfdbd9d1b891718d2e5614e3e432f35 >> which was absolutely not supposed to be breaking any concurrent-execution >> guarantees. I wonder what we got wrong. > With

Re: The documentation for READ COMMITTED may be incomplete or wrong

On Thu, May 18, 2023 at 11:22:54AM -0400, Tom Lane wrote: > Ugh. Bisecting says it broke at > > 86dc90056dfdbd9d1b891718d2e5614e3e432f35 is the first bad commit > commit 86dc90056dfdbd9d1b891718d2e5614e3e432f35 > Author: Tom Lane > Date: Wed Mar 31 11:52:34 2021 -0400 > > Rework planning

Re: The documentation for READ COMMITTED may be incomplete or wrong

Hi, > I wonder what we got wrong. One thing we noticed is that the description for EvalPlanQual may be wrong [1]: """ In UPDATE/DELETE, only the target relation needs to be handled this way. In SELECT FOR UPDATE, there may be multiple relations flagged FOR UPDATE, so we obtain lock on the curren

Re: The documentation for READ COMMITTED may be incomplete or wrong

I wrote: > Aleksander Alekseev writes: >> A colleague of mine, Ante Krešić, got puzzled by the following behavior: > That's not a documentation problem. That's a bug, and an extremely > nasty one. A quick check shows that it works as expected up through > v13, but fails as described in v14 and

Re: The documentation for READ COMMITTED may be incomplete or wrong

On Thu, May 18, 2023 at 10:53:35AM -0400, Tom Lane wrote: > That's not a documentation problem. That's a bug, and an extremely > nasty one. A quick check shows that it works as expected up through > v13, but fails as described in v14 and later. Needs bisecting ... git-bisect points me to 86dc90

Re: The documentation for READ COMMITTED may be incomplete or wrong

Aleksander Alekseev writes: > A colleague of mine, Ante Krešić, got puzzled by the following behavior: That's not a documentation problem. That's a bug, and an extremely nasty one. A quick check shows that it works as expected up through v13, but fails as described in v14 and later. Needs bise

The documentation for READ COMMITTED may be incomplete or wrong

Hi hackers, A colleague of mine, Ante Krešić, got puzzled by the following behavior: Setup: postgres=# create table inh_test (id serial, value float); CREATE TABLE postgres=# create table inh_child_1 () INHERITS ( inh_test); CREATE TABLE postgres=# create table inh_child_2 () INHERITS ( inh_test