On Thu, Mar 21, 2013 at 12:03:21AM +0100, Dimitri Fontaine wrote:
> Tom Lane writes:
> >> pg_is_lock_exclusive(lock, lock) returns boolean
> >> pg_is_lock_exclusive(lock[], lock[]) returns boolean
> >
> >> I suppose that the lock type would be text ('ExclusiveLock'), but we
> >> could also exp
Greg Smith wrote:
> Note that an EXPLAIN based approach doesn't solve all the problems
> in this area, because the trickiest ones I run into are ALTER TABLE
> changes--which you can't EXPLAIN. Some API that dumps the locks an
> arbitrary statement acquired just before it exits would be ideal.
> W
On 3/20/13 2:02 PM, Tom Lane wrote:
If isolationtester were the only market for this type of information,
maybe it wouldn't be worth worrying about. But I'm pretty sure that
there are a *lot* of monitoring applications out there that are trying
to extract who-blocks-whom information from pg_lock
On 3/20/13 10:36 PM, Tom Lane wrote:
Simon Riggs writes:
On 20 March 2013 18:02, Tom Lane wrote:
The API that comes to mind is (name subject to
bikeshedding)
pg_blocking_pids(pid int) returns int[]
Useful. Can we also have an SRF rather than an array?
I thought about that, but at least
Heikki Linnakangas writes:
> On 21.03.2013 05:36, Tom Lane wrote:
>>> The API that comes to mind is (name subject to bikeshedding)
>>> pg_blocking_pids(pid int) returns int[]
> How about inverting the function into:
> pg_pid_blocked_by(pid int) returns int
> It would take as argument a pid, and r
On 21.03.2013 05:36, Tom Lane wrote:
Simon Riggs writes:
On 20 March 2013 18:02, Tom Lane wrote:
The API that comes to mind is (name subject to
bikeshedding)
pg_blocking_pids(pid int) returns int[]
Useful. Can we also have an SRF rather than an array?
I thought about that, but at least
Simon Riggs writes:
> On 20 March 2013 18:02, Tom Lane wrote:
>> The API that comes to mind is (name subject to
>> bikeshedding)
>>
>> pg_blocking_pids(pid int) returns int[]
> Useful. Can we also have an SRF rather than an array?
I thought about that, but at least for the isolationtester use-
On Wed, Mar 20, 2013 at 02:02:32PM -0400, Tom Lane wrote:
[fun query for appraising lock contention]
> This is way more knowledge than we (should) want a client to embed about
> which lock types block which others. What's worse, it's still wrong.
> The query will find cases where one of the test
On 20 March 2013 18:02, Tom Lane wrote:
> The API that comes to mind is (name subject to
> bikeshedding)
>
> pg_blocking_pids(pid int) returns int[]
>
Useful. Can we also have an SRF rather than an array?
Does the definition as an array imply anything about our ability to
join an SRF to
Tom Lane writes:
>> pg_is_lock_exclusive(lock, lock) returns boolean
>> pg_is_lock_exclusive(lock[], lock[]) returns boolean
>
>> I suppose that the lock type would be text ('ExclusiveLock'), but we
>> could also expose a new ENUM type for that (pg_lock_mode).
>
> I don't have an objection to
Dimitri Fontaine writes:
> Tom Lane writes:
>> If we want a global view of the who-blocks-whom situation, I think we'll
>> need another approach. But since this way solves isolationtester's
>> problem fairly neatly, I was hopeful that it would be useful for other
>> apps too.
> What about a fun
Tom Lane writes:
>>> I propose that we should add a backend function that simplifies this
>>> type of query. The API that comes to mind is (name subject to
>>> bikeshedding)
>>>
>>> pg_blocking_pids(pid int) returns int[]
+1
> If we want a global view of the who-blocks-whom situation, I think
Greg Stark writes:
> On Wed, Mar 20, 2013 at 6:02 PM, Tom Lane wrote:
>> I propose that we should add a backend function that simplifies this
>> type of query. The API that comes to mind is (name subject to
>> bikeshedding)
>>
>> pg_blocking_pids(pid int) returns int[]
> I've wanted to use pg_
On Wed, Mar 20, 2013 at 6:02 PM, Tom Lane wrote:
> I propose that we should add a backend function that simplifies this
> type of query. The API that comes to mind is (name subject to
> bikeshedding)
>
> pg_blocking_pids(pid int) returns int[]
I've wanted to use pg_locks as a demonstrati
Robert Haas escribió:
> On Wed, Mar 20, 2013 at 2:02 PM, Tom Lane wrote:
> > I was just looking into why the -DCLOBBER_CACHE_ALWAYS buildfarm
> > critters aren't managing to run the new "timeouts" isolation test
> > successfully, despite very generous timeouts. The answer is that
> > 2 seconds is
On Wed, Mar 20, 2013 at 2:02 PM, Tom Lane wrote:
> I was just looking into why the -DCLOBBER_CACHE_ALWAYS buildfarm
> critters aren't managing to run the new "timeouts" isolation test
> successfully, despite very generous timeouts. The answer is that
> 2 seconds isn't quite enough time to parse+p
I was just looking into why the -DCLOBBER_CACHE_ALWAYS buildfarm
critters aren't managing to run the new "timeouts" isolation test
successfully, despite very generous timeouts. The answer is that
2 seconds isn't quite enough time to parse+plan+execute the query
that isolationtester uses to see if
17 matches
Mail list logo
