Re: Minimal logical decoding on standbys
Amit Khandekar <amitdkhan.pg@gmail.com>
Commits
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
Attachments
- logical-decoding-on-standby_v6.patch (application/octet-stream) patch v6
On Tue, 11 Jun 2019 at 12:24, Amit Khandekar <amitdkhan.pg@gmail.com> wrote: > > On Mon, 10 Jun 2019 at 10:37, Amit Khandekar <amitdkhan.pg@gmail.com> wrote: > > > > On Tue, 4 Jun 2019 at 21:28, Andres Freund <andres@anarazel.de> wrote: > > > > > > Hi, > > > > > > On 2019-06-04 15:51:01 +0530, Amit Khandekar wrote: > > > > After giving more thought on this, I think it might make sense to > > > > arrange for the xl_running_xact record to be sent from master to the > > > > standby, when a logical slot is to be created on standby. How about > > > > standby sending a new message type to the master, requesting for > > > > xl_running_xact record ? Then on master, ProcessStandbyMessage() will > > > > process this new message type and call LogStandbySnapshot(). > > > > > > I think that should be a secondary feature. You don't necessarily know > > > the upstream master, as the setup could be cascading one. > > Oh yeah, cascading setup makes it more complicated. > > > > > I think for > > > now just having to wait, perhaps with a comment to manually start a > > > checkpoint, ought to suffice? > > > > Ok. > > > > Since this requires the test to handle the > > fire-create-slot-and-then-fire-checkpoint-from-master actions, I was > > modifying the test file to do this. After doing that, I found that the > > slave gets an assertion failure in XLogReadRecord()=>XRecOffIsValid(). > > This happens only when the restart_lsn is set to ReplayRecPtr. > > Somehow, this does not happen when I manually create the logical slot. > > It happens only while running testcase. Working on it ... > > Like I mentioned above, I get an assertion failure for > Assert(XRecOffIsValid(RecPtr)) while reading WAL records looking for a > start position (DecodingContextFindStartpoint()). This is because in > CreateInitDecodingContext()=>ReplicationSlotReserveWal(), I now set > the logical slot's restart_lsn to XLogCtl->lastReplayedEndRecPtr. And > just after bringing up slave, lastReplayedEndRecPtr's initial values > are in this order : 0/2000028, 0/2000060, 0/20000D8, 0/2000100, > 0/3000000, 0/3000060. You can see that 0/3000000 is not a valid value > because it points to the start of a WAL block, meaning it points to > the XLog page header (I think it's possible because it is 1 + endof > last replayed record, which can be start of next block). So when we > try to create a slot when it's in that position, then XRecOffIsValid() > fails while looking for a starting point. > > One option I considered was : If lastReplayedEndRecPtr points to XLog > page header, get a position of the first record on that WAL block, > probably with XLogFindNextRecord(). But it is not trivial because > while in ReplicationSlotReserveWal(), XLogReaderState is not created > yet. In the attached v6 version of the patch, I did the above. That is, I used XLogFindNextRecord() to bump up the restart_lsn of the slot to the first valid record. But since XLogReaderState is not available in ReplicationSlotReserveWal(), I did this in DecodingContextFindStartpoint(). And then updated the slot restart_lsn with this corrected position. Since XLogFindNextRecord() is currently disabled using #if 0, removed this directive. > Or else, do you think we can just increment the record pointer by > doing something like (lastReplayedEndRecPtr % XLOG_BLCKSZ) + > SizeOfXLogShortPHD() ? I found out that we can't do this, because we don't know whether the xlog header is SizeOfXLogShortPHD or SizeOfXLogLongPHD. In fact, in our context, it is SizeOfXLogLongPHD. So we indeed need the XLogReaderState handle. > > Do you think that we can solve this using some other approach ? I am > not sure whether it's only the initial conditions that cause > lastReplayedEndRecPtr value to *not* point to a valid record, or is it > just a coincidence and that lastReplayedEndRecPtr can also have such a > value any time afterwards. If it's only possible initially, we can > just use GetRedoRecPtr() instead of lastReplayedEndRecPtr if > lastReplayedEndRecPtr is invalid. So now as the v6 patch stands, lastReplayedEndRecPtr is used to set the restart_lsn, but its position is later adjusted in DecodingContextFindStartpoint(). Also, modified the test to handle the requirement that the logical slot creation on standby requires a checkpoint (or any other transaction commit) to be given from master. For that, in src/test/perl/PostgresNode.pm, added a new function create_logical_slot_on_standby() which does the reqiured steps. -- Thanks, -Amit Khandekar EnterpriseDB Corporation The Postgres Database Company