Re: Moving test_fsync to /contrib? - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Moving test_fsync to /contrib?
Date
Msg-id AANLkTi=gdN2dBZQK0RMJcx6hdOJCbTeC-kXbFuAc256o@mail.gmail.com
Whole thread Raw
In response to Re: Moving test_fsync to /contrib?  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Moving test_fsync to /contrib?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, Jan 17, 2011 at 11:47 AM, Bruce Momjian <bruce@momjian.us> wrote:
> Tom Lane wrote:
>> Robert Haas <robertmhaas@gmail.com> writes:
>> > On Mon, Jan 17, 2011 at 11:02 AM, Bruce Momjian <bruce@momjian.us> wrote:
>> >> Is there value in moving test_fsync to /contrib?
>>
>> > Why would we want to do that?
>>
>> So it would be built by default, installed under reasonable conditions,
>> and there would be a place to document it.  Where it is, it's not a
>> user-facing thing at all.
>
> I have cleaned up the code so it is reasonable to ship and use by
> end-users.  It is documented already where we mention setting
> wal_sync_method, but having it in src/tools really is a hinderance.
>
> It seems like /contrib would be more natural, no?  /bin seems like
> overkill because most people will not want to run it.  Most of /contrib
> is installed already by installers, I think.

At least on Red Hat, it is packaged separately.  So if you install
postgresql-server and postgresql-client you will not get things that
are only in contrib.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Moving test_fsync to /contrib?
Next
From: Andrew Dunstan
Date:
Subject: Re: Add support for logging the current role