From: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
---|---|
To: | Nikhil Shetty <nikhil(dot)dba04(at)gmail(dot)com> |
Cc: | Pgsql-admin <pgsql-admin(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Long running backup preventing auto vacuum |
Date: | 2022-07-01 08:44:45 |
Message-ID: | CE90AAA4-6993-4676-A6BD-03122D887906@yandex-team.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
> 1 июля 2022 г., в 12:41, Nikhil Shetty <nikhil(dot)dba04(at)gmail(dot)com> написал(а):
>
> I think this tx can be safely removed
> How can I remove this? I can test whether this is the problem
I'v thought more about it and don't see any sense in removing tx from WAL-G code.
The very same virtual transaction would be started implicitly by "select pg_stop_backup()" SQL call. It will obtain a snapshot holding global xmin.
I don't think we can make anything here on WAL-G side, this is how Postgres backup API works.
But I'd recommend focusing on eliminating lag of the WAL archivation. Why did you have so many unarchived WALs? Maybe it worth some monitoring etc.
Thanks!
Best regards, Andrey Borodin.
From | Date | Subject | |
---|---|---|---|
Next Message | Joseph Hammerman | 2022-07-04 20:40:58 | Logical replication and pg_dump for out of band synchronization |
Previous Message | Nikhil Shetty | 2022-07-01 08:31:56 | Re: Long running backup preventing auto vacuum |