Re: [HACKERS] strange behavior on locks

2006-01-22 Thread Tom Lane 
Alfranio Correia Junior <[EMAIL PROTECTED]> writes:
> I am executing some stored procedures written in pl/pgsql
> But wouldn't PostgreSQL show information per statement executed by the 
> functions ?

No.  The command shown in the process status is always just the
outermost operation.

regards, tom lane

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [HACKERS] strange behavior on locks

2006-01-22 Thread Alfranio Correia Junior 

I am executing some stored procedures written in pl/pgsql
But wouldn't PostgreSQL show information per statement executed by the 
functions ?


or SELECT func_with_side_effects() ? 


-Mike

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
 




---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] strange behavior on locks

2006-01-22 Thread Alfranio Correia Junior 

Perhaps you are using SELECT FOR UPDATE?

I am not using "SELECT FOR UPDATES"...
Could it have another cause ?

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [HACKERS] strange behavior on locks

2006-01-20 Thread Michael Adler 
On Fri, Jan 20, 2006 at 11:47:55PM -0500, Tom Lane wrote:
> Alfranio Correia Junior <[EMAIL PROTECTED]> writes:
> > What could cause the status ("select waiting") ?
> 
> Perhaps you are using SELECT FOR UPDATE?

or SELECT func_with_side_effects() ? 

 -Mike

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] strange behavior on locks

2006-01-20 Thread Tom Lane 
Alfranio Correia Junior <[EMAIL PROTECTED]> writes:
> What could cause the status ("select waiting") ?

Perhaps you are using SELECT FOR UPDATE?

regards, tom lane

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org

[HACKERS] strange behavior on locks

2006-01-20 Thread Alfranio Correia Junior 
Hi, 

I running PostgreSQL 8.0.x with database that does not have foreign keys
and sometimes the following messages appears:

ERROR:  deadlock detected
DETAIL:  Process 10029 waits for ShareLock on transaction 65272; blocked
by process 32436.
Process 32436 waits for ShareLock on transaction 65117; blocked
by process 10029.

I also see (right after executing a ps) that there are lots of messages
"select waiting".

1 - Does it mean that process 10029 owns transaction  65117 and 
process 32436 owns transaction 65272 as a transaction acquires an
exclusive lock in its transaction id ?
2 - How is this situation possible ?
What could cause the status ("select waiting") ?

Best regards, 

Alfranio

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster