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

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

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Dimitri Fontaine <dimitri@2ndQuadrant.fr>
Cc: Robert Haas <robertmhaas@gmail.com>, Andres Freund <andres@2ndquadrant.com>, Heikki Linnakangas <hlinnakangas@vmware.com>, pgsql-hackers@postgresql.org
Date: 2012-12-11T22:24:08Z
Lists: pgsql-hackers
Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
> Robert Haas <robertmhaas@gmail.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


Commits

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

  2. Rearrange storage of data in xl_running_xacts.

  3. Basic binary heap implementation.

  4. Embedded list interface

  5. Refactor xlog.c to create src/backend/postmaster/startup.c