Horton

Re: [v9.1] sepgsql - userspace access vector cache

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Kohei KaiGai <kaigai@kaigai.gr.jp>, Kohei Kaigai <Kohei.Kaigai@emea.nec.com>, Yeb Havinga <yebhavinga@gmail.com>, PgHacker <pgsql-hackers@postgresql.org>
Date: 2011-08-19T15:26:04Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Remove the limit on the number of entries allowed in catcaches, and

Robert Haas <robertmhaas@gmail.com> writes:
> On further review, if the initial configure was done without
> --with-libxml, xml2 is doomed anyway.

True, but it's still possible to build a shlib that will then not work.
I just did, after manually supplying the right -I switch:

make PROFILE=-I/usr/include/libxml2

Now admittedly a clueless person would be unlikely to know to do that,
but if his libxml installation were arranged so that no special -I
switch was needed (unlike the Fedora packaging), it'd be more likely
that this could happen.

> This probably explains why no one's complained about this before, and
> I think the appropriate fix is to change just sepgsql.  I would like
> to back-patch that (one-line) change into 9.1 as well, to eliminate
> this as a foot-gun for anyone who may be packaging that module for the
> first time.

No objection to fixing or backpatching this, but I'm not seeing the
argument for treating this module differently from contrib/xml2.  If you
believe that someone will try to manually build in contrib/sepgsql after
having failed to configure correctly, why do you not believe that for
xml2?

			regards, tom lane