From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | Noah Misch <noah(at)leadboat(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: mvcc catalo gsnapshots and TopTransactionContext |
Date: | 2014-02-05 23:41:08 |
Message-ID: | 12235.1391643668@sss.pgh.pa.us |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> On 2014-02-05 14:07:29 -0500, Tom Lane wrote:
>> I stuck such an Assert in ScanPgRelation, and verified that it doesn't
>> break any existing regression tests --- although of course the above
>> test case still fails, and now even without declaring an index.
>>
>> Barring objections I'll go commit that. It's a bit pointless to be
>> Asserting that catcache.c does nothing unsafe when relcache.c does
>> the same things without any such test.
>>
>> (Alternatively, maybe we should centralize the asserting in
>> systable_beginscan or some such place?)
> I don't have a problem with sticking an additional assert elsewhere, but
> I think ScanPgRelation, systable_beginscan are a bit late, because they
> frequently won't be hit during testing because the lookups will be
> cached...
Oh, good point. By analogy to the placement of the existing Assert in
SearchCatCache, the one for relcache should be in RelationIdGetRelation.
[ experiments... ] OK, that passes regression tests too. Good...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2014-02-05 23:54:33 | Re: Failure while inserting parent tuple to B-tree is not fun |
Previous Message | Andres Freund | 2014-02-05 23:20:19 | Re: mvcc catalo gsnapshots and TopTransactionContext |