From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
Cc: | Jeff Davis <pgsql(at)j-davis(dot)com>, Patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: Synchronized scans |
Date: | 2007-06-08 15:31:22 |
Message-ID: | 26655.1181316682@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Heikki Linnakangas <heikki(at)enterprisedb(dot)com> writes:
> Tom Lane wrote:
>> It occurs to me that there's an actual bug here for catalog access.
>> The code assumes that it can measure rs_nblocks only once and not worry
>> about tuples added beyond that endpoint. But this is only true when
>> using an MVCC-safe snapshot.
> You would only miss tuples inserted after you began the seqscan. After
> you've began the scan, you're going to miss any tuples that are inserted
> before the current position anyway, so stopping the scan early shouldn't
> do any real harm.
Good point.
> It would only be a problem if you do something like:
> heap_beginscan(...)
> Lock
> while(heap_getnext) ...
> Unlock
> And expect to see all tuples inserted before acquiring the lock.
But that could be fixed by taking the lock before the heap_beginscan.
Indeed it's hard to conceive of a situation where you'd want/need to
take the lock afterward; in most cases the beginscan and the actual
scan are right together.
So I withdraw this complaint; it's complexity we don't need. I'll
add a comment about the point though.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Matthew T. O'Connor | 2007-06-08 16:02:53 | Re: COPYable logs status |
Previous Message | Heikki Linnakangas | 2007-06-08 15:25:41 | Re: Synchronized scans |