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
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 |