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

Re: Much Ado About COUNT(*)

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Manfred Koizar <mkoi-pg(at)aon(dot)at>,"Jonah H(dot) Harris" <jharris(at)tvi(dot)edu>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Much Ado About COUNT(*)
Date: 2005-01-22 21:19:16
Message-ID: 200501222119.j0MLJGt23855@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-announcepgsql-hackerspgsql-patches
Tom Lane wrote:
> 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.

I am thinking we have to somehow lock the row while we set the index
status bit.  We could add a new heap bit that says "my xid is going to
set the status bit" and put our xid in the expired location, set the
bit, then return to the heap and clear it.

Can we keep the heap and index page locked at the same time?

Anyway it is clearly something that could be an issue.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

In response to

pgsql-announce by date

Next:From: Ron MayerDate: 2005-01-23 08:36:10
Subject: Re: Much Ado About COUNT(*)
Previous:From: Bruce MomjianDate: 2005-01-22 20:06:33
Subject: Re: Much Ado About COUNT(*)

pgsql-hackers by date

Next:From: Josh BerkusDate: 2005-01-22 21:36:54
Subject: Re: Extending System Views: proposal for 8.1/8.2
Previous:From: Tom LaneDate: 2005-01-22 21:03:06
Subject: Re: Autotuning Group Commit

pgsql-patches by date

Next:From: Tom LaneDate: 2005-01-22 21:20:59
Subject: Re: vacuum hint on elog
Previous:From: Dave PageDate: 2005-01-22 20:51:00
Subject: Re: pg_autovacuum/Win32 Fixes

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