Craig Ringer wrote: > The reason the new src/test/recovery/ tests don't notice this is that using > pg_recvlogical from the TAP tests is currently pretty awkward. > pg_recvlogical has no way to specify a stop-point or return when there's no > immediately pending data like the SQL interface does. So you have to read > from it until you figure it's not going to return anything more then kill > it and look at what it did return and hope you don't lose anything in > buffering.I don't much like relying on timeouts as part of normal > successful results since they can upset some of the older and slower > buildfarm members. I'd rather be able to pass a --stoppos= or a --n-xacts= > option, but it was a bit too late to add those.
Considering that pg_recvlogical was introduced mostly as a way to test logical decoding features, I think this is a serious oversight and we should patch it. I suppose we could leave it for 9.7, thought I admit I would prefer it to introduce it in 9.6. Now everyone throwing stones at me in 3 ... 2 ... > Per the separate mail I sent to hackers, xlogreader is currently pretty > much timeline-agnostic. The timeline tracking code needs to know when the > xlogreader does a random read and do a fresh lookup so its state is part of > the XLogReaderState struct. But the walsender's xlogreader page read > callback doesn't use the xlogreader's state, and it can't because it's also > used for physical replication, which communicates the timeline to read from > with the page read function via globals. The globals there are a disaster and I welcome efforts to get rid of them. > So for now, I just set the globals before calling the page read > function: > > + XLogReadDetermineTimeline(state); > + sendTimeLineIsHistoric = state->currTLI == ThisTimeLineID; > + sendTimeLine = state->currTLI; > + sendTimeLineValidUpto = state->currTLIValidUntil; > + sendTimeLineNextTLI = state->nextTLI; Ok, this is pretty ugly but seems acceptable. > Per separate mail, I'd quite like to tackle the level of duplication in > timeline following logic in 9.7 and maybe see if the _three_ separate read > xlog page functions can be unified at the same time. But that sure isn't > 9.6 material. Agreed. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers