On Fri, Nov 11, 2011 at 9:40 AM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Thu, Nov 10, 2011 at 5:07 PM, Bruce Momjian wrote:
>> > Tom Lane wrote:
>> >> Robert Haas writes:
>> >> > It's possible to compile the source tree with LOCK_DEBUG defined, but
>> >> > the resulting postgres promptly
Robert Haas wrote:
> On Thu, Nov 10, 2011 at 5:07 PM, Bruce Momjian wrote:
> > Tom Lane wrote:
> >> Robert Haas writes:
> >> > It's possible to compile the source tree with LOCK_DEBUG defined, but
> >> > the resulting postgres promptly dumps core, due to the fact that
> >> > user_lockmethod doesn
Robert Haas writes:
> ... What I think it's mostly doing at this point is making it
> more difficult to make further changes - you do whatever you want to
> do, and then you have to go figure out what to do about the crazy
> LOCK_DEBUG stuff that no one uses.
[ shrug... ] If you're sufficiently
On Thu, Nov 10, 2011 at 5:04 PM, Tom Lane wrote:
> Robert Haas writes:
>> It's possible to compile the source tree with LOCK_DEBUG defined, but
>> the resulting postgres promptly dumps core, due to the fact that
>> user_lockmethod doesn't supply any value for trace_flag; thus, the
>> first LockRe
On Thu, Nov 10, 2011 at 5:07 PM, Bruce Momjian wrote:
> Tom Lane wrote:
>> Robert Haas writes:
>> > It's possible to compile the source tree with LOCK_DEBUG defined, but
>> > the resulting postgres promptly dumps core, due to the fact that
>> > user_lockmethod doesn't supply any value for trace_f
Tom Lane wrote:
> Robert Haas writes:
> > It's possible to compile the source tree with LOCK_DEBUG defined, but
> > the resulting postgres promptly dumps core, due to the fact that
> > user_lockmethod doesn't supply any value for trace_flag; thus, the
> > first LockReleaseAll(USER_LOCKMETHOD) dere
Robert Haas wrote:
> Now, whether or not this facility is well designed is a worthwhile
> question. Trace_lock_oidmin seems pretty sketchy to me, especially
> because it's blindly applied to even to lock tags where the second
> field isn't a relation - i.e. SET_LOCKTAG_TRANSACTION sets it to zero,
Robert Haas writes:
> It's possible to compile the source tree with LOCK_DEBUG defined, but
> the resulting postgres promptly dumps core, due to the fact that
> user_lockmethod doesn't supply any value for trace_flag; thus, the
> first LockReleaseAll(USER_LOCKMETHOD) dereferences a NULL pointer.
>
It's possible to compile the source tree with LOCK_DEBUG defined, but
the resulting postgres promptly dumps core, due to the fact that
user_lockmethod doesn't supply any value for trace_flag; thus, the
first LockReleaseAll(USER_LOCKMETHOD) dereferences a NULL pointer.
This is the result of the foll
