On Sat, Nov 02, 2019 at 09:54:54PM -0400, Jeff Janes wrote: > While monitoring pg_stat_subscription, I noticed that last_msg_send_time > was usually NULL, which doesn't make sense. Why would we have a message, > but not know when it was sent?
So... The timestamp is received and stored in LogicalRepApplyLoop() with send_time when a 'w' message is received in the subscription cluster. And it gets computed with a two-phase process: - WalSndPrepareWrite() reserves the space in the message for the timestamp. - WalSndWriteData() computes the timestamp in the reserved space once the write message is computed and ready to go. > Filling out the timestamp after the message has already been sent is taking > "as late as possible" a little too far. It results in every message having > a zero timestamp, other than keep-alives which go through a different path. It seems to me that you are right: the timestamp is computed too late. > Re-ordering the code blocks as in the attached seems to fix it. But I have > to wonder, if this has been broken from the start and no one ever noticed, > is this even valuable information to relay in the first place? We could > just take the column out of the view, and not bother calling > GetCurrentTimestamp() for each message. I think that there are use cases for such monitoring capabilities, see for example 7fee252. So I would rather keep it. -- Michael
signature.asc
Description: PGP signature
