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
92 matches
Mail list logo
