I went ahead and pushed this into 9.2 and 9.1. It did not apply at all
to 9.0, though, as there evidently was some refactoring affecting
LockReassignCurrentOwner() between 9.0 and 9.1. We could possibly have
applied some additional patches to 9.0, but I think that would be
stretching the
Jeff Janes jeff.ja...@gmail.com writes:
On Tue, Aug 25, 2015 at 5:48 AM, Michael Paquier michael.paqu...@gmail.com
On Fri, Jul 10, 2015 at 4:22 AM, Andres Freund and...@anarazel.de wrote:
That's the safest way. Sometimes you can decide that a function can not
sanely be called by external code
On 2015-08-25 13:54:20 -0400, Tom Lane wrote:
Jeff Janes jeff.ja...@gmail.com writes:
Once the code has to be rewritten, my argument that it has been working in
the field for a while doesn't really apply anymore.
If rewriting involves adding two one line wrapper functions, I don't see
the
On Tue, Aug 25, 2015 at 5:48 AM, Michael Paquier michael.paqu...@gmail.com
wrote:
On Fri, Jul 10, 2015 at 4:22 AM, Andres Freund and...@anarazel.de wrote:
On July 9, 2015 9:13:20 PM GMT+02:00, Jeff Janes jeff.ja...@gmail.com
wrote:
Unfortunately I don't know what that means about the API.
Andres Freund and...@anarazel.de writes:
On 2015-08-25 14:12:37 -0400, Tom Lane wrote:
How would they have done that without major code surgery? We don't have
any hooks or function pointers involved in the users of resowner.h.
Certainly locks would not be getting passed to a nonstandard
Andres Freund and...@anarazel.de writes:
On 2015-08-25 13:54:20 -0400, Tom Lane wrote:
However, I'm not entirely following Andres' concern here. AFAICS,
the only externally visible API change in commit eeb6f37d8 was that
LockReleaseCurrentOwner and LockReassignCurrentOwner gained some
Andres Freund and...@anarazel.de writes:
On 2015-08-25 14:33:25 -0400, Tom Lane wrote:
(IOW, yeah, certainly third-party code could create a new *instance* of
the ResourceOwner data structure, but they would not have any knowledge of
what's inside unless they had hacked the core code.)
What
On 2015-08-25 14:12:37 -0400, Tom Lane wrote:
How would they have done that without major code surgery? We don't have
any hooks or function pointers involved in the users of resowner.h.
Certainly locks would not be getting passed to a nonstandard resowner.
CurrentResourceOwner = myresowner;
On 2015-08-25 14:33:25 -0400, Tom Lane wrote:
(IOW, yeah, certainly third-party code could create a new *instance* of
the ResourceOwner data structure, but they would not have any knowledge of
what's inside unless they had hacked the core code.)
What I was thinking is that somebody created a
On Fri, Jul 10, 2015 at 4:22 AM, Andres Freund and...@anarazel.de wrote:
On July 9, 2015 9:13:20 PM GMT+02:00, Jeff Janes jeff.ja...@gmail.com wrote:
Unfortunately I don't know what that means about the API. Does it mean
that none of the functions declared in any .h file can have their
On 2015-06-07 13:44:08 -0700, Jeff Janes wrote:
I'd like to advocate for back-patching this to 9.0, 9.1, and 9.2. It has
run without problems for a while now, and it can be considered a bug that
systems with a very large number of objects cannot be upgraded in a
reasonable time.
In that
On Thu, Jun 21, 2012 at 5:32 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 18.06.2012 13:59, Heikki Linnakangas wrote:
On 10.06.2012 23:39, Jeff Janes wrote:
I found the interface between resowner.c and lock.c a bit confusing.
resowner.c would sometimes call
On 2015-06-07 13:44:08 -0700, Jeff Janes wrote:
I'd like to advocate for back-patching this to 9.0, 9.1, and 9.2. It has
run without problems for a while now, and it can be considered a bug that
systems with a very large number of objects cannot be upgraded in a
reasonable time.
+1
On Thu, Jun 21, 2012 at 5:32 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 18.06.2012 13:59, Heikki Linnakangas wrote:
On 10.06.2012 23:39, Jeff Janes wrote:
I found the interface between resowner.c and lock.c a bit confusing.
resowner.c would sometimes call
On 18.06.2012 13:59, Heikki Linnakangas wrote:
On 10.06.2012 23:39, Jeff Janes wrote:
I found the interface between resowner.c and lock.c a bit confusing.
resowner.c would sometimes call LockReassignCurrentOwner() to reassign
all the locks, and sometimes it would call LockReassignCurrentOwner()
And it doesn't seem right for ResourceOwnerRemember/ForgetLock to have to
accept a NULL owner.
I am not sure, if it can ever enter into this flow without resowner as
mentioned in jeff comments
for session level locks. If it cannot enter then it is okay.
Please take a look to see if I broke
On 19.06.2012 09:02, Amit Kapila wrote:
Please take a look to see if I broke something.
In you previous mail you agreed with level as ERROR for elog message in
function ResourceOwnerForgetLock(..) function,
but in your modification you have used PANIC, is there any specific reason
for it.
On 16.06.2012 09:04, Amit kapila wrote:
I don't think so. C doesn't ref count its pointers.
You are right I have misunderstood.
I don't think that lock tags have good human readable formats, and just
a pointer dump probably wouldn't be much use when something that can
never happen has
On 10.06.2012 23:39, Jeff Janes wrote:
The attached patch fixes that by remembering up to 10 local locks, and
pushing them up specifically rather than digging through the entire
lock table. If the list overflows, then it reverts to the old
behavior of digging through the entire local lock
A better error message would be nice, but I don't think it's worth that
much. resowner.c doesn't currently know about the internals of LOCALLOCk
struct or lock tags, and I'd prefer to keep it that way. Let's just
print the pointer's address, that's what we do in many other
corresponding
-tag.locktag_field3);
This can give more information about erroneous lock.
From: Jeff Janes [jeff.ja...@gmail.com]
Sent: Saturday, June 16, 2012 3:21 AM
To: Amit kapila
Cc: pgsql-hackers
Subject: Re: [HACKERS] Resource Owner reassign Locks
On Mon, Jun 11, 2012 at 9:30 PM
On Mon, Jun 11, 2012 at 9:30 PM, Amit Kapila amit.kap...@huawei.com wrote:
Yes, that means the list has over-flowed. Once it is over-flowed, it
is now invalid for the reminder of the life of the resource owner.
Don't we need any logic to clear the reference of locallock in owner-locks
array.
Jeff Janes jeff.ja...@gmail.com writes:
On Mon, Jun 11, 2012 at 9:30 PM, Amit Kapila amit.kap...@huawei.com wrote:
MAX_RESOWNER_LOCKS - How did you arrive at number 10 for it. Is there any
specific reason for 10.
I instrumented the code to record the maximum number of locks held by
a
On Fri, Jun 15, 2012 at 3:29 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Jeff Janes jeff.ja...@gmail.com writes:
On Mon, Jun 11, 2012 at 9:30 PM, Amit Kapila amit.kap...@huawei.com wrote:
MAX_RESOWNER_LOCKS - How did you arrive at number 10 for it. Is there any
specific reason for 10.
I
I have few doubts regarding logic of ResourceOwnerRememberLock() and
ResourceOwnerForgetLock():
1. In function ResourceOwnerRememberLock(), when lock count is
MAX_RESOWNER_LOCKS, it will not add the lock to lock array but increment the
count to make it 11.
Now in ResourceOwnerForgetLock(), it
On Sun, Jun 10, 2012 at 11:28 PM, Amit Kapila amit.kap...@huawei.com wrote:
I have few doubts regarding logic of ResourceOwnerRememberLock() and
ResourceOwnerForgetLock():
1. In function ResourceOwnerRememberLock(), when lock count is
MAX_RESOWNER_LOCKS, it will not add the lock to lock array
: Monday, June 11, 2012 8:52 PM
To: Amit Kapila
Cc: pgsql-hackers
Subject: Re: [HACKERS] Resource Owner reassign Locks
On Sun, Jun 10, 2012 at 11:28 PM, Amit Kapila amit.kap...@huawei.com
wrote:
I have few doubts regarding logic of ResourceOwnerRememberLock() and
ResourceOwnerForgetLock():
1
27 matches
Mail list logo
