Hi Andres, thanks a lot. I've managed to run DROP TABLE and then cancel process using pg_cancel_backend(autovacuum_pid) and it passed and dropped the 5T table.
Thanks a lot! Michal On 01/12/2016 12:37 PM, Andres Freund wrote: > Hi, > > On 2016-01-12 12:17:01 +0100, Michal Novotny wrote: >> thanks a lot for your reply. Unfortunately I've found out most it didn't >> really start DROP TABLE yet and it's locked on autovacuum running for >> the table and even if I kill the process it's autostarting again and again. > > Start the DROP TABLE and *then* cancel the autovacuum session. That > should work. > >> Is there any way how to do the DROP TABLE and bypass/disable autovacuum >> entirely? Please note the "autovacuum = off" is set in the config file >> (postgresql.conf). > > That actually is likely to have caused the problem. Every > autovacuum_freeze_max_age tables need to be vacuumed - otherwise the > data can't be interpreted correctly anymore at some point. That's called > 'anti-wraparound vacuum". It's started even if you disabled autovacuum, > to prevent database corruption. > > If you disable autovacuum, you really should start vacuums in some other > way. > > Greetings, > > Andres Freund > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
