Re: group locking: incomplete patch, just for discussion

On Sat, Nov 1, 2014 at 5:38 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> That's just a mislabeled function. It's obviously not parallel safe at
> all. I see absolutely no problem with erroring out.

I disagree.  It's entirely parallel-safe, as long as you don't
arbitrarily decide to have the lock manager break it.

>> There's no hazard there.  Where you
>> start getting into crash/exploit/data corruption territory is when you
>> are talking about DDL operations that change the physical structure of
>> the table.  That's why we have stuff like CheckTableNotInUse() to
>> verify that, for example, there are no old cursors around that are
>> still expecting the old relfilenode and tuple descriptor to be valid.
>
> It's not just fully structural changes although they are a concern.
> It's also that we've amassed a number of hacks to deal with local state
> that just won't be nicely transported. What's with stuff like
> RelationSetIndexList() (which is infrequently enough used to not be a
> big problem in practice...)? If we only allow parallel access while
> independent backends could acquire the relevant we can rely on us
> already having taken care about the concurrency hazards. Otherwise not.

RelationSetIndexList() is only used inside REINDEX, which I think
illustrates my point that it's mostly DDL we need to be worried about.

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