On 4/9/12 6:12 PM, Jeff Davis wrote:
On Mon, 2012-04-09 at 17:42 -0500, Jim Nasby wrote:
Dumb question... should operations in the various StrongLock functions
take place in a critical section? Or is that already ensure outside of
these functions?
Do you mean CRITICAL_SECTION() in the postgres
2012-04-09 19:32 keltezéssel, Robert Haas írta:
On Sun, Apr 8, 2012 at 9:37 PM, Robert Haas wrote:
Robert, the Assert triggering with the above procedure
is in your "fast path" locking code with current GIT.
Yes, that sure looks like a bug. It seems that if the top-level
transaction is aborti
On Mon, 2012-04-09 at 22:47 -0700, Jeff Davis wrote:
> but other similar paths do:
>
> if (!proclock)
> {
> AbortStrongLockAcquire();
>
> I don't think it's necessary outside of LockErrorCleanup(), right?
I take that back, it's necessary for the dontwait case, too.
Regards,
Jeff
On Mon, 2012-04-09 at 13:32 -0400, Robert Haas wrote:
> I looked at this more. The above analysis is basically correct, but
> the problem goes a bit beyond an error in LockWaitCancel(). We could
> also crap out with an error before getting as far as LockWaitCancel()
> and have the same problem.
On Mon, 2012-04-09 at 17:42 -0500, Jim Nasby wrote:
> Dumb question... should operations in the various StrongLock functions
> take place in a critical section? Or is that already ensure outside of
> these functions?
Do you mean CRITICAL_SECTION() in the postgres sense (that is, avoid
error paths
On 4/9/12 12:32 PM, Robert Haas wrote:
I looked at this more. The above analysis is basically correct, but
the problem goes a bit beyond an error in LockWaitCancel(). We could
also crap out with an error before getting as far as LockWaitCancel()
and have the same problem. I think that a correc
On Mon, 2012-04-09 at 16:11 -0400, Robert Haas wrote:
> > I wonder though whether
> > you actually need a *count*. What if it were just a flag saying "do not
> > take any fast path locks on this object", and once set it didn't get
> > unset until there were no locks left at all on that object?
>
On Mon, Apr 9, 2012 at 2:42 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Apr 9, 2012 at 1:49 PM, Tom Lane wrote:
>>> Haven't looked at the code, but maybe it'd be better to not bump the
>>> strong lock count in the first place until the final step of updating
>>> the lock tables?
>
>> We
Robert Haas writes:
> On Mon, Apr 9, 2012 at 1:49 PM, Tom Lane wrote:
>> Haven't looked at the code, but maybe it'd be better to not bump the
>> strong lock count in the first place until the final step of updating
>> the lock tables?
> Well, unfortunately, that would break the entire mechanism.
On Mon, Apr 9, 2012 at 1:49 PM, Tom Lane wrote:
> Robert Haas writes:
>> I looked at this more. The above analysis is basically correct, but
>> the problem goes a bit beyond an error in LockWaitCancel(). We could
>> also crap out with an error before getting as far as LockWaitCancel()
>> and ha
Robert Haas writes:
> I looked at this more. The above analysis is basically correct, but
> the problem goes a bit beyond an error in LockWaitCancel(). We could
> also crap out with an error before getting as far as LockWaitCancel()
> and have the same problem. I think that a correct statement
On Sun, Apr 8, 2012 at 9:37 PM, Robert Haas wrote:
>> Robert, the Assert triggering with the above procedure
>> is in your "fast path" locking code with current GIT.
>
> Yes, that sure looks like a bug. It seems that if the top-level
> transaction is aborting, then LockReleaseAll() is called and
On Sun, Apr 8, 2012 at 12:43 PM, Boszormenyi Zoltan wrote:
>> Indeed, the unpatched GIT version crashes if you enter
>> =#lock TABLE pgbench_accounts ;
>> the second time in session 2 after the first one failed. Also,
>> manually spelling it out:
>>
>> Session 1:
>>
>> $ psql
>> psql (9.2devel)
>
13 matches
Mail list logo
