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
Heikki Linnakangas <hlinnakangas@vmware.com> writes:
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.
I'm pretty much -1 on relocating anything that's under src/bin already.
The history mess and back-patching pain would outweigh any notional
cleanliness --- and AFAICS it's entirely notional. As an ex-packager
I can tell you that where stuff sits in the source tree makes precisely
*zero* difference to a packager. She's going to do "make install-world"
and then her package recipe will list out which files in the install tree
go into which sub-package. Perhaps it would get clearer to packagers if
we also installed stuff into $INSTALLDIR/sbin, but I doubt that such a
change is going to fly with anyone else. The bin vs sbin distinction
is not universal.
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
Peter Eisentraut <peter_e@gmx.net> writes:
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.
I don't particularly object to having the C code built into the backend;
there's not that much of it, and if we could static-ize some of the global
variables that are involved presently, it'd be a Good Thing IMO. However,
the current arrangement makes sure that the function are not accessible
except during pg_upgrade, and that seems like a Good Thing as well. So
I think pg_upgrade should continue to have SQL scripts that create and
delete the SQL function definitions for these.
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
Peter Eisentraut <peter_e@gmx.net> writes:
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.
It would be of zero value to packagers anyway; certainly so for those
following the Red Hat tradition, in which you tell the package Makefile
to install everything and then what goes into which subpackage is
sorted out in a separate, subsequent step. Possibly Debian or other
packaging infrastructures do it differently, but I doubt that.
Really, if we want to tell packagers that foo is a client program and
bar is a server-side program, the documentation is where to address it.
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-12 10:20:58 -0500, Tom Lane wrote:
Peter Eisentraut <peter_e@gmx.net> writes:
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.It would be of zero value to packagers anyway; certainly so for those
following the Red Hat tradition, in which you tell the package Makefile
to install everything and then what goes into which subpackage is
sorted out in a separate, subsequent step. Possibly Debian or other
packaging infrastructures do it differently, but I doubt that.
Debian has that step as well - you don't really have to use it, but the
postgres debian packages do so. They already don't adhere to the current
distinction.
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
Tom Lane wrote:
Heikki Linnakangas <hlinnakangas@vmware.com> writes:
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.I'm pretty much -1 on relocating anything that's under src/bin already.
So let's put the whole bunch under src/bin/ and be done with it.
--
�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 Fri, Dec 12, 2014 at 11:00 AM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
I'm pretty much -1 on relocating anything that's under src/bin already.
I agree. I can't see packagers putting it anywhere except for
$SOMETHING/bin in the final install, so what do we get out of dividing
it up in some weird way in our tree?
So let's put the whole bunch under src/bin/ and be done with it.
I'm not really convinced this is a very good idea. What do we get out
of moving everything, or even anything, from contrib? It will make
back-patching harder, but more importantly, it will possibly create
the false impression that everything we distribute is on equal
footing. Right now, we've got stuff like vacuumlo in contrib which is
useful but, let's face it, also a cheap hack. If we decide that
executables can no longer live in contrib, then every time somebody
submits something in the future, we've got to decide whether it
deserves parity with psql and pg_dump or whether we shouldn't include
it at all. contrib is a nice middle-ground.
--
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
On 12/08/2014 07:50 PM, Tom Lane wrote:
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
vacuumloThe 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:
Let's not forget pg_upgrade which is arguably the most important of
everything listed.
JD
--
Command Prompt, Inc. - http://www.commandprompt.com/ 503-667-4564
PostgreSQL Support, Training, Professional Services and Development
High Availability, Oracle Conversion, @cmdpromptinc
"If we send our children to Caesar for their education, we should
not be surprised when they come back as Romans."
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
I'm not really convinced this is a very good idea. What do we get out
of moving everything, or even anything, from contrib? It will make
back-patching harder, but more importantly, it will possibly create
the false impression that everything we distribute is on equal
footing. Right now, we've got stuff like vacuumlo in contrib which is
useful but, let's face it, also a cheap hack. If we decide that
executables can no longer live in contrib, then every time somebody
submits something in the future, we've got to decide whether it
deserves parity with psql and pg_dump or whether we shouldn't include
it at all. contrib is a nice middle-ground.
Yeah, that's a good point. I think part of the motivation here is the
thought that some of these programs, like pg_upgrade, *should* now be
considered on par with pg_dump et al. But it does not follow that
everything in contrib is, or should be, on that level.
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-12 11:14:56 -0500, Robert Haas wrote:
I'm not really convinced this is a very good idea. What do we get out
of moving everything, or even anything, from contrib?
The benefit of moving relevant stuff is that it'll actually be installed
by default when installing postgres on many platforms. That's currently
often not the case. The contrib umbrella, as used by many other
projects, actually justifies not doing so.
I don't think that's a good argument for moving everything, rather the
contrary, but relevant stuff that we properly support should imo be
moved.
It will make back-patching harder
I think the amount of effort a simple renamed directory which wholly
contains a binary creates is acceptable. Just use patch -p4 instead of
patch -p1...
Right now, we've got stuff like vacuumlo in contrib which is
useful but, let's face it, also a cheap hack.
On the other hand, we really don't provide any other solution. Since
large objects are part of core we really ought to provide at least some
support for cleanup.
If we decide that executables can no longer live in contrib, then
every time somebody submits something in the future, we've got to
decide whether it deserves parity with psql and pg_dump or whether we
shouldn't include it at all. contrib is a nice middle-ground.
I think it makes sense to still have it as a middleground for future
things.
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 11:26 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Robert Haas <robertmhaas@gmail.com> writes:
I'm not really convinced this is a very good idea. What do we get out
of moving everything, or even anything, from contrib? It will make
back-patching harder, but more importantly, it will possibly create
the false impression that everything we distribute is on equal
footing. Right now, we've got stuff like vacuumlo in contrib which is
useful but, let's face it, also a cheap hack. If we decide that
executables can no longer live in contrib, then every time somebody
submits something in the future, we've got to decide whether it
deserves parity with psql and pg_dump or whether we shouldn't include
it at all. contrib is a nice middle-ground.Yeah, that's a good point. I think part of the motivation here is the
thought that some of these programs, like pg_upgrade, *should* now be
considered on par with pg_dump et al. But it does not follow that
everything in contrib is, or should be, on that level.
Yeah. We have put enough effort collectively into pg_upgrade that I
think it's fair to say that it is on a part with pg_dump. I still
think the architecture there is awfully fragile and we should try to
improve it, but it's very widely-used and people rely on it to work,
which it generally does. And certainly we have put a lot of sweat
into making it work.
I would also say that pg_archivecleanup is a fundamental server tool
and that it belongs in src/bin.
But after that, I get fuzzy. For me, the next tier of things would
consist of pgbench, pg_test_fsync, pg_test_timing, and pg_xlogdump.
Those are all useful, but I would also classify them as optional. If
you are running a PostgreSQL installation, you definitely need initdb
and postgres and pg_dump and pg_dumpall and psql, but you don't
definitely need these. I think they are all robust enough to go in
src/bin, but they are not as necessary as much of the stuff that is in
that directory today, so it's unclear to me whether we want to put
them there.
Finally, there is the stuff that is either hacky or deprecated:
oid2name, pg_standby, vacuumlo. Putting that stuff in src/bin clearly
makes no sense IMV. But I wouldn't necessarily want to remove it all
either.
--
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
On Fri, Dec 12, 2014 at 11:40 AM, Andres Freund <andres@2ndquadrant.com> wrote:
The benefit of moving relevant stuff is that it'll actually be installed
by default when installing postgres on many platforms. That's currently
often not the case. The contrib umbrella, as used by many other
projects, actually justifies not doing so.
Agreed. See my other response for my thoughts on that topic.
It will make back-patching harder
I think the amount of effort a simple renamed directory which wholly
contains a binary creates is acceptable. Just use patch -p4 instead of
patch -p1...
That is fine if you are manually applying a patch that touches only
that directory, but if the patch also touches other stuff then it's
not as simple. And I don't know how well git cherry-pick will follow
the moves.
--
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
On 2014-12-12 11:42:57 -0500, Robert Haas wrote:
I think the amount of effort a simple renamed directory which wholly
contains a binary creates is acceptable. Just use patch -p4 instead of
patch -p1...That is fine if you are manually applying a patch that touches only
that directory, but if the patch also touches other stuff then it's
not as simple.
I think backpatchable commits that touch individual binaries and other
code at the same time are (and ought to be!) pretty rare.
And I don't know how well git cherry-pick will follow
the moves.
Not well if the patch is done in master first.
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
Andres Freund <andres@2ndquadrant.com> writes:
On 2014-12-12 11:42:57 -0500, Robert Haas wrote:
And I don't know how well git cherry-pick will follow
the moves.
Not well if the patch is done in master first.
FWIW, I always patch master first, and have zero intention of changing
that workflow. (I have given reasons for that in the past, and don't
feel like repeating them right now.) So I'm really not on board with
moving code around without *very* good reasons. This thread hasn't
done very well at coming up with good reasons to move stuff out of
contrib.
In the particular case of pg_upgrade, while it may be now on par
usefulness-wise with src/bin stuff, I think it is and always will
be a special case anyway so far as packagers are concerned; the
reason being that it needs to ride along with back-branch executables.
So I'm not sure that we're making their lives easier by moving it.
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 Fri, Dec 12, 2014 at 10:16:05AM -0500, Tom Lane wrote:
Peter Eisentraut <peter_e@gmx.net> writes:
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.I don't particularly object to having the C code built into the backend;
there's not that much of it, and if we could static-ize some of the global
variables that are involved presently, it'd be a Good Thing IMO. However,
the current arrangement makes sure that the function are not accessible
except during pg_upgrade, and that seems like a Good Thing as well. So
I think pg_upgrade should continue to have SQL scripts that create and
delete the SQL function definitions for these.
Oh, hmmm, would pg_upgrade_support still be a separate shared object
file, or would we just link to functions that already exist in the
backend binary, i.e. it is just the SQL-callabiity you want pg_upgrade
to do?
--
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
Robert Haas wrote:
On Fri, Dec 12, 2014 at 11:00 AM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
So let's put the whole bunch under src/bin/ and be done with it.
I'm not really convinced this is a very good idea. What do we get out
of moving everything, or even anything, from contrib?
We show that it's no longer "contrib" (== possibly low quality) stuff
anymore. At the beginning of pg_upgrade, for example, we didn't want it
in src/bin because it wasn't stable enough, it was full of bugs, there
were always going to be scenarios it wouldn't handle. Now that is all
gone, so we promote it to the next status level.
It will make back-patching harder,
Yes. We can deal with that. It's not that hard anyway.
but more importantly, it will possibly create the false impression
that everything we distribute is on equal footing.
Stuff in contrib is of lower quality. Some items have improved enough
that we can let them out of that sack now. What we're doing is create
the correct impression that stuff that's no longer in contrib is of
better quality than what remains in contrib.
Right now, we've got stuff like vacuumlo in contrib which is
useful but, let's face it, also a cheap hack.
Then we don't move vacuumlo. I agree we shouldn't move it. (And
neither oid2names.)
If we decide that executables can no longer live in contrib,
Nobody is saying that.
--
�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
Re: Andres Freund 2014-12-12 <20141212152723.GO31413@awork2.anarazel.de>
On 2014-12-12 10:20:58 -0500, Tom Lane wrote:
Peter Eisentraut <peter_e@gmx.net> writes:
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.
Ack. The default install location would still be .../bin, but invoked
from different targets.
Adding non-standard makefile targets comes with its own set of
maintenance issues.It would be of zero value to packagers anyway; certainly so for those
following the Red Hat tradition, in which you tell the package Makefile
to install everything and then what goes into which subpackage is
sorted out in a separate, subsequent step. Possibly Debian or other
packaging infrastructures do it differently, but I doubt that.Debian has that step as well - you don't really have to use it, but the
postgres debian packages do so. They already don't adhere to the current
distinction.
The standard Debian package installs into debian/tmp/ and then picks
files from there into individual packages.
However, for PostgreSQL this means lengthy debian/*.install files
(the equivalent of %files in rpm spec speak):
$ wc -l debian/*.install
2 debian/libecpg6.install
1 debian/libecpg-compat3.install
17 debian/libecpg-dev.install
1 debian/libpgtypes3.install
2 debian/libpq5.install
14 debian/libpq-dev.install
39 debian/postgresql-9.4.install
40 debian/postgresql-client-9.4.install
65 debian/postgresql-contrib-9.4.install
2 debian/postgresql-doc-9.4.install
3 debian/postgresql-plperl-9.4.install
2 debian/postgresql-plpython3-9.4.install
3 debian/postgresql-plpython-9.4.install
5 debian/postgresql-pltcl-9.4.install
3 debian/postgresql-server-dev-9.4.install
199 total
If there were separate "install-client", "install-server", and
"install-contrib" targets, that would probably shorten those files
quite a bit. Especially messy is the part where *.so needs to be
sorted into server/contrib, along with an similar large bunch of
binaries.
Of course that would only solve part of the problem (I'm not going to
suggest creating 15 targets for the 15 binary packages we are
building), but it would solve the uglier part.
Christoph
--
cb@df7cb.de | http://www.df7cb.de/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Christoph Berg <cb@df7cb.de> writes:
However, for PostgreSQL this means lengthy debian/*.install files
(the equivalent of %files in rpm spec speak):
Right ...
If there were separate "install-client", "install-server", and
"install-contrib" targets, that would probably shorten those files
quite a bit. Especially messy is the part where *.so needs to be
sorted into server/contrib, along with an similar large bunch of
binaries.
Pardon me for not knowing much about Debian packages, but how would
that work exactly? Is it possible to do make install-client, then
package the installed files, then rm -rf the install tree, then
repeat for install-server and install-contrib? In the RPM world
this would never work because the build/install step happens in
toto before the packaging step. Even without that, it seems like
it'd be hard to make it entirely automatic since some files would
be installed in multiple cases (and directories even more so).
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
Tom Lane wrote:
Christoph Berg <cb@df7cb.de> writes:
However, for PostgreSQL this means lengthy debian/*.install files
(the equivalent of %files in rpm spec speak):Right ...
If there were separate "install-client", "install-server", and
"install-contrib" targets, that would probably shorten those files
quite a bit. Especially messy is the part where *.so needs to be
sorted into server/contrib, along with an similar large bunch of
binaries.Pardon me for not knowing much about Debian packages, but how would
that work exactly? Is it possible to do make install-client, then
package the installed files, then rm -rf the install tree, then
repeat for install-server and install-contrib? In the RPM world
this would never work because the build/install step happens in
toto before the packaging step.
Uh, couldn't you just run "make install-client DESTDIR=.../client" for
client-only files, and so on? You would end up with separate
directories containing files for each subpackage.
Even without that, it seems like it'd be hard to make it entirely
automatic since some files would be installed in multiple cases (and
directories even more so).
Yeah, you would need to fix that somehow.
--
�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 Fri, Dec 12, 2014 at 12:19 PM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
If we decide that executables can no longer live in contrib,
Nobody is saying that.
The reason I though that might be on the table is that the first post
on this thread, at least as I understood it, proposed to move every
executable out of contrib, which would seem to also imply that we
wouldn't put any new ones there. I agree that course of action
doesn't seem to be garnering many votes, but I think it does seem to
have been proposed, unless I am confused.
--
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
On Sat, Dec 13, 2014 at 1:00 AM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
Tom Lane wrote:
Heikki Linnakangas <hlinnakangas@vmware.com> writes:
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.I'm pretty much -1 on relocating anything that's under src/bin already.
So let's put the whole bunch under src/bin/ and be done with it.
When doing so let's be careful with the MSVC specs, this will need a
set of definitions with AddSimpleFrontend. This should ensure as well
that versioning work that has been done on Windows for this release
cycle is not broken for all the things moved. I don't mind
double-checking that..
--
Michael
--
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 10:16 AM, Tom Lane wrote:
I don't particularly object to having the C code built into the backend;
there's not that much of it, and if we could static-ize some of the global
variables that are involved presently, it'd be a Good Thing IMO. However,
the current arrangement makes sure that the function are not accessible
except during pg_upgrade, and that seems like a Good Thing as well. So
I think pg_upgrade should continue to have SQL scripts that create and
delete the SQL function definitions for these.
That won't actually work very easily. LANGUAGE internal functions need
to be in fmgr_builtins, and the only way to get them there is by listing
them in pg_proc.h. (We could drop the functions in initdb, but seems
kind of silly.)
The functions do already check themselves that they are called in binary
upgrade mode, so exposing them in pg_proc doesn't seem risky.
--
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 3:20 PM, Tom Lane wrote:
Pardon me for not knowing much about Debian packages, but how would
that work exactly? Is it possible to do make install-client, then
package the installed files, then rm -rf the install tree, then
repeat for install-server and install-contrib? In the RPM world
this would never work because the build/install step happens in
toto before the packaging step.
I don't know exactly what Christoph had in mind, but the short answer to
your question is: Yes, that is possible. Almost anything is possible.
There are many tools available at various levels of abstraction that
facility common patterns, but you can also do everything by hand, as
long as you produce the right *.deb files at the right location at the
end. The only thing stopping you is your sanity.
However, other packaging systems clearly don't work that way, and so
designing something that would only work for one packaging system
doesn't seem worthwhile. And we don't even know whether and how it
would work anyway.
--
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:
On 12/12/14 10:16 AM, Tom Lane wrote:
I think pg_upgrade should continue to have SQL scripts that create and
delete the SQL function definitions for these.
That won't actually work very easily. LANGUAGE internal functions need
to be in fmgr_builtins, and the only way to get them there is by listing
them in pg_proc.h. (We could drop the functions in initdb, but seems
kind of silly.)
Oh, good point.
The functions do already check themselves that they are called in binary
upgrade mode, so exposing them in pg_proc doesn't seem risky.
Fair enough ... binary upgrade mode is not readily accessible, right?
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 12/12/14 11:45 AM, Andres Freund wrote:
On 2014-12-12 11:42:57 -0500, Robert Haas wrote:
I think the amount of effort a simple renamed directory which wholly
contains a binary creates is acceptable. Just use patch -p4 instead of
patch -p1...That is fine if you are manually applying a patch that touches only
that directory, but if the patch also touches other stuff then it's
not as simple.I think backpatchable commits that touch individual binaries and other
code at the same time are (and ought to be!) pretty rare.And I don't know how well git cherry-pick will follow
the moves.Not well if the patch is done in master first.
It does work. I have tried it with the changes I'm working on.
There might very well be limits to the cleverness of these tools, but if
you know of a fundamental reason why this would be a problem, let's
please hear 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/12/14 11:14 AM, Robert Haas wrote:
contrib is a nice middle-ground.
I respect that view. But if we consider contrib a place where things
can try to mature, then there must be a way to move things out of there
once they have matured. If it turns out that moving things out of
contrib causes major problems, then we must reconsider that system and
find a different process for maturing things (e.g., a makefile flag,
just a random idea). Therefore, I think it's worth trying this. We can
do it piece by piece.
--
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:57:55PM -0500, Tom Lane wrote:
Peter Eisentraut <peter_e@gmx.net> writes:
On 12/12/14 10:16 AM, Tom Lane wrote:
I think pg_upgrade should continue to have SQL scripts that create and
delete the SQL function definitions for these.That won't actually work very easily. LANGUAGE internal functions need
to be in fmgr_builtins, and the only way to get them there is by listing
them in pg_proc.h. (We could drop the functions in initdb, but seems
kind of silly.)Oh, good point.
The functions do already check themselves that they are called in binary
upgrade mode, so exposing them in pg_proc doesn't seem risky.Fair enough ... binary upgrade mode is not readily accessible, right?
Well, the postmaster allows anyone to use the flag, while the backends
have:
case 'b':
/* Undocumented flag used for binary upgrades */
if (secure)
IsBinaryUpgrade = true;
break;
which means it can only be passed in from the postmaster. I think only
the super-user can set postmaster options.
--
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
Re: Alvaro Herrera 2014-12-12 <20141212203700.GB1768@alvh.no-ip.org>
Pardon me for not knowing much about Debian packages, but how would
that work exactly? Is it possible to do make install-client, then
package the installed files, then rm -rf the install tree, then
repeat for install-server and install-contrib? In the RPM world
this would never work because the build/install step happens in
toto before the packaging step.Uh, couldn't you just run "make install-client DESTDIR=.../client" for
client-only files, and so on? You would end up with separate
directories containing files for each subpackage.
Exactly. You don't need to use DESTDIR=debian/tmp, you can "make
install-client DESTDIR=$(CURDIR)/debian/postgresql-client-9.4" and
skip the intermediate location for some of the files.
Even without that, it seems like it'd be hard to make it entirely
automatic since some files would be installed in multiple cases (and
directories even more so).Yeah, you would need to fix that somehow.
Directories shipped in multiple packages are not a problem for dpkg
(/usr/bin!). Files must not be installed twice, but if that happened,
I'd deem that a bug in the Makefile.
The src/contrib/doc (and config) directories already have separate
install targets. These do exactly what we need for server/contrib/doc
installation, so I'll likely move to using these to remove some
complexity from debian/*.install.
On top of that, a separate "install-client" or "make -C client
install" target would be very nice, as currently not only the client
binaries have to be picked from the server tree, but also the manpages
and locale files.
The same would be nice for end-users who just want a client install
when building from source. At the moment they need to install the full
server.
Christoph
--
cb@df7cb.de | http://www.df7cb.de/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Here is a patch series to move
pg_archivecleanup
pg_standby
pg_test_fsync
pg_test_timing
pg_upgrade
pg_xlogdump
pgbench
from contrib/ to src/bin/.
Move people didn't like moving oid2name and vacuumlo, which I
understand. So I'll leave those for now.
I have also included a patch to move pg_upgrade_support into the
backend, as discussed.
Open issues/discussion points:
- no Windows build system support yet
- I didn't move the source of the man pages to .../sgml/ref. This could
be done.
- I didn't rename to the SGML ids of the man pages to git the patter of
the other applications, because that would change the name of the HTML
pages.
- We have traditionally kept an individual author acknowledgement in the
man pages for contrib items. Should those be removed now?
Attachments:
0001-Sort-SUBDIRS-variable-in-src-bin-Makefile.patchapplication/x-patch; name=0001-Sort-SUBDIRS-variable-in-src-bin-Makefile.patchDownload
From 0a4b9a4eaf930b8e14b4b3e2077ca7706a65ab6a Mon Sep 17 00:00:00 2001
From: Peter Eisentraut <peter_e@gmx.net>
Date: Sun, 14 Dec 2014 20:41:58 -0500
Subject: [PATCH 1/9] Sort SUBDIRS variable in src/bin/Makefile
The previous order appears to have been historically grown randomness.
---
src/bin/Makefile | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/src/bin/Makefile b/src/bin/Makefile
index f03cc42..f0589f3 100644
--- a/src/bin/Makefile
+++ b/src/bin/Makefile
@@ -13,8 +13,16 @@ subdir = src/bin
top_builddir = ../..
include $(top_builddir)/src/Makefile.global
-SUBDIRS = initdb pg_ctl pg_dump \
- psql scripts pg_config pg_controldata pg_resetxlog pg_basebackup
+SUBDIRS = \
+ initdb \
+ pg_basebackup \
+ pg_config \
+ pg_controldata \
+ pg_ctl \
+ pg_dump \
+ pg_resetxlog \
+ psql \
+ scripts
ifeq ($(PORTNAME), win32)
SUBDIRS += pgevent
--
2.2.0
0002-Move-pg_archivecleanup-from-contrib-to-src-bin.patchapplication/x-patch; name=0002-Move-pg_archivecleanup-from-contrib-to-src-bin.patchDownload
From 403955c76136960d7d444e946ba2c20110d7e263 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut <peter_e@gmx.net>
Date: Sun, 14 Dec 2014 20:41:58 -0500
Subject: [PATCH 2/9] Move pg_archivecleanup from contrib/ to src/bin/
---
contrib/Makefile | 1 -
contrib/pg_archivecleanup/Makefile | 18 ------------------
doc/src/sgml/contrib.sgml | 1 -
doc/src/sgml/reference.sgml | 1 +
src/bin/Makefile | 1 +
{contrib => src/bin}/pg_archivecleanup/.gitignore | 0
src/bin/pg_archivecleanup/Makefile | 14 ++++++++++++++
.../bin}/pg_archivecleanup/pg_archivecleanup.c | 2 +-
8 files changed, 17 insertions(+), 21 deletions(-)
delete mode 100644 contrib/pg_archivecleanup/Makefile
rename {contrib => src/bin}/pg_archivecleanup/.gitignore (100%)
create mode 100644 src/bin/pg_archivecleanup/Makefile
rename {contrib => src/bin}/pg_archivecleanup/pg_archivecleanup.c (99%)
diff --git a/contrib/Makefile b/contrib/Makefile
index 195d447..c56050e 100644
--- a/contrib/Makefile
+++ b/contrib/Makefile
@@ -28,7 +28,6 @@ SUBDIRS = \
oid2name \
pageinspect \
passwordcheck \
- pg_archivecleanup \
pg_buffercache \
pg_freespacemap \
pg_prewarm \
diff --git a/contrib/pg_archivecleanup/Makefile b/contrib/pg_archivecleanup/Makefile
deleted file mode 100644
index ab52390..0000000
--- a/contrib/pg_archivecleanup/Makefile
+++ /dev/null
@@ -1,18 +0,0 @@
-# contrib/pg_archivecleanup/Makefile
-
-PGFILEDESC = "pg_archivecleanup - cleans archive when used with streaming replication"
-PGAPPICON = win32
-
-PROGRAM = pg_archivecleanup
-OBJS = pg_archivecleanup.o $(WIN32RES)
-
-ifdef USE_PGXS
-PG_CONFIG = pg_config
-PGXS := $(shell $(PG_CONFIG) --pgxs)
-include $(PGXS)
-else
-subdir = contrib/pg_archivecleanup
-top_builddir = ../..
-include $(top_builddir)/src/Makefile.global
-include $(top_srcdir)/contrib/contrib-global.mk
-endif
diff --git a/doc/src/sgml/contrib.sgml b/doc/src/sgml/contrib.sgml
index a698d0f..f21fa14 100644
--- a/doc/src/sgml/contrib.sgml
+++ b/doc/src/sgml/contrib.sgml
@@ -202,7 +202,6 @@ <title>Server Applications</title>
part of the core <productname>PostgreSQL</productname> distribution.
</para>
- &pgarchivecleanup;
&pgstandby;
&pgtestfsync;
&pgtesttiming;
diff --git a/doc/src/sgml/reference.sgml b/doc/src/sgml/reference.sgml
index 10c9a6d..62267db 100644
--- a/doc/src/sgml/reference.sgml
+++ b/doc/src/sgml/reference.sgml
@@ -257,6 +257,7 @@ <title>PostgreSQL Server Applications</title>
</partintro>
&initdb;
+ &pgarchivecleanup;
&pgControldata;
&pgCtl;
&pgResetxlog;
diff --git a/src/bin/Makefile b/src/bin/Makefile
index f0589f3..0e7b183 100644
--- a/src/bin/Makefile
+++ b/src/bin/Makefile
@@ -15,6 +15,7 @@ include $(top_builddir)/src/Makefile.global
SUBDIRS = \
initdb \
+ pg_archivecleanup \
pg_basebackup \
pg_config \
pg_controldata \
diff --git a/contrib/pg_archivecleanup/.gitignore b/src/bin/pg_archivecleanup/.gitignore
similarity index 100%
rename from contrib/pg_archivecleanup/.gitignore
rename to src/bin/pg_archivecleanup/.gitignore
diff --git a/src/bin/pg_archivecleanup/Makefile b/src/bin/pg_archivecleanup/Makefile
new file mode 100644
index 0000000..5df86eb
--- /dev/null
+++ b/src/bin/pg_archivecleanup/Makefile
@@ -0,0 +1,14 @@
+# src/bin/pg_archivecleanup/Makefile
+
+PGFILEDESC = "pg_archivecleanup - cleans archive when used with streaming replication"
+PGAPPICON = win32
+
+subdir = src/bin/pg_archivecleanup
+top_builddir = ../../..
+include $(top_builddir)/src/Makefile.global
+
+PROGRAM = pg_archivecleanup
+OBJS = pg_archivecleanup.o $(WIN32RES)
+
+NO_PGXS = 1
+include $(top_srcdir)/src/makefiles/pgxs.mk
diff --git a/contrib/pg_archivecleanup/pg_archivecleanup.c b/src/bin/pg_archivecleanup/pg_archivecleanup.c
similarity index 99%
rename from contrib/pg_archivecleanup/pg_archivecleanup.c
rename to src/bin/pg_archivecleanup/pg_archivecleanup.c
index 97225a8..2ff2a27 100644
--- a/contrib/pg_archivecleanup/pg_archivecleanup.c
+++ b/src/bin/pg_archivecleanup/pg_archivecleanup.c
@@ -1,5 +1,5 @@
/*
- * contrib/pg_archivecleanup/pg_archivecleanup.c
+ * src/bin/pg_archivecleanup/pg_archivecleanup.c
*
* pg_archivecleanup.c
*
--
2.2.0
0003-Move-pg_standby-from-contrib-to-src-bin.patchapplication/x-patch; name=0003-Move-pg_standby-from-contrib-to-src-bin.patchDownload
From 770112a5ee2c5e6df04fc540b93bbc596de98a4e Mon Sep 17 00:00:00 2001
From: Peter Eisentraut <peter_e@gmx.net>
Date: Sun, 14 Dec 2014 20:41:58 -0500
Subject: [PATCH 3/9] Move pg_standby from contrib/ to src/bin/
---
contrib/Makefile | 1 -
contrib/pg_standby/Makefile | 18 ------------------
doc/src/sgml/contrib.sgml | 1 -
doc/src/sgml/reference.sgml | 1 +
src/bin/Makefile | 1 +
{contrib => src/bin}/pg_standby/.gitignore | 0
src/bin/pg_standby/Makefile | 14 ++++++++++++++
{contrib => src/bin}/pg_standby/pg_standby.c | 2 +-
8 files changed, 17 insertions(+), 21 deletions(-)
delete mode 100644 contrib/pg_standby/Makefile
rename {contrib => src/bin}/pg_standby/.gitignore (100%)
create mode 100644 src/bin/pg_standby/Makefile
rename {contrib => src/bin}/pg_standby/pg_standby.c (99%)
diff --git a/contrib/Makefile b/contrib/Makefile
index c56050e..1732443 100644
--- a/contrib/Makefile
+++ b/contrib/Makefile
@@ -31,7 +31,6 @@ SUBDIRS = \
pg_buffercache \
pg_freespacemap \
pg_prewarm \
- pg_standby \
pg_stat_statements \
pg_test_fsync \
pg_test_timing \
diff --git a/contrib/pg_standby/Makefile b/contrib/pg_standby/Makefile
deleted file mode 100644
index 0bca2f8..0000000
--- a/contrib/pg_standby/Makefile
+++ /dev/null
@@ -1,18 +0,0 @@
-# contrib/pg_standby/Makefile
-
-PGFILEDESC = "pg_standby - supports creation of a warm standby"
-PGAPPICON = win32
-
-PROGRAM = pg_standby
-OBJS = pg_standby.o $(WIN32RES)
-
-ifdef USE_PGXS
-PG_CONFIG = pg_config
-PGXS := $(shell $(PG_CONFIG) --pgxs)
-include $(PGXS)
-else
-subdir = contrib/pg_standby
-top_builddir = ../..
-include $(top_builddir)/src/Makefile.global
-include $(top_srcdir)/contrib/contrib-global.mk
-endif
diff --git a/doc/src/sgml/contrib.sgml b/doc/src/sgml/contrib.sgml
index f21fa14..087cd9f 100644
--- a/doc/src/sgml/contrib.sgml
+++ b/doc/src/sgml/contrib.sgml
@@ -202,7 +202,6 @@ <title>Server Applications</title>
part of the core <productname>PostgreSQL</productname> distribution.
</para>
- &pgstandby;
&pgtestfsync;
&pgtesttiming;
&pgupgrade;
diff --git a/doc/src/sgml/reference.sgml b/doc/src/sgml/reference.sgml
index 62267db..d47272a 100644
--- a/doc/src/sgml/reference.sgml
+++ b/doc/src/sgml/reference.sgml
@@ -261,6 +261,7 @@ <title>PostgreSQL Server Applications</title>
&pgControldata;
&pgCtl;
&pgResetxlog;
+ &pgstandby;
&postgres;
&postmaster;
diff --git a/src/bin/Makefile b/src/bin/Makefile
index 0e7b183..6026b83 100644
--- a/src/bin/Makefile
+++ b/src/bin/Makefile
@@ -22,6 +22,7 @@ SUBDIRS = \
pg_ctl \
pg_dump \
pg_resetxlog \
+ pg_standby \
psql \
scripts
diff --git a/contrib/pg_standby/.gitignore b/src/bin/pg_standby/.gitignore
similarity index 100%
rename from contrib/pg_standby/.gitignore
rename to src/bin/pg_standby/.gitignore
diff --git a/src/bin/pg_standby/Makefile b/src/bin/pg_standby/Makefile
new file mode 100644
index 0000000..d45a47d
--- /dev/null
+++ b/src/bin/pg_standby/Makefile
@@ -0,0 +1,14 @@
+# src/bin/pg_standby/Makefile
+
+PGFILEDESC = "pg_standby - supports creation of a warm standby"
+PGAPPICON = win32
+
+subdir = src/bin/pg_standby
+top_builddir = ../../..
+include $(top_builddir)/src/Makefile.global
+
+PROGRAM = pg_standby
+OBJS = pg_standby.o $(WIN32RES)
+
+NO_PGXS = 1
+include $(top_srcdir)/src/makefiles/pgxs.mk
diff --git a/contrib/pg_standby/pg_standby.c b/src/bin/pg_standby/pg_standby.c
similarity index 99%
rename from contrib/pg_standby/pg_standby.c
rename to src/bin/pg_standby/pg_standby.c
index d6b1692..1d45cbf 100644
--- a/contrib/pg_standby/pg_standby.c
+++ b/src/bin/pg_standby/pg_standby.c
@@ -1,5 +1,5 @@
/*
- * contrib/pg_standby/pg_standby.c
+ * src/bin/pg_standby/pg_standby.c
*
*
* pg_standby.c
--
2.2.0
0004-Move-pg_xlogdump-from-contrib-to-src-bin.patchapplication/x-patch; name=0004-Move-pg_xlogdump-from-contrib-to-src-bin.patchDownload
From 1209761baff42f462907b25b0a9c64c04399bc32 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut <peter_e@gmx.net>
Date: Sun, 14 Dec 2014 20:41:58 -0500
Subject: [PATCH 4/9] Move pg_xlogdump from contrib/ to src/bin/
---
contrib/Makefile | 1 -
doc/src/sgml/contrib.sgml | 1 -
doc/src/sgml/reference.sgml | 1 +
src/bin/Makefile | 1 +
{contrib => src/bin}/pg_xlogdump/.gitignore | 0
{contrib => src/bin}/pg_xlogdump/Makefile | 19 ++++++++-----------
{contrib => src/bin}/pg_xlogdump/compat.c | 2 +-
{contrib => src/bin}/pg_xlogdump/pg_xlogdump.c | 2 +-
{contrib => src/bin}/pg_xlogdump/rmgrdesc.c | 2 +-
{contrib => src/bin}/pg_xlogdump/rmgrdesc.h | 2 +-
10 files changed, 14 insertions(+), 17 deletions(-)
rename {contrib => src/bin}/pg_xlogdump/.gitignore (100%)
rename {contrib => src/bin}/pg_xlogdump/Makefile (76%)
rename {contrib => src/bin}/pg_xlogdump/compat.c (98%)
rename {contrib => src/bin}/pg_xlogdump/pg_xlogdump.c (99%)
rename {contrib => src/bin}/pg_xlogdump/rmgrdesc.c (96%)
rename {contrib => src/bin}/pg_xlogdump/rmgrdesc.h (91%)
diff --git a/contrib/Makefile b/contrib/Makefile
index 1732443..8f0d926 100644
--- a/contrib/Makefile
+++ b/contrib/Makefile
@@ -41,7 +41,6 @@ SUBDIRS = \
pgcrypto \
pgrowlocks \
pgstattuple \
- pg_xlogdump \
postgres_fdw \
seg \
spi \
diff --git a/doc/src/sgml/contrib.sgml b/doc/src/sgml/contrib.sgml
index 087cd9f..dbe9d0a 100644
--- a/doc/src/sgml/contrib.sgml
+++ b/doc/src/sgml/contrib.sgml
@@ -205,6 +205,5 @@ <title>Server Applications</title>
&pgtestfsync;
&pgtesttiming;
&pgupgrade;
- &pgxlogdump;
</sect1>
</appendix>
diff --git a/doc/src/sgml/reference.sgml b/doc/src/sgml/reference.sgml
index d47272a..de2cdff 100644
--- a/doc/src/sgml/reference.sgml
+++ b/doc/src/sgml/reference.sgml
@@ -262,6 +262,7 @@ <title>PostgreSQL Server Applications</title>
&pgCtl;
&pgResetxlog;
&pgstandby;
+ &pgxlogdump;
&postgres;
&postmaster;
diff --git a/src/bin/Makefile b/src/bin/Makefile
index 6026b83..87f5c70 100644
--- a/src/bin/Makefile
+++ b/src/bin/Makefile
@@ -23,6 +23,7 @@ SUBDIRS = \
pg_dump \
pg_resetxlog \
pg_standby \
+ pg_xlogdump \
psql \
scripts
diff --git a/contrib/pg_xlogdump/.gitignore b/src/bin/pg_xlogdump/.gitignore
similarity index 100%
rename from contrib/pg_xlogdump/.gitignore
rename to src/bin/pg_xlogdump/.gitignore
diff --git a/contrib/pg_xlogdump/Makefile b/src/bin/pg_xlogdump/Makefile
similarity index 76%
rename from contrib/pg_xlogdump/Makefile
rename to src/bin/pg_xlogdump/Makefile
index 30a8706..ab8597b 100644
--- a/contrib/pg_xlogdump/Makefile
+++ b/src/bin/pg_xlogdump/Makefile
@@ -1,28 +1,25 @@
-# contrib/pg_xlogdump/Makefile
+# src/bin/pg_xlogdump/Makefile
PGFILEDESC = "pg_xlogdump - decode and display WAL"
PGAPPICON=win32
+subdir = src/bin/pg_xlogdump
+top_builddir = ../../..
+include $(top_builddir)/src/Makefile.global
+
PROGRAM = pg_xlogdump
OBJS = pg_xlogdump.o compat.o xlogreader.o rmgrdesc.o \
$(RMGRDESCOBJS) $(WIN32RES)
+override CPPFLAGS := -DFRONTEND $(CPPFLAGS)
RMGRDESCSOURCES = $(notdir $(wildcard $(top_srcdir)/src/backend/access/rmgrdesc/*desc.c))
RMGRDESCOBJS = $(patsubst %.c,%.o,$(RMGRDESCSOURCES))
EXTRA_CLEAN = $(RMGRDESCSOURCES) xlogreader.c
-ifdef USE_PGXS
-$(error "pg_xlogdump cannot be built with PGXS")
-endif
+NO_PGXS = 1
+include $(top_srcdir)/src/makefiles/pgxs.mk
-subdir = contrib/pg_xlogdump
-top_builddir = ../..
-include $(top_builddir)/src/Makefile.global
-include $(top_srcdir)/contrib/contrib-global.mk
-
-
-override CPPFLAGS := -DFRONTEND $(CPPFLAGS)
xlogreader.c: % : $(top_srcdir)/src/backend/access/transam/%
rm -f $@ && $(LN_S) $< .
diff --git a/contrib/pg_xlogdump/compat.c b/src/bin/pg_xlogdump/compat.c
similarity index 98%
rename from contrib/pg_xlogdump/compat.c
rename to src/bin/pg_xlogdump/compat.c
index 6ca7012..5c07e1e 100644
--- a/contrib/pg_xlogdump/compat.c
+++ b/src/bin/pg_xlogdump/compat.c
@@ -6,7 +6,7 @@
* Portions Copyright (c) 2013-2014, PostgreSQL Global Development Group
*
* IDENTIFICATION
- * contrib/pg_xlogdump/compat.c
+ * src/bin/pg_xlogdump/compat.c
*
* This file contains client-side implementations for various backend
* functions that the rm_desc functions in *desc.c files rely on.
diff --git a/contrib/pg_xlogdump/pg_xlogdump.c b/src/bin/pg_xlogdump/pg_xlogdump.c
similarity index 99%
rename from contrib/pg_xlogdump/pg_xlogdump.c
rename to src/bin/pg_xlogdump/pg_xlogdump.c
index 9f05e25..f767a97 100644
--- a/contrib/pg_xlogdump/pg_xlogdump.c
+++ b/src/bin/pg_xlogdump/pg_xlogdump.c
@@ -5,7 +5,7 @@
* Copyright (c) 2013-2014, PostgreSQL Global Development Group
*
* IDENTIFICATION
- * contrib/pg_xlogdump/pg_xlogdump.c
+ * src/bin/pg_xlogdump/pg_xlogdump.c
*-------------------------------------------------------------------------
*/
diff --git a/contrib/pg_xlogdump/rmgrdesc.c b/src/bin/pg_xlogdump/rmgrdesc.c
similarity index 96%
rename from contrib/pg_xlogdump/rmgrdesc.c
rename to src/bin/pg_xlogdump/rmgrdesc.c
index 180818d..4fb0a00 100644
--- a/contrib/pg_xlogdump/rmgrdesc.c
+++ b/src/bin/pg_xlogdump/rmgrdesc.c
@@ -3,7 +3,7 @@
*
* pg_xlogdump resource managers definition
*
- * contrib/pg_xlogdump/rmgrdesc.c
+ * src/bin/pg_xlogdump/rmgrdesc.c
*/
#define FRONTEND 1
#include "postgres.h"
diff --git a/contrib/pg_xlogdump/rmgrdesc.h b/src/bin/pg_xlogdump/rmgrdesc.h
similarity index 91%
rename from contrib/pg_xlogdump/rmgrdesc.h
rename to src/bin/pg_xlogdump/rmgrdesc.h
index aec4418..5440f94 100644
--- a/contrib/pg_xlogdump/rmgrdesc.h
+++ b/src/bin/pg_xlogdump/rmgrdesc.h
@@ -3,7 +3,7 @@
*
* pg_xlogdump resource managers declaration
*
- * contrib/pg_xlogdump/rmgrdesc.h
+ * src/bin/pg_xlogdump/rmgrdesc.h
*/
#ifndef RMGRDESC_H
#define RMGRDESC_H
--
2.2.0
0005-Move-pgbench-from-contrib-to-src-bin.patchapplication/x-patch; name=0005-Move-pgbench-from-contrib-to-src-bin.patchDownload
From 0bec76a953bded9e61dd31cbf7ec9cc96a0493f6 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut <peter_e@gmx.net>
Date: Sun, 14 Dec 2014 20:41:58 -0500
Subject: [PATCH 5/9] Move pgbench from contrib/ to src/bin/
---
contrib/Makefile | 1 -
doc/src/sgml/contrib.sgml | 1 -
doc/src/sgml/reference.sgml | 1 +
src/bin/Makefile | 1 +
{contrib => src/bin}/pgbench/.gitignore | 0
{contrib => src/bin}/pgbench/Makefile | 18 +++++++-----------
{contrib => src/bin}/pgbench/pgbench.c | 2 +-
7 files changed, 10 insertions(+), 14 deletions(-)
rename {contrib => src/bin}/pgbench/.gitignore (100%)
rename {contrib => src/bin}/pgbench/Makefile (59%)
rename {contrib => src/bin}/pgbench/pgbench.c (99%)
diff --git a/contrib/Makefile b/contrib/Makefile
index 8f0d926..12c7500 100644
--- a/contrib/Makefile
+++ b/contrib/Makefile
@@ -37,7 +37,6 @@ SUBDIRS = \
pg_trgm \
pg_upgrade \
pg_upgrade_support \
- pgbench \
pgcrypto \
pgrowlocks \
pgstattuple \
diff --git a/doc/src/sgml/contrib.sgml b/doc/src/sgml/contrib.sgml
index dbe9d0a..60c07ea 100644
--- a/doc/src/sgml/contrib.sgml
+++ b/doc/src/sgml/contrib.sgml
@@ -187,7 +187,6 @@ <title>Client Applications</title>
</para>
&oid2name;
- &pgbench;
&vacuumlo;
</sect1>
diff --git a/doc/src/sgml/reference.sgml b/doc/src/sgml/reference.sgml
index de2cdff..a839af7 100644
--- a/doc/src/sgml/reference.sgml
+++ b/doc/src/sgml/reference.sgml
@@ -230,6 +230,7 @@ <title>PostgreSQL Client Applications</title>
&dropuser;
&ecpgRef;
&pgBasebackup;
+ &pgbench;
&pgConfig;
&pgDump;
&pgDumpall;
diff --git a/src/bin/Makefile b/src/bin/Makefile
index 87f5c70..39d7e7d 100644
--- a/src/bin/Makefile
+++ b/src/bin/Makefile
@@ -24,6 +24,7 @@ SUBDIRS = \
pg_resetxlog \
pg_standby \
pg_xlogdump \
+ pgbench \
psql \
scripts
diff --git a/contrib/pgbench/.gitignore b/src/bin/pgbench/.gitignore
similarity index 100%
rename from contrib/pgbench/.gitignore
rename to src/bin/pgbench/.gitignore
diff --git a/contrib/pgbench/Makefile b/src/bin/pgbench/Makefile
similarity index 59%
rename from contrib/pgbench/Makefile
rename to src/bin/pgbench/Makefile
index b8e2fc8..de4863c 100644
--- a/contrib/pgbench/Makefile
+++ b/src/bin/pgbench/Makefile
@@ -1,24 +1,20 @@
-# contrib/pgbench/Makefile
+# src/bin/pgbench/Makefile
PGFILEDESC = "pgbench - a simple program for running benchmark tests"
PGAPPICON = win32
+subdir = src/bin/pgbench
+top_builddir = ../../..
+include $(top_builddir)/src/Makefile.global
+
PROGRAM = pgbench
OBJS = pgbench.o $(WIN32RES)
PG_CPPFLAGS = -I$(libpq_srcdir)
PG_LIBS = $(libpq_pgport) $(PTHREAD_LIBS)
-ifdef USE_PGXS
-PG_CONFIG = pg_config
-PGXS := $(shell $(PG_CONFIG) --pgxs)
-include $(PGXS)
-else
-subdir = contrib/pgbench
-top_builddir = ../..
-include $(top_builddir)/src/Makefile.global
-include $(top_srcdir)/contrib/contrib-global.mk
-endif
+NO_PGXS = 1
+include $(top_srcdir)/src/makefiles/pgxs.mk
ifneq ($(PORTNAME), win32)
override CFLAGS += $(PTHREAD_CFLAGS)
diff --git a/contrib/pgbench/pgbench.c b/src/bin/pgbench/pgbench.c
similarity index 99%
rename from contrib/pgbench/pgbench.c
rename to src/bin/pgbench/pgbench.c
index 3453a1f..616c986 100644
--- a/contrib/pgbench/pgbench.c
+++ b/src/bin/pgbench/pgbench.c
@@ -4,7 +4,7 @@
* A simple benchmark program for PostgreSQL
* Originally written by Tatsuo Ishii and enhanced by many contributors.
*
- * contrib/pgbench/pgbench.c
+ * src/bin/pgbench/pgbench.c
* Copyright (c) 2000-2014, PostgreSQL Global Development Group
* ALL RIGHTS RESERVED;
*
--
2.2.0
0006-Move-pg_test_fsync-from-contrib-to-src-bin.patchapplication/x-patch; name=0006-Move-pg_test_fsync-from-contrib-to-src-bin.patchDownload
From 94101dd7ac2c93ea7958b6e6d29c5c039fb63fdb Mon Sep 17 00:00:00 2001
From: Peter Eisentraut <peter_e@gmx.net>
Date: Sun, 14 Dec 2014 20:41:59 -0500
Subject: [PATCH 6/9] Move pg_test_fsync from contrib/ to src/bin/
---
contrib/Makefile | 1 -
contrib/pg_test_fsync/Makefile | 18 ------------------
doc/src/sgml/contrib.sgml | 1 -
doc/src/sgml/reference.sgml | 1 +
src/bin/Makefile | 1 +
{contrib => src/bin}/pg_test_fsync/.gitignore | 0
src/bin/pg_test_fsync/Makefile | 14 ++++++++++++++
{contrib => src/bin}/pg_test_fsync/pg_test_fsync.c | 0
8 files changed, 16 insertions(+), 20 deletions(-)
delete mode 100644 contrib/pg_test_fsync/Makefile
rename {contrib => src/bin}/pg_test_fsync/.gitignore (100%)
create mode 100644 src/bin/pg_test_fsync/Makefile
rename {contrib => src/bin}/pg_test_fsync/pg_test_fsync.c (100%)
diff --git a/contrib/Makefile b/contrib/Makefile
index 12c7500..6809ec8 100644
--- a/contrib/Makefile
+++ b/contrib/Makefile
@@ -32,7 +32,6 @@ SUBDIRS = \
pg_freespacemap \
pg_prewarm \
pg_stat_statements \
- pg_test_fsync \
pg_test_timing \
pg_trgm \
pg_upgrade \
diff --git a/contrib/pg_test_fsync/Makefile b/contrib/pg_test_fsync/Makefile
deleted file mode 100644
index 15afba7..0000000
--- a/contrib/pg_test_fsync/Makefile
+++ /dev/null
@@ -1,18 +0,0 @@
-# contrib/pg_test_fsync/Makefile
-
-PGFILEDESC = "pg_test_fsync - test various disk sync methods"
-PGAPPICON = win32
-
-PROGRAM = pg_test_fsync
-OBJS = pg_test_fsync.o $(WIN32RES)
-
-ifdef USE_PGXS
-PG_CONFIG = pg_config
-PGXS := $(shell $(PG_CONFIG) --pgxs)
-include $(PGXS)
-else
-subdir = contrib/pg_test_fsync
-top_builddir = ../..
-include $(top_builddir)/src/Makefile.global
-include $(top_srcdir)/contrib/contrib-global.mk
-endif
diff --git a/doc/src/sgml/contrib.sgml b/doc/src/sgml/contrib.sgml
index 60c07ea..57f4bbf 100644
--- a/doc/src/sgml/contrib.sgml
+++ b/doc/src/sgml/contrib.sgml
@@ -201,7 +201,6 @@ <title>Server Applications</title>
part of the core <productname>PostgreSQL</productname> distribution.
</para>
- &pgtestfsync;
&pgtesttiming;
&pgupgrade;
</sect1>
diff --git a/doc/src/sgml/reference.sgml b/doc/src/sgml/reference.sgml
index a839af7..c766c7b 100644
--- a/doc/src/sgml/reference.sgml
+++ b/doc/src/sgml/reference.sgml
@@ -263,6 +263,7 @@ <title>PostgreSQL Server Applications</title>
&pgCtl;
&pgResetxlog;
&pgstandby;
+ &pgtestfsync;
&pgxlogdump;
&postgres;
&postmaster;
diff --git a/src/bin/Makefile b/src/bin/Makefile
index 39d7e7d..e628a2c 100644
--- a/src/bin/Makefile
+++ b/src/bin/Makefile
@@ -23,6 +23,7 @@ SUBDIRS = \
pg_dump \
pg_resetxlog \
pg_standby \
+ pg_test_fsync \
pg_xlogdump \
pgbench \
psql \
diff --git a/contrib/pg_test_fsync/.gitignore b/src/bin/pg_test_fsync/.gitignore
similarity index 100%
rename from contrib/pg_test_fsync/.gitignore
rename to src/bin/pg_test_fsync/.gitignore
diff --git a/src/bin/pg_test_fsync/Makefile b/src/bin/pg_test_fsync/Makefile
new file mode 100644
index 0000000..e8d1952
--- /dev/null
+++ b/src/bin/pg_test_fsync/Makefile
@@ -0,0 +1,14 @@
+# src/bin/pg_test_fsync/Makefile
+
+PGFILEDESC = "pg_test_fsync - test various disk sync methods"
+PGAPPICON = win32
+
+subdir = src/bin/pg_test_fsync
+top_builddir = ../../..
+include $(top_builddir)/src/Makefile.global
+
+PROGRAM = pg_test_fsync
+OBJS = pg_test_fsync.o $(WIN32RES)
+
+NO_PGXS = 1
+include $(top_srcdir)/src/makefiles/pgxs.mk
diff --git a/contrib/pg_test_fsync/pg_test_fsync.c b/src/bin/pg_test_fsync/pg_test_fsync.c
similarity index 100%
rename from contrib/pg_test_fsync/pg_test_fsync.c
rename to src/bin/pg_test_fsync/pg_test_fsync.c
--
2.2.0
0007-Move-pg_test_timing-from-contrib-to-src-bin.patchapplication/x-patch; name=0007-Move-pg_test_timing-from-contrib-to-src-bin.patchDownload
From 01401e07f45dc51762080a0f09e2d6625b59233e Mon Sep 17 00:00:00 2001
From: Peter Eisentraut <peter_e@gmx.net>
Date: Sun, 14 Dec 2014 20:41:59 -0500
Subject: [PATCH 7/9] Move pg_test_timing from contrib/ to src/bin/
---
contrib/Makefile | 1 -
contrib/pg_test_timing/Makefile | 18 ------------------
doc/src/sgml/contrib.sgml | 1 -
doc/src/sgml/reference.sgml | 1 +
src/bin/Makefile | 1 +
{contrib => src/bin}/pg_test_timing/.gitignore | 0
src/bin/pg_test_timing/Makefile | 14 ++++++++++++++
{contrib => src/bin}/pg_test_timing/pg_test_timing.c | 0
8 files changed, 16 insertions(+), 20 deletions(-)
delete mode 100644 contrib/pg_test_timing/Makefile
rename {contrib => src/bin}/pg_test_timing/.gitignore (100%)
create mode 100644 src/bin/pg_test_timing/Makefile
rename {contrib => src/bin}/pg_test_timing/pg_test_timing.c (100%)
diff --git a/contrib/Makefile b/contrib/Makefile
index 6809ec8..6ff409b 100644
--- a/contrib/Makefile
+++ b/contrib/Makefile
@@ -32,7 +32,6 @@ SUBDIRS = \
pg_freespacemap \
pg_prewarm \
pg_stat_statements \
- pg_test_timing \
pg_trgm \
pg_upgrade \
pg_upgrade_support \
diff --git a/contrib/pg_test_timing/Makefile b/contrib/pg_test_timing/Makefile
deleted file mode 100644
index 8b37aa8..0000000
--- a/contrib/pg_test_timing/Makefile
+++ /dev/null
@@ -1,18 +0,0 @@
-# contrib/pg_test_timing/Makefile
-
-PGFILEDESC = "pg_test_timing - test timing overhead"
-PGAPPICON = win32
-
-PROGRAM = pg_test_timing
-OBJS = pg_test_timing.o $(WIN32RES)
-
-ifdef USE_PGXS
-PG_CONFIG = pg_config
-PGXS := $(shell $(PG_CONFIG) --pgxs)
-include $(PGXS)
-else
-subdir = contrib/pg_test_timing
-top_builddir = ../..
-include $(top_builddir)/src/Makefile.global
-include $(top_srcdir)/contrib/contrib-global.mk
-endif
diff --git a/doc/src/sgml/contrib.sgml b/doc/src/sgml/contrib.sgml
index 57f4bbf..aa47634 100644
--- a/doc/src/sgml/contrib.sgml
+++ b/doc/src/sgml/contrib.sgml
@@ -201,7 +201,6 @@ <title>Server Applications</title>
part of the core <productname>PostgreSQL</productname> distribution.
</para>
- &pgtesttiming;
&pgupgrade;
</sect1>
</appendix>
diff --git a/doc/src/sgml/reference.sgml b/doc/src/sgml/reference.sgml
index c766c7b..ac0ee62 100644
--- a/doc/src/sgml/reference.sgml
+++ b/doc/src/sgml/reference.sgml
@@ -264,6 +264,7 @@ <title>PostgreSQL Server Applications</title>
&pgResetxlog;
&pgstandby;
&pgtestfsync;
+ &pgtesttiming;
&pgxlogdump;
&postgres;
&postmaster;
diff --git a/src/bin/Makefile b/src/bin/Makefile
index e628a2c..1e65f2e 100644
--- a/src/bin/Makefile
+++ b/src/bin/Makefile
@@ -24,6 +24,7 @@ SUBDIRS = \
pg_resetxlog \
pg_standby \
pg_test_fsync \
+ pg_test_timing \
pg_xlogdump \
pgbench \
psql \
diff --git a/contrib/pg_test_timing/.gitignore b/src/bin/pg_test_timing/.gitignore
similarity index 100%
rename from contrib/pg_test_timing/.gitignore
rename to src/bin/pg_test_timing/.gitignore
diff --git a/src/bin/pg_test_timing/Makefile b/src/bin/pg_test_timing/Makefile
new file mode 100644
index 0000000..f96d2e9
--- /dev/null
+++ b/src/bin/pg_test_timing/Makefile
@@ -0,0 +1,14 @@
+# src/bin/pg_test_timing/Makefile
+
+PGFILEDESC = "pg_test_timing - test timing overhead"
+PGAPPICON = win32
+
+subdir = src/bin/pg_test_timing
+top_builddir = ../../..
+include $(top_builddir)/src/Makefile.global
+
+PROGRAM = pg_test_timing
+OBJS = pg_test_timing.o $(WIN32RES)
+
+NO_PGXS = 1
+include $(top_srcdir)/src/makefiles/pgxs.mk
diff --git a/contrib/pg_test_timing/pg_test_timing.c b/src/bin/pg_test_timing/pg_test_timing.c
similarity index 100%
rename from contrib/pg_test_timing/pg_test_timing.c
rename to src/bin/pg_test_timing/pg_test_timing.c
--
2.2.0
0008-Integrate-pg_upgrade_support-module-into-backend.patchapplication/x-patch; name=0008-Integrate-pg_upgrade_support-module-into-backend.patchDownload
From 7062fabcb4a8fc4e01460c6377bf14cf45b66db3 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut <peter_e@gmx.net>
Date: Sun, 14 Dec 2014 20:41:59 -0500
Subject: [PATCH 8/9] Integrate pg_upgrade_support module into backend
Previously, these functions were created in a schema "binary_upgrade",
which was deleted after pg_upgrade was finished. Because we don't want
to keep that schema around permanently, move them to pg_catalog but
rename them with a binary_upgrade_... prefix.
The provided functions are only small wrappers around global variables
that were added specifically for pg_upgrade use, so keeping the module
separate does not create any modularity.
The functions still check that they are only called in binary upgrade
mode, so it is not possible to call these during normal operation.
---
contrib/Makefile | 1 -
contrib/pg_upgrade/dump.c | 2 +-
contrib/pg_upgrade/function.c | 113 ---------------------
contrib/pg_upgrade/pg_upgrade.c | 27 -----
contrib/pg_upgrade/pg_upgrade.h | 2 -
contrib/pg_upgrade/test.sh | 1 -
contrib/pg_upgrade_support/Makefile | 16 ---
doc/src/sgml/pgupgrade.sgml | 5 +-
src/backend/catalog/heap.c | 2 +-
src/backend/catalog/index.c | 2 +-
src/backend/catalog/pg_enum.c | 2 +-
src/backend/catalog/pg_type.c | 2 +-
src/backend/catalog/toasting.c | 2 +-
src/backend/commands/typecmds.c | 2 +-
src/backend/commands/user.c | 2 +-
src/backend/utils/adt/Makefile | 2 +-
.../backend/utils/adt}/pg_upgrade_support.c | 45 ++++----
src/bin/pg_dump/pg_dump.c | 18 ++--
src/bin/pg_dump/pg_dumpall.c | 2 +-
src/include/catalog/pg_proc.h | 20 ++++
20 files changed, 60 insertions(+), 208 deletions(-)
delete mode 100644 contrib/pg_upgrade_support/Makefile
rename {contrib/pg_upgrade_support => src/backend/utils/adt}/pg_upgrade_support.c (73%)
diff --git a/contrib/Makefile b/contrib/Makefile
index 6ff409b..c20d4fe 100644
--- a/contrib/Makefile
+++ b/contrib/Makefile
@@ -34,7 +34,6 @@ SUBDIRS = \
pg_stat_statements \
pg_trgm \
pg_upgrade \
- pg_upgrade_support \
pgcrypto \
pgrowlocks \
pgstattuple \
diff --git a/contrib/pg_upgrade/dump.c b/contrib/pg_upgrade/dump.c
index e623a22..0dfce2b 100644
--- a/contrib/pg_upgrade/dump.c
+++ b/contrib/pg_upgrade/dump.c
@@ -121,7 +121,7 @@ optionally_create_toast_tables(void)
for (rowno = 0; rowno < ntups; rowno++)
{
/* enable auto-oid-numbered TOAST creation if needed */
- PQclear(executeQueryOrDie(conn, "SELECT binary_upgrade.set_next_toast_pg_class_oid('%d'::pg_catalog.oid);",
+ PQclear(executeQueryOrDie(conn, "SELECT pg_catalog.binary_upgrade_set_next_toast_pg_class_oid('%d'::pg_catalog.oid);",
OPTIONALLY_CREATE_TOAST_OID));
/* dummy command that also triggers check for required TOAST table */
diff --git a/contrib/pg_upgrade/function.c b/contrib/pg_upgrade/function.c
index a4dec6e..091119b 100644
--- a/contrib/pg_upgrade/function.c
+++ b/contrib/pg_upgrade/function.c
@@ -13,112 +13,6 @@
#include "access/transam.h"
-#define PG_UPGRADE_SUPPORT "$libdir/pg_upgrade_support"
-
-/*
- * install_support_functions_in_new_db()
- *
- * pg_upgrade requires some support functions that enable it to modify
- * backend behavior.
- */
-void
-install_support_functions_in_new_db(const char *db_name)
-{
- PGconn *conn = connectToServer(&new_cluster, db_name);
-
- /* suppress NOTICE of dropped objects */
- PQclear(executeQueryOrDie(conn,
- "SET client_min_messages = warning;"));
- PQclear(executeQueryOrDie(conn,
- "DROP SCHEMA IF EXISTS binary_upgrade CASCADE;"));
- PQclear(executeQueryOrDie(conn,
- "RESET client_min_messages;"));
-
- PQclear(executeQueryOrDie(conn,
- "CREATE SCHEMA binary_upgrade;"));
-
- PQclear(executeQueryOrDie(conn,
- "CREATE OR REPLACE FUNCTION "
- "binary_upgrade.set_next_pg_type_oid(OID) "
- "RETURNS VOID "
- "AS '$libdir/pg_upgrade_support' "
- "LANGUAGE C STRICT;"));
- PQclear(executeQueryOrDie(conn,
- "CREATE OR REPLACE FUNCTION "
- "binary_upgrade.set_next_array_pg_type_oid(OID) "
- "RETURNS VOID "
- "AS '$libdir/pg_upgrade_support' "
- "LANGUAGE C STRICT;"));
- PQclear(executeQueryOrDie(conn,
- "CREATE OR REPLACE FUNCTION "
- "binary_upgrade.set_next_toast_pg_type_oid(OID) "
- "RETURNS VOID "
- "AS '$libdir/pg_upgrade_support' "
- "LANGUAGE C STRICT;"));
- PQclear(executeQueryOrDie(conn,
- "CREATE OR REPLACE FUNCTION "
- "binary_upgrade.set_next_heap_pg_class_oid(OID) "
- "RETURNS VOID "
- "AS '$libdir/pg_upgrade_support' "
- "LANGUAGE C STRICT;"));
- PQclear(executeQueryOrDie(conn,
- "CREATE OR REPLACE FUNCTION "
- "binary_upgrade.set_next_index_pg_class_oid(OID) "
- "RETURNS VOID "
- "AS '$libdir/pg_upgrade_support' "
- "LANGUAGE C STRICT;"));
- PQclear(executeQueryOrDie(conn,
- "CREATE OR REPLACE FUNCTION "
- "binary_upgrade.set_next_toast_pg_class_oid(OID) "
- "RETURNS VOID "
- "AS '$libdir/pg_upgrade_support' "
- "LANGUAGE C STRICT;"));
- PQclear(executeQueryOrDie(conn,
- "CREATE OR REPLACE FUNCTION "
- "binary_upgrade.set_next_pg_enum_oid(OID) "
- "RETURNS VOID "
- "AS '$libdir/pg_upgrade_support' "
- "LANGUAGE C STRICT;"));
- PQclear(executeQueryOrDie(conn,
- "CREATE OR REPLACE FUNCTION "
- "binary_upgrade.set_next_pg_authid_oid(OID) "
- "RETURNS VOID "
- "AS '$libdir/pg_upgrade_support' "
- "LANGUAGE C STRICT;"));
- PQclear(executeQueryOrDie(conn,
- "CREATE OR REPLACE FUNCTION "
- "binary_upgrade.create_empty_extension(text, text, bool, text, oid[], text[], text[]) "
- "RETURNS VOID "
- "AS '$libdir/pg_upgrade_support' "
- "LANGUAGE C;"));
- PQfinish(conn);
-}
-
-
-void
-uninstall_support_functions_from_new_cluster(void)
-{
- int dbnum;
-
- prep_status("Removing support functions from new cluster");
-
- for (dbnum = 0; dbnum < new_cluster.dbarr.ndbs; dbnum++)
- {
- DbInfo *new_db = &new_cluster.dbarr.dbs[dbnum];
- PGconn *conn = connectToServer(&new_cluster, new_db->db_name);
-
- /* suppress NOTICE of dropped objects */
- PQclear(executeQueryOrDie(conn,
- "SET client_min_messages = warning;"));
- PQclear(executeQueryOrDie(conn,
- "DROP SCHEMA binary_upgrade CASCADE;"));
- PQclear(executeQueryOrDie(conn,
- "RESET client_min_messages;"));
- PQfinish(conn);
- }
- check_ok();
-}
-
/*
* get_loadable_libraries()
@@ -218,8 +112,6 @@ get_loadable_libraries(void)
if (found_public_plpython_handler)
pg_fatal("Remove the problem functions from the old cluster to continue.\n");
- totaltups++; /* reserve for pg_upgrade_support */
-
/* Allocate what's certainly enough space */
os_info.libraries = (char **) pg_malloc(totaltups * sizeof(char *));
@@ -228,7 +120,6 @@ get_loadable_libraries(void)
* there probably aren't enough entries to matter.
*/
totaltups = 0;
- os_info.libraries[totaltups++] = pg_strdup(PG_UPGRADE_SUPPORT);
for (dbnum = 0; dbnum < old_cluster.dbarr.ndbs; dbnum++)
{
@@ -321,10 +212,6 @@ check_loadable_libraries(void)
{
found = true;
- /* exit and report missing support library with special message */
- if (strcmp(lib, PG_UPGRADE_SUPPORT) == 0)
- pg_fatal("The pg_upgrade_support module must be created and installed in the new cluster.\n");
-
if (script == NULL && (script = fopen_priv(output_path, "w")) == NULL)
pg_fatal("Could not open file \"%s\": %s\n",
output_path, getErrorText(errno));
diff --git a/contrib/pg_upgrade/pg_upgrade.c b/contrib/pg_upgrade/pg_upgrade.c
index dd1113e..17c988e 100644
--- a/contrib/pg_upgrade/pg_upgrade.c
+++ b/contrib/pg_upgrade/pg_upgrade.c
@@ -276,14 +276,6 @@ prepare_new_databases(void)
prep_status("Restoring global objects in the new cluster");
/*
- * Install support functions in the global-object restore database to
- * preserve pg_authid.oid. pg_dumpall uses 'template0' as its template
- * database so objects we add into 'template1' are not propogated. They
- * are removed on pg_upgrade exit.
- */
- install_support_functions_in_new_db("template1");
-
- /*
* We have to create the databases first so we can install support
* functions in all the other databases. Ideally we could create the
* support functions in template1 but pg_dumpall creates database using
@@ -305,23 +297,6 @@ create_new_objects(void)
{
int dbnum;
- prep_status("Adding support functions to new cluster");
-
- /*
- * Technically, we only need to install these support functions in new
- * databases that also exist in the old cluster, but for completeness we
- * process all new databases.
- */
- for (dbnum = 0; dbnum < new_cluster.dbarr.ndbs; dbnum++)
- {
- DbInfo *new_db = &new_cluster.dbarr.dbs[dbnum];
-
- /* skip db we already installed */
- if (strcmp(new_db->db_name, "template1") != 0)
- install_support_functions_in_new_db(new_db->db_name);
- }
- check_ok();
-
prep_status("Restoring database schemas in the new cluster\n");
for (dbnum = 0; dbnum < old_cluster.dbarr.ndbs; dbnum++)
@@ -365,8 +340,6 @@ create_new_objects(void)
/* regenerate now that we have objects in the databases */
get_db_and_rel_infos(&new_cluster);
-
- uninstall_support_functions_from_new_cluster();
}
/*
diff --git a/contrib/pg_upgrade/pg_upgrade.h b/contrib/pg_upgrade/pg_upgrade.h
index c3b81e4..d20c1ef 100644
--- a/contrib/pg_upgrade/pg_upgrade.h
+++ b/contrib/pg_upgrade/pg_upgrade.h
@@ -406,8 +406,6 @@ FILE *fopen_priv(const char *path, const char *mode);
/* function.c */
-void install_support_functions_in_new_db(const char *db_name);
-void uninstall_support_functions_from_new_cluster(void);
void get_loadable_libraries(void);
void check_loadable_libraries(void);
diff --git a/contrib/pg_upgrade/test.sh b/contrib/pg_upgrade/test.sh
index 7bbd2c7..81aae74 100644
--- a/contrib/pg_upgrade/test.sh
+++ b/contrib/pg_upgrade/test.sh
@@ -63,7 +63,6 @@ if [ "$1" = '--install' ]; then
libdir=$temp_install/$libdir
"$MAKE" -s -C ../.. install DESTDIR="$temp_install"
- "$MAKE" -s -C ../pg_upgrade_support install DESTDIR="$temp_install"
"$MAKE" -s -C . install DESTDIR="$temp_install"
# platform-specific magic to find the shared libraries; see pg_regress.c
diff --git a/contrib/pg_upgrade_support/Makefile b/contrib/pg_upgrade_support/Makefile
deleted file mode 100644
index f7def16..0000000
--- a/contrib/pg_upgrade_support/Makefile
+++ /dev/null
@@ -1,16 +0,0 @@
-# contrib/pg_upgrade_support/Makefile
-
-PGFILEDESC = "pg_upgrade_support - server-side functions for pg_upgrade"
-
-MODULES = pg_upgrade_support
-
-ifdef USE_PGXS
-PG_CONFIG = pg_config
-PGXS := $(shell $(PG_CONFIG) --pgxs)
-include $(PGXS)
-else
-subdir = contrib/pg_upgrade_support
-top_builddir = ../..
-include $(top_builddir)/src/Makefile.global
-include $(top_srcdir)/contrib/contrib-global.mk
-endif
diff --git a/doc/src/sgml/pgupgrade.sgml b/doc/src/sgml/pgupgrade.sgml
index e1cd260..8d70727 100644
--- a/doc/src/sgml/pgupgrade.sgml
+++ b/doc/src/sgml/pgupgrade.sgml
@@ -253,11 +253,10 @@ <title>Install the new PostgreSQL binaries</title>
</step>
<step>
- <title>Install pg_upgrade and pg_upgrade_support</title>
+ <title>Install pg_upgrade</title>
<para>
- Install the <application>pg_upgrade</> binary and
- <application>pg_upgrade_support</> library in the new PostgreSQL
+ Install the <application>pg_upgrade</> binary in the new PostgreSQL
installation.
</para>
</step>
diff --git a/src/backend/catalog/heap.c b/src/backend/catalog/heap.c
index e523ee9..c7392e9 100644
--- a/src/backend/catalog/heap.c
+++ b/src/backend/catalog/heap.c
@@ -76,7 +76,7 @@
#include "utils/tqual.h"
-/* Potentially set by contrib/pg_upgrade_support functions */
+/* Potentially set by pg_upgrade_support functions */
Oid binary_upgrade_next_heap_pg_class_oid = InvalidOid;
Oid binary_upgrade_next_toast_pg_class_oid = InvalidOid;
diff --git a/src/backend/catalog/index.c b/src/backend/catalog/index.c
index 844d413..f096fd5 100644
--- a/src/backend/catalog/index.c
+++ b/src/backend/catalog/index.c
@@ -69,7 +69,7 @@
#include "utils/tqual.h"
-/* Potentially set by contrib/pg_upgrade_support functions */
+/* Potentially set by pg_upgrade_support functions */
Oid binary_upgrade_next_index_pg_class_oid = InvalidOid;
/* state info for validate_index bulkdelete callback */
diff --git a/src/backend/catalog/pg_enum.c b/src/backend/catalog/pg_enum.c
index 086e80e..d1209a0 100644
--- a/src/backend/catalog/pg_enum.c
+++ b/src/backend/catalog/pg_enum.c
@@ -31,7 +31,7 @@
#include "utils/tqual.h"
-/* Potentially set by contrib/pg_upgrade_support functions */
+/* Potentially set by pg_upgrade_support functions */
Oid binary_upgrade_next_pg_enum_oid = InvalidOid;
static void RenumberEnumType(Relation pg_enum, HeapTuple *existing, int nelems);
diff --git a/src/backend/catalog/pg_type.c b/src/backend/catalog/pg_type.c
index f1329f8..1c84a71 100644
--- a/src/backend/catalog/pg_type.c
+++ b/src/backend/catalog/pg_type.c
@@ -36,7 +36,7 @@
#include "utils/rel.h"
#include "utils/syscache.h"
-/* Potentially set by contrib/pg_upgrade_support functions */
+/* Potentially set by pg_upgrade_support functions */
Oid binary_upgrade_next_pg_type_oid = InvalidOid;
/* ----------------------------------------------------------------
diff --git a/src/backend/catalog/toasting.c b/src/backend/catalog/toasting.c
index 5ef6dcc..2532154 100644
--- a/src/backend/catalog/toasting.c
+++ b/src/backend/catalog/toasting.c
@@ -32,7 +32,7 @@
#include "utils/rel.h"
#include "utils/syscache.h"
-/* Potentially set by contrib/pg_upgrade_support functions */
+/* Potentially set by pg_upgrade_support functions */
Oid binary_upgrade_next_toast_pg_type_oid = InvalidOid;
static void CheckAndCreateToastTable(Oid relOid, Datum reloptions,
diff --git a/src/backend/commands/typecmds.c b/src/backend/commands/typecmds.c
index cbb65f8..c9fd191 100644
--- a/src/backend/commands/typecmds.c
+++ b/src/backend/commands/typecmds.c
@@ -87,7 +87,7 @@ typedef struct
/* atts[] is of allocated length RelationGetNumberOfAttributes(rel) */
} RelToCheck;
-/* Potentially set by contrib/pg_upgrade_support functions */
+/* Potentially set by pg_upgrade_support functions */
Oid binary_upgrade_next_array_pg_type_oid = InvalidOid;
static void makeRangeConstructors(const char *name, Oid namespace,
diff --git a/src/backend/commands/user.c b/src/backend/commands/user.c
index 1a73fd8..3f003d3 100644
--- a/src/backend/commands/user.c
+++ b/src/backend/commands/user.c
@@ -38,7 +38,7 @@
#include "utils/timestamp.h"
#include "utils/tqual.h"
-/* Potentially set by contrib/pg_upgrade_support functions */
+/* Potentially set by pg_upgrade_support functions */
Oid binary_upgrade_next_pg_authid_oid = InvalidOid;
diff --git a/src/backend/utils/adt/Makefile b/src/backend/utils/adt/Makefile
index 3ea9bf4..732974b 100644
--- a/src/backend/utils/adt/Makefile
+++ b/src/backend/utils/adt/Makefile
@@ -25,7 +25,7 @@ OBJS = acl.o arrayfuncs.o array_selfuncs.o array_typanalyze.o \
jsonfuncs.o like.o lockfuncs.o mac.o misc.o nabstime.o name.o \
network.o network_gist.o network_selfuncs.o \
numeric.o numutils.o oid.o oracle_compat.o \
- orderedsetaggs.o pg_lzcompress.o pg_locale.o pg_lsn.o \
+ orderedsetaggs.o pg_lzcompress.o pg_locale.o pg_lsn.o pg_upgrade_support.o \
pgstatfuncs.o pseudotypes.o quote.o rangetypes.o rangetypes_gist.o \
rangetypes_selfuncs.o rangetypes_spgist.o rangetypes_typanalyze.o \
regexp.o regproc.o ri_triggers.o rowtypes.o ruleutils.o \
diff --git a/contrib/pg_upgrade_support/pg_upgrade_support.c b/src/backend/utils/adt/pg_upgrade_support.c
similarity index 73%
rename from contrib/pg_upgrade_support/pg_upgrade_support.c
rename to src/backend/utils/adt/pg_upgrade_support.c
index beaee76..89a104b 100644
--- a/contrib/pg_upgrade_support/pg_upgrade_support.c
+++ b/src/backend/utils/adt/pg_upgrade_support.c
@@ -6,7 +6,7 @@
* hacks needed for pg_upgrade.
*
* Copyright (c) 2010-2014, PostgreSQL Global Development Group
- * contrib/pg_upgrade_support/pg_upgrade_support.c
+ * src/backend/utils/adt/pg_upgrade_support.c
*/
#include "postgres.h"
@@ -19,24 +19,17 @@
#include "utils/array.h"
#include "utils/builtins.h"
-/* THIS IS USED ONLY FOR PG >= 9.0 */
-#ifdef PG_MODULE_MAGIC
-PG_MODULE_MAGIC;
-#endif
+Datum binary_upgrade_set_next_pg_type_oid(PG_FUNCTION_ARGS);
+Datum binary_upgrade_set_next_array_pg_type_oid(PG_FUNCTION_ARGS);
+Datum binary_upgrade_set_next_toast_pg_type_oid(PG_FUNCTION_ARGS);
+Datum binary_upgrade_set_next_heap_pg_class_oid(PG_FUNCTION_ARGS);
+Datum binary_upgrade_set_next_index_pg_class_oid(PG_FUNCTION_ARGS);
+Datum binary_upgrade_set_next_toast_pg_class_oid(PG_FUNCTION_ARGS);
+Datum binary_upgrade_set_next_pg_enum_oid(PG_FUNCTION_ARGS);
+Datum binary_upgrade_set_next_pg_authid_oid(PG_FUNCTION_ARGS);
+Datum binary_upgrade_create_empty_extension(PG_FUNCTION_ARGS);
-PG_FUNCTION_INFO_V1(set_next_pg_type_oid);
-PG_FUNCTION_INFO_V1(set_next_array_pg_type_oid);
-PG_FUNCTION_INFO_V1(set_next_toast_pg_type_oid);
-
-PG_FUNCTION_INFO_V1(set_next_heap_pg_class_oid);
-PG_FUNCTION_INFO_V1(set_next_index_pg_class_oid);
-PG_FUNCTION_INFO_V1(set_next_toast_pg_class_oid);
-
-PG_FUNCTION_INFO_V1(set_next_pg_enum_oid);
-PG_FUNCTION_INFO_V1(set_next_pg_authid_oid);
-
-PG_FUNCTION_INFO_V1(create_empty_extension);
#define CHECK_IS_BINARY_UPGRADE \
do { \
@@ -47,7 +40,7 @@ do { \
} while (0)
Datum
-set_next_pg_type_oid(PG_FUNCTION_ARGS)
+binary_upgrade_set_next_pg_type_oid(PG_FUNCTION_ARGS)
{
Oid typoid = PG_GETARG_OID(0);
@@ -58,7 +51,7 @@ set_next_pg_type_oid(PG_FUNCTION_ARGS)
}
Datum
-set_next_array_pg_type_oid(PG_FUNCTION_ARGS)
+binary_upgrade_set_next_array_pg_type_oid(PG_FUNCTION_ARGS)
{
Oid typoid = PG_GETARG_OID(0);
@@ -69,7 +62,7 @@ set_next_array_pg_type_oid(PG_FUNCTION_ARGS)
}
Datum
-set_next_toast_pg_type_oid(PG_FUNCTION_ARGS)
+binary_upgrade_set_next_toast_pg_type_oid(PG_FUNCTION_ARGS)
{
Oid typoid = PG_GETARG_OID(0);
@@ -80,7 +73,7 @@ set_next_toast_pg_type_oid(PG_FUNCTION_ARGS)
}
Datum
-set_next_heap_pg_class_oid(PG_FUNCTION_ARGS)
+binary_upgrade_set_next_heap_pg_class_oid(PG_FUNCTION_ARGS)
{
Oid reloid = PG_GETARG_OID(0);
@@ -91,7 +84,7 @@ set_next_heap_pg_class_oid(PG_FUNCTION_ARGS)
}
Datum
-set_next_index_pg_class_oid(PG_FUNCTION_ARGS)
+binary_upgrade_set_next_index_pg_class_oid(PG_FUNCTION_ARGS)
{
Oid reloid = PG_GETARG_OID(0);
@@ -102,7 +95,7 @@ set_next_index_pg_class_oid(PG_FUNCTION_ARGS)
}
Datum
-set_next_toast_pg_class_oid(PG_FUNCTION_ARGS)
+binary_upgrade_set_next_toast_pg_class_oid(PG_FUNCTION_ARGS)
{
Oid reloid = PG_GETARG_OID(0);
@@ -113,7 +106,7 @@ set_next_toast_pg_class_oid(PG_FUNCTION_ARGS)
}
Datum
-set_next_pg_enum_oid(PG_FUNCTION_ARGS)
+binary_upgrade_set_next_pg_enum_oid(PG_FUNCTION_ARGS)
{
Oid enumoid = PG_GETARG_OID(0);
@@ -124,7 +117,7 @@ set_next_pg_enum_oid(PG_FUNCTION_ARGS)
}
Datum
-set_next_pg_authid_oid(PG_FUNCTION_ARGS)
+binary_upgrade_set_next_pg_authid_oid(PG_FUNCTION_ARGS)
{
Oid authoid = PG_GETARG_OID(0);
@@ -134,7 +127,7 @@ set_next_pg_authid_oid(PG_FUNCTION_ARGS)
}
Datum
-create_empty_extension(PG_FUNCTION_ARGS)
+binary_upgrade_create_empty_extension(PG_FUNCTION_ARGS)
{
text *extName = PG_GETARG_TEXT_PP(0);
text *schemaName = PG_GETARG_TEXT_PP(1);
diff --git a/src/bin/pg_dump/pg_dump.c b/src/bin/pg_dump/pg_dump.c
index 4175ddc..6c5261b 100644
--- a/src/bin/pg_dump/pg_dump.c
+++ b/src/bin/pg_dump/pg_dump.c
@@ -3014,7 +3014,7 @@ binary_upgrade_set_type_oids_by_type_oid(Archive *fout,
appendPQExpBufferStr(upgrade_buffer, "\n-- For binary upgrade, must preserve pg_type oid\n");
appendPQExpBuffer(upgrade_buffer,
- "SELECT binary_upgrade.set_next_pg_type_oid('%u'::pg_catalog.oid);\n\n",
+ "SELECT pg_catalog.binary_upgrade_set_next_pg_type_oid('%u'::pg_catalog.oid);\n\n",
pg_type_oid);
/* we only support old >= 8.3 for binary upgrades */
@@ -3033,7 +3033,7 @@ binary_upgrade_set_type_oids_by_type_oid(Archive *fout,
appendPQExpBufferStr(upgrade_buffer,
"\n-- For binary upgrade, must preserve pg_type array oid\n");
appendPQExpBuffer(upgrade_buffer,
- "SELECT binary_upgrade.set_next_array_pg_type_oid('%u'::pg_catalog.oid);\n\n",
+ "SELECT pg_catalog.binary_upgrade_set_next_array_pg_type_oid('%u'::pg_catalog.oid);\n\n",
pg_type_array_oid);
}
@@ -3075,7 +3075,7 @@ binary_upgrade_set_type_oids_by_rel_oid(Archive *fout,
appendPQExpBufferStr(upgrade_buffer, "\n-- For binary upgrade, must preserve pg_type toast oid\n");
appendPQExpBuffer(upgrade_buffer,
- "SELECT binary_upgrade.set_next_toast_pg_type_oid('%u'::pg_catalog.oid);\n\n",
+ "SELECT pg_catalog.binary_upgrade_set_next_toast_pg_type_oid('%u'::pg_catalog.oid);\n\n",
pg_type_toast_oid);
toast_set = true;
@@ -3115,7 +3115,7 @@ binary_upgrade_set_pg_class_oids(Archive *fout,
if (!is_index)
{
appendPQExpBuffer(upgrade_buffer,
- "SELECT binary_upgrade.set_next_heap_pg_class_oid('%u'::pg_catalog.oid);\n",
+ "SELECT pg_catalog.binary_upgrade_set_next_heap_pg_class_oid('%u'::pg_catalog.oid);\n",
pg_class_oid);
/* only tables have toast tables, not indexes */
if (OidIsValid(pg_class_reltoastrelid))
@@ -3130,18 +3130,18 @@ binary_upgrade_set_pg_class_oids(Archive *fout,
*/
appendPQExpBuffer(upgrade_buffer,
- "SELECT binary_upgrade.set_next_toast_pg_class_oid('%u'::pg_catalog.oid);\n",
+ "SELECT pg_catalog.binary_upgrade_set_next_toast_pg_class_oid('%u'::pg_catalog.oid);\n",
pg_class_reltoastrelid);
/* every toast table has an index */
appendPQExpBuffer(upgrade_buffer,
- "SELECT binary_upgrade.set_next_index_pg_class_oid('%u'::pg_catalog.oid);\n",
+ "SELECT pg_catalog.binary_upgrade_set_next_index_pg_class_oid('%u'::pg_catalog.oid);\n",
pg_index_indexrelid);
}
}
else
appendPQExpBuffer(upgrade_buffer,
- "SELECT binary_upgrade.set_next_index_pg_class_oid('%u'::pg_catalog.oid);\n",
+ "SELECT pg_catalog.binary_upgrade_set_next_index_pg_class_oid('%u'::pg_catalog.oid);\n",
pg_class_oid);
appendPQExpBufferChar(upgrade_buffer, '\n');
@@ -8360,7 +8360,7 @@ dumpExtension(Archive *fout, DumpOptions *dopt, ExtensionInfo *extinfo)
appendPQExpBuffer(q, "DROP EXTENSION IF EXISTS %s;\n", qextname);
appendPQExpBufferStr(q,
- "SELECT binary_upgrade.create_empty_extension(");
+ "SELECT pg_catalog.binary_upgrade_create_empty_extension(");
appendStringLiteralAH(q, extinfo->dobj.name, fout);
appendPQExpBufferStr(q, ", ");
appendStringLiteralAH(q, extinfo->namespace, fout);
@@ -8538,7 +8538,7 @@ dumpEnumType(Archive *fout, DumpOptions *dopt, TypeInfo *tyinfo)
if (i == 0)
appendPQExpBufferStr(q, "\n-- For binary upgrade, must preserve pg_enum oids\n");
appendPQExpBuffer(q,
- "SELECT binary_upgrade.set_next_pg_enum_oid('%u'::pg_catalog.oid);\n",
+ "SELECT pg_catalog.binary_upgrade_set_next_pg_enum_oid('%u'::pg_catalog.oid);\n",
enum_oid);
appendPQExpBuffer(q, "ALTER TYPE %s.",
fmtId(tyinfo->dobj.namespace->dobj.name));
diff --git a/src/bin/pg_dump/pg_dumpall.c b/src/bin/pg_dump/pg_dumpall.c
index eb633bc..1955932 100644
--- a/src/bin/pg_dump/pg_dumpall.c
+++ b/src/bin/pg_dump/pg_dumpall.c
@@ -781,7 +781,7 @@ dumpRoles(PGconn *conn)
{
appendPQExpBufferStr(buf, "\n-- For binary upgrade, must preserve pg_authid.oid\n");
appendPQExpBuffer(buf,
- "SELECT binary_upgrade.set_next_pg_authid_oid('%u'::pg_catalog.oid);\n\n",
+ "SELECT pg_catalog.binary_upgrade_set_next_pg_authid_oid('%u'::pg_catalog.oid);\n\n",
auth_oid);
}
diff --git a/src/include/catalog/pg_proc.h b/src/include/catalog/pg_proc.h
index e5912ea..6ab05de 100644
--- a/src/include/catalog/pg_proc.h
+++ b/src/include/catalog/pg_proc.h
@@ -5135,6 +5135,26 @@ DESCR("rank of hypothetical row without gaps");
DATA(insert OID = 3993 ( dense_rank_final PGNSP PGUID 12 1 0 2276 0 f f f f f f i 2 0 20 "2281 2276" "{2281,2276}" "{i,v}" _null_ _null_ hypothetical_dense_rank_final _null_ _null_ _null_ ));
DESCR("aggregate final function");
+/* pg_upgrade support */
+DATA(insert OID = 3584 ( binary_upgrade_set_next_pg_type_oid PGNSP PGUID 12 1 0 0 0 f f f f t f v 1 0 2278 "26" _null_ _null_ _null_ _null_ binary_upgrade_set_next_pg_type_oid _null_ _null_ _null_ ));
+DESCR("for use by pg_upgrade");
+DATA(insert OID = 3585 ( binary_upgrade_set_next_array_pg_type_oid PGNSP PGUID 12 1 0 0 0 f f f f t f v 1 0 2278 "26" _null_ _null_ _null_ _null_ binary_upgrade_set_next_array_pg_type_oid _null_ _null_ _null_ ));
+DESCR("for use by pg_upgrade");
+DATA(insert OID = 3586 ( binary_upgrade_set_next_toast_pg_type_oid PGNSP PGUID 12 1 0 0 0 f f f f t f v 1 0 2278 "26" _null_ _null_ _null_ _null_ binary_upgrade_set_next_toast_pg_type_oid _null_ _null_ _null_ ));
+DESCR("for use by pg_upgrade");
+DATA(insert OID = 3587 ( binary_upgrade_set_next_heap_pg_class_oid PGNSP PGUID 12 1 0 0 0 f f f f t f v 1 0 2278 "26" _null_ _null_ _null_ _null_ binary_upgrade_set_next_heap_pg_class_oid _null_ _null_ _null_ ));
+DESCR("for use by pg_upgrade");
+DATA(insert OID = 3588 ( binary_upgrade_set_next_index_pg_class_oid PGNSP PGUID 12 1 0 0 0 f f f f t f v 1 0 2278 "26" _null_ _null_ _null_ _null_ binary_upgrade_set_next_index_pg_class_oid _null_ _null_ _null_ ));
+DESCR("for use by pg_upgrade");
+DATA(insert OID = 3589 ( binary_upgrade_set_next_toast_pg_class_oid PGNSP PGUID 12 1 0 0 0 f f f f t f v 1 0 2278 "26" _null_ _null_ _null_ _null_ binary_upgrade_set_next_toast_pg_class_oid _null_ _null_ _null_ ));
+DESCR("for use by pg_upgrade");
+DATA(insert OID = 3590 ( binary_upgrade_set_next_pg_enum_oid PGNSP PGUID 12 1 0 0 0 f f f f t f v 1 0 2278 "26" _null_ _null_ _null_ _null_ binary_upgrade_set_next_pg_enum_oid _null_ _null_ _null_ ));
+DESCR("for use by pg_upgrade");
+DATA(insert OID = 3591 ( binary_upgrade_set_next_pg_authid_oid PGNSP PGUID 12 1 0 0 0 f f f f t f v 1 0 2278 "26" _null_ _null_ _null_ _null_ binary_upgrade_set_next_pg_authid_oid _null_ _null_ _null_ ));
+DESCR("for use by pg_upgrade");
+DATA(insert OID = 3788 ( binary_upgrade_create_empty_extension PGNSP PGUID 12 1 0 0 0 f f f f t f v 7 0 2278 "25 25 16 25 1028 1009 1009" _null_ _null_ _null_ _null_ binary_upgrade_create_empty_extension _null_ _null_ _null_ ));
+DESCR("for use by pg_upgrade");
+
/*
* Symbolic values for provolatile column: these indicate whether the result
--
2.2.0
0009-Move-pg_upgrade-from-contrib-to-src-bin.patchapplication/x-patch; name=0009-Move-pg_upgrade-from-contrib-to-src-bin.patchDownload
From 86310e6cbc986a5f13e60fba129c10edd648d099 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut <peter_e@gmx.net>
Date: Sun, 14 Dec 2014 20:41:59 -0500
Subject: [PATCH 9/9] Move pg_upgrade from contrib/ to src/bin/
---
contrib/Makefile | 1 -
doc/src/sgml/contrib.sgml | 1 -
doc/src/sgml/pgupgrade.sgml | 12 ++----------
doc/src/sgml/reference.sgml | 1 +
src/bin/Makefile | 1 +
{contrib => src/bin}/pg_upgrade/.gitignore | 0
{contrib => src/bin}/pg_upgrade/IMPLEMENTATION | 2 --
{contrib => src/bin}/pg_upgrade/Makefile | 18 +++++++-----------
{contrib => src/bin}/pg_upgrade/TESTING | 2 --
{contrib => src/bin}/pg_upgrade/check.c | 2 +-
{contrib => src/bin}/pg_upgrade/controldata.c | 2 +-
{contrib => src/bin}/pg_upgrade/dump.c | 2 +-
{contrib => src/bin}/pg_upgrade/exec.c | 2 +-
{contrib => src/bin}/pg_upgrade/file.c | 2 +-
{contrib => src/bin}/pg_upgrade/function.c | 2 +-
{contrib => src/bin}/pg_upgrade/info.c | 2 +-
{contrib => src/bin}/pg_upgrade/option.c | 2 +-
{contrib => src/bin}/pg_upgrade/page.c | 2 +-
{contrib => src/bin}/pg_upgrade/parallel.c | 2 +-
{contrib => src/bin}/pg_upgrade/pg_upgrade.c | 2 +-
{contrib => src/bin}/pg_upgrade/pg_upgrade.h | 2 +-
{contrib => src/bin}/pg_upgrade/relfilenode.c | 2 +-
{contrib => src/bin}/pg_upgrade/server.c | 2 +-
{contrib => src/bin}/pg_upgrade/tablespace.c | 2 +-
{contrib => src/bin}/pg_upgrade/test.sh | 6 +++---
{contrib => src/bin}/pg_upgrade/util.c | 2 +-
{contrib => src/bin}/pg_upgrade/version.c | 2 +-
27 files changed, 31 insertions(+), 47 deletions(-)
rename {contrib => src/bin}/pg_upgrade/.gitignore (100%)
rename {contrib => src/bin}/pg_upgrade/IMPLEMENTATION (99%)
rename {contrib => src/bin}/pg_upgrade/Makefile (79%)
rename {contrib => src/bin}/pg_upgrade/TESTING (99%)
rename {contrib => src/bin}/pg_upgrade/check.c (99%)
rename {contrib => src/bin}/pg_upgrade/controldata.c (99%)
rename {contrib => src/bin}/pg_upgrade/dump.c (99%)
rename {contrib => src/bin}/pg_upgrade/exec.c (99%)
rename {contrib => src/bin}/pg_upgrade/file.c (99%)
rename {contrib => src/bin}/pg_upgrade/function.c (99%)
rename {contrib => src/bin}/pg_upgrade/info.c (99%)
rename {contrib => src/bin}/pg_upgrade/option.c (99%)
rename {contrib => src/bin}/pg_upgrade/page.c (99%)
rename {contrib => src/bin}/pg_upgrade/parallel.c (99%)
rename {contrib => src/bin}/pg_upgrade/pg_upgrade.c (99%)
rename {contrib => src/bin}/pg_upgrade/pg_upgrade.h (99%)
rename {contrib => src/bin}/pg_upgrade/relfilenode.c (99%)
rename {contrib => src/bin}/pg_upgrade/server.c (99%)
rename {contrib => src/bin}/pg_upgrade/tablespace.c (98%)
rename {contrib => src/bin}/pg_upgrade/test.sh (98%)
rename {contrib => src/bin}/pg_upgrade/util.c (99%)
rename {contrib => src/bin}/pg_upgrade/version.c (99%)
diff --git a/contrib/Makefile b/contrib/Makefile
index c20d4fe..a30eb5a 100644
--- a/contrib/Makefile
+++ b/contrib/Makefile
@@ -33,7 +33,6 @@ SUBDIRS = \
pg_prewarm \
pg_stat_statements \
pg_trgm \
- pg_upgrade \
pgcrypto \
pgrowlocks \
pgstattuple \
diff --git a/doc/src/sgml/contrib.sgml b/doc/src/sgml/contrib.sgml
index aa47634..a8982db 100644
--- a/doc/src/sgml/contrib.sgml
+++ b/doc/src/sgml/contrib.sgml
@@ -201,6 +201,5 @@ <title>Server Applications</title>
part of the core <productname>PostgreSQL</productname> distribution.
</para>
- &pgupgrade;
</sect1>
</appendix>
diff --git a/doc/src/sgml/pgupgrade.sgml b/doc/src/sgml/pgupgrade.sgml
index 8d70727..bee62c4 100644
--- a/doc/src/sgml/pgupgrade.sgml
+++ b/doc/src/sgml/pgupgrade.sgml
@@ -240,7 +240,8 @@ <title>For source installs, build the new version</title>
<title>Install the new PostgreSQL binaries</title>
<para>
- Install the new server's binaries and support files.
+ Install the new server's binaries and support
+ files. <application>pg_upgrade</> is included in a default installation.
</para>
<para>
@@ -253,15 +254,6 @@ <title>Install the new PostgreSQL binaries</title>
</step>
<step>
- <title>Install pg_upgrade</title>
-
- <para>
- Install the <application>pg_upgrade</> binary in the new PostgreSQL
- installation.
- </para>
- </step>
-
- <step>
<title>Initialize the new PostgreSQL cluster</title>
<para>
diff --git a/doc/src/sgml/reference.sgml b/doc/src/sgml/reference.sgml
index ac0ee62..a26ec9f 100644
--- a/doc/src/sgml/reference.sgml
+++ b/doc/src/sgml/reference.sgml
@@ -265,6 +265,7 @@ <title>PostgreSQL Server Applications</title>
&pgstandby;
&pgtestfsync;
&pgtesttiming;
+ &pgupgrade;
&pgxlogdump;
&postgres;
&postmaster;
diff --git a/src/bin/Makefile b/src/bin/Makefile
index 1e65f2e..1572521 100644
--- a/src/bin/Makefile
+++ b/src/bin/Makefile
@@ -25,6 +25,7 @@ SUBDIRS = \
pg_standby \
pg_test_fsync \
pg_test_timing \
+ pg_upgrade \
pg_xlogdump \
pgbench \
psql \
diff --git a/contrib/pg_upgrade/.gitignore b/src/bin/pg_upgrade/.gitignore
similarity index 100%
rename from contrib/pg_upgrade/.gitignore
rename to src/bin/pg_upgrade/.gitignore
diff --git a/contrib/pg_upgrade/IMPLEMENTATION b/src/bin/pg_upgrade/IMPLEMENTATION
similarity index 99%
rename from contrib/pg_upgrade/IMPLEMENTATION
rename to src/bin/pg_upgrade/IMPLEMENTATION
index a0cfcf1..9b5ff72 100644
--- a/contrib/pg_upgrade/IMPLEMENTATION
+++ b/src/bin/pg_upgrade/IMPLEMENTATION
@@ -1,5 +1,3 @@
-contrib/pg_upgrade/IMPLEMENTATION
-
------------------------------------------------------------------------------
PG_UPGRADE: IN-PLACE UPGRADES FOR POSTGRESQL
------------------------------------------------------------------------------
diff --git a/contrib/pg_upgrade/Makefile b/src/bin/pg_upgrade/Makefile
similarity index 79%
rename from contrib/pg_upgrade/Makefile
rename to src/bin/pg_upgrade/Makefile
index 87da4b8..c22daa5 100644
--- a/contrib/pg_upgrade/Makefile
+++ b/src/bin/pg_upgrade/Makefile
@@ -1,8 +1,12 @@
-# contrib/pg_upgrade/Makefile
+# src/bin/pg_upgrade/Makefile
PGFILEDESC = "pg_upgrade - an in-place binary upgrade utility"
PGAPPICON = win32
+subdir = src/bin/pg_upgrade
+top_builddir = ../../..
+include $(top_builddir)/src/Makefile.global
+
PROGRAM = pg_upgrade
OBJS = check.o controldata.o dump.o exec.o file.o function.o info.o \
option.o page.o parallel.o pg_upgrade.o relfilenode.o server.o \
@@ -15,16 +19,8 @@ EXTRA_CLEAN = analyze_new_cluster.sh delete_old_cluster.sh log/ tmp_check/ \
pg_upgrade_dump_globals.sql \
pg_upgrade_dump_*.custom pg_upgrade_*.log
-ifdef USE_PGXS
-PG_CONFIG = pg_config
-PGXS := $(shell $(PG_CONFIG) --pgxs)
-include $(PGXS)
-else
-subdir = contrib/pg_upgrade
-top_builddir = ../..
-include $(top_builddir)/src/Makefile.global
-include $(top_srcdir)/contrib/contrib-global.mk
-endif
+NO_PGXS = 1
+include $(top_srcdir)/src/makefiles/pgxs.mk
check: test.sh all
MAKE=$(MAKE) bindir=$(bindir) libdir=$(libdir) EXTRA_REGRESS_OPTS="$(EXTRA_REGRESS_OPTS)" $(SHELL) $< --install
diff --git a/contrib/pg_upgrade/TESTING b/src/bin/pg_upgrade/TESTING
similarity index 99%
rename from contrib/pg_upgrade/TESTING
rename to src/bin/pg_upgrade/TESTING
index 359688c..4ecfc57 100644
--- a/contrib/pg_upgrade/TESTING
+++ b/src/bin/pg_upgrade/TESTING
@@ -1,5 +1,3 @@
-contrib/pg_upgrade/TESTING
-
The most effective way to test pg_upgrade, aside from testing on user
data, is by upgrading the PostgreSQL regression database.
diff --git a/contrib/pg_upgrade/check.c b/src/bin/pg_upgrade/check.c
similarity index 99%
rename from contrib/pg_upgrade/check.c
rename to src/bin/pg_upgrade/check.c
index 56db0dd..7dfa364 100644
--- a/contrib/pg_upgrade/check.c
+++ b/src/bin/pg_upgrade/check.c
@@ -4,7 +4,7 @@
* server checks and output routines
*
* Copyright (c) 2010-2014, PostgreSQL Global Development Group
- * contrib/pg_upgrade/check.c
+ * src/bin/pg_upgrade/check.c
*/
#include "postgres_fe.h"
diff --git a/contrib/pg_upgrade/controldata.c b/src/bin/pg_upgrade/controldata.c
similarity index 99%
rename from contrib/pg_upgrade/controldata.c
rename to src/bin/pg_upgrade/controldata.c
index 4e9d594..f7a87a3 100644
--- a/contrib/pg_upgrade/controldata.c
+++ b/src/bin/pg_upgrade/controldata.c
@@ -4,7 +4,7 @@
* controldata functions
*
* Copyright (c) 2010-2014, PostgreSQL Global Development Group
- * contrib/pg_upgrade/controldata.c
+ * src/bin/pg_upgrade/controldata.c
*/
#include "postgres_fe.h"
diff --git a/contrib/pg_upgrade/dump.c b/src/bin/pg_upgrade/dump.c
similarity index 99%
rename from contrib/pg_upgrade/dump.c
rename to src/bin/pg_upgrade/dump.c
index 0dfce2b..35954cc 100644
--- a/contrib/pg_upgrade/dump.c
+++ b/src/bin/pg_upgrade/dump.c
@@ -4,7 +4,7 @@
* dump functions
*
* Copyright (c) 2010-2014, PostgreSQL Global Development Group
- * contrib/pg_upgrade/dump.c
+ * src/bin/pg_upgrade/dump.c
*/
#include "postgres_fe.h"
diff --git a/contrib/pg_upgrade/exec.c b/src/bin/pg_upgrade/exec.c
similarity index 99%
rename from contrib/pg_upgrade/exec.c
rename to src/bin/pg_upgrade/exec.c
index c177288..fbc538a 100644
--- a/contrib/pg_upgrade/exec.c
+++ b/src/bin/pg_upgrade/exec.c
@@ -4,7 +4,7 @@
* execution functions
*
* Copyright (c) 2010-2014, PostgreSQL Global Development Group
- * contrib/pg_upgrade/exec.c
+ * src/bin/pg_upgrade/exec.c
*/
#include "postgres_fe.h"
diff --git a/contrib/pg_upgrade/file.c b/src/bin/pg_upgrade/file.c
similarity index 99%
rename from contrib/pg_upgrade/file.c
rename to src/bin/pg_upgrade/file.c
index ab9d1ed..a966506 100644
--- a/contrib/pg_upgrade/file.c
+++ b/src/bin/pg_upgrade/file.c
@@ -4,7 +4,7 @@
* file system operations
*
* Copyright (c) 2010-2014, PostgreSQL Global Development Group
- * contrib/pg_upgrade/file.c
+ * src/bin/pg_upgrade/file.c
*/
#include "postgres_fe.h"
diff --git a/contrib/pg_upgrade/function.c b/src/bin/pg_upgrade/function.c
similarity index 99%
rename from contrib/pg_upgrade/function.c
rename to src/bin/pg_upgrade/function.c
index 091119b..8789baf 100644
--- a/contrib/pg_upgrade/function.c
+++ b/src/bin/pg_upgrade/function.c
@@ -4,7 +4,7 @@
* server-side function support
*
* Copyright (c) 2010-2014, PostgreSQL Global Development Group
- * contrib/pg_upgrade/function.c
+ * src/bin/pg_upgrade/function.c
*/
#include "postgres_fe.h"
diff --git a/contrib/pg_upgrade/info.c b/src/bin/pg_upgrade/info.c
similarity index 99%
rename from contrib/pg_upgrade/info.c
rename to src/bin/pg_upgrade/info.c
index c347dfc..22cb3af 100644
--- a/contrib/pg_upgrade/info.c
+++ b/src/bin/pg_upgrade/info.c
@@ -4,7 +4,7 @@
* information support functions
*
* Copyright (c) 2010-2014, PostgreSQL Global Development Group
- * contrib/pg_upgrade/info.c
+ * src/bin/pg_upgrade/info.c
*/
#include "postgres_fe.h"
diff --git a/contrib/pg_upgrade/option.c b/src/bin/pg_upgrade/option.c
similarity index 99%
rename from contrib/pg_upgrade/option.c
rename to src/bin/pg_upgrade/option.c
index cfc88ec..4e22ef1 100644
--- a/contrib/pg_upgrade/option.c
+++ b/src/bin/pg_upgrade/option.c
@@ -4,7 +4,7 @@
* options functions
*
* Copyright (c) 2010-2014, PostgreSQL Global Development Group
- * contrib/pg_upgrade/option.c
+ * src/bin/pg_upgrade/option.c
*/
#include "postgres_fe.h"
diff --git a/contrib/pg_upgrade/page.c b/src/bin/pg_upgrade/page.c
similarity index 99%
rename from contrib/pg_upgrade/page.c
rename to src/bin/pg_upgrade/page.c
index 6354cec..9a486c5 100644
--- a/contrib/pg_upgrade/page.c
+++ b/src/bin/pg_upgrade/page.c
@@ -4,7 +4,7 @@
* per-page conversion operations
*
* Copyright (c) 2010-2014, PostgreSQL Global Development Group
- * contrib/pg_upgrade/page.c
+ * src/bin/pg_upgrade/page.c
*/
#include "postgres_fe.h"
diff --git a/contrib/pg_upgrade/parallel.c b/src/bin/pg_upgrade/parallel.c
similarity index 99%
rename from contrib/pg_upgrade/parallel.c
rename to src/bin/pg_upgrade/parallel.c
index 5d2565d..55f73cd 100644
--- a/contrib/pg_upgrade/parallel.c
+++ b/src/bin/pg_upgrade/parallel.c
@@ -4,7 +4,7 @@
* multi-process support
*
* Copyright (c) 2010-2014, PostgreSQL Global Development Group
- * contrib/pg_upgrade/parallel.c
+ * src/bin/pg_upgrade/parallel.c
*/
#include "postgres_fe.h"
diff --git a/contrib/pg_upgrade/pg_upgrade.c b/src/bin/pg_upgrade/pg_upgrade.c
similarity index 99%
rename from contrib/pg_upgrade/pg_upgrade.c
rename to src/bin/pg_upgrade/pg_upgrade.c
index 17c988e..bbc72c2 100644
--- a/contrib/pg_upgrade/pg_upgrade.c
+++ b/src/bin/pg_upgrade/pg_upgrade.c
@@ -4,7 +4,7 @@
* main source file
*
* Copyright (c) 2010-2014, PostgreSQL Global Development Group
- * contrib/pg_upgrade/pg_upgrade.c
+ * src/bin/pg_upgrade/pg_upgrade.c
*/
/*
diff --git a/contrib/pg_upgrade/pg_upgrade.h b/src/bin/pg_upgrade/pg_upgrade.h
similarity index 99%
rename from contrib/pg_upgrade/pg_upgrade.h
rename to src/bin/pg_upgrade/pg_upgrade.h
index d20c1ef..0c473b3 100644
--- a/contrib/pg_upgrade/pg_upgrade.h
+++ b/src/bin/pg_upgrade/pg_upgrade.h
@@ -2,7 +2,7 @@
* pg_upgrade.h
*
* Copyright (c) 2010-2014, PostgreSQL Global Development Group
- * contrib/pg_upgrade/pg_upgrade.h
+ * src/bin/pg_upgrade/pg_upgrade.h
*/
#include <unistd.h>
diff --git a/contrib/pg_upgrade/relfilenode.c b/src/bin/pg_upgrade/relfilenode.c
similarity index 99%
rename from contrib/pg_upgrade/relfilenode.c
rename to src/bin/pg_upgrade/relfilenode.c
index aa6aafd..0ac6185 100644
--- a/contrib/pg_upgrade/relfilenode.c
+++ b/src/bin/pg_upgrade/relfilenode.c
@@ -4,7 +4,7 @@
* relfilenode functions
*
* Copyright (c) 2010-2014, PostgreSQL Global Development Group
- * contrib/pg_upgrade/relfilenode.c
+ * src/bin/pg_upgrade/relfilenode.c
*/
#include "postgres_fe.h"
diff --git a/contrib/pg_upgrade/server.c b/src/bin/pg_upgrade/server.c
similarity index 99%
rename from contrib/pg_upgrade/server.c
rename to src/bin/pg_upgrade/server.c
index fc0d22e..6353ee1 100644
--- a/contrib/pg_upgrade/server.c
+++ b/src/bin/pg_upgrade/server.c
@@ -4,7 +4,7 @@
* database server functions
*
* Copyright (c) 2010-2014, PostgreSQL Global Development Group
- * contrib/pg_upgrade/server.c
+ * src/bin/pg_upgrade/server.c
*/
#include "postgres_fe.h"
diff --git a/contrib/pg_upgrade/tablespace.c b/src/bin/pg_upgrade/tablespace.c
similarity index 98%
rename from contrib/pg_upgrade/tablespace.c
rename to src/bin/pg_upgrade/tablespace.c
index 68e9cb2..f335b84 100644
--- a/contrib/pg_upgrade/tablespace.c
+++ b/src/bin/pg_upgrade/tablespace.c
@@ -4,7 +4,7 @@
* tablespace functions
*
* Copyright (c) 2010-2014, PostgreSQL Global Development Group
- * contrib/pg_upgrade/tablespace.c
+ * src/bin/pg_upgrade/tablespace.c
*/
#include "postgres_fe.h"
diff --git a/contrib/pg_upgrade/test.sh b/src/bin/pg_upgrade/test.sh
similarity index 98%
rename from contrib/pg_upgrade/test.sh
rename to src/bin/pg_upgrade/test.sh
index 81aae74..d6c5f97 100644
--- a/contrib/pg_upgrade/test.sh
+++ b/src/bin/pg_upgrade/test.sh
@@ -1,6 +1,6 @@
#!/bin/sh
-# contrib/pg_upgrade/test.sh
+# src/bin/pg_upgrade/test.sh
#
# Test driver for pg_upgrade. Initializes a new database cluster,
# runs the regression tests (to put in some data), runs pg_dumpall,
@@ -85,9 +85,9 @@ fi
: ${oldbindir=$bindir}
-: ${oldsrc=../..}
+: ${oldsrc=../../..}
oldsrc=`cd "$oldsrc" && pwd`
-newsrc=`cd ../.. && pwd`
+newsrc=`cd ../../.. && pwd`
PATH=$bindir:$PATH
export PATH
diff --git a/contrib/pg_upgrade/util.c b/src/bin/pg_upgrade/util.c
similarity index 99%
rename from contrib/pg_upgrade/util.c
rename to src/bin/pg_upgrade/util.c
index 79da8d7..4b710fd 100644
--- a/contrib/pg_upgrade/util.c
+++ b/src/bin/pg_upgrade/util.c
@@ -4,7 +4,7 @@
* utility functions
*
* Copyright (c) 2010-2014, PostgreSQL Global Development Group
- * contrib/pg_upgrade/util.c
+ * src/bin/pg_upgrade/util.c
*/
#include "postgres_fe.h"
diff --git a/contrib/pg_upgrade/version.c b/src/bin/pg_upgrade/version.c
similarity index 99%
rename from contrib/pg_upgrade/version.c
rename to src/bin/pg_upgrade/version.c
index 0f9dc07..e1bebaa 100644
--- a/contrib/pg_upgrade/version.c
+++ b/src/bin/pg_upgrade/version.c
@@ -4,7 +4,7 @@
* Postgres-version-specific routines
*
* Copyright (c) 2010-2014, PostgreSQL Global Development Group
- * contrib/pg_upgrade/version.c
+ * src/bin/pg_upgrade/version.c
*/
#include "postgres_fe.h"
--
2.2.0
On Mon, Dec 15, 2014 at 10:59 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
- no Windows build system support yet
Do you need some help here? I am getting worried about potential
breakage with the version information built with MSVC and MinGW..
- We have traditionally kept an individual author acknowledgement in the
man pages for contrib items. Should those be removed now?
+1.
--
Michael
--
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/14/14 9:08 PM, Michael Paquier wrote:
- no Windows build system support yet
Do you need some help here?
Sure.
I am getting worried about potential
breakage with the version information built with MSVC and MinGW..
I don't know what that is.
--
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 15, 2014 at 11:45 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
On 12/14/14 9:08 PM, Michael Paquier wrote:
- no Windows build system support yet
Do you need some help here?
Sure.
I am getting worried about potential
breakage with the version information built with MSVC and MinGW..I don't know what that is.
File version information for all the binaries and libraries produced
by compilation, per se for example ee9569e.
--
Michael
--
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 15, 2014 at 11:53 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:
On Mon, Dec 15, 2014 at 11:45 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
On 12/14/14 9:08 PM, Michael Paquier wrote:
- no Windows build system support yet
Do you need some help here?
Sure.
Peter,
Attached is a patch that can be applied on your existing set to
complete support on Windows for the move to src/bin. For MinGW there
was nothing to do, but on MSVC we have to declare frontend utilities
in the build scripts, which is roughly what this patch does. There are
as well some updates needed for clean.bat and the regression test
script. I did the following checks btw:
- Checked the builds worked correctly
- Checked that file version information was generated when building
with either MinGW or MSVC
- Checked that clean.bat ran correctly
- Checked that vcregress upgradecheck was working correctly
- Checked as well the other regression tests, but that's minor here...
I also noticed when looking at your patches that we actually forgot to
ignore the *.bat scripts generated by regressions of pg_upgrade when
running vcregress upgradecheck with MSVC stuff, but that's a different
issue that I reported on a new thread. It is included in my patch btw
for completeness.
Regards,
--
Michael
Attachments:
20141216_srcbin_win.patchapplication/octet-stream; name=20141216_srcbin_win.patchDownload
From a92aef5432edda3f00d7d334a51c90de3a7f79a7 Mon Sep 17 00:00:00 2001
From: Michael Paquier <michael@otacoo.com>
Date: Mon, 15 Dec 2014 22:16:36 -0800
Subject: [PATCH] Add MSVC support for new modules in src/bin
---
src/bin/pg_upgrade/.gitignore | 6 +++--
src/tools/msvc/Mkvcbuild.pm | 61 +++++++++++++++++++++----------------------
src/tools/msvc/clean.bat | 4 +--
src/tools/msvc/vcregress.pl | 6 ++---
4 files changed, 39 insertions(+), 38 deletions(-)
diff --git a/src/bin/pg_upgrade/.gitignore b/src/bin/pg_upgrade/.gitignore
index 9555f54..d24ec60 100644
--- a/src/bin/pg_upgrade/.gitignore
+++ b/src/bin/pg_upgrade/.gitignore
@@ -1,6 +1,8 @@
/pg_upgrade
# Generated by test suite
-analyze_new_cluster.sh
-delete_old_cluster.sh
+/analyze_new_cluster.sh
+/delete_old_cluster.sh
+/analyze_new_cluster.bat
+/delete_old_cluster.bat
/log/
/tmp_check/
diff --git a/src/tools/msvc/Mkvcbuild.pm b/src/tools/msvc/Mkvcbuild.pm
index 004942c..083c6d2 100644
--- a/src/tools/msvc/Mkvcbuild.pm
+++ b/src/tools/msvc/Mkvcbuild.pm
@@ -30,21 +30,10 @@ my $postgres;
my $libpq;
my $contrib_defines = { 'refint' => 'REFINT_VERBOSE' };
-my @contrib_uselibpq =
- ('dblink', 'oid2name', 'pgbench', 'pg_upgrade', 'postgres_fdw', 'vacuumlo');
-my @contrib_uselibpgport = (
- 'oid2name', 'pgbench',
- 'pg_standby', 'pg_archivecleanup',
- 'pg_test_fsync', 'pg_test_timing',
- 'pg_upgrade', 'pg_xlogdump',
- 'vacuumlo');
-my @contrib_uselibpgcommon = (
- 'oid2name', 'pgbench',
- 'pg_standby', 'pg_archivecleanup',
- 'pg_test_fsync', 'pg_test_timing',
- 'pg_upgrade', 'pg_xlogdump',
- 'vacuumlo');
-my $contrib_extralibs = { 'pgbench' => ['ws2_32.lib'] };
+my @contrib_uselibpq = ('dblink', 'oid2name', 'postgres_fdw', 'vacuumlo');
+my @contrib_uselibpgport = ('oid2name', 'vacuumlo');
+my @contrib_uselibpgcommon = ('oid2name', 'vacuumlo');
+my $contrib_extralibs;
my $contrib_extraincludes =
{ 'tsearch2' => ['contrib/tsearch2'], 'dblink' => ['src/backend'] };
my $contrib_extrasource = {
@@ -444,6 +433,8 @@ sub mkvcbuild
$pgdumpall->AddFile('src\backend\parser\kwlookup.c');
$pgdumpall->AddLibrary('ws2_32.lib');
+ my $pgarchivecleanup = AddSimpleFrontend('pg_archivecleanup');
+
my $pgrestore = AddSimpleFrontend('pg_dump', 1);
$pgrestore->{name} = 'pg_restore';
$pgrestore->AddIncludeDir('src\backend');
@@ -452,6 +443,30 @@ sub mkvcbuild
$pgrestore->AddFile('src\backend\parser\kwlookup.c');
$pgrestore->AddLibrary('ws2_32.lib');
+ my $pgstandby = AddSimpleFrontend('pg_standby');
+
+ my $pgtestfsync = AddSimpleFrontend('pg_test_fsync');
+
+ my $pgtesttiming = AddSimpleFrontend('pg_test_timing');
+
+ my $pgbench = AddSimpleFrontend('pgbench', 1);
+ $pgbench->AddLibrary('ws2_32.lib');
+
+ my $pgupgrade = AddSimpleFrontend('pg_upgrade', 1);
+
+ # Get necessary files for pg_xlogdump as files symlinked
+ # on Linux are copied on Windows.
+ my $pgxlogdump = AddSimpleFrontend('pg_xlogdump');
+ $pgxlogdump->AddDefine('FRONTEND');
+ foreach my $xf (glob('src/backend/access/rmgrdesc/*desc.c'))
+ {
+ my $bf = basename $xf;
+ copy($xf, "src/bin/pg_xlogdump/$bf");
+ $pgxlogdump->AddFile("src\\bin\\pg_xlogdump\\$bf");
+ }
+ copy('src/backend/access/transam/xlogreader.c',
+ 'src/bin/pg_xlogdump/xlogreader.c');
+
my $zic = $solution->AddProject('zic', 'exe', 'utils');
$zic->AddFiles('src\timezone', 'zic.c', 'ialloc.c', 'scheck.c',
'localtime.c');
@@ -608,22 +623,6 @@ sub mkvcbuild
$pgregress->AddDirResourceFile('src\test\regress');
$pgregress->AddReference($libpgcommon, $libpgport);
- # fix up pg_xlogdump once it's been set up
- # files symlinked on Unix are copied on windows
- my $pg_xlogdump =
- (grep { $_->{name} eq 'pg_xlogdump' }
- @{ $solution->{projects}->{contrib} })[0];
- $pg_xlogdump->AddDefine('FRONTEND');
- foreach my $xf (glob('src/backend/access/rmgrdesc/*desc.c'))
- {
- my $bf = basename $xf;
- copy($xf, "contrib/pg_xlogdump/$bf");
- $pg_xlogdump->AddFile("contrib\\pg_xlogdump\\$bf");
- }
- copy(
- 'src/backend/access/transam/xlogreader.c',
- 'contrib/pg_xlogdump/xlogreader.c');
-
$solution->Save();
return $solution->{vcver};
}
diff --git a/src/tools/msvc/clean.bat b/src/tools/msvc/clean.bat
index 9c7ea42..c48fb25 100755
--- a/src/tools/msvc/clean.bat
+++ b/src/tools/msvc/clean.bat
@@ -93,8 +93,8 @@ REM cd contrib
REM for /r %%f in (*.sql) do if exist %%f.in del %%f
REM clean up files copied into contrib\pg_xlogdump
-if exist contrib\pg_xlogdump\xlogreader.c del /q contrib\pg_xlogdump\xlogreader.c
-for %%f in (contrib\pg_xlogdump\*desc.c) do if not %%f==contrib\pg_xlogdump\rmgrdesc.c del /q %%f
+if exist src\bin\pg_xlogdump\xlogreader.c del /q src\bin\pg_xlogdump\xlogreader.c
+for %%f in (src\bin\pg_xlogdump\*desc.c) do if not %%f==src\bin\pg_xlogdump\rmgrdesc.c del /q %%f
cd %D%
diff --git a/src/tools/msvc/vcregress.pl b/src/tools/msvc/vcregress.pl
index b84f70d..bd12362 100644
--- a/src/tools/msvc/vcregress.pl
+++ b/src/tools/msvc/vcregress.pl
@@ -259,7 +259,7 @@ sub upgradecheck
# what pg_upgrade's "make check" does.
$ENV{PGPORT} ||= 50432;
- my $tmp_root = "$topdir/contrib/pg_upgrade/tmp_check";
+ my $tmp_root = "$topdir/src/bin/pg_upgrade/tmp_check";
(mkdir $tmp_root || die $!) unless -d $tmp_root;
my $tmp_install = "$tmp_root/install";
print "Setting up temp install\n\n";
@@ -272,7 +272,7 @@ sub upgradecheck
$ENV{PATH} = "$bindir;$ENV{PATH}";
my $data = "$tmp_root/data";
$ENV{PGDATA} = "$data.old";
- my $logdir = "$topdir/contrib/pg_upgrade/log";
+ my $logdir = "$topdir/src/bin/pg_upgrade/log";
(mkdir $logdir || die $!) unless -d $logdir;
print "\nRunning initdb on old cluster\n\n";
system("initdb") == 0 or exit 1;
@@ -282,7 +282,7 @@ sub upgradecheck
installcheck();
# now we can chdir into the source dir
- chdir "$topdir/contrib/pg_upgrade";
+ chdir "$topdir/src/bin/pg_upgrade";
print "\nDumping old cluster\n\n";
system("pg_dumpall -f $tmp_root/dump1.sql") == 0 or exit 1;
print "\nStopping old cluster\n\n";
--
1.9.2.msysgit.0
I know this is how it currently works, but it looks way too messy to me:
+ my $pgarchivecleanup = AddSimpleFrontend('pg_archivecleanup');
+ my $pgstandby = AddSimpleFrontend('pg_standby');
+ my $pgtestfsync = AddSimpleFrontend('pg_test_fsync');
+ my $pgtesttiming = AddSimpleFrontend('pg_test_timing');
+ my $pgbench = AddSimpleFrontend('pgbench', 1);
ISTM we should be something like
for each $elem in src/bin/Makefile:$(SUBDIRS)
AddSimpleFrontend($elem)
and avoid having to list the modules one by one.
--
�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 Thu, Dec 18, 2014 at 4:02 AM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
I know this is how it currently works, but it looks way too messy to me:
+ my $pgarchivecleanup = AddSimpleFrontend('pg_archivecleanup'); + my $pgstandby = AddSimpleFrontend('pg_standby'); + my $pgtestfsync = AddSimpleFrontend('pg_test_fsync'); + my $pgtesttiming = AddSimpleFrontend('pg_test_timing'); + my $pgbench = AddSimpleFrontend('pgbench', 1);ISTM we should be something like
for each $elem in src/bin/Makefile:$(SUBDIRS)
AddSimpleFrontend($elem)and avoid having to list the modules one by one.
If we take this road, I'd like to avoid a huge if/elseif scanning the
names of the submodules to do the necessary adjustments (Some need
FRONTEND defined, others ws2_32, etc.). Also, there is the case of
pg_basebackup where multiple binaries are included with pg_basebackup,
pg_recvlogical and pg_receivexlog. So I think that we'd need something
similar to what contrib does, aka:
my @frontend_excludes = ('pg_basebackup', 'pg_dump', 'pg_dumpall',
'pg_xlogdump', 'initdb' ...);
my frontend_extralibs = ('pgbench' => 'ws2_32.lib');
my @frontend_uselibpq = ('pgbench', 'pg_ctl', 'pg_upgrade');
And for each frontend name excluded we have an individual project
declaration with its own exceptions. With this way of doing when a new
frontend is added by default in src/bin it will be automatically
compiled. How does that sound?
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Dec 18, 2014 at 10:37 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:
On Thu, Dec 18, 2014 at 4:02 AM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:I know this is how it currently works, but it looks way too messy to me:
+ my $pgarchivecleanup = AddSimpleFrontend('pg_archivecleanup'); + my $pgstandby = AddSimpleFrontend('pg_standby'); + my $pgtestfsync = AddSimpleFrontend('pg_test_fsync'); + my $pgtesttiming = AddSimpleFrontend('pg_test_timing'); + my $pgbench = AddSimpleFrontend('pgbench', 1);ISTM we should be something like
for each $elem in src/bin/Makefile:$(SUBDIRS)
AddSimpleFrontend($elem)and avoid having to list the modules one by one.
If we take this road, I'd like to avoid a huge if/elseif scanning the
names of the submodules to do the necessary adjustments (Some need
FRONTEND defined, others ws2_32, etc.). Also, there is the case of
pg_basebackup where multiple binaries are included with pg_basebackup,
pg_recvlogical and pg_receivexlog. So I think that we'd need something
similar to what contrib does, aka:
my @frontend_excludes = ('pg_basebackup', 'pg_dump', 'pg_dumpall',
'pg_xlogdump', 'initdb' ...);
my frontend_extralibs = ('pgbench' => 'ws2_32.lib');
my @frontend_uselibpq = ('pgbench', 'pg_ctl', 'pg_upgrade');
And for each frontend name excluded we have an individual project
declaration with its own exceptions. With this way of doing when a new
frontend is added by default in src/bin it will be automatically
compiled. How does that sound?
And here is an updated patch following those lines. Similarly to the
things in contrib/, a set of variables are used to define for each
module what are the extra libraries, include dirs, etc. This refactors
quite a bit of code, even if there are a couple of exceptions like
pg_xlogdump/ or pg_basebackup/.
--
Michael
Attachments:
20141222_srcbin_win_v2.patchtext/x-diff; charset=US-ASCII; name=20141222_srcbin_win_v2.patchDownload
From 894ed2d918b142727661055d1ef60dd3ba9f6022 Mon Sep 17 00:00:00 2001
From: Michael Paquier <michael@otacoo.com>
Date: Mon, 15 Dec 2014 22:16:36 -0800
Subject: [PATCH] Add MSVC support for new modules in src/bin
---
src/tools/msvc/Mkvcbuild.pm | 158 +++++++++++++++++++++++++-------------------
src/tools/msvc/clean.bat | 4 +-
src/tools/msvc/vcregress.pl | 6 +-
3 files changed, 96 insertions(+), 72 deletions(-)
diff --git a/src/tools/msvc/Mkvcbuild.pm b/src/tools/msvc/Mkvcbuild.pm
index 004942c..d4fd03f 100644
--- a/src/tools/msvc/Mkvcbuild.pm
+++ b/src/tools/msvc/Mkvcbuild.pm
@@ -29,29 +29,37 @@ my $libpgcommon;
my $postgres;
my $libpq;
+# Set of variables for contrib modules
my $contrib_defines = { 'refint' => 'REFINT_VERBOSE' };
-my @contrib_uselibpq =
- ('dblink', 'oid2name', 'pgbench', 'pg_upgrade', 'postgres_fdw', 'vacuumlo');
-my @contrib_uselibpgport = (
- 'oid2name', 'pgbench',
- 'pg_standby', 'pg_archivecleanup',
- 'pg_test_fsync', 'pg_test_timing',
- 'pg_upgrade', 'pg_xlogdump',
- 'vacuumlo');
-my @contrib_uselibpgcommon = (
- 'oid2name', 'pgbench',
- 'pg_standby', 'pg_archivecleanup',
- 'pg_test_fsync', 'pg_test_timing',
- 'pg_upgrade', 'pg_xlogdump',
- 'vacuumlo');
-my $contrib_extralibs = { 'pgbench' => ['ws2_32.lib'] };
+my @contrib_uselibpq = ('dblink', 'oid2name', 'postgres_fdw', 'vacuumlo');
+my @contrib_uselibpgport = ('oid2name', 'vacuumlo');
+my @contrib_uselibpgcommon = ('oid2name', 'vacuumlo');
+my $contrib_extralibs = {};
my $contrib_extraincludes =
- { 'tsearch2' => ['contrib/tsearch2'], 'dblink' => ['src/backend'] };
-my $contrib_extrasource = {
- 'cube' => [ 'cubescan.l', 'cubeparse.y' ],
- 'seg' => [ 'segscan.l', 'segparse.y' ], };
+ { 'tsearch2' => ['contrib\tsearch2'], 'dblink' => ['src\backend'] };
+my $contrib_extrafiles = {
+ 'cube' => [ 'contrib\cube\cubescan.l', 'contrib\cube\cubeparse.y' ],
+ 'seg' => [ 'contrib\seg\segscan.l', 'contrib\seg\segparse.y' ], };
my @contrib_excludes = ('pgcrypto', 'intagg', 'sepgsql');
+# Set of variables for frontend modules
+my $frontend_defines = { 'initdb' => 'FRONTEND' };
+my @frontend_uselibpq = ('pg_ctl', 'pg_upgrade', 'pgbench', 'psql');
+my @frontend_uselibpgport = ('pg_ctl', 'pg_upgrade', 'psql');
+my @frontend_uselibpgcommon = ('pg_ctl', 'psql');
+my $frontend_extralibs = {'initdb' => ['ws2_32.lib'],
+ 'pg_dump' => ['ws2_32.lib'],
+ 'pg_restore' => ['ws2_32.lib'],
+ 'pgbench' => ['ws2_32.lib'],
+ 'psql' => ['ws2_32.lib'] };
+my $frontend_extraincludes = {
+ 'initdb' => ['src\timezone'],
+ 'psql' => ['src\bin\pg_dump', 'src\backend'] };
+my $frontend_extrafiles = {
+ 'psql' => [ 'src\bin\psql\psqlscan.l' ] };
+my @frontend_excludes = ('pgevent', 'pg_basebackup', 'pg_dump', 'pg_dumpall',
+ 'pg_restore', 'pg_xlogdump', 'pgevent', 'scripts');
+
sub mkvcbuild
{
our $config = shift;
@@ -376,11 +384,15 @@ sub mkvcbuild
$pgregress_isolation->AddReference($libpgcommon, $libpgport);
# src/bin
- my $initdb = AddSimpleFrontend('initdb');
- $initdb->AddIncludeDir('src\interfaces\libpq');
- $initdb->AddIncludeDir('src\timezone');
- $initdb->AddDefine('FRONTEND');
- $initdb->AddLibrary('ws2_32.lib');
+ my $D;
+ opendir($D, 'src/bin') || croak "Could not opendir on src/bin!\n";
+ while (my $d = readdir($D))
+ {
+ next if ($d =~ /^\./);
+ next unless (-f "src/bin/$d/Makefile");
+ next if (grep { /^$d$/ } @frontend_excludes);
+ AddSimpleFrontend($d);
+ }
my $pgbasebackup = AddSimpleFrontend('pg_basebackup', 1);
$pgbasebackup->AddFile('src\bin\pg_basebackup\pg_basebackup.c');
@@ -396,14 +408,6 @@ sub mkvcbuild
$pgrecvlogical->AddFile('src\bin\pg_basebackup\pg_recvlogical.c');
$pgrecvlogical->AddLibrary('ws2_32.lib');
- my $pgconfig = AddSimpleFrontend('pg_config');
-
- my $pgcontrol = AddSimpleFrontend('pg_controldata');
-
- my $pgctl = AddSimpleFrontend('pg_ctl', 1);
-
- my $pgreset = AddSimpleFrontend('pg_resetxlog');
-
my $pgevent = $solution->AddProject('pgevent', 'dll', 'bin');
$pgevent->AddFiles('src\bin\pgevent', 'pgevent.c', 'pgmsgevent.rc');
$pgevent->AddResourceFile('src\bin\pgevent', 'Eventlog message formatter',
@@ -412,12 +416,6 @@ sub mkvcbuild
$pgevent->UseDef('src\bin\pgevent\pgevent.def');
$pgevent->DisableLinkerWarnings('4104');
- my $psql = AddSimpleFrontend('psql', 1);
- $psql->AddIncludeDir('src\bin\pg_dump');
- $psql->AddIncludeDir('src\backend');
- $psql->AddFile('src\bin\psql\psqlscan.l');
- $psql->AddLibrary('ws2_32.lib');
-
my $pgdump = AddSimpleFrontend('pg_dump', 1);
$pgdump->AddIncludeDir('src\backend');
$pgdump->AddFile('src\bin\pg_dump\pg_dump.c');
@@ -452,6 +450,19 @@ sub mkvcbuild
$pgrestore->AddFile('src\backend\parser\kwlookup.c');
$pgrestore->AddLibrary('ws2_32.lib');
+ # Get necessary files for pg_xlogdump as files symlinked
+ # on Linux are copied on Windows.
+ my $pgxlogdump = AddSimpleFrontend('pg_xlogdump');
+ $pgxlogdump->AddDefine('FRONTEND');
+ foreach my $xf (glob('src/backend/access/rmgrdesc/*desc.c'))
+ {
+ my $bf = basename $xf;
+ copy($xf, "src/bin/pg_xlogdump/$bf");
+ $pgxlogdump->AddFile("src\\bin\\pg_xlogdump\\$bf");
+ }
+ copy('src/backend/access/transam/xlogreader.c',
+ 'src/bin/pg_xlogdump/xlogreader.c');
+
my $zic = $solution->AddProject('zic', 'exe', 'utils');
$zic->AddFiles('src\timezone', 'zic.c', 'ialloc.c', 'scheck.c',
'localtime.c');
@@ -528,7 +539,6 @@ sub mkvcbuild
my $mf = Project::read_file('contrib/pgcrypto/Makefile');
GenerateContribSqlFiles('pgcrypto', $mf);
- my $D;
opendir($D, 'contrib') || croak "Could not opendir on contrib!\n";
while (my $d = readdir($D))
{
@@ -608,22 +618,6 @@ sub mkvcbuild
$pgregress->AddDirResourceFile('src\test\regress');
$pgregress->AddReference($libpgcommon, $libpgport);
- # fix up pg_xlogdump once it's been set up
- # files symlinked on Unix are copied on windows
- my $pg_xlogdump =
- (grep { $_->{name} eq 'pg_xlogdump' }
- @{ $solution->{projects}->{contrib} })[0];
- $pg_xlogdump->AddDefine('FRONTEND');
- foreach my $xf (glob('src/backend/access/rmgrdesc/*desc.c'))
- {
- my $bf = basename $xf;
- copy($xf, "contrib/pg_xlogdump/$bf");
- $pg_xlogdump->AddFile("contrib\\pg_xlogdump\\$bf");
- }
- copy(
- 'src/backend/access/transam/xlogreader.c',
- 'contrib/pg_xlogdump/xlogreader.c');
-
$solution->Save();
return $solution->{vcver};
}
@@ -646,6 +640,10 @@ sub AddSimpleFrontend
$p->AddIncludeDir('src\interfaces\libpq');
$p->AddReference($libpq);
}
+
+ # Adjust module definition using frontent variables
+ AdjustFrontendProj($p);
+
return $p;
}
@@ -738,45 +736,71 @@ sub GenerateContribSqlFiles
sub AdjustContribProj
{
my $proj = shift;
- my $n = $proj->{name};
+ AdjustModule($proj, $contrib_defines, \@contrib_uselibpq,
+ \@contrib_uselibpgport, \@contrib_uselibpgcommon, $contrib_extralibs,
+ $contrib_extrafiles, $contrib_extraincludes);
+}
+
+sub AdjustFrontendProj
+{
+ my $proj = shift;
+ AdjustModule($proj, $frontend_defines, \@frontend_uselibpq,
+ \@frontend_uselibpgport, \@frontend_uselibpgcommon, $frontend_extralibs,
+ $frontend_extrafiles, $frontend_extraincludes);
+}
- if ($contrib_defines->{$n})
+sub AdjustModule
+{
+ my $proj = shift;
+ my $module_defines = shift;
+ my $module_uselibpq = shift;
+ my $module_uselibpgport = shift;
+ my $module_uselibpgcommon = shift;
+ my $module_extralibs = shift;
+ my $module_extrafiles = shift;
+ my $module_extraincludes = shift;
+ my $n = $proj->{name};
+
+ if ($module_defines->{$n})
{
- foreach my $d ($contrib_defines->{$n})
+ foreach my $d ($module_defines->{$n})
{
$proj->AddDefine($d);
}
}
- if (grep { /^$n$/ } @contrib_uselibpq)
+ if (grep { /^$n$/ } @{ $module_uselibpq })
{
$proj->AddIncludeDir('src\interfaces\libpq');
$proj->AddReference($libpq);
}
- if (grep { /^$n$/ } @contrib_uselibpgport)
+ if (grep { /^$n$/ } @{ $module_uselibpgport })
{
$proj->AddReference($libpgport);
}
- if (grep { /^$n$/ } @contrib_uselibpgcommon)
+ if (grep { /^$n$/ } @{ $module_uselibpgcommon })
{
$proj->AddReference($libpgcommon);
}
- if ($contrib_extralibs->{$n})
+ if ($module_extralibs->{$n})
{
- foreach my $l (@{ $contrib_extralibs->{$n} })
+ foreach my $l (@{ $module_extralibs->{$n} })
{
$proj->AddLibrary($l);
}
}
- if ($contrib_extraincludes->{$n})
+ if ($module_extraincludes->{$n})
{
- foreach my $i (@{ $contrib_extraincludes->{$n} })
+ foreach my $i (@{ $module_extraincludes->{$n} })
{
$proj->AddIncludeDir($i);
}
}
- if ($contrib_extrasource->{$n})
+ if ($module_extrafiles->{$n})
{
- $proj->AddFiles('contrib\\' . $n, @{ $contrib_extrasource->{$n} });
+ foreach my $i (@{ $module_extrafiles->{$n} })
+ {
+ $proj->AddFile($i);
+ }
}
}
diff --git a/src/tools/msvc/clean.bat b/src/tools/msvc/clean.bat
index 9c7ea42..c48fb25 100755
--- a/src/tools/msvc/clean.bat
+++ b/src/tools/msvc/clean.bat
@@ -93,8 +93,8 @@ REM cd contrib
REM for /r %%f in (*.sql) do if exist %%f.in del %%f
REM clean up files copied into contrib\pg_xlogdump
-if exist contrib\pg_xlogdump\xlogreader.c del /q contrib\pg_xlogdump\xlogreader.c
-for %%f in (contrib\pg_xlogdump\*desc.c) do if not %%f==contrib\pg_xlogdump\rmgrdesc.c del /q %%f
+if exist src\bin\pg_xlogdump\xlogreader.c del /q src\bin\pg_xlogdump\xlogreader.c
+for %%f in (src\bin\pg_xlogdump\*desc.c) do if not %%f==src\bin\pg_xlogdump\rmgrdesc.c del /q %%f
cd %D%
diff --git a/src/tools/msvc/vcregress.pl b/src/tools/msvc/vcregress.pl
index 699c286..36689ad 100644
--- a/src/tools/msvc/vcregress.pl
+++ b/src/tools/msvc/vcregress.pl
@@ -259,7 +259,7 @@ sub upgradecheck
# what pg_upgrade's "make check" does.
$ENV{PGPORT} ||= 50432;
- my $tmp_root = "$topdir/contrib/pg_upgrade/tmp_check";
+ my $tmp_root = "$topdir/src/bin/pg_upgrade/tmp_check";
(mkdir $tmp_root || die $!) unless -d $tmp_root;
my $tmp_install = "$tmp_root/install";
print "Setting up temp install\n\n";
@@ -272,7 +272,7 @@ sub upgradecheck
$ENV{PATH} = "$bindir;$ENV{PATH}";
my $data = "$tmp_root/data";
$ENV{PGDATA} = "$data.old";
- my $logdir = "$topdir/contrib/pg_upgrade/log";
+ my $logdir = "$topdir/src/bin/pg_upgrade/log";
(mkdir $logdir || die $!) unless -d $logdir;
print "\nRunning initdb on old cluster\n\n";
system("initdb") == 0 or exit 1;
@@ -282,7 +282,7 @@ sub upgradecheck
installcheck();
# now we can chdir into the source dir
- chdir "$topdir/contrib/pg_upgrade";
+ chdir "$topdir/src/bin/pg_upgrade";
print "\nDumping old cluster\n\n";
system("pg_dumpall -f $tmp_root/dump1.sql") == 0 or exit 1;
print "\nStopping old cluster\n\n";
--
1.9.2.msysgit.0
Michael Paquier wrote:
And here is an updated patch following those lines. Similarly to the
things in contrib/, a set of variables are used to define for each
module what are the extra libraries, include dirs, etc. This refactors
quite a bit of code, even if there are a couple of exceptions like
pg_xlogdump/ or pg_basebackup/.
In a broad look, this looks a lot better. I think we should press
forward with this whole set of patches and see what the buildfarm
thinks.
--
�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 Mon, Dec 22, 2014 at 11:30 PM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
Michael Paquier wrote:
And here is an updated patch following those lines. Similarly to the
things in contrib/, a set of variables are used to define for each
module what are the extra libraries, include dirs, etc. This refactors
quite a bit of code, even if there are a couple of exceptions like
pg_xlogdump/ or pg_basebackup/.In a broad look, this looks a lot better. I think we should press
forward with this whole set of patches and see what the buildfarm
thinks.
Here is a new series of patches for all those things, with the
following additions:
- Some cleanup for MSVC scripts compared to last patch
- Moved documentation to ref/
- Removed mention to the authors of the utilities moved (?)
This set of patches is basically made of the former set, with 2
additional patches for MSVC stuff and documentation pages moved to
ref/.
Regards,
--
Michael
Attachments:
20141223_contrib_to_bin.tar.gzapplication/x-gzip; name=20141223_contrib_to_bin.tar.gzDownload
� 8
�T ���cG�/~~����7��H�$?��]� �����C��#idk�4�f�q�����������x7�3���������4j��z���l��x�k5����
��c�?�ZmwW��=�]k��o�#�����Fm�'j�]��?��:��3�bM�������A�nwJ9�����F��C���pW������������V?����h��@��[�S���������yu@Y{;;��_��7���vE��������� �����jDm�������'�'��������z#���l����;������x�U0�}Q���EFp�9o{�[?����I/��~��0��aXm���/�88���,��e�����}��sX�^�I��q5i�#h��������A&l��r��)G��P Gn!�*�����
�h|���H������8���@��`(n{Q�{m���7��n(����AU7*��F�t�'0������������]Q0�{�0*z%������+���N����M/�V��V��Fo� ��nm���iT�������6���[�Q�4/����MT�������=�������3��
������~_�nU���v� ��E�{����������P��������f;����d0�nT
��������(��{8��n�_�8�w����q��~H�Z~�����h�3����dM���N����']�z
��F���zz���?d�����
~������g�oO`��z��FiC���|�1���hT�����f�O������sP�^���m�s���p2�ta�Wd�J�� w�.����;�������#��?$�w��`��]�5�}��I�Iw���v�����������~P�����i�����H��H�)$Gn�xW�n���������?������*�������q�P���![�@T��K���!���������M29���d�U|��k'�8��`��2r6/c����V�Eh<5[�w�g�'������<��e�I=��o?�uW~~
� �U�W��xm��z�_,[%�7���(a��[0�i�B��Z�jW)�J���U��nggg�Zm�F�[\�*�����k���}����\���(�^�1�A��F�M L3��^D�(�������R!-�8%�7�.L����]w��o�$u�� Q&q�N��\�6��:�[�'�{P��<�U�r�� �����[����p����
�E�������������3���v����a�D���.��e��^��\�~u������`��4�T� �^���&hA��z���b�y���F��Q�E(�6�������gP,)�T��������YzM������W��/�v?��m7.O�JXL�� ����I����+�� �:}������_��g�;�
�}���`�G7_"(��N0=��PFonr��Q���T��$CJ��TJ3��>A������j�"5�m��~��h���spVY�LK����7*������\��]�����<[>�����?AO�������2#��` �}�Js tG�f%V3�����}���L�:��'��E��4~?X$�����s0��Y���0�o����z#�5��[>����~_���6
W������DBD�����������a�5e|1�������_ y���fd����� jv���&�A��i;�����;�b(>�2���������0�'���S/!�p]N�n�7��X�
�$�Q����qx��~���H�w@����~Qg[a�/:Akr#��A
�����.��}�W;��~<f�cJ����tL�[��\6� ��cD�����K���{���;�C���q0�
�_pBb���va��oB�GX
�$4J����m��5�c���?�y��!�d�$ ���[��a���2���_W��\�������/^������+]���""��C���|������]�E��4�K�P
����`HB�C�i�6H�y��5m���@�A�w:���@zZ��69���e Q/R� P'�=����e�!�/�!�pR ~�DQ���
�|_�]qN4E����s�<��T@4~�#)}�m�N8��������8)�2q|q��
p-���$1�������,��@Jb�TU�/�z���a8��L�aM�� �������&��_����@��MI����p|Ce�@�i����c�����Uq}F�.z������|�A����Q+��|�aAA5�U){A��x�r��7���/������������Ph�_^�����%�n����`L2�E�.,�Q3��E�T���0�7e`�����h%tU��6O��b�A����o3YV�?���������/"��D����|���w�I���'�h(@��RTm�Qy�4w���2���)�O��6�G���Zc����vU�.V���a��Q1�+���@(l;��kB*��V Q�SK�! R�b�}�������uE/~ 3���`�'��B�����
W�\E|SLT]U�������?�D���U��
v�E���������b�+y!�;�x�cj��U�~���n�N}�1(R�(�u�Yf ���r�&�#L ��b����Q��]q�=�
�JX��]-�e����h4T��DG�)�'I(�D.-����8�'c�
��
G<�?Lzjh���ZS2�S����x��#�&%�P�<]8��FMQi?X)?B��~�=:���\$/��p,����W������Q/����,yd���7z�zS��;�����]��"��7(�$�������@����5!c�,���Q�2�L7'g�YGk�5hUfn�<���HNC��y��������}��+MaW�4�%��.���,qW�x:8�=� �qR%��I�C����Q�T��r>���
���aA�]�El�od����(I]H���N��\S��L��:�[��G�h?���4(HQ�����G��k�d�^������4&(��7�l�[��o2�����t�v$��������p�(����/���j�)��7l!>�W����i�J�/�0�8�M��vCR2Z�Kp�zU�����!�U!Mb�wT�pw�Q��P]�X�Qt]~�Z�lBX�k�fo�c�%4t��^��Q���!| ��P)E�?��c�<�YC��,���
������T��<�����w��x+,�-B������(� G���B�����J[��z^�H�J& ��s<|�� $�F�o���������'�?�xy�js�"P�"@�sI�_K���R� �dx'�T�w $���h��������f�a�nnc���}�F@����]���(��� �����]��-�M��Y�1K��j�� R�4�L)����F���LEM���pNa�W��sH1
F���� sv��T��� �<7�>���3��(oB��1�a��i�:��� M�f@-2
j�b���C��$�6����RKB��@I�0�0�-&iN�y�-iQ"�`�%Wg���z�I ��:c�'SS��n�S{n��b���z2�����:l$�N)2�=2[sryy~y(���9v������@z<��Y�4�Z�V|2�R�J��6H�Sf#����<
8��\�7����v���4O�(��i�W��� w/`Z���|�X�
_�>Q\����p,�u���~�"H�"�� �^L�2���OA0���W�r��P����@>Tk�� �W�m����"����'����^�>��Q��^��+�yx��� $`���l�Iz�����p���+�*�����P�S;��
���/\TB�)����9��CuQ���q(�uX4.@����zM^=4j�Q��nLJ��lz7m) ���P$�&�5H�+%zS�J ��yzH9c<Xl>�-\`�Z1g���3�M�e��7�4���F��{P[]��q�]�|u�~�%
�\�&,�����l��'KU������t�����BU�/�`d(W�L�X����"��h:�Ms��9���=����I^�Z�
�v-�9y�`� �H.Qr���}'{1�x�7u��1"�7��t%y%�$s_��I`�J�6��@I�c2����x�AR��QT��:�����d��p����*�J��L"��9�3���[]?����x�j����%�����{��w����S|8��>=?�X�V����O�~����1��o^�\]�trq�����I~
��-XF-��cwu��J^)����B}�
3
:��6A�>X�6������[Qbkm��d�/g��Q� �lqh��7d��R�������|�+��%&�kiF{W�G�(��e9U�(�E����4�W�����MP��(��p��4,�!
�*�7�%s�z��*U��L<JzL��������Mu����x6f��-�i�����<"��m���}m�\��iM��=���6_#�;� CLO�� �K��2���=&��O���k�?(�zh ��QE��r�V'�����s���O��� n�G\=?�}����8�\��Z�j��P��GX<x"���7"������6��,Z�N�V��Y��*�S~j]O��"*f�9��.�\�n����
�?�Y� �C�b� ��"�-�r���v��.����[��Y��s�G�G�����$ni^��e��<wO���:���r9&JP�
��������l����@'�w�\�s~QP�0�����{D�QV�=�������8u��T����^�&�M������i����k��H}-�����2��h<U����e.���`��:�� �UrNP�� n�*�i��}�8jbT�e�D3n�d9�8g��V%OI�h.O��&�N����{^��!_��v�f��s��v;��c����:�~�o�����!����
��R�On���/h(�aN�����=u�/��$��Io�9���!@���7[.TSx&
-Pg�������jO�
l^u���[f1�����,v��>p�����(����$y��t$���c��!�;.�|�c�N�����$�2��%u�2��5��wni�SV�{O:�n��m��>:�6�����?�;Y��d����M���n%���62��[�"A�}����^t���� �
,���{�������U|� ��; ��L��~�����2M�j���5��������{�ju�������P6�?���D��} ������XQ$W<�$H����y�� �M!z���}�wq_�}��=��w�%�j��������b��_���� ��76��$�1+�Y������o������]�����U����hjl�]RN���v�^9���I2�����������N�`/h-�7�q�ger�����|�mx����K{�@eI�����\3�;�[d*`��x�xsz�@1g������&(�l�@6 �B�������=������n�o�/�`Y�Y���4�� ~�����\��-�����������Z����7����������Y��������e;yxN^�������9���<�K����l����-�������[���g�����^'o-N��N^��)���Nc�Ar�z.����u�P�z��������������-�������[���[�����7���[���[���[���7���S����<�����c`_�z)'� �}}N�,'��9�'�-���Mw��
����<��F]�#L�O����
�+��6�t�����<<��C*���3N�*����w�P������r����'�&�����<�l'o�����"N���p��
��g��N���<d �8yx�/�����u��D[��C�����,e5'����<d�:y�b�N��j��N6�Wp���9�*N��e�<l�_���V���<T�8y`^BjB-����.���Jp�<��-���o��Fh��K���^H�h�����X��C�^��Ce������I�[7I�����b��������q��A�_��������7�rN������<�X��cj�\8�4�P�R�J�YN^^#t��������q���I�9y,����GA�^`A'�����6|5��iNj��'o^'����'��s�<��p�������<��9yx�:yx�9yL��w�K;yxks������<�������;y�6�N^����������m'������K9y�mc�H�}�JNZ���<l-wI'^��2�:yL;����#+���U�g8�<:�������������A|�N^����F'/���[������<��8yx�s���v�����8yx����s='��h��G&�t��k��r��Vq�P�r%'�<�iN� p�W��Nj�1NJ-X��C�������\������Z��#�Y� /����<����5����(���K�ig8yp ��Gv��A_�v�H���8y$��<�����5G7q�4C�vO+:y����q����������3N��)a�/�|���g�98��j�BN�R����9�<V��'�Y��u���
V�{'����G��%�<T���<���./'��/���7�s8y$�����������(���A��z����GD��g
�����;�����Om�S}��o�?2������?�S~���n��[���~4�:�'������v�`�s�n���t����i���������?I�\�)�I���MK�.��2�? \�`{���l4�����Fl�[�B���)�$q��'yi6���N��`�`!�t_��1/�RV�gae�j���+e�jY<% �T����A�o/���]G�J�7Oi9�
=�N�LdT��l\���G��(�+������1iZ�������[�i(-e�P�yf�#2)�f3�Pk��Fw�>,����������&#<