moving from contrib to bin
Let's take another crack at moving stuff out of contrib. Nobody likes
contrib. The task is only finding something that most people like better.
Last time this was attempted, the discussion got lost in exactly which
extensions are worthy enough to be considered official or something like
that. I want to dodge that here by starting at the opposite end:
1. move programs to src/bin/
2. move test things to src/test/ (I had that in my notes, but someone
already did that, so the stars must be aligned.)
3. deal with extensions later
Here are the contrib programs:
oid2name
pg_archivecleanup
pg_standby
pg_test_fsync
pg_test_timing
pg_upgrade
pg_xlogdump
pgbench
vacuumlo
The proposal would basically be to mv contrib/$x src/bin/$x and also
move the reference pages in the documentation.
We could consider alternative arrangements, if there is interest, such
as moving vacuumlo to scripts or moving pg_archivecleanup and pg_standby
into one directory. It doesn't matter very much to me.
There is precedent for this: Some time ago we moved reindexdb from
contrib to scripts.
Besides moving things out of contrib, there is also a practical
motivation for this. Putting both client and server programs into
contrib creates issues for packagers. One would have to create a
separate -contrib-client package to package this properly. Not to
mention packaging a bunch of unrelated extensions with these programs.
If we make these normal programs in src/bin/, packagers can put them
into the normal -client and -server packages, and everything will fall
into place.
Besides, a number of packagers have been treating pg_upgrade specially
and moved it out of contrib, so this would just be catching up with
reality a bit.
Comments?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
Last time this was attempted, the discussion got lost in exactly which
extensions are worthy enough to be considered official or something like
that. I want to dodge that here by starting at the opposite end:
1. move programs to src/bin/
Here are the contrib programs:
oid2name
pg_archivecleanup
pg_standby
pg_test_fsync
pg_test_timing
pg_upgrade
pg_xlogdump
pgbench
vacuumlo
The proposal would basically be to mv contrib/$x src/bin/$x and also
move the reference pages in the documentation.
Personally, I'm good with moving pg_archivecleanup, pg_standby,
pg_upgrade, pg_xlogdump, and pgbench this way. (Although wasn't there
just some discussion about pg_standby being obsolete? If so, shouldn't
we remove it instead of promoting it?) As for the others:
I'm not exactly convinced that we want to encourage packagers to include
either pg_test_fsync or pg_test_timing in standard packages. They are not
all that useful to ordinary users.
oid2name and vacuumlo, besides being of very dubious general utility,
are fails from a namespacing standpoint. If we were to promote them
into standard install components I think a minimum requirement should be
to rename them to pg_something. (oid2name is an entirely bogus name for
what it does, anyway.) That would also be a good opportunity to revisit
their rather-ad-hoc APIs.
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
On 2014-12-08 22:50:30 -0500, Tom Lane wrote:
I'm not exactly convinced that we want to encourage packagers to include
either pg_test_fsync or pg_test_timing in standard packages. They are not
all that useful to ordinary users.
I actually think both are quite useful when setting up new systems to
quickly screen for problems. There still is a fairly large number of
virtualized systems with pretty much broken timing functions; and
checking whether fsync actually takes some time is also good thing to do
in virtualized environments - it's not an infrequent thing to see fsyncs
taking unrealistically low time.
Neither is likely to be harmful. So it doesn't seem harmful to move
them.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Dec 8, 2014 at 9:00 PM, Andres Freund <andres@2ndquadrant.com> wrote:
I actually think both are quite useful when setting up new systems to
quickly screen for problems. There still is a fairly large number of
virtualized systems with pretty much broken timing functions; and
checking whether fsync actually takes some time is also good thing to do
in virtualized environments - it's not an infrequent thing to see fsyncs
taking unrealistically low time.Neither is likely to be harmful. So it doesn't seem harmful to move
them.
+1
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Here are the contrib programs:
oid2name
pg_archivecleanup
pg_standby
pg_test_fsync
pg_test_timing
pg_upgrade
pg_xlogdump
pgbench
vacuumloThe proposal would basically be to mv contrib/$x src/bin/$x and also
move the reference pages in the documentation.
+1
Considering that all of the above have been around for a while, it's
kind of silly that they're still in contrib. Mostly that just
guarantees that nobody will use them, even when it's appropriate.
The one exception I might make above is pg_standby. What do we need
this for today, exactly?
--
Josh Berkus
PostgreSQL Experts Inc.
http://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
Import Notes
Reply to msg id not found: WMf837ec468487b4fb7a1e6e8096dc9a483e1d3bacfe9cbe5ce95270abd487f5beb532ca848e25392c8913552669358379@asav-2.01.com
On Mon, Dec 8, 2014 at 10:26 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
Let's take another crack at moving stuff out of contrib. Nobody likes
contrib. The task is only finding something that most people like better.
I like contrib fine. It's a great place for things to live that are
not quite baked enough for core, but still worth distributing.
oid2name
pg_archivecleanup
pg_standby
pg_test_fsync
pg_test_timing
pg_upgrade
pg_xlogdump
pgbench
vacuumloThe proposal would basically be to mv contrib/$x src/bin/$x and also
move the reference pages in the documentation.
I think pg_archivecleanup, pg_upgrade, and possibly pgbench have
enough general utility to justify putting them in src/bin, but not the
rest. oid2name, pg_standby, and vacuumlo are probably closer to being
candidates for removal than promotion in my book.
--
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
Peter Eisentraut wrote:
Here are the contrib programs:
oid2name
pg_archivecleanup
pg_standby
pg_test_fsync
pg_test_timing
pg_upgrade
pg_xlogdump
pgbench
vacuumloThe proposal would basically be to mv contrib/$x src/bin/$x and also
move the reference pages in the documentation.
Maybe it makes sense to have a distinction between client programs and
server programs. Can we have src/sbin/ and move stuff that involves the
server side in there? I think that'd be pg_xlogdump, pg_archivecleanup,
pg_upgrade, pg_test_timing, pg_test_fsync. (If we were feeling bold we
could also move pg_resetxlog, pg_controldata and initdb there.)
(For pg_upgrade you also need to do something about pg_upgrade_support,
which is good because that is one very ugly crock.)
I agree that oid2name and vacuumlo need to be in a better state to
deserve their promotion to src/bin, if we keep them at all.
In any case I support the move out of contrib of everything except
vacuumlo and oid2name, for reasons already stated by others in the
thread.
--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Dec 9, 2014 at 06:10:02PM -0300, Alvaro Herrera wrote:
(For pg_upgrade you also need to do something about pg_upgrade_support,
which is good because that is one very ugly crock.)
FYI, pg_upgrade_support was segregated from pg_upgrade only because we
wanted separate binary and shared object build/install targets.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 12/9/14 1:18 PM, Josh Berkus wrote:
The one exception I might make above is pg_standby. What do we need
this for today, exactly?
This was discussed recently and people wanted to keep it.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 12/9/14 4:10 PM, Alvaro Herrera wrote:
Maybe it makes sense to have a distinction between client programs and
server programs. Can we have src/sbin/ and move stuff that involves the
server side in there? I think that'd be pg_xlogdump, pg_archivecleanup,
pg_upgrade, pg_test_timing, pg_test_fsync. (If we were feeling bold we
could also move pg_resetxlog, pg_controldata and initdb there.)
I was thinking about that. What do others think?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 12/12/2014 03:07 PM, Peter Eisentraut wrote:
On 12/9/14 4:10 PM, Alvaro Herrera wrote:
Maybe it makes sense to have a distinction between client programs and
server programs. Can we have src/sbin/ and move stuff that involves the
server side in there? I think that'd be pg_xlogdump, pg_archivecleanup,
pg_upgrade, pg_test_timing, pg_test_fsync. (If we were feeling bold we
could also move pg_resetxlog, pg_controldata and initdb there.)I was thinking about that. What do others think?
Sounds good. We already separate server and client programs in the docs,
and packagers put them in different packages too. This should make
packagers' life a little bit easier in the long run.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 12/9/14 4:32 PM, Bruce Momjian wrote:
On Tue, Dec 9, 2014 at 06:10:02PM -0300, Alvaro Herrera wrote:
(For pg_upgrade you also need to do something about pg_upgrade_support,
which is good because that is one very ugly crock.)FYI, pg_upgrade_support was segregated from pg_upgrade only because we
wanted separate binary and shared object build/install targets.
I think the actual reason is that the makefile structure won't let you
have them both in the same directory. I don't see why you would need
separate install targets.
How about we move these support functions into the backend? It's not
like we don't already have other pg_upgrade hooks baked in all over the
place.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 12/12/2014 03:11 PM, Heikki Linnakangas wrote:
On 12/12/2014 03:07 PM, Peter Eisentraut wrote:
On 12/9/14 4:10 PM, Alvaro Herrera wrote:
Maybe it makes sense to have a distinction between client programs and
server programs. Can we have src/sbin/ and move stuff that involves the
server side in there? I think that'd be pg_xlogdump, pg_archivecleanup,
pg_upgrade, pg_test_timing, pg_test_fsync. (If we were feeling bold we
could also move pg_resetxlog, pg_controldata and initdb there.)I was thinking about that. What do others think?
Sounds good. We already separate server and client programs in the docs,
and packagers put them in different packages too. This should make
packagers' life a little bit easier in the long run.
src/sbin might not be a good name for the directory, though. We're not
going to install the programs in /usr/sbin, are we? Maybe src/server-bin
and src/client-bin.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2014-12-12 15:11:01 +0200, Heikki Linnakangas wrote:
On 12/12/2014 03:07 PM, Peter Eisentraut wrote:
On 12/9/14 4:10 PM, Alvaro Herrera wrote:
Maybe it makes sense to have a distinction between client programs and
server programs. Can we have src/sbin/ and move stuff that involves the
server side in there? I think that'd be pg_xlogdump, pg_archivecleanup,
pg_upgrade, pg_test_timing, pg_test_fsync. (If we were feeling bold we
could also move pg_resetxlog, pg_controldata and initdb there.)I was thinking about that. What do others think?
Sounds good. We already separate server and client programs in the docs, and
packagers put them in different packages too. This should make packagers'
life a little bit easier in the long run.
Wouldn't a make install-server/client targets or something similar
actually achieve the same thing? Seems simpler to maintain to me.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Dec 12, 2014 at 03:13:44PM +0200, Heikki Linnakangas wrote:
On 12/12/2014 03:11 PM, Heikki Linnakangas wrote:
On 12/12/2014 03:07 PM, Peter Eisentraut wrote:
On 12/9/14 4:10 PM, Alvaro Herrera wrote:
Maybe it makes sense to have a distinction between client programs and
server programs. Can we have src/sbin/ and move stuff that involves the
server side in there? I think that'd be pg_xlogdump, pg_archivecleanup,
pg_upgrade, pg_test_timing, pg_test_fsync. (If we were feeling bold we
could also move pg_resetxlog, pg_controldata and initdb there.)I was thinking about that. What do others think?
Sounds good. We already separate server and client programs in the docs,
and packagers put them in different packages too. This should make
packagers' life a little bit easier in the long run.src/sbin might not be a good name for the directory, though. We're
not going to install the programs in /usr/sbin, are we? Maybe
src/server-bin and src/client-bin.
I am confused by the above because you are mixing /src and /bin. If we
install the binaries in new directories, that is going to require
multiple adjustments to $PATH --- that doesn't seem like a win, and we
only have 25 binaries in pgsql/bin now (my Debian /usr/bin has 2306
binaries). I assume I am misunderstanding something.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Dec 12, 2014 at 08:11:31AM -0500, Peter Eisentraut wrote:
On 12/9/14 4:32 PM, Bruce Momjian wrote:
On Tue, Dec 9, 2014 at 06:10:02PM -0300, Alvaro Herrera wrote:
(For pg_upgrade you also need to do something about pg_upgrade_support,
which is good because that is one very ugly crock.)FYI, pg_upgrade_support was segregated from pg_upgrade only because we
wanted separate binary and shared object build/install targets.I think the actual reason is that the makefile structure won't let you
have them both in the same directory. I don't see why you would need
separate install targets.How about we move these support functions into the backend? It's not
like we don't already have other pg_upgrade hooks baked in all over the
place.
Yes, we can easily do that, and it makes sense. The functions are
already protected to not do anything unless the server is in binary
upgrade mode. If we move them into the backend I think we need to add a
super-user check as well. The reason we don't have one now is that they
are installed/uninstalled by the super-user as part of the pg_upgrade
process.
Moving pg_upgrade out of contrib is going to give me additional gloating
opportunities at conferences. :-)
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 12/8/14 10:50 PM, Tom Lane wrote:
oid2name and vacuumlo, besides being of very dubious general utility,
are fails from a namespacing standpoint. If we were to promote them
into standard install components I think a minimum requirement should be
to rename them to pg_something. (oid2name is an entirely bogus name for
what it does, anyway.) That would also be a good opportunity to revisit
their rather-ad-hoc APIs.
I'm going to leave these two out for now.
I'll start investigating whether they can be removed, or replaced by
something else.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 12/12/14 8:13 AM, Andres Freund wrote:
Wouldn't a make install-server/client targets or something similar
actually achieve the same thing? Seems simpler to maintain to me.
Adding non-standard makefile targets comes with its own set of
maintenance issues.
Restructuring the source tree and having the existing makefile structure
just work might end up being simpler.
Just to be clear, I'm far from convinced that any of this is worthwhile;
I'm just keeping the conversation going.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Bruce Momjian wrote:
On Fri, Dec 12, 2014 at 03:13:44PM +0200, Heikki Linnakangas wrote:
On 12/12/2014 03:11 PM, Heikki Linnakangas wrote:
Sounds good. We already separate server and client programs in the docs,
and packagers put them in different packages too. This should make
packagers' life a little bit easier in the long run.src/sbin might not be a good name for the directory, though. We're
not going to install the programs in /usr/sbin, are we? Maybe
src/server-bin and src/client-bin.I am confused by the above because you are mixing /src and /bin. If we
install the binaries in new directories, that is going to require
multiple adjustments to $PATH --- that doesn't seem like a win, and we
only have 25 binaries in pgsql/bin now (my Debian /usr/bin has 2306
binaries). I assume I am misunderstanding something.
We already have src/bin/; the mixture of "src/" and "bin/" predates us.
Of course, the stuff we keep in there is not binaries but source code
that produces binaries.
As for src/sbin/, we wouldn't install anything to the system's
/usr/sbin/ of course, only /usr/bin/, just like the stuff in src/bin/.
But it would be slightly more clear what we keep in each src/ subdir.
I think our current src/bin/ is a misnomer, but it seems late to fix
that. In a greenfield I think we could have "src/clients/" and
"src/srvtools/" or something like that, and everything would install to
/usr/bin. Then there would be no doubt where to move each program from
contrib.
Maybe there is no point to all of this and we should just move it all to
src/bin/ as originally proposed, which is simpler anyway.
--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2014-12-12 11:27:01 -0300, Alvaro Herrera wrote:
We already have src/bin/; the mixture of "src/" and "bin/" predates us.
Of course, the stuff we keep in there is not binaries but source code
that produces binaries.As for src/sbin/, we wouldn't install anything to the system's
/usr/sbin/ of course, only /usr/bin/, just like the stuff in src/bin/.
But it would be slightly more clear what we keep in each src/ subdir.
I think sbin is a spectactularly bad name, let's not go there. If
anything, make it srvbin or something like that.
I think our current src/bin/ is a misnomer, but it seems late to fix
that. In a greenfield I think we could have "src/clients/" and
"src/srvtools/" or something like that, and everything would install to
/usr/bin. Then there would be no doubt where to move each program from
contrib.
Maybe. We could just do that now - git's file change tracking is good
enough for that kind of move.
Maybe there is no point to all of this and we should just move it all to
src/bin/ as originally proposed, which is simpler anyway.
+1. Packagers already don't use the current boundaries for packaging...
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
