Jonathan Gardner <jgardner (AT) jonathangardner (DOT) net> writes:
That's really bizarre. For awhile I thought you might have fmgroids.h
and fmgrtab.c generated from some pre-7.4-release version of pg_proc.h,
but that theory doesn't seem to hold water --- for instance your files
include box_send() but not box_recv(), which were added in the same
commit. I don't see a pattern to the functions you are missing. Anyone
have a theory?

In the absence of any brilliant insight, I'd suggest slogging through
Gen_fmgrtab.sh to try to narrow down where functions are getting lost
--- add code to save the various intermediate files, and see what's in
'em. If we knew exactly which step was losing the functions it'd be a
leg up.

I can't see that as a plausible answer. With all due respect to Perl,
it's neither more portable nor more bug-free than awk/sed.

We could fall back in that direction if we had to. But I'd like to
understand why we have to, first. Gen_fmgrtab.sh has worked on all our
supported platforms for a long time, and I'm disinclined to assume that
it's suddenly broken ... especially on what's presumably a modern
platform. I'm having a real problem with the idea that Fedora
incorporates a broken awk or sed.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 08 December 2003 9:33 pm, Tom Lane wrote:
I just did this. I am no awk or sed expert. I can't see any faults in the=
=20
script other than it is difficult to read. My only thought is that some of=
=20
the regex behavior has changed, but I can't identify anything. The regexes=
=20
used here are very standard.

Unfortunately, in testing the bugger, it accidentally worked. I find this=
=20
most disturbing. However, I was pleasantly surprised that it failed at=20
least one more time before working properly.

Chalk the cause of this bug up as high-energy particles striking the memory=
=20
chip in just the right place at just the right time.

The only other thing I think might affect it is the fact that I was=20
simultaneously compiling PostgreSQL 7.3.4, reading email, and downloading=
=20
stuff. Perhaps there is a strange race condition in the make process. Of=20
course, the recent power outage in the area (that didn't affect us)=20
might've been a cause as well.

I apologize that I couldn't ease your pain, Tom. I know how it feels to see=
=20
the same bug pop up occasionally, only to be solved by hitting the "Redo"=
=20
key.

- --=20
Jonathan Gardner
jgardner (AT) jonathangardner (DOT) net
Live Free, Use Linux!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/1XQJWgwF3QvpWNwRAi0FAKCkPV+yn0y3kNT3AoHy5TX9a0v6NA CaA7qI
PlIJfFguW4LNr+4RL535rIM=3D
=3DwWkP
-----END PGP SIGNATURE-----


---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Tom Lane wrote:
I was able to rebuild from source rpm on a Fedora machine without any
problem, so I don't think it's a case of wholesale breakage. It's not my
normal development machine, but I'll try compiling from source [...tries...]
Yup, I got a clean build from source with the following configure line:

../configure \
--prefix=/usr/local/pgsql-7.4 \
--with-pgport=55434 \
--with-perl \
--with-tcl \
--with-tclconfig=/usr/lib \
--without-tk \
--with-python \
--enable-nls \
--enable-debug \
--enable-cassert \
--enable-depend \
--with-openssl \
--with-pam \
--enable-integer-datetimes \
--with-krb5=/usr/kerberos \
--with-includes=/usr/include/et/

The only adjustment from my RH9 box was the last line. Without it
com_err.h wasn't being found.

Joe


---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo (AT) postgresql (DOT) org

Jonathan Gardner <jgardner (AT) jonathangardner (DOT) net> writes:
Weird; there's no obvious reason for the script to be nondeterministic.

The only idea I can think of is that you were almost out of /tmp space
and the missing data got lost because of lack of space to put it. I'm
not sure whether awk/sed/etc would detect write failures on stdout.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo (AT) postgresql (DOT) org