Re: Walreceiver create temp slot more than once when timeline switch

> 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