pg.ddx.io  pgsql-admin@postgresql.org mailing list archive  
help / color / mirror / Atom feed
make 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>
  2017-09-20 18:00 ` Re: make installcheck failing for postgres_fdw Tom Lane <tgl@sss.pgh.pa.us>
  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
====================================================================== -- 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 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   ` Re: make installcheck failing for postgres_fdw 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 16:44 make installcheck failing for postgres_fdw Natalie Wenz <nataliewenz@ebureau.com>
  2017-09-20 18:00 ` Re: make installcheck failing for postgres_fdw Tom Lane <tgl@sss.pgh.pa.us>
@ 2017-09-20 18:53   ` Natalie Wenz <nataliewenz@ebureau.com>
  2017-09-20 19:57     ` Re: make installcheck failing for postgres_fdw 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 16:44 make installcheck failing for postgres_fdw Natalie Wenz <nataliewenz@ebureau.com>
  2017-09-20 18:00 ` Re: make installcheck failing for postgres_fdw Tom Lane <tgl@sss.pgh.pa.us>
  2017-09-20 18:53   ` Re: make installcheck failing for postgres_fdw Natalie Wenz <nataliewenz@ebureau.com>
@ 2017-09-20 19:57     ` Tom Lane <tgl@sss.pgh.pa.us>
  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