Re: group locking: incomplete patch, just for discussion - Mailing list pgsql-hackers

On 30 October 2014 04:24, Amit Kapila <amit.kapila16@gmail.com> wrote:

>> Locking the toast table of any main tables we access seems easily
>> done. Though perhaps we should make weak locking of the toast table
>> presumed. Do we have cases where the toast table can be accessed when
>> the main table is not also strong locked first?
>
> I think it is possible to have a strong lock on toast table before
> main table.
> Cluster pg_toast.<toast_table_name> using <toast_index>;
> Vacuum Full pg_toast.<toast_table_name>;
> Reindex Index pg_toast.<toast_index_name>;
> ..
>
> Now if take the lock on toast table in main task, it will block some of
> the operations before actually they need to be blocked.

Very strange.

Those commands are not common operations? I doubt many people even
know that exists.

All of those commands would block SELECTs on the main table, so there
is no significant benefit in that behaviour.

In fact it would be more sensible to lock the toast table earlier.


>> As for locking the enums table or collation table, that's simple stuff
>> also. They're just AccessShareLocks.
>
> Yeah, taking AccessShareLocks is not a problem, however the main
> problem is that they block any other operation on those tables which require
> AccessExclusiveLock lock or any other strong lock required, before it is
> actually required to block any such operation.

What operations are those? How frequently do they occur?

I can't see any need for major maintenance operations on small catalog tables.


>> I can't imagine we'll be able to presume that all functions of every
>> kind are parallel-safe.
>
> Yeah, thats right, so we need to either block such functions to get executed
> in parallel worker or make arrangements so that they can be safely executed,
> I think for first version blocking might be better.

I think that also. That way we won't need complex locking.

> Now, I think we can find ways to avoid all such things by hacking code such
> that conflicting operations can be banned/blocked, however eventually we
> need to have some kind of group locking to avoid deadlocks which can arise
> due to operations in parallel worker.  So it seems to me it is not a bad
> idea
> to have a strong infrastructure first for the things (like group locking)
> which
> we think are required for any non-trivial useful parallel operation without
> putting too much restrictions on users for using the feature.

We are all agreed we need to block some functions from executing in
parallel mode.

Why don't we start by making a list of the functions that might cause
problems in parallel workers, and why. That way we might find out
easier ways of doing things.

-- Simon Riggs                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services