Skip site navigation (1) Skip section navigation (2)

Re: Problem building 9.0 Beta 3 US PDF file

From: "Albe Laurenz" <laurenz(dot)albe(at)wien(dot)gv(dot)at>
To: "Tom Lane *EXTERN*" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Devrim GÜNDÜZ <devrim(at)gunduz(dot)org>,"pgsql-docs" <pgsql-docs(at)postgresql(dot)org>
Subject: Re: Problem building 9.0 Beta 3 US PDF file
Date: 2010-07-16 09:58:55
Message-ID: (view raw, whole thread or download thread mbox)
Lists: 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
> on the basis of Laurenz Albe's suggestion here
> 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.

Laurenz Albe

In response to


pgsql-docs by date

Next:From: Thom BrownDate: 2010-07-16 12:25:07
Subject: Management of External Data (SQL/MED) in core?
Previous:From: Tom LaneDate: 2010-07-14 22:04:47
Subject: Re: see recovery_command

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group