On Mon, Jun 19, 2017 at 1:53 PM, Dmitry O Litvintsev wrote:
> yes, we had to restart database 4 days ago (and vacuum has resumed on start).
> I checked the log files and discovered that autovacuum on this table takes
>
> pages: 0 removed, 14072307 remain
> tuples: 43524292 removed,
suggestions in the test environment.
Thank you,
Dmitry
From: Jeff Janes
Sent: Monday, June 19, 2017 1:16 PM
To: Dmitry O Litvintsev
Cc: Andreas Kretschmer; pgsql-general@postgresql.org
Subject: Re: [GENERAL] autovacuum holds exclusive lock on table
On Mon, 19 Jun 2017 17:33:23 +
Dmitry O Litvintsev wrote:
>
> The test stand where I was to test schema upgrade is stuck cuz vacuum is
> blocking.
If you're in "panic mode" I would recommend cancelling the existing vacuum,
running your upgrades, then immeditely running VACUUM FREEZE ANALYZ
On Mon, Jun 19, 2017 at 10:33 AM, Dmitry O Litvintsev
wrote:
> Hi
>
> Since I have posted this nothing really changed. I am starting to panic
> (mildly).
>
> The source (production) runs :
>
> relname | mode | granted |
> substr
Dmitry O Litvintsev wrote:
> Hi
>
> Since I have posted this nothing really changed. I am starting to panic
> (mildly).
...
> vacuum_cost_delay = 50ms
Most likely, this value is far too high. You're causing autovacuum to
sleep for a very long time with this setting. Hard to say for certain
hmer
Sent: Tuesday, June 13, 2017 1:54 PM
To: pgsql-general@postgresql.org; Dmitry O Litvintsev;
pgsql-general@postgresql.org
Subject: Re: [GENERAL] autovacuum holds exclusive lock on table preventing it
from to be updated
Am 13. Juni 2017 20:04:04 MESZ schrieb Dmitry O Litvintsev :
>
&
Am 13. Juni 2017 20:04:04 MESZ schrieb Dmitry O Litvintsev :
>
>I
>wraparound)| 2017-
>| t | enstore | autovacuum: VACUUM public.t_inodes (to prevent
>wraparound)| 2017-06-13 12:31:04.870064-05 |
>00:28:50.276437 | 40672
>chimera | t_inodes
Hi,
I run postgresql 9.3.17. I am preparing for a major database schema upgrade.
I copied production database to test system using pg_basebackup.
Having started the database and waited for all WALs to be applied I proceeded
to run
schema modifications.
Immediately I run into issue - updat
