Обсуждение: [ADMIN] make installcheck failing for postgres_fdw
Hi all,
I have a server that has 9.4.4 with the postgres_fdw module successfully running for the past couple of years. I am
lookingto update it, so I'm testing the procedure on a test server, and have been running into trouble. Out of
curiosity,I tried installing it with 10beta4, but the gmake installcheck failed. So I tried with 9.6.2 (because it
happenedto be on the machine) and it still failed. I tried 9.6.5--and it also failed.
I decided to try installing 9.4.4, since it hadn't failed once upon a time, and to rule out differences in OS being the
cause(original server is running FreeBSD 9, test server is running FreeBSD 11), and the gmake installcheck did *not*
failfor that version on my test server. Great. I repeated my procedure for 9.4.14, and that also worked. I moved on to
9.5.9,and the gmake installcheck failed again.
gmake installcheck succeeds:
9.4.4
9.4.14
gmake installcheck fails:
9.5.9
9.6.2
9.6.5
10beta4
Note that the installation doesn't seem to have any issue, just the installcheck. Is this a known issue? Is it just a
matterof the regression tests lagging behind, or should I be concerned? The regression.diffs files are not identical
betweenversions, but they only seem to contain query plans with differences.
Thank you!
Natalie
e.g.:
cat /tmp/postgresql-9.5.9/contrib/postgres_fdw/regression.diffs
*** /tmp/postgresql-9.5.9/contrib/postgres_fdw/expected/postgres_fdw.out Mon Aug 28 16:24:28 2017
--- /tmp/postgresql-9.5.9/contrib/postgres_fdw/results/postgres_fdw.out Tue Sep 19 23:36:12 2017
***************
*** 3522,3545 **** Update on public.bar Foreign Update on public.bar2 Remote SQL: UPDATE public.loct2 SET f2
=$2 WHERE ctid = $1
! -> Hash Join Output: bar.f1, (bar.f2 + 100), bar.ctid, (ROW(foo.f1))
! Hash Cond: (foo.f1 = bar.f1)
! -> Append
! -> Seq Scan on public.foo
! Output: ROW(foo.f1), foo.f1
! -> Foreign Scan on public.foo2
! Output: ROW(foo2.f1), foo2.f1
! Remote SQL: SELECT f1 FROM public.loct1
! -> Seq Scan on public.foo foo_1
! Output: ROW((foo_1.f1 + 3)), (foo_1.f1 + 3)
! -> Foreign Scan on public.foo2 foo2_1
! Output: ROW((foo2_1.f1 + 3)), (foo2_1.f1 + 3)
! Remote SQL: SELECT f1 FROM public.loct1
! -> Hash Output: bar.f1, bar.f2, bar.ctid -> Seq Scan on public.bar
Output: bar.f1, bar.f2, bar.ctid -> Merge Join Output: bar2.f1, (bar2.f2 + 100), bar2.f3,
bar2.ctid,(ROW(foo.f1)) Merge Cond: (bar2.f1 = foo.f1)
--- 3522,3549 ---- Update on public.bar Foreign Update on public.bar2 Remote SQL: UPDATE public.loct2 SET f2
=$2 WHERE ctid = $1
! -> Merge Join Output: bar.f1, (bar.f2 + 100), bar.ctid, (ROW(foo.f1))
! Merge Cond: (bar.f1 = foo.f1)
! -> Sort Output: bar.f1, bar.f2, bar.ctid
+ Sort Key: bar.f1 -> Seq Scan on public.bar Output: bar.f1,
bar.f2,bar.ctid
+ -> Sort
+ Output: (ROW(foo.f1)), foo.f1
+ Sort Key: foo.f1
+ -> Append
+ -> Seq Scan on public.foo
+ Output: ROW(foo.f1), foo.f1
+ -> Foreign Scan on public.foo2
+ Output: ROW(foo2.f1), foo2.f1
+ Remote SQL: SELECT f1 FROM public.loct1
+ -> Seq Scan on public.foo foo_1
+ Output: ROW((foo_1.f1 + 3)), (foo_1.f1 + 3)
+ -> Foreign Scan on public.foo2 foo2_1
+ Output: ROW((foo2_1.f1 + 3)), (foo2_1.f1 + 3)
+ Remote SQL: SELECT f1 FROM public.loct1 -> Merge Join Output: bar2.f1,
(bar2.f2+ 100), bar2.f3, bar2.ctid, (ROW(foo.f1)) Merge Cond: (bar2.f1 = foo.f1)
***************
*** 3563,3569 **** -> Foreign Scan on public.foo2 foo2_1 Output:
ROW((foo2_1.f1+ 3)), (foo2_1.f1 + 3) Remote SQL: SELECT f1 FROM public.loct1
! (45 rows) update bar set f2 = f2 + 100 from
--- 3567,3573 ---- -> Foreign Scan on public.foo2 foo2_1 Output:
ROW((foo2_1.f1+ 3)), (foo2_1.f1 + 3) Remote SQL: SELECT f1 FROM public.loct1
! (49 rows) update bar set f2 = f2 + 100 from
======================================================================
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
Natalie Wenz <nataliewenz@ebureau.com> writes:
> I have a server that has 9.4.4 with the postgres_fdw module successfully running for the past couple of years. I am
lookingto update it, so I'm testing the procedure on a test server, and have been running into trouble. Out of
curiosity,I tried installing it with 10beta4, but the gmake installcheck failed. So I tried with 9.6.2 (because it
happenedto be on the machine) and it still failed. I tried 9.6.5--and it also failed.
> Note that the installation doesn't seem to have any issue, just the installcheck. Is this a known issue? Is it just a
matterof the regression tests lagging behind, or should I be concerned? The regression.diffs files are not identical
betweenversions, but they only seem to contain query plans with differences.
If you're running with any non-default planner settings in your
installation, this would likely be unsurprising. I'd try "make check",
which is more self-contained, before concluding you have a problem.
regards, tom lane
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
Thanks for your response! I actually created a new database with initdb and started it without tuning anything just prior to running the installcheckeach time. However, I did start fresh and try just the make check anyway: cd /tmp/postgresql-9.5.9/ ./configure --with-segsize=10 --with-blocksize=32 --with-pam --with-libraries=/usr/local/lib --with-includes=/usr/local/include make -j8 cd contrib/postgres_fdw/ gmake gmake check And it did fail again: gmake: *** [../../src/makefiles/pgxs.mk:280: check] Error 1 The regression.diffs file was identical to what I previously attached (besides the timestamps). Is there an issue with myprocedure, maybe? (Though the same procedure worked with 9.4.4 and 9.4.9.) > On Sep 20, 2017, at 1:00 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Natalie Wenz <nataliewenz@ebureau.com> writes: >> I have a server that has 9.4.4 with the postgres_fdw module successfully running for the past couple of years. I am lookingto update it, so I'm testing the procedure on a test server, and have been running into trouble. Out of curiosity,I tried installing it with 10beta4, but the gmake installcheck failed. So I tried with 9.6.2 (because it happenedto be on the machine) and it still failed. I tried 9.6.5--and it also failed. > >> Note that the installation doesn't seem to have any issue, just the installcheck. Is this a known issue? Is it just amatter of the regression tests lagging behind, or should I be concerned? The regression.diffs files are not identical betweenversions, but they only seem to contain query plans with differences. > > If you're running with any non-default planner settings in your > installation, this would likely be unsurprising. I'd try "make check", > which is more self-contained, before concluding you have a problem. > > regards, tom lane > > > -- > Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-admin -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
Natalie Wenz <nataliewenz@ebureau.com> writes:
> I actually created a new database with initdb and started it without tuning anything just prior to running the
installcheckeach time. However, I did start fresh and try just the make check anyway:
> cd /tmp/postgresql-9.5.9/
> ./configure --with-segsize=10 --with-blocksize=32 --with-pam --with-libraries=/usr/local/lib
--with-includes=/usr/local/include
Oh. It's likely the --with-blocksize=32 that is causing you to get
different results. That will affect cost estimates ...
regards, tom lane
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin