public inbox for [email protected]help / color / mirror / Atom feed
[PATCH v4 3/3] Fix timeline-tracking failure while sending a historic timeline 3+ messages / 3 participants [nested] [flat]
* [PATCH v4 3/3] Fix timeline-tracking failure while sending a historic timeline @ 2020-12-09 08:22 Kyotaro Horiguchi <[email protected]> 0 siblings, 0 replies; 3+ messages in thread From: Kyotaro Horiguchi @ 2020-12-09 08:22 UTC (permalink / raw) Walsender should track timeline switches while sending a historic timeline. Regain that behavior, which was broken in PG13, by a thinko of 709d003fbd. --- src/backend/replication/walsender.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/backend/replication/walsender.c b/src/backend/replication/walsender.c index fe0d368a35..8545c6c423 100644 --- a/src/backend/replication/walsender.c +++ b/src/backend/replication/walsender.c @@ -2491,7 +2491,7 @@ WalSndSegmentOpen(XLogReaderState *state, XLogSegNo nextSegNo, XLogSegNo endSegNo; XLByteToSeg(sendTimeLineValidUpto, endSegNo, state->segcxt.ws_segsize); - if (state->seg.ws_segno == endSegNo) + if (nextSegNo == endSegNo) *tli_p = sendTimeLineNextTLI; } -- 2.27.0 ----Next_Part(Thu_Jan__7_16_32_36_2021_122)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="0001-Fix-timeline-tracking-failure-while-sending-a-PG13.patch.txt" ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Remove no-op PlaceHolderVars @ 2026-01-16 03:37 Tom Lane <[email protected]> 0 siblings, 1 reply; 3+ messages in thread From: Tom Lane @ 2026-01-16 03:37 UTC (permalink / raw) To: Richard Guo <[email protected]>; +Cc: pgsql-hackers Richard Guo <[email protected]> writes: > While fixing some performance issues caused by PHVs recently, it > struck me again that we should be removing "no-op" PHVs whenever > possible, because PHVs can be optimization barriers in several cases. My immediate reaction is "how sure are you that they're no-ops"? I recall that there are places where we intentionally insert PHVs to preserve the separate identity of the contained expression (so that, for example, it can be matched to a subquery output later). > I still do not have a good idea for ensuring that removing the PHV > wrapper does not break the expression tree invariants. But maybe we > can use a conservative approach: we only strip the PHV if the > contained expression is known to be safe (for example, a simple Var). Do we generate a PHV at all in that case? Seems like we could deal with that by adding to the Var's varnullingrels instead of making a wrapper node. regards, tom lane ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Remove no-op PlaceHolderVars @ 2026-01-16 06:21 Richard Guo <[email protected]> parent: Tom Lane <[email protected]> 0 siblings, 0 replies; 3+ messages in thread From: Richard Guo @ 2026-01-16 06:21 UTC (permalink / raw) To: Tom Lane <[email protected]>; +Cc: pgsql-hackers On Fri, Jan 16, 2026 at 12:37 PM Tom Lane <[email protected]> wrote: > My immediate reaction is "how sure are you that they're no-ops"? > I recall that there are places where we intentionally insert PHVs > to preserve the separate identity of the contained expression > (so that, for example, it can be matched to a subquery output > later). The new phpreserved flag is used for that purpose, as explained in the commit message and the code comments. > Do we generate a PHV at all in that case? Seems like we could > deal with that by adding to the Var's varnullingrels instead of > making a wrapper node. The Var can be a reference to something outside the subquery being pulled up. If it is a reference to the non-nullable side, we'll have to wrap it in a PHV to ensure that it is forced to null when the outer join should do so. - Richard ^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2026-01-16 06:21 UTC | newest] Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2020-12-09 08:22 [PATCH v4 3/3] Fix timeline-tracking failure while sending a historic timeline Kyotaro Horiguchi <[email protected]> 2026-01-16 03:37 Re: Remove no-op PlaceHolderVars Tom Lane <[email protected]> 2026-01-16 06:21 ` Re: Remove no-op PlaceHolderVars Richard Guo <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox