Re: Synchronized scans

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Synchronized scans
Date: 2007-06-04 22:09:19
Message-ID: 1180994959.7660.61.camel@dogma.v10.wvs
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

On Mon, 2007-06-04 at 22:57 +0100, Heikki Linnakangas wrote:
> > 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.
>

My thought was that every time the location was reported by a backend,
it would store 3 pieces of information, not 2:
* relfilenode
* the PID of the backend that created or updated this particular hint
last
* the location

Then, on heap_endscan() (if that's the right place), we find the hint,
and if the PID matches, we remove it. If not, it does nothing.

This would only matter when there weren't other scans. When concurrent
scans were happening, chances are the PID wouldn't match anyway, and
thus not be removed.

Regards,
Jeff Davis

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Michael Glaesemann 2007-06-04 22:19:54 Re: Synchronized scans
Previous Message Heikki Linnakangas 2007-06-04 21:57:59 Re: Synchronized scans