I wrote:
> Bruce Momjian writes:
>> On Sun, Feb 7, 2021 at 11:21:05AM +0100, Magnus Hagander wrote:
>>> Isn't the whole "Success." at the end redundant here, and we should
>>> just end the message after the pg_ctl command? So not just the extra
>>> newline, but the whole thing?
>> Agreed.
> +1
Bruce Momjian writes:
> On Sun, Feb 7, 2021 at 11:21:05AM +0100, Magnus Hagander wrote:
>> Isn't the whole "Success." at the end redundant here, and we should
>> just end the message after the pg_ctl command? So not just the extra
>> newline, but the whole thing?
> Agreed.
+1
On Sun, Feb 7, 2021 at 11:21:05AM +0100, Magnus Hagander wrote:
> > It appears that there is an extra blank line in the initdb output before
> > "Success" now.
>
> Oops, clearly it does.
>
> That said, the full output is:
>
> """
> Success. You can now start the database server using:
>
>
On Wed, Feb 3, 2021 at 4:21 PM Peter Eisentraut
wrote:
>
> On 2021-01-17 14:38, Magnus Hagander wrote:
> > On Thu, Jan 7, 2021 at 11:53 AM Peter Eisentraut
> > wrote:
> >>
> >> After pondering this again, I think we can go with initdb
> >> --no-instructions, as in your patch.
> >>
> >> As a minor
On 2021-01-17 14:38, Magnus Hagander wrote:
On Thu, Jan 7, 2021 at 11:53 AM Peter Eisentraut
wrote:
After pondering this again, I think we can go with initdb
--no-instructions, as in your patch.
As a minor nitpick, I would leave out the
else
printf(_("\nSuccess.\n"));
in the
On Thu, Jan 7, 2021 at 11:53 AM Peter Eisentraut
wrote:
>
> After pondering this again, I think we can go with initdb
> --no-instructions, as in your patch.
>
> As a minor nitpick, I would leave out the
>
> else
> printf(_("\nSuccess.\n"));
>
> in the --no-instructions case.
OK, tha
After pondering this again, I think we can go with initdb
--no-instructions, as in your patch.
As a minor nitpick, I would leave out the
else
printf(_("\nSuccess.\n"));
in the --no-instructions case.
(I don't know where the pg_upgrade part of this discussion is right now.)
--
Pet
On Wed, Nov 25, 2020 at 04:25:56PM +0100, Magnus Hagander wrote:
> On Wed, Nov 25, 2020 at 9:29 AM Peter Eisentraut
> wrote:
>> Perhaps it's worth asking whom the advice applies to then. You suggest
>> it's mostly developers. I for one am still grumpy that in 9.5 we
>> removed the variant of th
On Wed, Nov 25, 2020 at 10:33:09AM -0500, Tom Lane wrote:
> Magnus Hagander writes:
> > I guess one option could be to just remove it, unconditionally. And
> > assume that any users who is running it manually read that in docs
> > somewhere that tells them what to do next, and that any user who's
Magnus Hagander writes:
> I guess one option could be to just remove it, unconditionally. And
> assume that any users who is running it manually read that in docs
> somewhere that tells them what to do next, and that any user who's
> running it under a wrapper will have the wrapper set it up?
I c
On Wed, Nov 25, 2020 at 9:29 AM Peter Eisentraut
wrote:
>
> On 2020-11-24 13:32, Magnus Hagander wrote:
> > I think it boils down to that today the output from initdb is entirely
> > geared towards people running initdb directly and starting their
> > server manually, and very few people outside t
On 2020-11-24 13:32, Magnus Hagander wrote:
I think it boils down to that today the output from initdb is entirely
geared towards people running initdb directly and starting their
server manually, and very few people outside the actual PostgreSQL
developers ever do that. But there are still a lot
On Tue, Nov 24, 2020 at 04:05:26PM +0100, Magnus Hagander wrote:
> pg_upgrade is a somewhat different but also interesting case. I think
> the actual progress output is more interesting in pg_upgrade as it's
> more likely to take measurable amounts of time. Whereas in initdb,
> it's actually the "d
On Tue, Nov 24, 2020 at 3:12 PM Bruce Momjian wrote:
>
> On Tue, Nov 24, 2020 at 01:32:45PM +0100, Magnus Hagander wrote:
> > I think it boils down to that today the output from initdb is entirely
> > geared towards people running initdb directly and starting their
> > server manually, and very fe
On Tue, Nov 24, 2020 at 01:32:45PM +0100, Magnus Hagander wrote:
> I think it boils down to that today the output from initdb is entirely
> geared towards people running initdb directly and starting their
> server manually, and very few people outside the actual PostgreSQL
> developers ever do that
On Fri, Nov 20, 2020 at 4:46 PM Peter Eisentraut
wrote:
>
> On 2020-11-09 13:05, Magnus Hagander wrote:
> > PFA a rebased version of this patch on top of what has happened since,
> > and changing the pg_upgrade parameter to be --no-scripts.
>
> It seems were are still finding out more nuances abou
On 2020-11-09 13:05, Magnus Hagander wrote:
PFA a rebased version of this patch on top of what has happened since,
and changing the pg_upgrade parameter to be --no-scripts.
It seems were are still finding out more nuances about pg_upgrade, but
looking at initdb for moment, I think the solution
On Wed, Nov 11, 2020 at 05:39:10PM +0100, Magnus Hagander wrote:
> On Wed, Nov 11, 2020 at 5:38 PM Bruce Momjian wrote:
> >
> > On Wed, Nov 11, 2020 at 11:21:22AM -0500, Bruce Momjian wrote:
> > > On Wed, Nov 11, 2020 at 05:11:38PM +0100, Magnus Hagander wrote:
> > > > > In summary, I think the va
On Wed, Nov 11, 2020 at 5:38 PM Bruce Momjian wrote:
>
> On Wed, Nov 11, 2020 at 11:21:22AM -0500, Bruce Momjian wrote:
> > On Wed, Nov 11, 2020 at 05:11:38PM +0100, Magnus Hagander wrote:
> > > > In summary, I think the vacuumdb --analyze is now a one-line command,
> > > > but the delete part can
On Wed, Nov 11, 2020 at 11:21:22AM -0500, Bruce Momjian wrote:
> On Wed, Nov 11, 2020 at 05:11:38PM +0100, Magnus Hagander wrote:
> > > In summary, I think the vacuumdb --analyze is now a one-line command,
> > > but the delete part can be complex and not easily typed.
> >
> > I definitely agree to
On Wed, Nov 11, 2020 at 05:11:38PM +0100, Magnus Hagander wrote:
> > Uh, pg_upgrade does enumerate things like tablespaces in
> > create_script_for_old_cluster_deletion(). I think config file locations
> > are beyond the scope of what we want pg_upgrade to handle.
>
> Ah, that's right. Forgot tha
On Wed, Nov 11, 2020 at 4:53 PM Bruce Momjian wrote:
>
> On Mon, Nov 2, 2020 at 02:23:35PM +0100, Magnus Hagander wrote:
> > On Tue, Oct 27, 2020 at 12:40 PM Bruce Momjian wrote:
> > >
> > > On Tue, Oct 27, 2020 at 12:35:56PM +0100, Peter Eisentraut wrote:
> > > > On 2020-10-27 11:53, Bruce Momj
On Mon, Nov 2, 2020 at 02:23:35PM +0100, Magnus Hagander wrote:
> On Tue, Oct 27, 2020 at 12:40 PM Bruce Momjian wrote:
> >
> > On Tue, Oct 27, 2020 at 12:35:56PM +0100, Peter Eisentraut wrote:
> > > On 2020-10-27 11:53, Bruce Momjian wrote:
> > > > On Tue, Oct 27, 2020 at 11:35:25AM +0100, Peter
On 2020-Nov-09, Magnus Hagander wrote:
> On Mon, Nov 9, 2020 at 3:29 PM Alvaro Herrera wrote:
> >
> > How about a switch like "--with-scripts=" where the list can be
> > "all" to include everything (default), "none" to include nothing, or a
> > comma-separated list of things to include? (Also "-
On Mon, Nov 9, 2020 at 3:29 PM Alvaro Herrera wrote:
>
> On 2020-Nov-09, Magnus Hagander wrote:
>
> > But for usability that makes less sense. For the delete script, the
> > wrapper (that the switch is intended for) knows more than pg_upgrade
> > about how to delete it, so it can do a better job,
On 2020-Nov-09, Magnus Hagander wrote:
> But for usability that makes less sense. For the delete script, the
> wrapper (that the switch is intended for) knows more than pg_upgrade
> about how to delete it, so it can do a better job, and thus it makes
> sense to silence it. But for something like t
On Mon, Nov 9, 2020 at 2:18 PM Anastasia Lubennikova
wrote:
>
> On 02.11.2020 16:23, Magnus Hagander wrote:
>
> On Tue, Oct 27, 2020 at 11:35:25AM +0100, Peter Eisentraut wrote:
>
> On 2020-10-06 12:26, Magnus Hagander wrote:
>
> I went with the name --no-instructions to have the same name for bot
On 02.11.2020 16:23, Magnus Hagander wrote:
On Tue, Oct 27, 2020 at 11:35:25AM +0100, Peter Eisentraut wrote:
On 2020-10-06 12:26, Magnus Hagander wrote:
I went with the name --no-instructions to have the same name for both
initdb and pg_upgrade. The downside is that "no-instructions" also
caus
On Mon, Nov 2, 2020 at 2:23 PM Magnus Hagander wrote:
>
> On Tue, Oct 27, 2020 at 12:40 PM Bruce Momjian wrote:
> >
> > On Tue, Oct 27, 2020 at 12:35:56PM +0100, Peter Eisentraut wrote:
> > > On 2020-10-27 11:53, Bruce Momjian wrote:
> > > > On Tue, Oct 27, 2020 at 11:35:25AM +0100, Peter Eisentr
On Tue, Oct 27, 2020 at 12:40 PM Bruce Momjian wrote:
>
> On Tue, Oct 27, 2020 at 12:35:56PM +0100, Peter Eisentraut wrote:
> > On 2020-10-27 11:53, Bruce Momjian wrote:
> > > On Tue, Oct 27, 2020 at 11:35:25AM +0100, Peter Eisentraut wrote:
> > > > On 2020-10-06 12:26, Magnus Hagander wrote:
> >
On Tue, Oct 27, 2020 at 12:35:56PM +0100, Peter Eisentraut wrote:
> On 2020-10-27 11:53, Bruce Momjian wrote:
> > On Tue, Oct 27, 2020 at 11:35:25AM +0100, Peter Eisentraut wrote:
> > > On 2020-10-06 12:26, Magnus Hagander wrote:
> > > > I went with the name --no-instructions to have the same name
On 2020-10-27 11:53, Bruce Momjian wrote:
On Tue, Oct 27, 2020 at 11:35:25AM +0100, Peter Eisentraut wrote:
On 2020-10-06 12:26, Magnus Hagander wrote:
I went with the name --no-instructions to have the same name for both
initdb and pg_upgrade. The downside is that "no-instructions" also
causes
On Tue, Oct 27, 2020 at 11:53 AM Bruce Momjian wrote:
> On Tue, Oct 27, 2020 at 11:35:25AM +0100, Peter Eisentraut wrote:
> > On 2020-10-06 12:26, Magnus Hagander wrote:
> > > I went with the name --no-instructions to have the same name for both
> > > initdb and pg_upgrade. The downside is that "
On Tue, Oct 27, 2020 at 11:35:25AM +0100, Peter Eisentraut wrote:
> On 2020-10-06 12:26, Magnus Hagander wrote:
> > I went with the name --no-instructions to have the same name for both
> > initdb and pg_upgrade. The downside is that "no-instructions" also
> > causes the scripts not to be written i
On 2020-10-06 12:26, Magnus Hagander wrote:
I went with the name --no-instructions to have the same name for both
initdb and pg_upgrade. The downside is that "no-instructions" also
causes the scripts not to be written in pg_upgrade, which arguably is a
different thing. We could go with "--no-in
On Tue, Oct 06, 2020 at 11:22:11AM -0400, Bruce Momjian wrote:
> On Tue, Oct 6, 2020 at 11:06:13AM -0400, Tom Lane wrote:
>> OK. FWIW, I'd vote for separate --no-instructions and --no-scripts
>> switches.
>
> Works for me.
+1.
--
Michael
signature.asc
Description: PGP signature
On Tue, Oct 6, 2020 at 11:06:13AM -0400, Tom Lane wrote:
> Magnus Hagander writes:
> > On Tue, Oct 6, 2020 at 4:31 PM Tom Lane wrote:
> >> Hm, does it matter? I think those wrappers send the output to /dev/null
> >> anyway.
>
> > The debian ones don't, because they consider it useful informati
Magnus Hagander writes:
> On Tue, Oct 6, 2020 at 4:31 PM Tom Lane wrote:
>> Hm, does it matter? I think those wrappers send the output to /dev/null
>> anyway.
> The debian ones don't, because they consider it useful information to the
> user. I'd say that it is, especially in the case of pg_upg
On Tue, Oct 6, 2020 at 4:31 PM Tom Lane wrote:
> Magnus Hagander writes:
> > The use case for this is for example the debian or redhat package
> wrappers.
> > When these commands are run under those wrappers the printed instructions
> > are *wrong*. It's better in that case to exclude them, and
Magnus Hagander writes:
> The use case for this is for example the debian or redhat package wrappers.
> When these commands are run under those wrappers the printed instructions
> are *wrong*. It's better in that case to exclude them, and let the wrapper
> be responsible for printing the correct i
On Tue, Oct 6, 2020 at 1:49 PM Ian Lawrence Barwick
wrote:
> 2020年10月6日(火) 19:26 Magnus Hagander :
> >
> > The attached patch adds a switch --no-instructions to initdb and
> pg_upgrade, which prevents them from printing instructions about how to
> start the cluster (initdb) or how to analyze and
2020年10月6日(火) 19:26 Magnus Hagander :
>
> The attached patch adds a switch --no-instructions to initdb and pg_upgrade,
> which prevents them from printing instructions about how to start the cluster
> (initdb) or how to analyze and delete clusters (pg_upgrade).
>
> The use case for this is for ex
The attached patch adds a switch --no-instructions to initdb and
pg_upgrade, which prevents them from printing instructions about how to
start the cluster (initdb) or how to analyze and delete clusters
(pg_upgrade).
The use case for this is for example the debian or redhat package wrappers.
When t
43 matches
Mail list logo
