From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Michal Novotny <michal(dot)novotny(at)trustport(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Question about DROP TABLE |
Date: | 2016-01-12 11:37:21 |
Message-ID: | 20160112113721.propayaclisblniy@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Cramer | 2016-01-12 11:38:26 | Re: Re: 9.4-1207 behaves differently with server side prepared statements compared to 9.2-1102 |
Previous Message | Thom Brown | 2016-01-12 11:36:56 | Re: Odd behavior in foreign table modification (Was: Re: Optimization for updating foreign tables in Postgres FDW) |