On Wed, Apr 22, 2015 at 09:18:40AM +0200, Andres Freund wrote:
Peter, Michael,
On 2015-04-22 16:13:15 +0900, Michael Paquier wrote:
All the patches have been committed, finishing the work on this thread.
Many thanks for that effort!
And pg_upgrade thanks you. ;-)
--
Bruce Momjian
Peter, Michael,
On 2015-04-22 16:13:15 +0900, Michael Paquier wrote:
All the patches have been committed, finishing the work on this thread.
Many thanks for that effort!
Andres
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Sun, Apr 12, 2015 at 12:36 PM, Peter Eisentraut pete...@gmx.net wrote:
On 3/11/15 8:21 PM, Michael Paquier wrote:
Attached is a series of patch rebased on current HEAD, there were some
conflicts after perl-tidying the refactoring patch for MSVC. Note that
this series still uses PGXS in the
On 4/12/15 8:00 PM, Alvaro Herrera wrote:
Peter Eisentraut wrote:
On 3/11/15 8:21 PM, Michael Paquier wrote:
Attached is a series of patch rebased on current HEAD, there were some
conflicts after perl-tidying the refactoring patch for MSVC. Note that
this series still uses PGXS in the
Peter Eisentraut wrote:
On 3/11/15 8:21 PM, Michael Paquier wrote:
Attached is a series of patch rebased on current HEAD, there were some
conflicts after perl-tidying the refactoring patch for MSVC. Note that
this series still uses PGXS in the Makefiles, I am fine to update them
if
On 3/11/15 8:21 PM, Michael Paquier wrote:
Attached is a series of patch rebased on current HEAD, there were some
conflicts after perl-tidying the refactoring patch for MSVC. Note that
this series still uses PGXS in the Makefiles, I am fine to update them
if necessary once this matter is set
On 3/11/15 10:00 AM, Andres Freund wrote:
On 2015-03-10 22:06:37 -0300, Alvaro Herrera wrote:
I don't think we care one bit whether these modules use pgxs, at least
not currently. If we find any issues later on, it should be an easy fix
anyway.
I personally find it quite ugly to use pgxs
On Thu, Mar 12, 2015 at 8:50 AM, Peter Eisentraut wrote:
On 3/11/15 10:00 AM, Andres Freund wrote:
On 2015-03-10 22:06:37 -0300, Alvaro Herrera wrote:
I don't think we care one bit whether these modules use pgxs, at least
not currently. If we find any issues later on, it should be an easy fix
Michael Paquier wrote:
On Tue, Mar 10, 2015 at 8:07 PM, Michael Paquier wrote:
I'd rather vote for having the Windows-side stuff integrated with each
patch. Mind if I rebase what you just sent with the Windows things
added?
And here is the rebased series with the MSVC changes included
On 2015-03-11 11:19:24 -0300, Alvaro Herrera wrote:
Andres Freund wrote:
On 2015-03-10 22:06:37 -0300, Alvaro Herrera wrote:
I don't think we care one bit whether these modules use pgxs, at least
not currently. If we find any issues later on, it should be an easy fix
anyway.
I
On 2015-03-10 22:06:37 -0300, Alvaro Herrera wrote:
I don't think we care one bit whether these modules use pgxs, at least
not currently. If we find any issues later on, it should be an easy fix
anyway.
I personally find it quite ugly to use pgxs for stuff in
src/bin. pgxs.mk says:
# This
Andres Freund and...@2ndquadrant.com writes:
On 2015-03-10 22:06:37 -0300, Alvaro Herrera wrote:
I don't think we care one bit whether these modules use pgxs, at least
not currently. If we find any issues later on, it should be an easy fix
anyway.
I personally find it quite ugly to use pgxs
Andres Freund wrote:
On 2015-03-10 22:06:37 -0300, Alvaro Herrera wrote:
I don't think we care one bit whether these modules use pgxs, at least
not currently. If we find any issues later on, it should be an easy fix
anyway.
I personally find it quite ugly to use pgxs for stuff in
Andres Freund wrote:
Rebased (fair amount of trivial conflicts due to the copyright year
bump) and attached as -MC style format-patch. If you look at the content
of the patches you can see that the diff makes more sense now.
Ah --- I just realized that the change Peter is proposing from
Michael Paquier wrote:
On Tue, Mar 10, 2015 at 10:48 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
How do we go about getting these patches pushed?
I think that one of the last point raised (by Andres) was if the
Makefiles in src/bin should depend on pgxs.mk or not. FWIW, I think as
Michael Paquier wrote:
On Wed, Mar 11, 2015 at 10:06 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Now, the pushing plan was to have the stuff of pg_upgrade done in a
separate commit. Note that I am fine helping out wrapping up things
particularly on Windows if that helps.
I vote
On Wed, Mar 11, 2015 at 12:00 PM, Peter Eisentraut pete...@gmx.net wrote:
Here is a rebase of my previous patch set. I have integrated the
various minor fixes from Michael and Andres. I have dropped moving
pg_standby, because no one seemed to like that.
I wasn't able to do anything with
Here is a rebase of my previous patch set. I have integrated the
various minor fixes from Michael and Andres. I have dropped moving
pg_standby, because no one seemed to like that.
I wasn't able to do anything with Michael's Mkvcbuild.pm patch, since
that appeared to include a significant
On Tue, Mar 10, 2015 at 8:07 PM, Michael Paquier wrote:
I'd rather vote for having the Windows-side stuff integrated with each
patch. Mind if I rebase what you just sent with the Windows things
added?
And here is the rebased series with the MSVC changes included for each
module in its
On Wed, Mar 11, 2015 at 10:06 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Michael Paquier wrote:
On Tue, Mar 10, 2015 at 10:48 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
How do we go about getting these patches pushed?
I think that one of the last point raised (by Andres)
On Tue, Mar 10, 2015 at 10:48 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Andres Freund wrote:
Rebased (fair amount of trivial conflicts due to the copyright year
bump) and attached as -MC style format-patch. If you look at the content
of the patches you can see that the diff makes
On Sat, Jan 17, 2015 at 02:08:34PM +0100, Andres Freund wrote:
7) Are we sure that the authors in the affected contrib modules are ok
with their authorship notice being removed? I don't think Ants, Bruce
or Simon have a problem with that, but ...
I am fine. It means others can be
On Sat, Jan 17, 2015 at 01:16:18PM +0100, Andres Freund wrote:
Hi,
FWIW, I find it rather annoying if people attach patchsets as
tarballs. That makes it impossible to look at them in the mailreader
since I really don't have anything reasonable to go on to teach it to
treat it as a set of
On Sun, Jan 18, 2015 at 10:21 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2015-01-18 21:05:29 +0900, Michael Paquier wrote:
On Sat, Jan 17, 2015 at 10:08 PM, Andres Freund and...@2ndquadrant.com
wrote:
Observations:
1) Are we sure it's a good idea to rely on pgxs.mk in src/bin
Correct me if I'm wrong, but is it not the case that:
1) pg_standby was intended to be customizable code, even if usable as
distributed, and
2) in any event it is essentially deprecated in favour of standby_mode
and therefore moving it to src/bin seems like a wrong move on two counts?
--
Hi,
On 2015-01-18 12:56:59 +, Andrew Gierth wrote:
Correct me if I'm wrong, but is it not the case that:
1) pg_standby was intended to be customizable code, even if usable as
distributed, and
I don't think that really happened in reality though...
2) in any event it is essentially
Andres Freund wrote:
Hi,
On 2015-01-18 12:56:59 +, Andrew Gierth wrote:
and therefore moving it to src/bin seems like a wrong move on two counts?
I personally agree that that pg_standby shouldn't be moved. Even if we
could not find agreement to remove it, there's little reason to
On 1/17/15 8:08 AM, Andres Freund wrote:
1) Are we sure it's a good idea to rely on pgxs.mk in src/bin programs?
I am. Why not?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 1/18/15 8:16 AM, Andres Freund wrote:
On 2015-01-18 22:02:13 +0900, Michael Paquier wrote:
On Sun, Jan 18, 2015 at 9:56 PM, Andrew Gierth
2) in any event it is essentially deprecated in favour of standby_mode
and therefore moving it to src/bin seems like a wrong move on two counts?
There
On Sat, Jan 17, 2015 at 10:08 PM, Andres Freund and...@2ndquadrant.com wrote:
Observations:
1) Are we sure it's a good idea to rely on pgxs.mk in src/bin programs?
Yeah, this seems like a bad dependency, PGXS being made for contrib
modules... So corrected in the patch attached (the headers of
On Sun, Jan 18, 2015 at 9:56 PM, Andrew Gierth
and...@tao11.riddles.org.uk wrote:
Correct me if I'm wrong, but is it not the case that:
1) pg_standby was intended to be customizable code, even if usable as
distributed, and
I am not sure about that.
2) in any event it is essentially deprecated
On 2015-01-18 22:02:13 +0900, Michael Paquier wrote:
On Sun, Jan 18, 2015 at 9:56 PM, Andrew Gierth
2) in any event it is essentially deprecated in favour of standby_mode
and therefore moving it to src/bin seems like a wrong move on two counts?
There were some discussions about that a couple
On 2015-01-18 21:05:29 +0900, Michael Paquier wrote:
On Sat, Jan 17, 2015 at 10:08 PM, Andres Freund and...@2ndquadrant.com
wrote:
Observations:
1) Are we sure it's a good idea to rely on pgxs.mk in src/bin programs?
Yeah, this seems like a bad dependency, PGXS being made for contrib
Simon, Bruce, Ants,
(CCing..)
On Sun, Jan 18, 2015 at 9:05 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Sat, Jan 17, 2015 at 10:08 PM, Andres Freund and...@2ndquadrant.com
wrote:
7) Are we sure that the authors in the affected contrib modules are ok
with their authorship notice
Hi,
FWIW, I find it rather annoying if people attach patchsets as
tarballs. That makes it impossible to look at them in the mailreader
since I really don't have anything reasonable to go on to teach it to
treat it as a set of patches.
I'd also like to see patches that primarily move code around
On 2015-01-17 13:16:18 +0100, Andres Freund wrote:
I'd also like to see patches that primarily move code around as git diff
-M -C style diffs (can also be passed to format-patch). That will show
the file move and then additionally the changes that have been made in
addition to the rename.
On Tue, Dec 23, 2014 at 3:24 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Mon, Dec 22, 2014 at 11:30 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Michael Paquier wrote:
And here is an updated patch following those lines. Similarly to the
things in contrib/, a set of
On Thu, Dec 18, 2014 at 10:37 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Thu, Dec 18, 2014 at 4:02 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
I know this is how it currently works, but it looks way too messy to me:
+ my $pgarchivecleanup =
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
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 =
On Thu, Dec 18, 2014 at 4:02 AM, Alvaro Herrera
alvhe...@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
On Mon, Dec 15, 2014 at 11:53 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Mon, Dec 15, 2014 at 11:45 AM, Peter Eisentraut pete...@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
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
On Mon, Dec 15, 2014 at 10:59 AM, Peter Eisentraut pete...@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
Re: Alvaro Herrera 2014-12-12 20141212203700.gb1...@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
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
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,
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
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,
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
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
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
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
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
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
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
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
Heikki Linnakangas hlinnakan...@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
Peter Eisentraut pete...@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,
Peter Eisentraut pete...@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
On 2014-12-12 10:20:58 -0500, Tom Lane wrote:
Peter Eisentraut pete...@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
Tom Lane wrote:
Heikki Linnakangas hlinnakan...@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
On Fri, Dec 12, 2014 at 11:00 AM, Alvaro Herrera
alvhe...@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
On 12/08/2014 07:50 PM, Tom Lane wrote:
Peter Eisentraut pete...@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.
Robert Haas robertmh...@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
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
On Fri, Dec 12, 2014 at 11:26 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@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,
On Fri, Dec 12, 2014 at 11:40 AM, Andres Freund and...@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
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,
Andres Freund and...@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.
On Fri, Dec 12, 2014 at 10:16:05AM -0500, Tom Lane wrote:
Peter Eisentraut pete...@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
Robert Haas wrote:
On Fri, Dec 12, 2014 at 11:00 AM, Alvaro Herrera
alvhe...@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?
Re: Andres Freund 2014-12-12 20141212152723.go31...@awork2.anarazel.de
On 2014-12-12 10:20:58 -0500, Tom Lane wrote:
Peter Eisentraut pete...@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
Christoph Berg c...@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
Tom Lane wrote:
Christoph Berg c...@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
On Fri, Dec 12, 2014 at 12:19 PM, Alvaro Herrera
alvhe...@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
On Sat, Dec 13, 2014 at 1:00 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Tom Lane wrote:
Heikki Linnakangas hlinnakan...@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
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
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
Peter Eisentraut pete...@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,
On Fri, Dec 12, 2014 at 08:57:55PM -0500, Tom Lane wrote:
Peter Eisentraut pete...@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
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.
+1
Considering that all
On Mon, Dec 8, 2014 at 10:26 PM, Peter Eisentraut pete...@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
Peter Eisentraut wrote:
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.
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
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.
Peter Eisentraut pete...@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
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
On Mon, Dec 8, 2014 at 9:00 PM, Andres Freund and...@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
89 matches
Mail list logo
