Re: [HACKERS] Moving test_fsync to /contrib?
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 much reason to rename it more than necessary, so how about pg_test_fsync? +1. OK, src/tools/test_fsync moved to contrib/pg_test_fsync. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Moving test_fsync to /contrib?
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 MB, that I have never used and I have no idea what is it for. It's for converting between the various types of text-like markup, i.e. reST, LaTex, Markdown, etc. Anyway, just because the rest of the world has no standards anymore doesn't mean we shouldn't. The changes Bruce has made recently have gotten this tool to where its output is starting to be readable and reliable. The sort of people who want to run this will certainly be fine with installing contrib to do it, because they may want to have things like pgbench too. There's really not enough demand for this to pollute the default server install footprint with any overhead from this tool, either in bytes or increased tool name squatting. And the fact that it's still a little rough around the edges nudges away from the standard server package too. Install in contrib as pg_test_fsync and I think you'll achieve the optimal subset of people who can be made happy here. Not having it packaged at all before wasn't a big deal, because it was so hard to collect good data from only developer-level people were doing it anyway. Now that it is starting to be more useful in that role for less experienced users, we need to make it easier for more people to run it, to collect feedback toward further improving its quality. 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? -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Moving test_fsync to /contrib?
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 pg_test_fsync? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Moving test_fsync to /contrib?
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 more than necessary, so how about pg_test_fsync? Yeah, there's no reason to try to confuse people about whether it's the same program or not. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Moving test_fsync to /contrib?
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 more than necessary, so how about pg_test_fsync? +1. -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Moving test_fsync to /contrib?
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 (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Moving test_fsync to /contrib?
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.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Moving test_fsync to /contrib?
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 choose the best wal_sync_method. I don't see how moving it from src/tools to contrib is going to make that happen more often. src/tools to src/bin might have that effect. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Moving test_fsync to /contrib?
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 to document it. Where it is, it's not a user-facing thing at all. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Moving test_fsync to /contrib?
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 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. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Moving test_fsync to /contrib?
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 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Moving test_fsync to /contrib?
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 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 and I have no idea what is it for. -- Álvaro Herrera alvhe...@commandprompt.com The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Moving test_fsync to /contrib?
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. +1 to move it to contrib/ -- Bruce Momjian br...@momjian.us http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Cédric Villemain 2ndQuadrant http://2ndQuadrant.fr/ PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Moving test_fsync to /contrib?
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 think. At least on Red Hat, it is packaged separately. 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. 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. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Moving test_fsync to /contrib?
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 to run it. Most of /contrib is installed already by installers, I think. At least on Red Hat, it is packaged separately. 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 about what things belong where. Is contrib the right place for this because we think it's half-baked, or because we think most people won't use it, or just because we're violently allergic to adding stuff to src/bin, or what? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Moving test_fsync to /contrib?
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 by installers, I think. At least on Red Hat, it is packaged separately. 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. 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. Agreed on the need for a name change. /contrib or /bin are fine with me. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Moving test_fsync to /contrib?
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 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. 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 about what things belong where. Is contrib the right place for this because we think it's half-baked, or because we think most people won't use it, or just because we're violently allergic to adding stuff to src/bin, or what? 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. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Moving test_fsync to /contrib?
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 about what things belong where. Is contrib the right place for this because we think it's half-baked, or because we think most people won't use it, or just because we're violently allergic to adding stuff to src/bin, or what? The first two, if you ask me. And there's another point: I disagree with the assumption that platform-specific packagings will or should include test_fsync by default. It'd be better for the packager to make a platform-specific choice of default for the users. I don't mind too much putting it into a secondary subpackage such as postgresql-contrib, but you won't be seeing it in postgresql-server. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Moving test_fsync to /contrib?
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 issue, really. I think it's in contrib because we don't trust it fully and don't want to promise that it will work in every single future release anyway. But even if we moved it to core, it will always be a special case for packagers: not only is it not appropriate to put it in the base package, it's not useful to package it at all unless you also provide a copy of a back-rev postmaster. So at least for my money it will always be part of its own special subpackage postgresql-upgrade. (BTW, I just recently got round to making that work for Fedora.) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Moving test_fsync to /contrib?
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 believe it belongs in the base package. I confess to some confusion about what things belong where. Is contrib the right place for this because we think it's half-baked, or because we think most people won't use it, or just because we're violently allergic to adding stuff to src/bin, or what? The first two, if you ask me. And there's another point: I disagree with the assumption that platform-specific packagings will or should include test_fsync by default. It'd be better for the packager to make a platform-specific choice of default for the users. I don't mind too much putting it into a secondary subpackage such as postgresql-contrib, but you won't be seeing it in postgresql-server. I see. Well, that seems reasonable. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Moving test_fsync to /contrib?
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 easier to tell people on -performance to use this if it was in contrib, for that matter. Go to *what* directory? -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Moving test_fsync to /contrib?
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 and I have no idea what is it for. It's for converting between the various types of text-like markup, i.e. reST, LaTex, Markdown, etc. Anyway, just because the rest of the world has no standards anymore doesn't mean we shouldn't. The changes Bruce has made recently have gotten this tool to where its output is starting to be readable and reliable. The sort of people who want to run this will certainly be fine with installing contrib to do it, because they may want to have things like pgbench too. There's really not enough demand for this to pollute the default server install footprint with any overhead from this tool, either in bytes or increased tool name squatting. And the fact that it's still a little rough around the edges nudges away from the standard server package too. Install in contrib as pg_test_fsync and I think you'll achieve the optimal subset of people who can be made happy here. Not having it packaged at all before wasn't a big deal, because it was so hard to collect good data from only developer-level people were doing it anyway. Now that it is starting to be more useful in that role for less experienced users, we need to make it easier for more people to run it, to collect feedback toward further improving its quality. -- Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us PostgreSQL 9.0 High Performance: http://www.2ndQuadrant.com/books -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
