On 2011-02-18 7:16 AM +0200, Itagaki Takahiro wrote:
Committed with a few typo fixes. Thanks, Marko!
Thanks a lot!
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hack
On Thu, Feb 17, 2011 at 17:05, Itagaki Takahiro
wrote:
> I did a few cosmetic fixes, mainly lmgr/README and make a subroutine
> ReleaseLockForOwner() for LockReleaseSession and LockReleaseCurrentOwner.
Committed with a few typo fixes. Thanks, Marko!
--
Itagaki Takahiro
--
Sent via pgsql-hacke
On Thu, Feb 10, 2011 at 08:36, Marko Tiikkaja
wrote:
>> One issue might be in pg_locks
> Robert suggested not doing this for 9.1, and I don't have anything against
> that.
Agreed.
> Updated patch attached.
Looks good to commit. I note a few minor issues for committer:
* Functions listed in "Ta
On Wed, Feb 9, 2011 at 7:12 AM, Itagaki Takahiro
wrote:
> One issue might be in pg_locks, as you pointed out in the previous mail:
>> if a session holds both a transaction level and a session level lock
>> on the same resource, only one of them will appear in pg_locks.
> Also, we cannot distinguis
On Thu, Feb 3, 2011 at 00:24, Marko Tiikkaja
wrote:
> .. and here's the patch. I'm not too confident with the code I added to
> storage/lmgr/lock.c, but it seems to be working.
Sorry for the delayed review.
The patch needs adjustment of OIDs for recently commits, but it still works
well. See th
On 2011-01-28 10:12 AM +0200, I wrote:
I still didn't
address the issue with pg_advisory_unlock_all() releasing transaction
scoped locks, but I'm going to.
.. and here's the patch. I'm not too confident with the code I added to
storage/lmgr/lock.c, but it seems to be working.
Earlier there
On Tue, Feb 1, 2011 at 7:28 AM, Itagaki Takahiro
wrote:
> On Fri, Jan 28, 2011 at 17:12, Marko Tiikkaja
> wrote:
>> I still didn't address
>> the issue with pg_advisory_unlock_all() releasing transaction scoped locks,
>
> I guess you don't want independent locks, right? If an user object
> is loc
On Fri, Jan 28, 2011 at 17:12, Marko Tiikkaja
wrote:
> I still didn't address
> the issue with pg_advisory_unlock_all() releasing transaction scoped locks,
I guess you don't want independent locks, right? If an user object
is locked by session locks, it also blocks backends trying to lock it
with
On 1/23/2011 4:24 AM, Robert Haas wrote:
On Thu, Jan 20, 2011 at 5:22 AM, Marko Tiikkaja
wrote:
On 2011-01-17 9:28 AM +0200, Itagaki Takahiro wrote:
== Coding ==
I expect documentation will come soon.
I'm sorry about this, I have been occupied with other stuff. I'm going to
work on this to
On Thu, Jan 20, 2011 at 5:22 AM, Marko Tiikkaja
wrote:
> On 2011-01-17 9:28 AM +0200, Itagaki Takahiro wrote:
>>
>> Here is a short review for Transaction scoped advisory locks:
>> https://commitfest.postgresql.org/action/patch_view?id=518
>
> Thanks for reviewing!
>
>> == Features ==
>> The patch
On 1/20/2011 7:35 AM, Tom Lane wrote:
Marko Tiikkaja writes:
This seems useful, since the xact lock would be automatically released
if an error happens during "-- do something here" so you wouldn't need
to worry about releasing the lock elsewhere. But I'm not sure this is
safe. Can anyone see
Marko Tiikkaja writes:
> Another thing I now see is this:
> BEGIN;
> SELECT pg_advisory_xact_lock(1);
> -- do something here
> -- upgrade to session lock
> SELECT pg_advisory_lock(1);
> COMMIT;
> This seems useful, since the xact lock would be automatically released
> if an error happens dur
On 2011-01-17 9:28 AM +0200, Itagaki Takahiro wrote:
Here is a short review for Transaction scoped advisory locks:
https://commitfest.postgresql.org/action/patch_view?id=518
Thanks for reviewing!
== Features ==
The patch adds pg_[try_]advisory_xact_lock[_shared] functions.
The function names
On Sun, Jan 16, 2011 at 06:20, Marko Tiikkaja
wrote:
> Here's the latest version of the patch. It now uses the API proposed by
> Simon, but still lacks documentation changes, which I'm going to send
> tomorrow.
Here is a short review for Transaction scoped advisory locks:
https://commitfest.post
On 2010-12-14 12:52 AM +0200, Marko Tiikkaja wrote:
Here's the latest version of the patch. It now uses the API proposed by
Simon, but still lacks documentation changes, which I'm going to send
tomorrow.
Regards,
Marko Tiikkaja
*** a/src/backend/storage/lmgr/lock.c
--- b/src/backend/stor
On 2010-12-14 7:05 PM +0200, Tom Lane wrote:
Marko Tiikkaja writes:
On 2010-12-14 4:23 AM +0200, Tom Lane wrote:
Uh, I don't think so. It sure looks like you have changed the user
lockmethod to be transactional, ie, auto-release on commit/abort.
I was under the impression that passing sess
Marko Tiikkaja writes:
> On 2010-12-14 4:23 AM +0200, Tom Lane wrote:
>> Uh, I don't think so. It sure looks like you have changed the user
>> lockmethod to be transactional, ie, auto-release on commit/abort.
> I was under the impression that passing sessionLock=true to
> LockAcquire(), combine
On Tue, Dec 14, 2010 at 9:51 AM, Tom Lane wrote:
> Merlin Moncure writes:
>> Not that I'm necessarily against the proposal, but what does this do
>> that can't already be done by locking a table or a table's row?
>
> I agree with Andres' point about this: sometimes it'd be more convenient
> for a
On 12/14/2010 09:51 AM, Tom Lane wrote:
Merlin Moncure writes:
Not that I'm necessarily against the proposal, but what does this do
that can't already be done by locking a table or a table's row?
I agree with Andres' point about this: sometimes it'd be more convenient
for an advisory lock to
Merlin Moncure writes:
> Not that I'm necessarily against the proposal, but what does this do
> that can't already be done by locking a table or a table's row?
I agree with Andres' point about this: sometimes it'd be more convenient
for an advisory lock to be released automatically at transaction
On Tuesday 14 December 2010 15:19:32 Merlin Moncure wrote:
> On Tue, Dec 14, 2010 at 7:07 AM, Andres Freund wrote:
> > On Tuesday 14 December 2010 00:14:22 Marko Tiikkaja wrote:
> >> The lock space is the same though, but I don't feel strongly about it.
> >
> > I feel strongly that it needs the s
On 2010-12-14 4:19 PM +0200, Merlin Moncure wrote:
On Tue, Dec 14, 2010 at 7:07 AM, Andres Freund wrote:
On Tuesday 14 December 2010 00:14:22 Marko Tiikkaja wrote:
The lock space is the same though, but I don't feel strongly about it.
I feel strongly that it needs the same locking space. I pr
On Tue, Dec 14, 2010 at 7:07 AM, Andres Freund wrote:
> On Tuesday 14 December 2010 00:14:22 Marko Tiikkaja wrote:
>> The lock space is the same though, but I don't feel strongly about it.
> I feel strongly that it needs the same locking space. I pretty frequently have
> the need for multiple clie
On Tuesday 14 December 2010 00:14:22 Marko Tiikkaja wrote:
> The lock space is the same though, but I don't feel strongly about it.
I feel strongly that it needs the same locking space. I pretty frequently have
the need for multiple clients trying to acquiring a lock in transaction scope
(i.e. fo
Marko Tiikkaja writes:
> I often find myself wanting advisory locks that are automatically released
> when the transaction ends, so here's a small patch trying to do just that.
Excellent idea, I sure need that (been doing some pl stuff to track
locks granted then unlock them, transaction scope wo
On 2010-12-14 4:23 AM +0200, Tom Lane wrote:
Marko Tiikkaja writes:
On 2010-12-14 1:08 AM +0200, Szymon Guz wrote:
In my opinion changing current behavior is not a good idea. I know some
software that relies on current behavior and this would break it. Maybe add
that as an option, or add anoth
Marko Tiikkaja writes:
> On 2010-12-14 1:08 AM +0200, Szymon Guz wrote:
>> In my opinion changing current behavior is not a good idea. I know some
>> software that relies on current behavior and this would break it. Maybe add
>> that as an option, or add another type of advisory lock?
> Oh, I for
> Oh, I forgot to mention. The patch doesn't change any existing
> behaviour; the new behaviour can be invoked only by adding a new boolean
> argument:
>
> SELECT pg_advisory_lock(1, false);
>
> The lock space is the same though, but I don't feel strongly about it.
I could use this, and I thin
On 2010-12-14 2:35 AM +0200, Simon Riggs wrote:
On Tue, 2010-12-14 at 01:14 +0200, Marko Tiikkaja wrote:
Oh, I forgot to mention. The patch doesn't change any existing
behaviour; the new behaviour can be invoked only by adding a new boolean
argument:
SELECT pg_advisory_lock(1, false);
Don't
On 12/13/2010 07:35 PM, Simon Riggs wrote:
Same lock space is good. Easy to separate if required.
Explicitly nameable lock spaces would be even better, since if multiple
applications use them you get strange and unmanageable contention.
Yeah. I have a table of lock names for different locks,
On Tue, 2010-12-14 at 01:14 +0200, Marko Tiikkaja wrote:
> On 2010-12-14 1:08 AM +0200, Szymon Guz wrote:
> > On 13 December 2010 23:52, Marko
> > Tiikkajawrote:
> >> So, thoughts?
> >>
> > In my opinion changing current behavior is not a good idea. I know some
> > software that relies on current
On 2010-12-14 1:08 AM +0200, Szymon Guz wrote:
On 13 December 2010 23:52, Marko Tiikkajawrote:
So, thoughts?
In my opinion changing current behavior is not a good idea. I know some
software that relies on current behavior and this would break it. Maybe add
that as an option, or add another typ
On 13 December 2010 23:52, Marko Tiikkaja wrote:
> Hi,
>
> I often find myself wanting advisory locks that are automatically released
> when the transaction ends, so here's a small patch trying to do just that.
> I don't know much about the lock system so the patch is in the state "it
> looks lik
Hi,
I often find myself wanting advisory locks that are automatically
released when the transaction ends, so here's a small patch trying to do
just that. I don't know much about the lock system so the patch is in
the state "it looks like this would work". Any comments on the
technical detai
34 matches
Mail list logo
