Re: [HACKERS] lazy vxid locks, v3

2011-08-04 Thread Jeff Davis
On Mon, 2011-08-01 at 12:12 -0400, Robert Haas wrote: I guess you could look at that way. It just seemed like the obvious way to write the code: we do LockRefindAndRelease() only if we have a fast-path lock that someone else has pushed into the main table. OK, looks good to me. Marked ready

Re: [HACKERS] lazy vxid locks, v3

2011-08-04 Thread Robert Haas
On Thu, Aug 4, 2011 at 11:29 AM, Jeff Davis pg...@j-davis.com wrote: On Mon, 2011-08-01 at 12:12 -0400, Robert Haas wrote: I guess you could look at that way.  It just seemed like the obvious way to write the code: we do LockRefindAndRelease() only if we have a fast-path lock that someone else

Re: [HACKERS] lazy vxid locks, v3

2011-08-01 Thread Robert Haas
On Sun, Jul 31, 2011 at 8:32 PM, Jeff Davis pg...@j-davis.com wrote: fpLocalTransactionId is redundant with the lxid, and the explanation is that one that they have different locking semantics. That looks reasonable, and it avoided the need for the careful ordering while starting/ending a

Re: [HACKERS] lazy vxid locks, v3

2011-08-01 Thread Jeff Davis
On Mon, 2011-08-01 at 08:12 -0400, Robert Haas wrote: Is the LocalTransactionIdIsValid(lxid) a guard against calling VirtualXactLockTableCleanup twice? Can that happen? Or is it just defensive coding to avoid making an additional assumption? lxid there is just a local variable storing

Re: [HACKERS] lazy vxid locks, v3

2011-08-01 Thread Robert Haas
On Mon, Aug 1, 2011 at 11:21 AM, Jeff Davis pg...@j-davis.com wrote: On Mon, 2011-08-01 at 08:12 -0400, Robert Haas wrote: Is the LocalTransactionIdIsValid(lxid) a guard against calling VirtualXactLockTableCleanup twice? Can that happen? Or is it just defensive coding to avoid making an

Re: [HACKERS] lazy vxid locks, v3

2011-07-31 Thread Jeff Davis
On Wed, 2011-07-20 at 13:41 -0400, Robert Haas wrote: I took another look at v2 of my lazy vxid locks patch and realized that it was pretty flaky in a couple of different ways. Here's a version that I think is a bit more robust, but considering the extent of the revisions, it probably needs

[HACKERS] lazy vxid locks, v3

2011-07-20 Thread Robert Haas
I took another look at v2 of my lazy vxid locks patch and realized that it was pretty flaky in a couple of different ways. Here's a version that I think is a bit more robust, but considering the extent of the revisions, it probably needs another round of review from someone before I commit it.