Re: standby recovery fails (tablespace related) (tentative patch and discussion) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: standby recovery fails (tablespace related) (tentative patch and discussion)
Date
Msg-id 509375.1659199895@sss.pgh.pa.us
Whole thread Raw
In response to Re: standby recovery fails (tablespace related) (tentative patch and discussion)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: standby recovery fails (tablespace related) (tentative patch and discussion)
Re: standby recovery fails (tablespace related) (tentative patch and discussion)
List pgsql-hackers
I wrote:
> Looks like conchuela is still intermittently unhappy.

BTW, quite aside from stability, is it really necessary for this test to
be so freakin' slow?  florican for instance reports

[12:43:38] t/025_stuck_on_old_timeline.pl ....... ok    49010 ms ( 0.00 usr  0.00 sys +  3.64 cusr  2.49 csys =  6.13
CPU)
[12:44:12] t/026_overwrite_contrecord.pl ........ ok    34751 ms ( 0.01 usr  0.00 sys +  3.14 cusr  1.76 csys =  4.91
CPU)
[12:49:00] t/027_stream_regress.pl .............. ok   287278 ms ( 0.00 usr  0.00 sys +  9.66 cusr  6.95 csys = 16.60
CPU)
[12:50:04] t/028_pitr_timelines.pl .............. ok    64543 ms ( 0.00 usr  0.00 sys +  3.59 cusr  3.20 csys =  6.78
CPU)
[12:50:17] t/029_stats_restart.pl ............... ok    12505 ms ( 0.02 usr  0.00 sys +  3.16 cusr  1.40 csys =  4.57
CPU)
[12:50:51] t/030_stats_cleanup_replica.pl ....... ok    33933 ms ( 0.01 usr  0.01 sys +  3.55 cusr  2.46 csys =  6.03
CPU)
[12:51:25] t/031_recovery_conflict.pl ........... ok    34249 ms ( 0.00 usr  0.00 sys +  3.37 cusr  2.20 csys =  5.57
CPU)
[12:52:09] t/032_relfilenode_reuse.pl ........... ok    44274 ms ( 0.01 usr  0.00 sys +  3.21 cusr  2.05 csys =  5.27
CPU)
[12:54:07] t/033_replay_tsp_drops.pl ............ ok   117840 ms ( 0.01 usr  0.00 sys +  8.72 cusr  5.41 csys = 14.14
CPU)

027 is so bloated because it runs the core regression tests YA time,
which I'm not very happy about either; but that's no excuse for
every new test to contribute an additional couple of minutes.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Using each rel as both outer and inner for JOIN_ANTI
Next
From: Tom Lane
Date:
Subject: Re: Problem about postponing gathering partial paths for topmost scan/join rel