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
>
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, 395006545 remain
buffer usage: -1493114028 hits, 107664973
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
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 |
>
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
Hi
Since I have posted this nothing really changed. I am starting to panic
(mildly).
The source (production) runs :
relname | mode | granted |
substr| query_start
|
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 |
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 -