From: | Abhishek Prakash <abhishek(dot)prakash08(at)infosys(dot)com> |
---|---|
To: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "usergroups(at)postgresql(dot)org" <usergroups(at)postgresql(dot)org> |
Cc: | RaviTeja Pippalla <raviteja(dot)pippalla(at)edgeverve(dot)com> |
Subject: | RE: ***Conflict with recovery error*** |
Date: | 2023-01-20 09:59:12 |
Message-ID: | SI2PR02MB5490CF8B0D514EB671AF3ACB81C59@SI2PR02MB5490.apcprd02.prod.outlook.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
Hi Laurenz,
Thanks for your reply.
We had set max_standby_streaming_delay = -1, but faced storage issues nearly 3.5 TB of storage was consumed.
Regards,
Abhishek P
-----Original Message-----
From: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
Sent: Friday, January 20, 2023 3:26 PM
To: Abhishek Prakash <abhishek(dot)prakash08(at)infosys(dot)com>; pgsql-general(at)lists(dot)postgresql(dot)org; pgsql-hackers(at)lists(dot)postgresql(dot)org; usergroups(at)postgresql(dot)org
Subject: Re: ***Conflict with recovery error***
[**EXTERNAL EMAIL**]
On Fri, 2023-01-20 at 08:56 +0000, Abhishek Prakash wrote:
> We are facing below issue with read replica we did work arounds by
> setting hot_standby_feedback, max_standby_streaming_delay and
> max_standby_archive_delay, which indeed caused adverse effects on
> primary DB and storage. As our DB is nearly 6 TB which runs as AWS Postgres RDS.
>
> Even the below error occurs on tables where vacuum is disabled and no
> DML operations are permitted. Will there be any chances to see row
> versions being changed even if vacuum is disabled.
> Please advise.
>
> 2023-01-13 07:20:12
> UTC:10.64.103.75(61096):ubpreplica(at)ubprdb01:[17707]:ERROR: canceling
> statement due to conflict with recovery
> 2023-01-13 07:20:12 UTC:10.64.103.75(61096):ubpreplica(at)ubprdb01:[17707]:DETAIL: User query might have needed to see row versions that must be removed.
It could be HOT chain pruning or an anti-wraparound autovacuum (which runs even if autovacuum is disabled).
Disabling autovacuum is not a smart idea to begin with.
Your best bet is to set "max_standby_streaming_delay = -1".
Yours,
Laurenz Albe
From | Date | Subject | |
---|---|---|---|
Next Message | Laurenz Albe | 2023-01-20 10:08:49 | Re: ***Conflict with recovery error*** |
Previous Message | Laurenz Albe | 2023-01-20 09:55:48 | Re: ***Conflict with recovery error*** |
From | Date | Subject | |
---|---|---|---|
Next Message | vignesh C | 2023-01-20 10:00:54 | Re: Skipping schema changes in publication |
Previous Message | Laurenz Albe | 2023-01-20 09:55:48 | Re: ***Conflict with recovery error*** |