Hi!
> On 30 Jun 2022, at 14:23, Nikhil Shetty <nikhil.dba04@gmail.com> wrote:
>
> Hi,
>
> PostgreSQL version - 11.7
>
> We are using wal-g for backup/restore. We had a duration of high WAL generation due to application usage due to which
archivebackup was delayed.
>
> Backup was started through cron schedule and it didn't complete because it waits for the last WAL to be archived.
Now,I know that long running transactions will prevent vacuuming of dead tuples but in this case we were able to run
manualvacuums successfully but auto-vacuum never starts.
>
> As soon as we terminated the long running backup session, the auto-vacuum started kicking in.
>
> Wanted to understand why a backup operation is blocking the auto-vacuum?
>
> Wal-g uses non-exclusive backups and waits for the last wal to be archived.
As far as I know, WAL-G should not prevent running autovacuums on tables. WAL-G can be run against replication standby,
wherevacuum is not possible at all, so there must be no conflicts...
The only probable problem I can imagine is that we open transaction during pg_stop_backup() [0] to set a
statement_timeout.I think this is superflous and unneeded. I think this tx can be safely removed. But anyway, this tx
doesnot have a xid (otherwise it could not run on Standby).
BTW which version of WAL-G do you use?
Best regards, Andrey Borodin.
[0]
https://github.com/wal-g/wal-g/blob/8b9b3ca06efb44be4724208dc6f6d11836bd34d9/internal/databases/postgres/queryRunner.go#L243
