> I also confirmed that the patch fixes the reported issue. But, > during that test, I found that pg_stat_wal_receiver.slot_name became > NULL after a timeline switch. > > I think this can happen because RequestXLogStreaming() clears > walrcv->slotname when primary_slot_name is not configured. > The walreceiver then does not write the existing temporary slot name > back to shared memory because create_temp_slot is already false. > Then, streaming continues to use the temporary slot, but > pg_stat_wal_receiver.slot_name can show NULL.
Good catch, fixed.
> The reported case could be covered easily by 004_timeline_switch.pl.
> For example, we could enable wal_receiver_create_temp_slot without
> setting primary_slot_name, switch the upstream to a new timeline,
> check that the standby log does not contain "could not create replication
> slot ... already exists", and verify that pg_stat_wal_receiver.slot_name
> still reports a pg_walreceiver_% slot after the timeline switch.
> Thought?
Good idea.
> > Furthermore, if a log output is added before walrcv_create_slot(). This
> > might make the log more clear.
> >
> > ereport(LOG, errmsg("creating replication slot \"%s\"", slotname));
>
> I think this would be better discussed separately from the bug fix
> as an improvement, since it isn't necessary for fixing the reported
> issue.
+1
Please see the v2 patch.
--
Regards,
ChangAo Chen
v2-0001-Fix-temporary-WAL-receiver-slot-handling-on-timel.patch
Description: Binary data
