pgsql: Move test_fsync to /contrib.

On 01/21/2011 12:48 PM, Bruce Momjian wrote:

Move test_fsync to /contrib.

This appears to have broken Solaris, Unixware and MSVC builds.

Here's the error on Solaris:

gmake[1]: Entering directory `/export/home/dpage/pgbuildfarm/moa/HEAD/pgsql.4167/contrib/pg_test_fsync'
cc -Xa -m64 -xarch=native -xdepend -xO3 -xprefetch=auto,explicit -g -I. -I. -I../../src/include -c -o pg_test_fsync.o pg_test_fsync.c
cc -Xa -m64 -xarch=native -xdepend -xO3 -xprefetch=auto,explicit -g pg_test_fsync.o -L../../src/port -Wl,-R'/export/home/dpage/pgbuildfarm/moa/HEAD/inst/lib' -lpgport -lpam -lgss -lz -lnsl -lsocket -lm -o pg_test_fsync
Undefined first referenced
symbol in file
CurrentMemoryContext pg_test_fsync.o
ld: fatal: Symbol referencing errors. No output written to pg_test_fsync

Why does pg_test_fsync.c include postgres.h? Shouldn't it use postgres_fe.h?

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:

Why does pg_test_fsync.c include postgres.h? Shouldn't it use postgres_fe.h?

I had tried that, actually, but it fails because the other include files
test_fsync needs are backend-specific. We may have to refactor those
include files so that the stuff test_fsync actually needs is includable
with less context required. I thought I'd wait on that project till we
had a full cycle from the buildfarm and could see what other portability
issues surface.

regards, tom lane

Andrew Dunstan <andrew@dunslane.net> writes:

This appears to have broken Solaris, Unixware and MSVC builds.

BTW, the MSVC problem appears to stem from failure to include libpgport
when linking pg_test_fsync. I imagine this requires a fix in the MSVC
build scripts.

regards, tom lane

On Sat, Jan 22, 2011 at 18:12, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

This appears to have broken Solaris, Unixware and MSVC builds.

BTW, the MSVC problem appears to stem from failure to include libpgport
when linking pg_test_fsync.  I imagine this requires a fix in the MSVC
build scripts.

Yup, fixed and pushed.

I still get:
pg_test_fsync.c
1>.\contrib\pg_test_fsync\pg_test_fsync.c(398) : warning C4101: 'ops'
: unreferenced local variable
1>.\contrib\pg_test_fsync\pg_test_fsync.c(398) : warning C4101:
'writes' : unreferenced local variable
1>.\contrib\pg_test_fsync\pg_test_fsync.c(398) : warning C4101:
'tmpfile' : unreferenced local variable

ISTM that the declaration of variables should be moved inside the #ifdef, no?

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

Magnus Hagander <magnus@hagander.net> writes:

I still get:
pg_test_fsync.c
1>.\contrib\pg_test_fsync\pg_test_fsync.c(398) : warning C4101: 'ops'
: unreferenced local variable
1>.\contrib\pg_test_fsync\pg_test_fsync.c(398) : warning C4101:
'writes' : unreferenced local variable
1>.\contrib\pg_test_fsync\pg_test_fsync.c(398) : warning C4101:
'tmpfile' : unreferenced local variable

ISTM that the declaration of variables should be moved inside the #ifdef, no?

Yeah, I independently came to the same conclusion ...

regards, tom lane

I wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

Why does pg_test_fsync.c include postgres.h? Shouldn't it use postgres_fe.h?

I had tried that, actually, but it fails because the other include files
test_fsync needs are backend-specific. We may have to refactor those
include files so that the stuff test_fsync actually needs is includable
with less context required.

On closer inspection, test_fsync doesn't even need the include files
that caused the problem. I think my latest commit will fix everything.

regards, tom lane