Re: group locking: incomplete patch, just for discussion

On 29 October 2014 12:08, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> On Wed, Oct 29, 2014 at 2:18 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>>
>> My proposal is we do a parallel index build scan... just as we
>> discussed earlier, so you would be following the direction set by Dev
>> Meeting, not just a proposal of mine.
>>
>> As I mentioned previously when you started discussing shared memory
>> segments, parallel sort does NOT require shared memory. The only thing
>> you need to share are files. Split the problem into N pieces, sort
>> them to produce N files and then merge the files using existing code.
>> That only applies to large sorts, but then those are the ones you
>> cared about doing in parallel anyway.
>>
>> 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?

As for locking the enums table or collation table, that's simple stuff
also. They're just AccessShareLocks.

I can't imagine we'll be able to presume that all functions of every
kind are parallel-safe.

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