Обсуждение: [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