Re: [HACKERS] Why forcing Hot_standby_feedback to be enabled whencreating a logical decoding slot on standby - Mailing list pgsql-hackers

From sanyam jain
Subject Re: [HACKERS] Why forcing Hot_standby_feedback to be enabled whencreating a logical decoding slot on standby
Date
Msg-id MA1PR0101MB1320E62683D5A56435946731C0FB0@MA1PR0101MB1320.INDPRD01.PROD.OUTLOOK.COM
Whole thread Raw
In response to Re: [HACKERS] Why forcing Hot_standby_feedback to be enabled whencreating a logical decoding slot on standby  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Hi,
I am trying to create logical decoding slot on a standby. 
Enabling Hot_standby_feedback on standby is one of the requirement ; which will delay vacuuming of stale data on Master server. 
I am working on a hack to avoid Hot_standby_feedback so that Standby doesn't have any dependency on Master (except receiving WAL).

Hot_standby_feedback restricts Master to do early vacuuming of catalog relation which will be in decoding WAL record using "time travelling snapshot" on a Standby.

The other way to prevent early vacuuming on Standby can be by pausing recovery on Standby when a vacuum record belonging to catalog relation is encountered.
And when walsender process belonging to logical slot on Standby reaches this record it will resume the recovery by executing SetRecoveryPause(false).

To check whether VACUUM record belongs to a catalog relation i simply check if relationID < 10000.

This hack will only work for a single logical slot on standby.
Pausing recovery will increase the size of pg_xlog directory as walreceiver will continue receiving WAL.
Querying standby might result in wrong output.

Thanks,
Sanyam Jain

pgsql-hackers by date:

Previous
From: "Daniel Verite"
Date:
Subject: Re: csv format for psql
Next
From: "Daniel Verite"
Date:
Subject: Re: csv format for psql