Re: DROP TABLE and autovacuum - Mailing list pgsql-hackers

From ITAGAKI Takahiro
Subject Re: DROP TABLE and autovacuum
Date
Msg-id 20070614174225.6A6B.ITAGAKI.TAKAHIRO@oss.ntt.co.jp
Whole thread Raw
In response to Re: DROP TABLE and autovacuum  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: DROP TABLE and autovacuum  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-hackers
Alvaro Herrera <alvherre@commandprompt.com> wrote:

> ITAGAKI Takahiro wrote:
> > autovacuum killer triggered in CREATE/DROP/RENAME DATABASE commands.
> > Can we extend the feature to several TABLE commands?
> 
> Well, one problem with this is that currently SIGINT cancels the whole
> autovacuum worker, not just the table currently being processed.  I
> think this can be fixed easily by improving the signal handling.

There is no difference between SIGINT and SIGTERM against autovacuum
workers presently. I'm thinking to split their effects -- SIGINT to 
'skip the current table' and SIGTERM to 'cancel all tables'.

BTW, if autovacuum workers are signaled by an internal server activity,
we will see 'ERROR: canceling statement due to user request' in server log.
Is it surprising to users? I prefer quiet shutdown to ERROR logs.


> Aside from that, I don't see any problem in handling DROP TABLE like you
> suggest.  But I don't feel comfortable with doing it with just any
> strong locker, because that would easily starve tables from being
> vacuumed at all.

Hmm, how about canceling only the cases of DROP TABLE, TRUNCATE and CLUSTER.
We will obviously not need the table after the commands. Other commands,
VACUUM (FULL), ANALYZE, CREATE INDEX (CONCURRENTLY), REINDEX and LOCK TABLE
still conflict with autovacuum, but I'll leave it as-is in the meantime.

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center




pgsql-hackers by date:

Previous
From: ITAGAKI Takahiro
Date:
Subject: Sorted writes in checkpoint
Next
From: Gregory Stark
Date:
Subject: Re: EXPLAIN omits schema?