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:
On Thu, Feb 17, 2011 at 17:05, Itagaki Takahiro
itagaki.takah...@gmail.com 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
On Thu, Feb 10, 2011 at 08:36, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi 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:
On Thu, Feb 3, 2011 at 00:24, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi 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
On Wed, Feb 9, 2011 at 7:12 AM, Itagaki Takahiro
itagaki.takah...@gmail.com 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,
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 Fri, Jan 28, 2011 at 17:12, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi 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
On Tue, Feb 1, 2011 at 7:28 AM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
On Fri, Jan 28, 2011 at 17:12, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
I still didn't address
the issue with pg_advisory_unlock_all() releasing transaction scoped locks,
I guess you don't want
On 1/23/2011 4:24 AM, Robert Haas wrote:
On Thu, Jan 20, 2011 at 5:22 AM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi 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.
On Thu, Jan 20, 2011 at 5:22 AM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi 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!
==
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
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi 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
On 1/20/2011 7:35 AM, Tom Lane wrote:
Marko Tiikkajamarko.tiikk...@cs.helsinki.fi 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
On Sun, Jan 16, 2011 at 06:20, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi 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
On 2010-12-14 12:52 AM +0200, Marko Tiikkaja wrote:
patch
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
---
On 2010-12-14 4:23 AM +0200, Tom Lane wrote:
Marko Tiikkajamarko.tiikk...@cs.helsinki.fi 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
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi 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
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.
On Tue, Dec 14, 2010 at 7:07 AM, Andres Freund and...@anarazel.de 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
On 2010-12-14 4:19 PM +0200, Merlin Moncure wrote:
On Tue, Dec 14, 2010 at 7:07 AM, Andres Freundand...@anarazel.de 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
On Tuesday 14 December 2010 15:19:32 Merlin Moncure wrote:
On Tue, Dec 14, 2010 at 7:07 AM, Andres Freund and...@anarazel.de 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
Merlin Moncure mmonc...@gmail.com 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
On 12/14/2010 09:51 AM, Tom Lane wrote:
Merlin Moncuremmonc...@gmail.com 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
On Tue, Dec 14, 2010 at 9:51 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Merlin Moncure mmonc...@gmail.com 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
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi 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
On 2010-12-14 7:05 PM +0200, Tom Lane wrote:
Marko Tiikkajamarko.tiikk...@cs.helsinki.fi 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
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
On 13 December 2010 23:52, Marko Tiikkaja marko.tiikk...@cs.helsinki.fiwrote:
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
On 2010-12-14 1:08 AM +0200, Szymon Guz wrote:
On 13 December 2010 23:52, Marko Tiikkajamarko.tiikk...@cs.helsinki.fiwrote:
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
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
Tiikkajamarko.tiikk...@cs.helsinki.fiwrote:
So, thoughts?
In my opinion changing current behavior is not a good idea. I know some
software that
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
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
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 think a
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi 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
34 matches
Mail list logo
