Re: Problem building 9.0 Beta 3 US PDF file - Mailing list pgsql-docs

From Albe Laurenz
Subject Re: Problem building 9.0 Beta 3 US PDF file
Date
Msg-id D960CB61B694CF459DCFB4B0128514C2049FCDCD@exadv11.host.magwien.gv.at
Whole thread Raw
In response to Problem building 9.0 Beta 3 US PDF file  (Devrim GÜNDÜZ <devrim@gunduz.org>)
Responses Re: Problem building 9.0 Beta 3 US PDF file
List pgsql-docs
Tom Lane wrote:
> I find that removing the AIX-fixlevels table (and the two references to
> it) from installation.sgml makes the postgres-US.pdf build go through on
> my F-13 box.  This is pretty weird, since there's nothing obviously
> wrong with that table; and if there were something wrong with it, why
> doesn't it bother the postgres-A4.pdf build?  Seems like we must be
> looking at a strange toolchain bug.
>
> Now, ordinarily I wouldn't suggest removing information from the manual,
> but I'm not sure that that table is worth fighting the toolchain for.
> It was added here
> http://archives.postgresql.org/pgsql-committers/2009-06/msg00197.php
> on the basis of Laurenz Albe's suggestion here
> http://archives.postgresql.org/pgsql-hackers/2009-06/msg00884.php
> but I don't know how carefully that was researched.  I'm tempted to
> propose going back to the "use the latest fixpack" wording that was
> there before.
>
> Comments?  Can anyone else reproduce the behavior I'm seeing?

I created the table based on known AIX bugs that affect getaddrinfo,
and it's more than random numbers.

Maybe the problem would go away if the information were not in a table,
but in some other format, say, an unordered list.

But I also see no big problem with returning to "use the latest fixpack".
It is certainly a safe wording, although it will urge people to undergo
the painful procedure of an upgrade even if that is unnecessary.

Yours,
Laurenz Albe

pgsql-docs by date:

Previous
From: Tom Lane
Date:
Subject: Re: see recovery_command
Next
From: Thom Brown
Date:
Subject: Management of External Data (SQL/MED) in core?