Skip site navigation (1) Skip section navigation (2)

Re: Much Ado About COUNT(*)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Manfred Koizar <mkoi-pg(at)aon(dot)at>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>,"Jonah H(dot) Harris" <jharris(at)tvi(dot)edu>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Much Ado About COUNT(*)
Date: 2005-01-16 20:22:11
Message-ID: 19382.1105906931@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-announcepgsql-hackerspgsql-patches
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Manfred Koizar <mkoi-pg(at)aon(dot)at> writes:
>> Last time we discussed this, didn't we come to the conclusion, that
>> resetting status bits is not a good idea because of possible race
>> conditions?

> There's no race condition,

Actually, wait a minute --- you have a point.  Consider a tuple whose
inserting transaction (A) has just dropped below GlobalXmin.
Transaction B is doing an index scan, so it's going to do something like

* Visit index entry, observe that it is in "uncertain" state.
* Visit heap tuple, observe that A has committed and is < GlobalXmin,
  and there is no deleter.
* Return to index entry and mark it "visible to all".

Now suppose transaction C decides to delete the tuple.  It will

* Insert itself as the XMAX of the heap tuple.
* Visit index entry, set state to "uncertain" if not already that way.

C could do this between steps 2 and 3 of B, in which case the index
entry ends up improperly marked "visible to all" while in fact a
deletion is pending.  Ugh.  We'd need some kind of interlock to prevent
this from happening, and it's not clear what.  Might be tricky to create
such an interlock without introducing either deadlock or a big
performance penalty.

			regards, tom lane

In response to

Responses

pgsql-announce by date

Next:From: Jochem van DietenDate: 2005-01-16 20:38:31
Subject: Re: Much Ado About COUNT(*)
Previous:From: Tom LaneDate: 2005-01-16 20:11:37
Subject: Re: Much Ado About COUNT(*)

pgsql-hackers by date

Next:From: Jochem van DietenDate: 2005-01-16 20:38:31
Subject: Re: Much Ado About COUNT(*)
Previous:From: Tom LaneDate: 2005-01-16 20:11:37
Subject: Re: Much Ado About COUNT(*)

pgsql-patches by date

Next:From: Jochem van DietenDate: 2005-01-16 20:38:31
Subject: Re: Much Ado About COUNT(*)
Previous:From: Bruce MomjianDate: 2005-01-16 20:13:26
Subject: Re: Increased error verbosity when querying row-returning

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group