Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Gurjeet Singh escribió:
>> I just looked at the patch... Isn't PG_TRY() an expensive call to make in
>> the lock.c code? I was thinking of registering a Xact callback using
>> RegisterXactCallback() and performing 'waiting' reset in that callback if
>> t
On Feb 2, 2008 3:27 PM, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Gurjeet Singh escribió:
>
> > I just looked at the patch... Isn't PG_TRY() an expensive call to make
> in
> > the lock.c code? I was thinking of registering a Xact callback using
> > RegisterXactCallback() and performing 'waiting'
Gurjeet Singh escribió:
> I just looked at the patch... Isn't PG_TRY() an expensive call to make in
> the lock.c code? I was thinking of registering a Xact callback using
> RegisterXactCallback() and performing 'waiting' reset in that callback if
> the Xact event is XACT_EVENT_ABORT.
PG_TRY is no
On Feb 2, 2008 2:28 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> I wrote:
> > "Gurjeet Singh" <[EMAIL PROTECTED]> writes:
> >> I saw a strange behaviour on one of the production boxes. The
> >> pg_stat_activity shows a process as and yet 'waiting' !!! On top
> of
> >> it (understandably, since its I
I wrote:
> "Gurjeet Singh" <[EMAIL PROTECTED]> writes:
>> I saw a strange behaviour on one of the production boxes. The
>> pg_stat_activity shows a process as and yet 'waiting' !!! On top of
>> it (understandably, since its IDLE), there are no entries for this pid in
>> pg_locks!
> Hmm, I can rep
On Feb 1, 2008 3:56 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Gurjeet Singh" <[EMAIL PROTECTED]> writes:
> > The situation seems pretty bad!!
>
> I think at least part of your problem is not understanding that a single
> transaction sees a frozen snapshot of pg_stat_activity.
>
>
It does! I assum
"Gurjeet Singh" <[EMAIL PROTECTED]> writes:
> The situation seems pretty bad!!
I think at least part of your problem is not understanding that a single
transaction sees a frozen snapshot of pg_stat_activity.
regards, tom lane
---(end of broadcast)-
The situation seems pretty bad!!
Here are the steps to reproduce in 'PostgreSQL 8.3beta2 on
x86_64-unknown-linux-gnu, compiled by GCC gcc (GCC) 3.3.3 (SuSE Linux)':
session 1: begin;
session 1: update test set a = 112 where a = 112;
session 2: update test set a = 113 where a = 112; --waits
sessio
"Gurjeet Singh" <[EMAIL PROTECTED]> writes:
> I saw a strange behaviour on one of the production boxes. The
> pg_stat_activity shows a process as and yet 'waiting' !!! On top of
> it (understandably, since its IDLE), there are no entries for this pid in
> pg_locks!
Hmm, I can reproduce someth
Hi guys,
I saw a strange behaviour on one of the production boxes. The
pg_stat_activity shows a process as and yet 'waiting' !!! On top of
it (understandably, since its IDLE), there are no entries for this pid in
pg_locks!
Following are the snapshots of the two system views.
procpid |
10 matches
Mail list logo