Josh Berkus wrote:
On 1/20/11 6:15 AM, Robert Haas wrote:
On Thu, Jan 20, 2011 at 9:13 AM, Bruce Momjian br...@momjian.us wrote:
OK, I am ready to move test_fsync to /contrib. Is pg_test_fsync the
best name? pg_check_fsync? pg_fsync_performance? pg_verify_fsync?
I don't see too
Greg Smith wrote:
Alvaro Herrera wrote:
I don't understand why it would be overkill. Are you saying people
would complain because you installed a 25 kB executable that they might
not want to use? Just for fun I checked /usr/bin and noticed that I
have a pandoc executable, weighing 17
On Thu, Jan 20, 2011 at 9:13 AM, Bruce Momjian br...@momjian.us wrote:
OK, I am ready to move test_fsync to /contrib. Is pg_test_fsync the
best name? pg_check_fsync? pg_fsync_performance? pg_verify_fsync?
I don't see too much reason to rename it more than necessary, so how
about
Robert Haas robertmh...@gmail.com writes:
On Thu, Jan 20, 2011 at 9:13 AM, Bruce Momjian br...@momjian.us wrote:
OK, I am ready to move test_fsync to /contrib. Is pg_test_fsync the
best name? pg_check_fsync? pg_fsync_performance? pg_verify_fsync?
I don't see too much reason to rename it
On 1/20/11 6:15 AM, Robert Haas wrote:
On Thu, Jan 20, 2011 at 9:13 AM, Bruce Momjian br...@momjian.us wrote:
OK, I am ready to move test_fsync to /contrib. Is pg_test_fsync the
best name? pg_check_fsync? pg_fsync_performance? pg_verify_fsync?
I don't see too much reason to rename it
On Mon, Jan 17, 2011 at 11:02 AM, Bruce Momjian br...@momjian.us wrote:
Is there value in moving test_fsync to /contrib?
Why would we want to do that?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list
Robert Haas wrote:
On Mon, Jan 17, 2011 at 11:02 AM, Bruce Momjian br...@momjian.us wrote:
Is there value in moving test_fsync to /contrib?
Why would we want to do that?
If we expect users to run the tool to best choose the best
wal_sync_method.
--
Bruce Momjian br...@momjian.us
On Mon, Jan 17, 2011 at 11:16 AM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Mon, Jan 17, 2011 at 11:02 AM, Bruce Momjian br...@momjian.us wrote:
Is there value in moving test_fsync to /contrib?
Why would we want to do that?
If we expect users to run the tool to best
Robert Haas robertmh...@gmail.com writes:
On Mon, Jan 17, 2011 at 11:02 AM, Bruce Momjian br...@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
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Jan 17, 2011 at 11:02 AM, Bruce Momjian br...@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
On Mon, Jan 17, 2011 at 11:47 AM, Bruce Momjian br...@momjian.us wrote:
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Jan 17, 2011 at 11:02 AM, Bruce Momjian br...@momjian.us wrote:
Is there value in moving test_fsync to /contrib?
Why would we want to do that?
So it
Excerpts from Bruce Momjian's message of lun ene 17 13:47:40 -0300 2011:
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.
I don't understand why it would be
2011/1/17 Bruce Momjian br...@momjian.us:
Robert Haas wrote:
On Mon, Jan 17, 2011 at 11:02 AM, Bruce Momjian br...@momjian.us wrote:
Is there value in moving test_fsync to /contrib?
Why would we want to do that?
If we expect users to run the tool to best choose the best
wal_sync_method.
Robert Haas robertmh...@gmail.com writes:
On Mon, Jan 17, 2011 at 11:47 AM, Bruce Momjian br...@momjian.us wrote:
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
On Mon, Jan 17, 2011 at 12:05 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Jan 17, 2011 at 11:47 AM, Bruce Momjian br...@momjian.us wrote:
It seems like /contrib would be more natural, no? /bin seems like
overkill because most people will not want
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Jan 17, 2011 at 11:47 AM, Bruce Momjian br...@momjian.us wrote:
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
Robert Haas wrote:
On Mon, Jan 17, 2011 at 12:05 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Jan 17, 2011 at 11:47 AM, Bruce Momjian br...@momjian.us wrote:
It seems like /contrib would be more natural, no? ?/bin seems like
overkill because
Robert Haas robertmh...@gmail.com writes:
On Mon, Jan 17, 2011 at 12:05 PM, Tom Lane t...@sss.pgh.pa.us wrote:
On Red Hat, it is not packaged at all (at least not by me), and won't
be unless it goes into contrib. I don't believe it belongs in the
base package.
I confess to some confusion
Bruce Momjian br...@momjian.us writes:
Robert Haas wrote:
I confess to some confusion about what things belong where.
I was suggesting /contrib because it seems to be of limited usefulness.
I assume people want pg_upgrade to stay in /contrib for the same reason.
pg_upgrade is a different
On Mon, Jan 17, 2011 at 12:48 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Jan 17, 2011 at 12:05 PM, Tom Lane t...@sss.pgh.pa.us wrote:
On Red Hat, it is not packaged at all (at least not by me), and won't
be unless it goes into contrib. I don't
Also, it's not going to get packaged at all unless it gets renamed to
something less generic, maybe pg_test_fsync; I'm not going to risk the
oppobrium of sticking something named test_fsync into /usr/bin.
Moving to contrib would be a good opportunity to fix the name.
+1.
It would be a lot
Alvaro Herrera wrote:
I don't understand why it would be overkill. Are you saying people
would complain because you installed a 25 kB executable that they might
not want to use? Just for fun I checked /usr/bin and noticed that I
have a pandoc executable, weighing 17 MB, that I have never used
22 matches
Mail list logo
