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.
Regards,
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
