Re: RFC: Making TRUNCATE more "MVCC-safe"

On Mon, Mar 5, 2012 at 12:42 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On Mon, Mar 5, 2012 at 4:46 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>>> It does not seem right that the logic for detecting the serialization
>>> error is in heap_beginscan_internal().  Surely this is just as much of
>>> a problem for an index-scan or index-only-scan.
>>
>> err, very good point. Doh.
>>
>>> We don't want to
>>> patch all those places individually, either: I think the check should
>>> happen right around the time we initially lock the relation and build
>>> its relcache entry.
>>
>> OK, that makes sense and works if we need to rebuild relcache.
>
> Except the reason to do it at the start of the scan is that is the
> first time a specific snapshot has been associated with a relation and
> also the last point we can apply the check before the errant behaviour
> occurs.
>
> If we reject locks against tables that might be used against an
> illegal snapshot then we could easily prevent valid snapshot use cases
> when a transaction has multiple snapshots, one illegal, one not.
>
> We can certainly have a looser test when we first get the lock and
> then another test later, but I don't think we can avoid making all
> scans apply this test. And while I'm there, we have to add tests for
> things like index build scans.

Well, there's no point that I can see in having two checks. I just
dislike the idea that we have to remember to add this check for every
method of accessing the relation - doesn't seem terribly future-proof.
It gets even worse if you start adding checks to DDL code paths - if
we're going to do that, we really need to cover them all, and that
doesn't seem very practical if they're going to spread out all over
the place.

I don't understand your comment that a snapshot doesn't get associated
with a relation until scan time. I believe we associated a snapshot
with each query before we even know what relations are involved; that
query then gets passed down to all the individual scans. The query
also opens and locks those relations. We ought to be able to arrange
for the query snapshot to be cross-checked at that point, rather than
waiting until scan-start time.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company