Re: Uh-oh: documentation PDF output no longer builds in HEAD - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Uh-oh: documentation PDF output no longer builds in HEAD
Date
Msg-id 7290.1447018196@sss.pgh.pa.us
Whole thread Raw
In response to Re: Uh-oh: documentation PDF output no longer builds in HEAD  (andres@anarazel.de (Andres Freund))
Responses Re: Uh-oh: documentation PDF output no longer builds in HEAD  (andres@anarazel.de (Andres Freund))
List pgsql-hackers
andres@anarazel.de (Andres Freund) writes:
> While taking pretty short of forever, postgres-US.pdf seems to build on
> my debian unstable as of 8d7396e509 + some additional docs. Is this
> dependant of what version of text you're using (plain tex, pdftex,
> xetex, whatnot)?

> postgres-US.log contains:
> 360764 strings out of 481710

Interesting.  They must have boosted the strings limit from 2^18 to 2^19.
According to what I've read, this is doable when compiling TeX from
source, but we can hardly expect users (or packagers) to do that if their
distribution hasn't built it that way.  (The 2^18 limit I'm seeing is with
RHEL6's tex package.  I'm currently downloading the Fedora rawhide package
to see if it's any better, but man that is one large package...)

BTW, I realized after poking around that the hack I put in back in 9.0
probably only eliminates about 5000 strings from the pool, because
it should save one string per \pagelabel entry added to the .aux
file, and there are less than 5000 such entries after a successful
build.  So that was a good quick-n-dirty fix but it's really only
scratching the surface of the problem: there are ~240000 other strings
getting made somewhere.  I wonder if a better answer is possible.
        regards, tom lane



pgsql-hackers by date:

Previous
From: andres@anarazel.de (Andres Freund)
Date:
Subject: Re: Uh-oh: documentation PDF output no longer builds in HEAD
Next
From: Robert Haas
Date:
Subject: Re: extend pgbench expressions with functions