On 2013-12-11 10:07:19 -0500, Tom Lane wrote:
> Andres Freund <and...@2ndquadrant.com> writes:
> > On 2013-12-10 19:55:12 -0500, Tom Lane wrote:
> >> We need a more consistent strategy for this :-(
>
> > Agreed, although I have no clue how it should look like. As a further
> > datapoint I'll add that installcheck already regularly fails in HEAD if
> > you have a HS standby connected via SR and hot_standby_feedback=on on
> > the standby. Some plans just change from index(only) scans to sequential
> > scans, presumably because of the lower xmin horizon changed the
> > stats. Since there's nothing running on the standby in those cases,
> > there has to be a pretty damn tiny window here somewhere.
>
> The case in create_index does a "vacuum analyze tenk1" and expects
> to get an index-only scan in the very next SQL command. So any delay
> in considering the table all-visible could break that test. I'm not
> sure if that's what you're talking about though. We could easily
> create some more delay for that case, for instance by moving the
> vacuum step to copy.sql as I was idly speculating about upthread.
> Do you remember offhand where the failures are?
No, but they are easy enough to reproduce. Out of 10 runs, I've attached
the one with the most failures and checked that it seems to contain all
the failures from other runs. All of them probably could be fixed by
moving things around, but I am not sure how maintainable that approach
is :/
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--- /home/andres/src/postgresql/src/test/regress/expected/create_index.out
2013-12-08 19:57:01.646559353 +0100
+++
/home/andres/build/postgres/dev-assert/vpath/src/test/regress/results/create_index.out
2013-12-11 16:54:00.043641015 +0100
@@ -2720,11 +2720,15 @@
SELECT unique1 FROM tenk1
WHERE unique1 IN (1,42,7)
ORDER BY unique1;
- QUERY PLAN
--------------------------------------------------------
- Index Only Scan using tenk1_unique1 on tenk1
- Index Cond: (unique1 = ANY ('{1,42,7}'::integer[]))
-(2 rows)
+ QUERY PLAN
+-------------------------------------------------------------------
+ Sort
+ Sort Key: unique1
+ -> Bitmap Heap Scan on tenk1
+ Recheck Cond: (unique1 = ANY ('{1,42,7}'::integer[]))
+ -> Bitmap Index Scan on tenk1_unique1
+ Index Cond: (unique1 = ANY ('{1,42,7}'::integer[]))
+(6 rows)
SELECT unique1 FROM tenk1
WHERE unique1 IN (1,42,7)
======================================================================
--- /home/andres/src/postgresql/src/test/regress/expected/subselect.out
2013-12-11 16:42:18.791039738 +0100
+++
/home/andres/build/postgres/dev-assert/vpath/src/test/regress/results/subselect.out
2013-12-11 16:54:06.823376218 +0100
@@ -727,7 +727,7 @@
-> Seq Scan on public.tenk1 b
Output: b.unique1, b.unique2, b.two, b.four, b.ten, b.twenty,
b.hundred, b.thousand, b.twothousand, b.fivethous, b.tenthous, b.odd, b.even,
b.stringu1, b.stringu2, b.string4
SubPlan 1
- -> Index Only Scan using tenk1_unique1 on public.tenk1 a
+ -> Seq Scan on public.tenk1 a
Output: a.unique1
(10 rows)
======================================================================
--- /home/andres/src/postgresql/src/test/regress/expected/join.out
2013-12-08 19:57:01.649892559 +0100
+++
/home/andres/build/postgres/dev-assert/vpath/src/test/regress/results/join.out
2013-12-11 16:54:08.439979745 +0100
@@ -3354,16 +3354,16 @@
explain (costs off)
select count(*) from tenk1 a,
tenk1 b join lateral (values(a.unique1)) ss(x) on b.unique2 = ss.x;
- QUERY PLAN
-------------------------------------------------------------------
+ QUERY PLAN
+-----------------------------------------------------
Aggregate
-> Hash Join
Hash Cond: ("*VALUES*".column1 = b.unique2)
-> Nested Loop
- -> Index Only Scan using tenk1_unique1 on tenk1 a
+ -> Seq Scan on tenk1 a
-> Values Scan on "*VALUES*"
-> Hash
- -> Index Only Scan using tenk1_unique2 on tenk1 b
+ -> Seq Scan on tenk1 b
(8 rows)
select count(*) from tenk1 a,
======================================================================
--- /home/andres/src/postgresql/src/test/regress/expected/rowtypes.out
2013-12-08 19:14:10.614689754 +0100
+++
/home/andres/build/postgres/dev-assert/vpath/src/test/regress/results/rowtypes.out
2013-12-11 16:54:31.072429133 +0100
@@ -240,11 +240,15 @@
select thousand, tenthous from tenk1
where (thousand, tenthous) >= (997, 5000)
order by thousand, tenthous;
- QUERY PLAN
------------------------------------------------------------
- Index Only Scan using tenk1_thous_tenthous on tenk1
- Index Cond: (ROW(thousand, tenthous) >= ROW(997, 5000))
-(2 rows)
+ QUERY PLAN
+-----------------------------------------------------------------------
+ Sort
+ Sort Key: thousand, tenthous
+ -> Bitmap Heap Scan on tenk1
+ Recheck Cond: (ROW(thousand, tenthous) >= ROW(997, 5000))
+ -> Bitmap Index Scan on tenk1_thous_tenthous
+ Index Cond: (ROW(thousand, tenthous) >= ROW(997, 5000))
+(6 rows)
select thousand, tenthous from tenk1
where (thousand, tenthous) >= (997, 5000)
======================================================================
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
