Skip site navigation (1) Skip section navigation (2)

Re: Deadlock situation?

From: "Dan Armbrust" <daniel(dot)armbrust(dot)list(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Erik Jones" <erik(at)myemma(dot)com>, "pgsql general" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Deadlock situation?
Date: 2008-04-30 14:55:25
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-general
>  Well, there went the evidence :-( ... but what exactly did you have
>  to do to shut it down?  I'm wondering whether the backends responded

Sorry :(

First, I tried issuing a kill to the pid of the vacuum process.  It
didn't respond to kill.
Then, I tried a kill -9.  It responded to that :)

However, postgres got very unhappy at this point - I tried to log in
to issue another query against the pg_stat_activity table, but every
command I issued at this point simply hung.

In this case, Postgres had been started in the foreground on a
terminal, so I went to that terminal, and did a ctrl-c.  Eventually,
postgres stopped, but the terminal wouldn't respond either - and I had
to close it.

>  Next time, it'd be good to confirm (with top or vmstat or similar)
>  whether the backends are actually idle or are eating CPU or I/O.

I didn't notice any high load on the processor - the server seemed
idle.  But I didn't look real close a the individual postgres

>  Also try strace'ing a few of them; the pattern of kernel calls if
>  any would be revealing.
>  The lack of deadlock reports or 't' values in pg_stat_activity.waiting
>  says that you weren't blocking on heavyweight locks.  It's not
>  impossible that there was a deadlock at the LWLock level, though.
>  What sort of indexes are there on this table?

Here is the DDL for the table where vacuum was trying to run:

  ethernetmacaddr char(17) NOT NULL,
  cpemac char(11) NOT NULL,
  ipaddr varchar(15) NOT NULL,
  regtime timestamp NOT NULL,
  leasetime timestamp,
  last_updated timestamp NOT NULL DEFAULT now(),
  CONSTRAINT pk_iphost PRIMARY KEY (ethernetmacaddr, ipaddr),
  CONSTRAINT fk_iphost_cpe FOREIGN KEY (cpemac)
      REFERENCES cpe (cpemac) MATCH SIMPLE
ALTER TABLE iphost OWNER TO pslogin;

CREATE INDEX ix_iphost_cpemac
  ON iphost
  USING btree

CREATE INDEX ix_iphost_ipaddr
  ON iphost
  USING btree

> Teodor just fixed
>  an issue in GIN indexes that involved taking an unreasonable number of
>  LWLocks, and if that code wasn't exposing itself to deadlock risks
>  I'd be pretty surprised.
>                         regards, tom lane

Thanks.  If/when I can recreate this, I'll try to gather more info.


In response to


pgsql-general by date

Next:From: Craig RingerDate: 2008-04-30 15:00:46
Subject: Re: How to modify ENUM datatypes?
Previous:From: Andy AndersonDate: 2008-04-30 14:33:19
Subject: Re: Quoting "

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group