Jeff Davis wrote:
On Mon, 2007-06-04 at 22:09 +0100, Heikki Linnakangas wrote:
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.
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?
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?
Were you thinking of storing the PID of the backend that originally
created the hint, or updating the PID every time the hint is updated? In
any case, we still wouldn't know if there's other scanners still running.
We could just always remove the hint when a scan ends, and rely on the
fact that if there's other scans still running they will put the hint
back very quickly. There would then be a small window where there's no
hint but a scan is active, and a new scan starting during that window
would fail to synchronize with the other scanners.
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.
Oh, did you mean that the PID would be updated whenever a new scan
starts? So that the PID stored would always be the PID of the latest
scanner. That might work pretty well, though a small scan with a LIMIT,
or any other situation where some scans run faster than others, might
clear the hint prematurely while other scans are still running.
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend