Acquire ProcArrayLock exclusively in ProcArrayClearTransaction.
This corrects an oversight by me in 20729324078, which made
ProcArrayClearTransaction() increment xactCompletionCount. That requires an
exclusive lock, obviously.
There's other approaches that avoid the exclusive acquisition, but giv
Hi,
On 2020-08-18 23:31:04 -0400, Tom Lane wrote:
> David Rowley writes:
> >> On 2020-08-18 19:55:50 -0400, Tom Lane wrote:
> >>> On Wed, 19 Aug 2020 at 12:37, Andres Freund wrote:
> I'm inclined to just make ClearTransaction take an exclusive lock - the
> rest of the 2PC operations ar
On 2020-Aug-18, Andres Freund wrote:
> So unless somebody disagrees I'm gonna add a new
> prepared-transactions-2.spec.
I think keeping things separate if they're not really related is
sensible.
I think it might be a good idea to add that test to older branches too,
even if it's just 13 -- at le
Suppress unnecessary RelabelType nodes in yet more cases.
Commit a477bfc1d fixed eval_const_expressions() to ensure that it
didn't generate unnecessary RelabelType nodes, but I failed to notice
that some other places in the planner had the same issue. Really
noplace in the planner should be using
Suppress unnecessary RelabelType nodes in yet more cases.
Commit a477bfc1d fixed eval_const_expressions() to ensure that it
didn't generate unnecessary RelabelType nodes, but I failed to notice
that some other places in the planner had the same issue. Really
noplace in the planner should be using
Suppress unnecessary RelabelType nodes in yet more cases.
Commit a477bfc1d fixed eval_const_expressions() to ensure that it
didn't generate unnecessary RelabelType nodes, but I failed to notice
that some other places in the planner had the same issue. Really
noplace in the planner should be using
