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

Dimitri Fontaine <dimitri@2ndquadrant.fr>

From: Dimitri Fontaine <dimitri@2ndQuadrant.fr>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>, Andres Freund <andres@2ndquadrant.com>, Heikki Linnakangas <hlinnakangas@vmware.com>, pgsql-hackers@postgresql.org
Date: 2012-12-11T22:51:25Z
Lists: pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes:
> User trust, maybe, but the "maintenance" argument seems bogus.
> We ship contrib on the same release schedule as core.

I meant maintenance as in updating the code when it needs to be, I'm not
sure contrib systematically receives the same careness as core. I have
no data to back my feeling, though.

> 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.

Oh. I didn't know that the server package would be considered bloated by
anyone and that would impact the way to ship our binaries.

What about splitting contrib *officially* then, not just in your RH
packages, and have postgresql-server-extra-diagnosis, -extra-data-types
and -contrib with the things you tipically don't want in production?

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