On Wed, Oct 29, 2014 at 7:38 PM, Simon Riggs <
simon@2ndquadrant.com> wrote:
> On 29 October 2014 12:08, Amit Kapila <
amit.kapila16@gmail.com> wrote:
> > On Wed, Oct 29, 2014 at 2:18 PM, Simon Riggs <
simon@2ndquadrant.com> wrote:
> >>
> >> CREATE INDEX has a lock on the table. Worker tasks can be simply
> >> banned from acquiring new locks and doing many other tasks.
> >
> > Banning worker tasks from taking locks is only possible if the
> > worker backend doesn't need to acquire any lock which is not
> > already acquired by main backend, but can we safely assume
> > the same? One example as taken by Robert upthread about
> > bttextcmp() can break that assumption.
>
> I think its reasonable to imagine some prep work will be required in
> the main task before workers begin.
>
> 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.
> 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.
> 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.
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.