Intermittent failure in InstallCheck-C "stat" test
Hi,
Just now, and also once 5-and-a-bit days ago, flaviventris failed like
this, as did filefish 41 days ago[1]https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=filefish&dt=2019-02-23%2009%3A53%3A11 (there may be more, I just
checked a random sample of InstallCheck-C failures accessible via the
web interface):
WHERE relname like 'trunc_stats_test%' order by relname;
relname | n_tup_ins | n_tup_upd | n_tup_del | n_live_tup |
n_dead_tup
-------------------+-----------+-----------+-----------+------------+------------
- trunc_stats_test | 3 | 0 | 0 | 0 |
0
- trunc_stats_test1 | 4 | 2 | 1 | 1 |
0
- trunc_stats_test2 | 1 | 0 | 0 | 1 |
0
- trunc_stats_test3 | 4 | 0 | 0 | 2 |
2
- trunc_stats_test4 | 2 | 0 | 0 | 0 |
2
+ trunc_stats_test | 0 | 0 | 0 | 0 |
0
+ trunc_stats_test1 | 0 | 0 | 0 | 0 |
0
+ trunc_stats_test2 | 0 | 0 | 0 | 0 |
0
+ trunc_stats_test3 | 0 | 0 | 0 | 0 |
0
+ trunc_stats_test4 | 0 | 0 | 0 | 0 |
0
(5 rows) SELECT st.seq_scan >= pr.seq_scan + 1,
@@ -180,7 +180,7 @@
WHERE st.relname='tenk2' AND cl.relname='tenk2';
?column? | ?column? | ?column? | ?column?
----------+----------+----------+----------
- t | t | t | t
+ f | f | f | f
(1 row) SELECT st.heap_blks_read + st.heap_blks_hit >= pr.heap_blks + cl.relpages,
@@ -189,7 +189,7 @@
WHERE st.relname='tenk2' AND cl.relname='tenk2';
?column? | ?column?
----------+----------
- t | t
+ t | f
(1 row)[1]: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=filefish&dt=2019-02-23%2009%3A53%3A11
--
Thomas Munro
https://enterprisedb.com
Thomas Munro <thomas.munro@gmail.com> writes:
Just now, and also once 5-and-a-bit days ago, flaviventris failed like
this, as did filefish 41 days ago[1] (there may be more, I just
checked a random sample of InstallCheck-C failures accessible via the
web interface):
This sort of thing has pretty much always happened. I believe it is
just down to the designed-in unreliability of the current stats collection
mechanism. We might be able to get rid of it if we go over to
shared-memory stats, but I've yet to look at that patch :-(. In the
meantime I don't see any reason to think that anything's worse here
than it has been for many years.
regards, tom lane
Hi,
On 2019-04-05 18:19:17 -0400, Tom Lane wrote:
We might be able to get rid of it if we go over to shared-memory
stats, but I've yet to look at that patch :-(.
I did a few review cycles on it, and while I believe the concept is
sound, I think it needs a good bit more time to mature. Not
realistically doable for v12.
Greetings,
Andres Freund
On Sat, Apr 6, 2019 at 11:19 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Thomas Munro <thomas.munro@gmail.com> writes:
Just now, and also once 5-and-a-bit days ago, flaviventris failed like
this, as did filefish 41 days ago[1] (there may be more, I just
checked a random sample of InstallCheck-C failures accessible via the
web interface):This sort of thing has pretty much always happened. I believe it is
just down to the designed-in unreliability of the current stats collection
mechanism. We might be able to get rid of it if we go over to
shared-memory stats, but I've yet to look at that patch :-(. In the
meantime I don't see any reason to think that anything's worse here
than it has been for many years.
Does it imply that the kernel dropped a UDP packet to localhost?
--
Thomas Munro
https://enterprisedb.com
Thomas Munro <thomas.munro@gmail.com> writes:
On Sat, Apr 6, 2019 at 11:19 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
This sort of thing has pretty much always happened. I believe it is
just down to the designed-in unreliability of the current stats collection
mechanism. We might be able to get rid of it if we go over to
shared-memory stats, but I've yet to look at that patch :-(. In the
meantime I don't see any reason to think that anything's worse here
than it has been for many years.
Does it imply that the kernel dropped a UDP packet to localhost?
That's a possible explanation, anyway. The problem shows up seldom enough
that it's hard to say that conclusively. So *maybe* there's a bug here
we could actually fix, but again, without any way to repro it, it's hard
to say much.
regards, tom lane