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: | D960CB61B694CF459DCFB4B0128514C2049FCDCD@exadv11.host.magwien.gv.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Thom Brown | 2010-07-16 12:25:07 | Management of External Data (SQL/MED) in core? |
Previous Message | Tom Lane | 2010-07-14 22:04:47 | Re: see recovery_command |