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 Momj
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:
http:/
On Sun, Apr 12, 2015 at 12:36 PM, 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
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
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
> > i
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 se
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
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 us
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
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 i
Andres Freund 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 for stuff in
>
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 f
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 inc
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 indivi
On Wed, Mar 11, 2015 at 12:00 PM, Peter Eisentraut 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 Michael's Mkvc
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 refacto
Michael Paquier wrote:
> On Wed, Mar 11, 2015 at 10:06 AM, Alvaro Herrera
> 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 for movin
On Wed, Mar 11, 2015 at 10:06 AM, Alvaro Herrera
wrote:
> Michael Paquier wrote:
>> On Tue, Mar 10, 2015 at 10:48 PM, Alvaro Herrera
>> 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 sho
Michael Paquier wrote:
> On Tue, Mar 10, 2015 at 10:48 PM, Alvaro Herrera
> 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
> well that it sho
On Tue, Mar 10, 2015 at 10:48 PM, Alvaro Herrera
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 more sense now.
>
>
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 bac
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 blam
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
On Sun, Jan 18, 2015 at 10:21 PM, Andres Freund wrote:
> On 2015-01-18 21:05:29 +0900, Michael Paquier wrote:
>> On Sat, Jan 17, 2015 at 10:08 PM, Andres Freund
>> 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
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?
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
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 reaso
On 2015-01-18 21:05:29 +0900, Michael Paquier wrote:
> On Sat, Jan 17, 2015 at 10:08 PM, Andres Freund
> 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 corr
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 c
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 d
On Sun, Jan 18, 2015 at 9:56 PM, 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 am not sure about that.
> 2) in any event it is essentially deprecated in favour of standby_mo
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?
--
Andre
Simon, Bruce, Ants,
(CCing..)
On Sun, Jan 18, 2015 at 9:05 PM, Michael Paquier
wrote:
> On Sat, Jan 17, 2015 at 10:08 PM, 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
On Sat, Jan 17, 2015 at 10:08 PM, Andres Freund 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 the
Makefiles are impro
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. T
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 a
On Tue, Dec 23, 2014 at 3:24 PM, Michael Paquier
wrote:
> On Mon, Dec 22, 2014 at 11:30 PM, Alvaro Herrera
> 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
>>> modu
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 exception
On Thu, Dec 18, 2014 at 10:37 AM, Michael Paquier
wrote:
> On Thu, Dec 18, 2014 at 4:02 AM, Alvaro Herrera
> wrote:
>>
>> I know this is how it currently works, but it looks way too messy to me:
>>
>> + my $pgarchivecleanup = AddSimpleFrontend('pg_archivecleanup');
>> + my $pgstandby
On Thu, Dec 18, 2014 at 4:02 AM, Alvaro Herrera
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 = AddS
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 = AddSimpl
On Mon, Dec 15, 2014 at 11:53 AM, Michael Paquier
wrote:
> On Mon, Dec 15, 2014 at 11:45 AM, Peter Eisentraut 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 o
On Mon, Dec 15, 2014 at 11:45 AM, Peter Eisentraut 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..
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 l
On Mon, Dec 15, 2014 at 10:59 AM, Peter Eisentraut 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
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_upgr
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 inst
On Fri, Dec 12, 2014 at 08:57:55PM -0500, Tom Lane wrote:
> Peter Eisentraut 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
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 cause
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 a
Peter Eisentraut 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
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
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 Sat, Dec 13, 2014 at 1:00 AM, Alvaro Herrera
wrote:
> Tom Lane wrote:
>> Heikki Linnakangas 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 p
On Fri, Dec 12, 2014 at 12:19 PM, Alvaro Herrera
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 o
Tom Lane wrote:
> Christoph Berg 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 s
Christoph Berg 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
Re: Andres Freund 2014-12-12 <20141212152723.go31...@awork2.anarazel.de>
> On 2014-12-12 10:20:58 -0500, Tom Lane wrote:
> > Peter Eisentraut writes:
> > > On 12/12/14 8:13 AM, Andres Freund wrote:
> > >> Wouldn't a make install-server/client targets or something similar
> > >> actually achieve th
Robert Haas wrote:
> On Fri, Dec 12, 2014 at 11:00 AM, Alvaro Herrera
> 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'
On Fri, Dec 12, 2014 at 10:16:05AM -0500, Tom Lane wrote:
> Peter Eisentraut 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 b
Andres Freund 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 re
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 direc
On Fri, Dec 12, 2014 at 11:40 AM, Andres Freund 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 justifi
On Fri, Dec 12, 2014 at 11:26 AM, Tom Lane wrote:
> Robert Haas 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 fa
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 pla
Robert Haas 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
On 12/08/2014 07:50 PM, Tom Lane wrote:
Peter Eisentraut 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
On Fri, Dec 12, 2014 at 11:00 AM, Alvaro Herrera
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 t
Tom Lane wrote:
> Heikki Linnakangas 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 th
On 2014-12-12 10:20:58 -0500, Tom Lane wrote:
> Peter Eisentraut 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
Peter Eisentraut 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.
I
Peter Eisentraut 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
Heikki Linnakangas 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
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/
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 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 h
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
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 u
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
> >>>s
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
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
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_archi
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 on
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_t
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 subsc
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 o
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 docum
On Mon, Dec 8, 2014 at 10:26 PM, Peter Eisentraut 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 enoug
> 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
Consideri
On Mon, Dec 8, 2014 at 9:00 PM, Andres Freund 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
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 syst
Peter Eisentraut 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 pr
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
93 matches
Mail list logo
