Re: [COMMITTERS] pgsql-server: Rearrange pg_subtrans handling

Поиск
Список
Период
Сортировка
От Richard Huxton
Тема Re: [COMMITTERS] pgsql-server: Rearrange pg_subtrans handling
Дата
Msg-id 412AF6C0.4010607@archonet.com
обсуждение исходный текст
Ответ на Re: [COMMITTERS] pgsql-server: Rearrange pg_subtrans handling  (Christopher Kings-Lynne <chriskl@familyhealth.com.au>)
Ответы Re: [COMMITTERS] pgsql-server: Rearrange pg_subtrans handling  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: [COMMITTERS] pgsql-server: Rearrange pg_subtrans handling  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Christopher Kings-Lynne wrote:
>> Uh ... the interesting question is usually not "does this backend hold
>> any row locks", it is "is this row locked by any backends".  If the
>> latter question is not *exceedingly* cheap to answer, at least in the
>> normal case where the answer is no, you don't have a workable solution,
>> because you'll be adding nontrivial overhead to every row update.
> 
> 
> OK, what I mean is to know if a row is locked by any backend, why can't 
> we just put a reference count of the number of locks on that row, 
> instead of recording each backend separately?  Wouldn't that require a 
> fixed amount of shared mem?

Don't forget having to deal with a backend dying without being able to 
decrement the count (not my idea, Bruce (iirc) mentioned it last time 
this was discussed). I think at the least you'd need a 
max-trans-id-with-lock number stored next to the count so that in the 
event of backend crashes the lock will eventually be released.

--  Richard Huxton  Archonet Ltd


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Zeugswetter Andreas SB SD"
Дата:
Сообщение: Re: PITR: XLog File compression on Archive
Следующее
От: "Zeugswetter Andreas SB SD"
Дата:
Сообщение: Re: 8.0 beta 1 on linux-mipsel R5900