Re: group locking: incomplete patch, just for discussion

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: group locking: incomplete patch, just for discussion
Date: 2014-11-13 21:57:01
Message-ID: CAMp0ubcyCcSZRJ4n0z0eBUnagUot=pAt+rbi2G03YFQWZna1aA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Nov 13, 2014 at 11:26 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Thu, Nov 13, 2014 at 3:38 AM, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> > If two backends both have an exclusive lock on the relation for a join
> > operation, that implies that they need to do their own synchronization,
> > because obviously the lock manager is not doing it for them.
>
> This doesn't make sense to me. Why would they need to synchronize
> access to a relation in order to join it?

Unfortunate typo: that was supposed to be "joint" operation, just meaning
that they are working together for something (e.g. CLUSTER, VACUUM FULL as
you suggest). Sorry for the confusion.

I meant that the backends need to divide up the work somehow. And if each
operator needs to divide up the work before operating, that means we need
to change every operator.

Regards,
Jeff Davis

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2014-11-13 22:04:52 Re: Missing FIN_CRC32 calls in logical replication code
Previous Message Andres Freund 2014-11-13 21:50:21 Re: REINDEX CONCURRENTLY 2.0