public inbox for [email protected]help / color / mirror / Atom feed
[PATCH] Fix timeline-tracking failure while sending a historic timeline 5+ messages / 4 participants [nested] [flat]
* [PATCH] Fix timeline-tracking failure while sending a historic timeline @ 2021-01-05 04:34 Kyotaro Horiguchi <[email protected]> 0 siblings, 0 replies; 5+ messages in thread From: Kyotaro Horiguchi @ 2021-01-05 04:34 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. Backpatch to PG13. --- src/backend/replication/walsender.c | 2 +- src/test/perl/PostgresNode.pm | 36 ++++++++++++++++++++ src/test/recovery/t/001_stream_rep.pl | 41 ++++++++++++++++++++++- src/test/recovery/t/019_replslot_limit.pl | 37 ++++---------------- 4 files changed, 83 insertions(+), 33 deletions(-) diff --git a/src/backend/replication/walsender.c b/src/backend/replication/walsender.c index 7f87eb7f19..04f6c3ebb4 100644 --- a/src/backend/replication/walsender.c +++ b/src/backend/replication/walsender.c @@ -2478,7 +2478,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; } diff --git a/src/test/perl/PostgresNode.pm b/src/test/perl/PostgresNode.pm index 980f1f1533..a08c71b549 100644 --- a/src/test/perl/PostgresNode.pm +++ b/src/test/perl/PostgresNode.pm @@ -2138,6 +2138,42 @@ sub pg_recvlogical_upto =pod +=item $node->current_log_position() + +Return the current position of server log. + +=cut + +sub current_log_position +{ + my $self = shift; + + return (stat $self->logfile)[7]; +} + +=pod + +=item $node->find_in_log($pattern, $startpos) + +Returns whether the $pattern occurs after $startpos in the server log. + +=cut + +sub find_in_log +{ + my ($self, $pattern, $startpos) = @_; + + $startpos = 0 unless defined $startpos; + my $log = TestLib::slurp_file($self->logfile); + return 0 if (length($log) <= $startpos); + + $log = substr($log, $startpos); + + return $log =~ m/$pattern/; +} + +=pod + =back =cut diff --git a/src/test/recovery/t/001_stream_rep.pl b/src/test/recovery/t/001_stream_rep.pl index 778f11b28b..8d2b24fe55 100644 --- a/src/test/recovery/t/001_stream_rep.pl +++ b/src/test/recovery/t/001_stream_rep.pl @@ -2,8 +2,9 @@ use strict; use warnings; use PostgresNode; +use Time::HiRes qw(usleep); use TestLib; -use Test::More tests => 36; +use Test::More tests => 37; # Initialize master node my $node_master = get_new_node('master'); @@ -409,3 +410,41 @@ ok( ($phys_restart_lsn_pre cmp $phys_restart_lsn_post) == 0, my $master_data = $node_master->data_dir; ok(!-f "$master_data/pg_wal/$segment_removed", "WAL segment $segment_removed recycled after physical slot advancing"); + +# +# Check if timeline-increment works while reading a historic timeline. +my $node_primary_2 = get_new_node('primary_2'); +# archiving is needed to create .paritial segment +$node_primary_2->init(allows_streaming => 1, has_archiving => 1); +$node_primary_2->start; +$node_primary_2->backup($backup_name); +my $node_standby_3 = get_new_node('standby_3'); +$node_standby_3->init_from_backup($node_primary_2, $backup_name, + has_streaming => 1); +$node_primary_2->stop; +$node_primary_2->set_standby_mode; # increment primary timeline +$node_primary_2->start; +$node_primary_2->promote; +my $logstart = $node_standby_3->current_log_position(); +$node_standby_3->start; + +my $success = 0; +for (my $i = 0 ; $i < 1000; $i++) +{ + if ($node_standby_3->find_in_log( + "requested WAL segment [0-9A-F]+ has already been removed", + $logstart)) + { + last; + } + elsif ($node_standby_3->find_in_log( + "End of WAL reached on timeline", + $logstart)) + { + $success = 1; + last; + } + usleep(100_000); +} + +ok($success, 'Timeline increment while reading a historic timeline'); diff --git a/src/test/recovery/t/019_replslot_limit.pl b/src/test/recovery/t/019_replslot_limit.pl index a7231dcd47..8b3c5de057 100644 --- a/src/test/recovery/t/019_replslot_limit.pl +++ b/src/test/recovery/t/019_replslot_limit.pl @@ -165,19 +165,17 @@ $node_master->wait_for_catchup($node_standby, 'replay', $start_lsn); $node_standby->stop; -ok( !find_in_log( - $node_standby, - "requested WAL segment [0-9A-F]+ has already been removed"), +ok( !$node_standby->find_in_log( + "requested WAL segment [0-9A-F]+ has already been removed"), 'check that required WAL segments are still available'); # Advance WAL again, the slot loses the oldest segment. -my $logstart = get_log_size($node_master); +my $logstart = $node_master->current_log_position(); advance_wal($node_master, 7); $node_master->safe_psql('postgres', "CHECKPOINT;"); # WARNING should be issued -ok( find_in_log( - $node_master, +ok( $node_master->find_in_log( "invalidating slot \"rep1\" because its restart_lsn [0-9A-F/]+ exceeds max_slot_wal_keep_size", $logstart), 'check that the warning is logged'); @@ -190,14 +188,13 @@ is($result, "rep1|f|t|lost|", 'check that the slot became inactive and the state "lost" persists'); # The standby no longer can connect to the master -$logstart = get_log_size($node_standby); +$logstart = $node_standby->current_log_position(); $node_standby->start; my $failed = 0; for (my $i = 0; $i < 10000; $i++) { - if (find_in_log( - $node_standby, + if ($node_standby->find_in_log( "requested WAL segment [0-9A-F]+ has already been removed", $logstart)) { @@ -264,25 +261,3 @@ sub advance_wal } return; } - -# return the size of logfile of $node in bytes -sub get_log_size -{ - my ($node) = @_; - - return (stat $node->logfile)[7]; -} - -# find $pat in logfile of $node after $off-th byte -sub find_in_log -{ - my ($node, $pat, $off) = @_; - - $off = 0 unless defined $off; - my $log = TestLib::slurp_file($node->logfile); - return 0 if (length($log) <= $off); - - $log = substr($log, $off); - - return $log =~ m/$pat/; -} -- 2.27.0 ----Next_Part(Thu_Jan__7_16_32_36_2021_122)---- ^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: [PATCH] Fix ARM64/MSVC atomic memory ordering issues on Win11 by adding explicit DMB ?barriers @ 2026-01-04 20:13 Tom Lane <[email protected]> 0 siblings, 1 reply; 5+ messages in thread From: Tom Lane @ 2026-01-04 20:13 UTC (permalink / raw) To: Greg Burd <[email protected]>; +Cc: Thomas Munro <[email protected]>; Nathan Bossart <[email protected]>; Andres Freund <[email protected]>; PostgreSQL Hackers <[email protected]>; Peter Eisentraut <[email protected]>; Dave Cramer <[email protected]> "Greg Burd" <[email protected]> writes: > What this patch does is get "unicorn" off the dead list, which would be nice. Indeed ... I'm getting pretty tired of seeing unicorn cluttering the BF failures list. Is there a reason we're still holding off committing, other than it being holiday season? regards, tom lane ^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: [PATCH] Fix ARM64/MSVC atomic memory ordering issues on Win11 by adding explicit DMB ?barriers @ 2026-01-04 20:21 Nathan Bossart <[email protected]> parent: Tom Lane <[email protected]> 0 siblings, 2 replies; 5+ messages in thread From: Nathan Bossart @ 2026-01-04 20:21 UTC (permalink / raw) To: Tom Lane <[email protected]>; +Cc: Greg Burd <[email protected]>; Thomas Munro <[email protected]>; Andres Freund <[email protected]>; PostgreSQL Hackers <[email protected]>; Peter Eisentraut <[email protected]>; Dave Cramer <[email protected]> On Sun, Jan 04, 2026 at 03:13:15PM -0500, Tom Lane wrote: > "Greg Burd" <[email protected]> writes: >> What this patch does is get "unicorn" off the dead list, which would be nice. > > Indeed ... I'm getting pretty tired of seeing unicorn cluttering > the BF failures list. Is there a reason we're still holding off > committing, other than it being holiday season? Nope, I was planning to commit it in a few days when I am back. -- nathan ^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: [PATCH] Fix ARM64/MSVC atomic memory ordering issues on Win11 by adding explicit DMB ?barriers @ 2026-01-05 12:42 Greg Burd <[email protected]> parent: Nathan Bossart <[email protected]> 1 sibling, 0 replies; 5+ messages in thread From: Greg Burd @ 2026-01-05 12:42 UTC (permalink / raw) To: Nathan Bossart <[email protected]>; Tom Lane <[email protected]>; +Cc: Thomas Munro <[email protected]>; Andres Freund <[email protected]>; PostgreSQL Hackers <[email protected]>; Peter Eisentraut <[email protected]>; Dave Cramer <[email protected]> On Sun, Jan 4, 2026, at 3:21 PM, Nathan Bossart wrote: > On Sun, Jan 04, 2026 at 03:13:15PM -0500, Tom Lane wrote: >> "Greg Burd" <[email protected]> writes: >>> What this patch does is get "unicorn" off the dead list, which would be nice. >> >> Indeed ... I'm getting pretty tired of seeing unicorn cluttering >> the BF failures list. Is there a reason we're still holding off >> committing, other than it being holiday season? Tom, I'd turned off the "cron" equivalent on unicorn (or so I hope, Windows is... odd) the morning you sent this to reduce noise. Apologies for that. As soon as Nathan commits that patch I'll re-start it. I'm also still committed to finishing up the other pieces and docs so that it's not half-done. > Nope, I was planning to commit it in a few days when I am back. Nathan, thanks! Let's coordinate when you're back online. :) > -- > nathan best, -greg ^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: [PATCH] Fix ARM64/MSVC atomic memory ordering issues on Win11 by adding explicit DMB ?barriers @ 2026-01-07 19:46 Nathan Bossart <[email protected]> parent: Nathan Bossart <[email protected]> 1 sibling, 0 replies; 5+ messages in thread From: Nathan Bossart @ 2026-01-07 19:46 UTC (permalink / raw) To: Tom Lane <[email protected]>; +Cc: Greg Burd <[email protected]>; Thomas Munro <[email protected]>; Andres Freund <[email protected]>; PostgreSQL Hackers <[email protected]>; Peter Eisentraut <[email protected]>; Dave Cramer <[email protected]> On Sun, Jan 04, 2026 at 02:21:44PM -0600, Nathan Bossart wrote: > Nope, I was planning to commit it in a few days when I am back. Committed. -- nathan ^ permalink raw reply [nested|flat] 5+ messages in thread
end of thread, other threads:[~2026-01-07 19:46 UTC | newest] Thread overview: 5+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2021-01-05 04:34 [PATCH] Fix timeline-tracking failure while sending a historic timeline Kyotaro Horiguchi <[email protected]> 2026-01-04 20:13 Re: [PATCH] Fix ARM64/MSVC atomic memory ordering issues on Win11 by adding explicit DMB ?barriers Tom Lane <[email protected]> 2026-01-04 20:21 ` Re: [PATCH] Fix ARM64/MSVC atomic memory ordering issues on Win11 by adding explicit DMB ?barriers Nathan Bossart <[email protected]> 2026-01-05 12:42 ` Re: [PATCH] Fix ARM64/MSVC atomic memory ordering issues on Win11 by adding explicit DMB ?barriers Greg Burd <[email protected]> 2026-01-07 19:46 ` Re: [PATCH] Fix ARM64/MSVC atomic memory ordering issues on Win11 by adding explicit DMB ?barriers Nathan Bossart <[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