public inbox for [email protected]help / color / mirror / Atom feed
[PATCH v3 2/3] New test for timeline-tracking of walsender 3+ messages / 3 participants [nested] [flat]
* [PATCH v3 2/3] New test for timeline-tracking of walsender @ 2020-12-09 08:21 Kyotaro Horiguchi <[email protected]> 0 siblings, 0 replies; 3+ messages in thread From: Kyotaro Horiguchi @ 2020-12-09 08:21 UTC (permalink / raw) Walsender should track timeline changes while sending a historic timeline. Add a test for it. --- src/test/recovery/t/001_stream_rep.pl | 41 ++++++++++++++++++++++++++- 1 file changed, 40 insertions(+), 1 deletion(-) diff --git a/src/test/recovery/t/001_stream_rep.pl b/src/test/recovery/t/001_stream_rep.pl index 9e31a53de7..e78e98fb43 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 primary node my $node_primary = get_new_node('primary'); @@ -409,3 +410,41 @@ ok( ($phys_restart_lsn_pre cmp $phys_restart_lsn_post) == 0, my $primary_data = $node_primary->data_dir; ok(!-f "$primary_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'); -- 2.27.0 ----Next_Part(Tue_Jan__5_17_26_02_2021_224)-- Content-Type: Text/X-Patch; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="v3-0003-Fix-timeline-tracking-failure-while-sending-a-his.patch" ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: MultiXact\SLRU buffers configuration @ 2024-08-21 17:55 Alvaro Herrera <[email protected]> 0 siblings, 1 reply; 3+ messages in thread From: Alvaro Herrera @ 2024-08-21 17:55 UTC (permalink / raw) To: Michael Paquier <[email protected]>; +Cc: Andrey M. Borodin <[email protected]>; vignesh C <[email protected]>; Andrew Borodin <[email protected]>; [email protected]; Yura Sokolov <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; Gilles Darold <[email protected]>; Alexander Korotkov <[email protected]>; Anastasia Lubennikova <[email protected]>; Daniel Gustafsson <[email protected]>; Kyotaro Horiguchi <[email protected]>; pgsql-hackers On 2024-Aug-21, Michael Paquier wrote: > From fd8ab7b6845a2c56aa2c8d9c60f404f6b3407338 Mon Sep 17 00:00:00 2001 > From: Michael Paquier <[email protected]> > Date: Wed, 21 Aug 2024 15:16:06 +0900 > Subject: [PATCH 2/3] injection_point: Add injection_points.stats > This GUC controls if statistics should be used or not in the module. > Custom statistics require the module to be loaded with > shared_preload_libraries, hence this GUC is made PGC_POSTMASTER. By > default, stats are disabled. > > This will be used by an upcoming change in a test where stats should not > be used, as the test has a dependency on a critical section. I find it's strange that the information that stats cannot be used with injection points that have dependency on critical sections (?), is only in the commit message and not in the code. Also, maybe it'd make sense for stats to be globally enabled, and that only the tests that require it would disable them? (It's probably easy enough to have a value "injection_points.stats=auto" which means, if the module is loaded in shared_preload_libraries them set stats on, otherwise turn them off.) TBH I don't understand why the issue that stats require shared_preload_libraries only comes up now ... Maybe another approach is to say that if an injection point is loaded via _LOAD() rather than the normal way, then stats are disabled for that one rather than globally? Or give the _LOAD() macro a boolean argument to indicate whether to collect stats for that injection point or not. Lastly, it's not clear to me what does it mean that the test has a "dependency" on a critical section. Do you mean to say that the injection point runs inside a critical section? > From e5329d080b9d8436af8f65aac118745cf1f81ca2 Mon Sep 17 00:00:00 2001 > From: Michael Paquier <[email protected]> > Date: Wed, 21 Aug 2024 15:09:06 +0900 > Subject: [PATCH 3/3] Rework new SLRU test with injection points > > Rather than the SQL injection_points_load, this commit makes the test > rely on the two macros to load and run an injection point from the > cache, acting as an example of how to use them. No issues with this, feel free to go ahead. -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ "Cada quien es cada cual y baja las escaleras como quiere" (JMSerrat) ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: MultiXact\SLRU buffers configuration @ 2024-08-22 00:29 Michael Paquier <[email protected]> parent: Alvaro Herrera <[email protected]> 0 siblings, 0 replies; 3+ messages in thread From: Michael Paquier @ 2024-08-22 00:29 UTC (permalink / raw) To: Alvaro Herrera <[email protected]>; +Cc: Andrey M. Borodin <[email protected]>; vignesh C <[email protected]>; Andrew Borodin <[email protected]>; [email protected]; Yura Sokolov <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; Gilles Darold <[email protected]>; Alexander Korotkov <[email protected]>; Anastasia Lubennikova <[email protected]>; Daniel Gustafsson <[email protected]>; Kyotaro Horiguchi <[email protected]>; pgsql-hackers On Wed, Aug 21, 2024 at 01:55:06PM -0400, Alvaro Herrera wrote: > I find it's strange that the information that stats cannot be used with > injection points that have dependency on critical sections (?), is only > in the commit message and not in the code. A comment close to where inj_stats_enabled is declared in injection_points.c may be adapted for that, say: "This GUC is useful to control if statistics should be enabled or not during a test with injection points, like for example if a test relies on a callback run in a critical section where no allocation should happen." > Also, maybe it'd make sense for stats to be globally enabled, and that > only the tests that require it would disable them? (It's probably easy > enough to have a value "injection_points.stats=auto" which means, if the > module is loaded in shared_preload_libraries them set stats on, > otherwise turn them off.) I'm not sure that we need to get down to that until somebody has a case where they want to rely on stats of injection points for their stuff. At this stage, I only want the stats to be enabled to provide automated checks for the custom pgstats APIs, so disabling it by default and enabling it only in the stats test of the module injection_points sounds kind of enough to me for now. The module could always be tweaked to do that in the future, if there's a case. > TBH I don't understand why the issue that > stats require shared_preload_libraries only comes up now ... Because there was no need to, simply. It is the first test that relies on a critical section, and we need allocations if we want to use a wait condition. > Maybe another approach is to say that if an injection point is loaded via > _LOAD() rather than the normal way, then stats are disabled for that one > rather than globally? One trick would be to force the GUC to be false for the duration of the callback based on a check of CritSectionCount, a second one would be to just skip the stats if are under CritSectionCount. A third option, that I find actually interesting, would be to call MemoryContextAllowInCriticalSection in some strategic code paths of the test module injection_points because we're OK to live with this restriction in the module. > Or give the _LOAD() macro a boolean argument to > indicate whether to collect stats for that injection point or not. Sticking some knowledge about the stats in the backend part of injection points does not sound like a good idea to me. > Lastly, it's not clear to me what does it mean that the test has a > "dependency" on a critical section. Do you mean to say that the > injection point runs inside a critical section? Yes. > No issues with this, feel free to go ahead. Cool, thanks. -- Michael Attachments: [application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc) download ^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2024-08-22 00:29 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:21 [PATCH v3 2/3] New test for timeline-tracking of walsender Kyotaro Horiguchi <[email protected]> 2024-08-21 17:55 Re: MultiXact\SLRU buffers configuration Alvaro Herrera <[email protected]> 2024-08-22 00:29 ` Re: MultiXact\SLRU buffers configuration Michael Paquier <[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