Hi, On 2019-05-23 17:39:21 +0530, Amit Khandekar wrote: > On Tue, 21 May 2019 at 21:49, Andres Freund <and...@anarazel.de> wrote: > Yeah, I agree we should add such checks to minimize the possibility of > reading logical records from a master that has insufficient wal_level. > So to summarize : > a. CheckLogicalDecodingRequirements() : Add Controlfile wal_level checks > b. Call this function call in CreateInitDecodingContext() as well. > c. While decoding XLOG_PARAMETER_CHANGE record, emit recovery conflict > error if there is an existing logical slot. > > This made me think more of the race conditions. For instance, in > pg_create_logical_replication_slot(), just after > CheckLogicalDecodingRequirements and before actually creating the > slot, suppose concurrently Controlfile->wal_level is changed from > logical to replica. So suppose a new slot does get created. Later the > slot is read, so in pg_logical_slot_get_changes_guts(), > CheckLogicalDecodingRequirements() is called where it checks > ControlFile->wal_level value. But just before it does that, > ControlFile->wal_level concurrently changes back to logical, because > of replay of another param-change record. So this logical reader will > think that the wal_level is sufficient, and will proceed to read the > records, but those records are *before* the wal_level change, so these > records don't have logical data.
I don't think that's an actual problem, because there's no decoding before the slot exists and CreateInitDecodingContext() has determined the start LSN. And by that point the slot exists, slo XLOG_PARAMETER_CHANGE replay can error out. Greetings, Andres Freund