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

From Jeff Davis
Subject Re: group locking: incomplete patch, just for discussion
Date
Msg-id CAMp0ubcyCcSZRJ4n0z0eBUnagUot=pAt+rbi2G03YFQWZna1aA@mail.gmail.com
Whole thread Raw
In response to Re: group locking: incomplete patch, just for discussion  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: group locking: incomplete patch, just for discussion  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
<div dir="ltr">On Thu, Nov 13, 2014 at 11:26 AM, Robert Haas <<a
href="mailto:robertmhaas@gmail.com">robertmhaas@gmail.com</a>>wrote:<br />><br />> On Thu, Nov 13, 2014 at
3:38AM, Jeff Davis <<a href="mailto:pgsql@j-davis.com">pgsql@j-davis.com</a>> wrote:<br />> > If two
backendsboth have an exclusive lock on the relation for a join<br />> > operation, that implies that they need to
dotheir own synchronization,<br />> > because obviously the lock manager is not doing it for them.<br />><br
/>>This doesn't make sense to me.  Why would they need to synchronize<br />> access to a relation in order to
joinit?<br /><br /><br />Unfortunate typo: that was supposed to be "joint" operation, just meaning that they are
workingtogether for something (e.g. CLUSTER, VACUUM FULL as you suggest). Sorry for the confusion.<br /><br />I meant
thatthe backends need to divide up the work somehow. And if each operator needs to divide up the work before operating,
thatmeans we need to change every operator.<br /><br />Regards,<br />     Jeff Davis</div> 

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: REINDEX CONCURRENTLY 2.0
Next
From: Heikki Linnakangas
Date:
Subject: Re: Missing FIN_CRC32 calls in logical replication code