On Sun, 16 Jan 2005 20:01:36 -0500, Tom Lane wrote:
> "Jim C. Nasby" writes:
>> Wouldn't the original proposal that had a state machine handle this?
>> IIRC the original idea was:
>> 
>> new tuple -> known good -> possibly dead -> known dead
> 
> Only if you disallow the transition from possibly dead back to known
> good, which strikes me as a rather large disadvantage.  Failed UPDATEs
> aren't so uncommon that it's okay to have one permanently disable the
> optimization.

But how about allowing the transition from "possibly dead" to "new
tuple"? What if a failed update restores the tuple to the "new tuple"
state, and only after that it can be promoted to "known good" state?

Jochem

In response to

• Re: Much Ado About COUNT(*) at 2005-01-17 01:01:36 from Tom Lane

pgsql-announce by date

Next:	From: Jim C. Nasby	Date: 2005-01-17 01:28:07
	Subject: Re: Much Ado About COUNT(*)
Previous:	From: Tom Lane	Date: 2005-01-17 01:01:36
	Subject: Re: Much Ado About COUNT(*)

pgsql-hackers by date

Next:	From: Jim C. Nasby	Date: 2005-01-17 01:28:07
	Subject: Re: Much Ado About COUNT(*)
Previous:	From: Tom Lane	Date: 2005-01-17 01:01:36
	Subject: Re: Much Ado About COUNT(*)

pgsql-patches by date

Next:	From: Jim C. Nasby	Date: 2005-01-17 01:28:07
	Subject: Re: Much Ado About COUNT(*)
Previous:	From: Tom Lane	Date: 2005-01-17 01:01:36
	Subject: Re: Much Ado About COUNT(*)