Re: Minimal logical decoding on standbys
tushar <tushar.ahuja@enterprisedb.com>
From: tushar <tushar.ahuja@enterprisedb.com>
To: Amit Khandekar <amitdkhan.pg@gmail.com>,
Robert Haas <robertmhaas@gmail.com>
Cc: Andres Freund <andres@anarazel.de>,
Petr Jelinek <petr.jelinek@2ndquadrant.com>,
Craig Ringer <craig@2ndquadrant.com>, Petr Jelinek <petr@2ndquadrant.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2019-07-04T10:22:21Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Reduce the log level in 035_standby_logical_decoding.pl.
- 3034dc56ef4b 16.0 landed
-
035_standby_logical_decoding: Add missing waits for replication
- 57411c82ce86 16.0 landed
-
For cascading replication, wake physical and logical walsenders separately
- e101dfac3a53 16.0 landed
-
Handle logical slot conflicts on standby
- 26669757b6a7 16.0 landed
-
Support invalidating replication slots due to horizon and wal_level
- be87200efd93 16.0 landed
-
Prevent use of invalidated logical slot in CreateDecodingContext()
- 4397abd0a2af 16.0 landed
-
Replace replication slot's invalidated_at LSN with an enum
- 15f8203a5975 16.0 landed
-
Pass down table relation into more index relation functions
- 61b313e47eb9 16.0 landed
-
Assert only valid flag bits are passed to visibilitymap_set()
- a88a18b1250b 16.0 landed
-
Remove unused _bt_delitems_delete() argument.
- dc43492e46c7 14.0 cited
-
Add xl_btree_delete optimization.
- d2e5e20e5711 13.0 cited
On 07/01/2019 11:04 AM, Amit Khandekar wrote:
> Also, in the updated patch (v11), I have added some scenarios that
> verify that slot is dropped when either master wal_level is
> insufficient, or when slot is conflicting. Also organized the test
> file a bit.
One scenario where replication slot removed even after fixing the
problem (which Error message suggested to do)
Please refer this below scenario
Master cluster-
postgresql,conf file
wal_level=logical
hot_standby_feedback = on
port=5432
Standby cluster-
postgresql,conf file
wal_level=logical
hot_standby_feedback = on
port=5433
both Master/Slave cluster are up and running and are in SYNC with each other
Create a logical replication slot on SLAVE ( SELECT * from
pg_create_logical_replication_slot('m', 'test_decoding'); )
change wal_level='hot_standby' on Master postgresql.conf file / restart
the server
Run get_changes function on Standby -
postgres=# select * from pg_logical_slot_get_changes('m',null,null);
ERROR: logical decoding on standby requires wal_level >= logical on master
Correct it on Master postgresql.conf file ,i.e set wal_level='logical'
again / restart the server
and again fire get_changes function on Standby -
postgres=# select * from pg_logical_slot_get_changes('m',null,null);
*ERROR: replication slot "m" does not exist
*This looks little weird as slot got dropped/removed internally . i
guess it should get invalid rather than removed automatically.
Lets user's delete the slot themself rather than automatically removed
as a surprise.
--
regards,tushar
EnterpriseDB https://www.enterprisedb.com/
The Enterprise PostgreSQL Company