Re: [HACKERS] Why forcing Hot_standby_feedback to be enabled whencreating a logical decoding slot on standby

Поиск
Список
Период
Сортировка
От sanyam jain
Тема Re: [HACKERS] Why forcing Hot_standby_feedback to be enabled whencreating a logical decoding slot on standby
Дата
Msg-id MA1PR0101MB1320E62683D5A56435946731C0FB0@MA1PR0101MB1320.INDPRD01.PROD.OUTLOOK.COM
обсуждение исходный текст
Ответ на Re: [HACKERS] Why forcing Hot_standby_feedback to be enabled whencreating a logical decoding slot on standby  (Andres Freund <andres@anarazel.de>)
Список 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 по дате отправления:

Предыдущее
От: "Daniel Verite"
Дата:
Сообщение: Re: csv format for psql
Следующее
От: "Daniel Verite"
Дата:
Сообщение: Re: csv format for psql