Horton
Menu

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

Dimitri Fontaine <dimitri@2ndquadrant.fr>

View thread
From: Dimitri Fontaine <dimitri@2ndQuadrant.fr>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Andres Freund <andres@2ndquadrant.com>, Heikki Linnakangas <hlinnakangas@vmware.com>, pgsql-hackers@postgresql.org
Date: 2012-12-11T22:05:32Z
Lists: pgsql-hackers 
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.
Second, a lot of users won't install contribs in their production server
and will then miss the tool when they need it most. In some places
getting new software installed on a certified production setup is not
easy.

I would agree to get that piece in contrib if we were to work again on
separating contribs into "production monitoring and diagnosis",
"production ready extra" (hstore) and the rest, basically.

Regards,
-- 
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support

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