Re: [COMMITTERS] pgsql: Move test_fsync to /contrib.

Move test_fsync to /contrib.

Branch
------
master

Details
-------
http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=606a3d54fcd053c31e52886f4c69848a68777480

Modified Files
--------------
contrib/pg_test_fsync/Makefile | 23 ++
contrib/pg_test_fsync/test_fsync.c | 549 ++++++++++++++++++++++++++++++++++++
doc/src/sgml/contrib.sgml | 1 +
doc/src/sgml/filelist.sgml | 1 +
doc/src/sgml/pgtestfsync.sgml | 70 +++++
src/tools/fsync/Makefile | 25 --
src/tools/fsync/README | 25 --
src/tools/fsync/test_fsync.c | 549 ------------------------------------
8 files changed, 644 insertions(+), 599 deletions(-)

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(at)dunslane(dot)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(at)dunslane(dot)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(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)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(at)hagander(dot)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(at)dunslane(dot)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