Re: Question on Hot Standby in PostgreSQL

["Williams, Alex" <awilliams@xxxxxxxxxxx>]

Hi Laurenz and Raja,

Thank you both for your feedback and insight, I really appreciate it. I think I'll leave it with -1 (since we may add columns in the future and other possible DDL changes,) so we'll schedule downtime on the standby at least 1x a week for cleaning up the master.

Again, I thank everyone for your help, this really helped my situation.

Happy Thanksgiving and Best Regards,

Alex

P.S. If anyone is ever in NJ, let me know, lunch is on me :)

From: Yaser Raja <yrraja@xxxxxxxxx>
Date: Wednesday, November 25, 2015 3:57 PM
To: Albe Laurenz <laurenz.albe@xxxxxxxxxx>
Cc: "Williams, Alex" <awilliams@xxxxxxxxxxx>, Scott Ribe <scott_ribe@xxxxxxxxxxxxxxxx>, "pgsql-admin@xxxxxxxxxxxxxx" <pgsql-admin@xxxxxxxxxxxxxx>
Subject: Re: Question on Hot Standby in PostgreSQL

On Wed, Nov 25, 2015 at 3:43 AM, Albe Laurenz <laurenz.albe@xxxxxxxxxx> wrote:

Alex Williams wrote:
> Concerning these two params below, when using hot_standby_feedback,  what would you set them if you
> had the situation where you had queries constantly running on the standby, some quick and some long,
> practically all day/night, everyday?
>
> max_standby_archive_delay (integer)
> max_standby_streaming_delay (integer)

> Should I still keep them as -1 (infinite)?

I'd say set them both to 0.

If you have hot_standby_feedback=on, the primary will not remove any rows still
needed on the standby, so there should never be a need to delay WAL application.

hot_standby_feedback will significantly reduce the conflicts but it will not totally eliminate them. For example if a new column is added to a table, any query using this table on slave will be cancelled to apply this change.

IF query cancellation is totally not acceptable then you will have to set these delays to -1.

 

The drawback is that you may get considerable bloat on the primary if many
DELETE/UPDATE operation are going on and queries on the standby take a long time.

Yours,
Laurenz Albe