Re: reducing the overhead of frequent table locks, v4

Поиск
Список
Период
Сортировка
От Jeff Davis
Тема Re: reducing the overhead of frequent table locks, v4
Дата
Msg-id 1310332555.3012.251.camel@jdavis
обсуждение исходный текст
Ответ на reducing the overhead of frequent table locks, v4  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: reducing the overhead of frequent table locks, v4
Список pgsql-hackers
On Mon, 2011-06-27 at 10:13 -0400, Robert Haas wrote:
> I didn't get a lot of comments on my the previous version of my patch
> to accelerate table locks.
> 
> http://archives.postgresql.org/pgsql-hackers/2011-06/msg00953.php
> 
> Here's a new version anyway.  In this version, I have:

I am trying to figure out holdsStrongLockCount. It's declared as an
integer, but (unless cscope is failing me) is only ever set to 0 or 1.
It's never incremented or decremented. It looks like it's supposed to be
a boolean indicating that the lock should decrement something in
FastPathStrongLocks when released.

Furthermore, in AtPrepare_Locks(), the comment says:

/** Arrange not to release any strong lock count held by this lock* entry.  We must retain the count until the prepared
transaction*is committed or rolled back.*/
 
locallock->holdsStrongLockCount = 0;

But doesn't seem to "arrange" much, as far as I can tell.

I think the 2PC code is still correct, because it infers from the
lockmode that the FastPathStrongLocks counter needs to be incremented.
However, why doesn't other code (RemoveLocalLock is the only reader)
make a similar inference?

Can we just get rid of holdsStrongLockCount completely?

Regards,Jeff Davis



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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: Re: Proposed Windows-specific change: Enable crash dumps (like core files)
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Patch Review: Bugfix for XPATH() if text or attribute nodes are selected