On Mon, Nov 9, 2009 at 9:48 AM, digitaldeath wrote:
> Everybody is doing SELECT only on "adc" table, so why deadlocks if there
> are no write attempts on any row?
Well the deadlock error does include the information about what
queries deadlocked. In newer versions it includes the full text of the
Oh no, I thought my message was rejected and I reposted it in a
slightly modified form..
2009/11/9 Tom Lane :
> It's not a bug. The CREATE TABLE AS SELECT is acquiring a read lock on
> table "adc", and then the ALTER TABLE RENAME tries to upgrade that lock
> to exclusive. If you've got some othe
It's your "fault" though I don't know how you would know that without
knowing a lot about how postgres handles internal locking.
The problem is that the creat table as select * from adc takes a share
lock on adc then later the rename table upgrades the lock. This is
always a deadlock risk.
"digital.de...@gmx.it" writes:
> I hope it's not a bug, but I get a deadlock error in a
> function/transaction with these statements:
It's not a bug. The CREATE TABLE AS SELECT is acquiring a read lock on
table "adc", and then the ALTER TABLE RENAME tries to upgrade that lock
to exclusive. If y
Hello,
I hope it's not a bug, but I get a deadlock error in a
function/transaction with these statements:
CREATE OR REPLACE FUNCTION cluster_adc_table () RETURNS INTEGER AS $$
BEGIN
DROP TABLE IF EXISTS adc_clustered;
RAISE NOTICE 'start creating clustered table at %s',
clock_ti
