Re: Cancel autovacuum conflicting with DROP TABLE

ITAGAKI Takahiro wrote:
> ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp> wrote:
>
> > 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
>
> I made an adjustment for the latest 'more autovacuum fixes' patch.
> http://archives.postgresql.org/pgsql-patches/2007-06/msg00217.php
>
> Now, autovacuum workers handles ProcDie signals using ERROR
> instead of FATAL. The exception is caught by the worker and
> converted to the following logs.
>
>   SIGINT -- Cancel the current job.
>       LOG: autovacuum on <db>.<schema>.<table> is canceled
>   SIGTERM -- Cancel all jobs.
>       LOG: autovacuum on <db> is canceled

Thanks for the patch.  I think there are actually three patches in here:

1. changing SIGINT so that it cancels the current table instead of
shutting down the entire worker.

2. changing DROP TABLE and TRUNCATE so that they cancel an autovac
worker by sending SIGINT.

3. change the interrupt code so that autovac workers are terminated with
ERROR instead of FATAL, knowing that the final outcome is the same.  If
I'm not mistaken the only point of the change is to be able to change
the error message, is that correct?


I don't feel very much comfortable with the patch (3).  I would prefer
that we keep errcode FATAL and select a different error message in
ProcessInterrupts instead.  I don't see the point in complicating the
sigjmp target without need.

I agree with the (2) change.

The change in (1) I don't feel comfortable with commenting.  It seems
strange to me, and although it seems like it would be safe, I cannot
help having a strange feeling about it.  I'll try to digest it a bit
more.

--
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support