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

Cancel autovacuum conflicting with DROP TABLE

From: ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
To: pgsql-patches(at)postgresql(dot)org
Subject: Cancel autovacuum conflicting with DROP TABLE
Date: 2007-06-20 02:40:28
Message-ID: 20070620111526.6956.ITAGAKI.TAKAHIRO@oss.ntt.co.jp (view raw or flat)
Thread:
Lists: pgsql-patches
Here is a patch that cancels autovacuum workers conflicting with
DROP TABLE, TRUNCATE and CLUSTER. It was discussed here:
http://archives.postgresql.org/pgsql-hackers/2007-06/msg00556.php

Before backends drop a table, they search autovacuum workers that
are running on the table. If found, they send SIGINT signal to
the autovacuum to avoid waiting for the worthless vacuum.

When an autovacuum worker receives SIGINT, it skips only the vacuuming
table and continues the remaining jobs. Now SIGINT and SIGTERM have
different meanings and their logs are changed.

  SIGINT -- Cancel the current job.
      DEBUG: autovacuum on relation <schema>.<table> is canceled
  SIGTERM -- Cancel all jobs.
      FATAL: terminating autovacuum due to administrator command

We can see the second SIGTERM log on shutdown and DROP DATABASE.
In such case, we send SIGTERM to autovacuums instead of SIGINT.
I'd like to bring down the error level to WARNING or less actually,
but I have no idea to do it because canceling queries and error levels
are tightly coupled in the present implementation.
Instead, I added the special FATAL message for autovacuum workers
so that we can distinguish the lines are ignorable.

Comments welcome.

---
ITAGAKI Takahiro
NTT Open Source Software Center

Attachment: cancel_autovac_on_drop.patch
Description: application/octet-stream (9.6 KB)

Responses

pgsql-patches by date

Next:From: Alexey KlyukinDate: 2007-06-20 07:50:00
Subject: bitmapscan changes patch review
Previous:From: Henry B. HotzDate: 2007-06-20 01:19:37
Subject: Re: Preliminary GSSAPI Patches

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