Re: Re: [PATCH 02/14] Add support for a generic wal reading facility dubbed XLogReader

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Re: [PATCH 02/14] Add support for a generic wal reading facility dubbed XLogReader
Date: 2012-12-11 22:24:08
Message-ID: 24534.1355264648@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> writes:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> I think I'm with Heikki on this one. Dumping xlog data is useful, but
>> it's really for developers and troubleshooters, not something we
>> expect people to do on a regular basis, so contrib seems appropriate.

> There are two downsides for contrib rather than src/bin. First,
> maintainance and user trust are easier done and achieved in src/bin.

User trust, maybe, but the "maintenance" argument seems bogus.
We ship contrib on the same release schedule as core.

> Second, a lot of users won't install contribs in their production server
> and will then miss the tool when they need it most.

TBH, I don't believe that ordinary users will need this tool at all,
ever, and thus I don't want it in src/bin/. From a packaging standpoint
it will be a lot easier if it's in contrib ... otherwise I'll probably
have to invent some new sub-RPM along the lines of postgresql-extras
so as to avoid bloating the core server package.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dimitri Fontaine 2012-12-11 22:43:10 Re: pg_dump cosmetic problem while dumping/restoring rules
Previous Message Dimitri Fontaine 2012-12-11 22:05:32 Re: Re: [PATCH 02/14] Add support for a generic wal reading facility dubbed XLogReader