Re: group locking: incomplete patch, just for discussion

Поиск
Список
Период
Сортировка
От Jeff Davis
Тема Re: group locking: incomplete patch, just for discussion
Дата
Msg-id CAMp0ubcyCcSZRJ4n0z0eBUnagUot=pAt+rbi2G03YFQWZna1aA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: group locking: incomplete patch, just for discussion  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: group locking: incomplete patch, just for discussion  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: REINDEX CONCURRENTLY 2.0
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Missing FIN_CRC32 calls in logical replication code