I didn't check whether your transformation is correct, but if so then it
can be changed like this and save the extra XidDidCommit call:
xvac_committed = TransactionIdDidCommit(xvac);
if (xvac_committed)
{
/* committed */
}
else if (!TransactionIdIsInProgress(xvac))
On Tue, Mar 11, 2008 at 6:37 PM, Alvaro Herrera
[EMAIL PROTECTED] wrote:
I didn't check whether your transformation is correct, but if so then it
can be changed like this and save the extra XidDidCommit call:
xvac_committed = TransactionIdDidCommit(xvac);
if (xvac_committed)
{
Alvaro Herrera wrote:
I didn't check whether your transformation is correct, but if so then it
can be changed like this and save the extra XidDidCommit call:
xvac_committed = TransactionIdDidCommit(xvac);
if (xvac_committed)
{
/* committed */
}
else if
Heikki Linnakangas wrote:
Nope, that's not good. Per comments in tqual.c, you have to call
TransactionIdIsInProgress *before* TransactionIdDidCommit, to avoid this
race condition:
1. Xact A inserts a record
2. Xact B does TransactionIdDidCommit, which retuns false because it's
still
Heikki Linnakangas [EMAIL PROTECTED] writes:
I presume the case where this would help would be when you populate a
large table, with COPY for example, and the run a seq scan on it. As all
rows in the table have the same xmin, you keep testing for the same XID
over and over again.
Yeah, that's
On Tue, 2008-03-11 at 12:57 +, Heikki Linnakangas wrote:
We could do this instead:
if (TransactionIdDidCommit(xvac))
{
/* committed */
}
else if (!TransactionIdIsInProgress(xvac))
{
if (TransactionIdDidCommit(xvac))
{
/* committed */
}
On Tue, 2008-03-11 at 13:15 -0400, Tom Lane wrote:
Maybe instead TransactionIdIsKnownCompleted?
Works for me.
--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com
PostgreSQL UK 2008 Conference: http://www.postgresql.org.uk
--
Sent via pgsql-patches mailing list
Simon Riggs [EMAIL PROTECTED] writes:
No, I haven't done any formal performance testing on it. It seemed an
obvious hole that everyone would agree we should avoid, since we can do
it so cheaply: one integer comparison against scanning the whole
procarray and taking an LWlock.
[ after reading
I wrote:
[ after reading the patch a bit closer... ] Actually, it's not as
obvious as all that. TransactionIdIsInProgress already falls out before
the proposed test for any XID RecentXmin, which means that in reality
it's fairly probable that the target XID is running. So while this test
Simon Riggs [EMAIL PROTECTED] writes:
We currently have a single item cache of the last checked TransactionId,
which optimises the call to TransactionIdDidCommit() during
HeapTupleSatisfiesMVCC() and partners.
Before we call TransactionIdDidCommit() we always call
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
We currently have a single item cache of the last checked TransactionId,
which optimises the call to TransactionIdDidCommit() during
HeapTupleSatisfiesMVCC() and partners.
Before we call TransactionIdDidCommit() we always call
TransactionIdIsInProgress().
TransactionIdIsInProgress() doesn't
12 matches
Mail list logo
