On Mon, 2007-06-04 at 22:09 +0100, Heikki Linnakangas wrote:
> > I think the real problem here is that the first scan is leaving state
> > behind that changes the behavior of the next scan.  Which can have no
> > positive benefit, since obviously the first scan is not still
> > proceeding; the best you can hope for is that it's a no-op and the worst
> > case is that it actively pessimizes things.  Why doesn't the patch
> > remove the shmem entry at scan termination?
> Because there's no reason why it should, and it would require a lot more 
> bookkeeping. There can be many scanners on the same table, so we'd need 
> to implement some kind of reference counting, which means having to 
> reliably decrement the counter when a scan terminates.

That's what I thought at first, and why I didn't do it. Right now I'm
thinking we could just add the PID to the hint, so that it would only
remove its own hint. Would that work?

It's still vulnerable to a backend being killed and the hint hanging
around. However, the next scan would clear get it back to normal.
Reference counting would cause weirdness if a backend died or something,
because it would never decrement to 0.

> In any case if there actually is a concurrent scan, you'd still see 
> different ordering. Removing the entry when a scan is over would just 
> make it harder to trigger.

Agreed. I don't know for sure whether that's good or bad, but it would
make the nondeterminism less immediately visible.

        Jeff Davis

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
       subscribe-nomail command to [EMAIL PROTECTED] so that your
       message can get through to the mailing list cleanly

Reply via email to