Re: Patch: show relation and tuple infos of a lock to acquire
От | Christian Kruse |
---|---|
Тема | Re: Patch: show relation and tuple infos of a lock to acquire |
Дата | |
Msg-id | 20140311090239.GD9524@defunct.ch обсуждение исходный текст |
Ответ на | Re: Patch: show relation and tuple infos of a lock to acquire (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: Patch: show relation and tuple infos of a lock to acquire
Re: Patch: show relation and tuple infos of a lock to acquire |
Список | pgsql-hackers |
Hi, On 11/03/14 13:23, Amit Kapila wrote: > [… snip …] > So I think it's better to leave logging it as you have done in > patch. Agreed. > […] > 2. Name new functions as MultiXactIdWaitExtended()/XactLockTableWaitExtended() > or MultiXactIdWaitEx()/XactLockTableWaitEx(). > You can find some other similar functions (ReadBufferExtended, > relation_openrv_extended) > > 3. MultiXactIdWaitWithInfo()/XactLockTableWaitWithInfo() > > Earlier I found option 3 as a good choice, but now again thinking on > it I am leaning towards option 2. Changing it once again will only cause more work and won't do a big difference. So I suggest sticking with the current function names. > Today, again looking into it, I found that function > heap_lock_updated_tuple_rec() is using SnapshotAny to fetch the tuple > and I think for this case also it's not safe to Log the tuple. > > Could you please once check (if you are comfortable doing so) wherever > this patch is passing tuple, whether it is okay to pass it based on visibility > rules, else I will again verify it once. I think I got all places, but it would be nice to have a confirmation. > > [… policy regarding whitespaces …] > The simple rule I follow is don't touch the code which has no relation > to current patch. OK. Thanks. Best regards, -- Christian Kruse http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Вложения
В списке pgsql-hackers по дате отправления: