pg.ddx.io pgsql-admin@postgresql.org mailing list archive
help / color / mirror / Atom feedmake installcheck failing for postgres_fdw
4+ messages / 2 participants
[nested] [flat]
* make installcheck failing for postgres_fdw
@ 2017-09-20 16:44 Natalie Wenz <nataliewenz@ebureau.com>
0 siblings, 1 reply; 4+ messages in thread
From: Natalie Wenz @ 2017-09-20 16:44 UTC (permalink / raw)
To: pgsql-admin
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 looking to 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 happened to 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* fail for 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 matter of the regression tests lagging behind, or should I be concerned? The regression.diffs files are not identical between versions, 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
inline patch 1: /tmp/postgresql-9.5.9/contrib/postgres_fdw/results/postgres_fdw.out (+19/-15 lines) download inline-1.patch
*** /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
* Re: make installcheck failing for postgres_fdw
@ 2017-09-20 18:00 Tom Lane <tgl@sss.pgh.pa.us>
parent: Natalie Wenz <nataliewenz@ebureau.com>
0 siblings, 1 reply; 4+ messages in thread
From: Tom Lane @ 2017-09-20 18:00 UTC (permalink / raw)
To: Natalie Wenz <nataliewenz@ebureau.com>; +Cc: 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 looking to 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 happened to 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 matter of the regression tests lagging behind, or should I be concerned? The regression.diffs files are not identical between versions, 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
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: make installcheck failing for postgres_fdw
@ 2017-09-20 18:53 Natalie Wenz <nataliewenz@ebureau.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 4+ messages in thread
From: Natalie Wenz @ 2017-09-20 18:53 UTC (permalink / raw)
To: pgsql-admin; +Cc: Tom Lane <tgl@sss.pgh.pa.us>
Thanks for your response!
I actually created a new database with initdb and started it without tuning anything just prior to running the installcheck each 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 my procedure, 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 looking to 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 happened to 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 matter of the regression tests lagging behind, or should I be concerned? The regression.diffs files are not identical between versions, 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
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: make installcheck failing for postgres_fdw
@ 2017-09-20 19:57 Tom Lane <tgl@sss.pgh.pa.us>
parent: Natalie Wenz <nataliewenz@ebureau.com>
0 siblings, 0 replies; 4+ messages in thread
From: Tom Lane @ 2017-09-20 19:57 UTC (permalink / raw)
To: Natalie Wenz <nataliewenz@ebureau.com>; +Cc: 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 installcheck each 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
^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2017-09-20 19:57 UTC | newest]
Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2017-09-20 16:44 make installcheck failing for postgres_fdw Natalie Wenz <nataliewenz@ebureau.com>
2017-09-20 18:00 ` Tom Lane <tgl@sss.pgh.pa.us>
2017-09-20 18:53 ` Natalie Wenz <nataliewenz@ebureau.com>
2017-09-20 19:57 ` Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox