From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andres Freund <andres(at)2ndquadrant(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 22:23:25 |
Message-ID: | 20140205222325.GD2422724@tornado.leadboat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Feb 05, 2014 at 02:07:29PM -0500, Tom Lane wrote:
> Of course, a direct system catalog scan is certainly no safer in an
> aborted transaction than the one that catcache.c is refusing to do.
> Therefore, in my opinion, relcache.c ought also to be doing an
> Assert(IsTransactionState()), at least in ScanPgRelation and perhaps
> everywhere that it does catalog scans.
>
> 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'd put it in LockAcquireExtended() and perhaps also heap_beginscan_internal()
and/or index_beginscan_internal(). ScanPgRelation() isn't special.
--
Noah Misch
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2014-02-05 23:20:19 | Re: mvcc catalo gsnapshots and TopTransactionContext |
Previous Message | Robert Haas | 2014-02-05 21:56:41 | Re: Minor performance improvement in transition to external sort |