To give you another thanks: IT is compatible with discapacity. Great
Sascha Kuhl schrieb am Mo., 29. Nov. 2021, 17:39:
> Buch (buchen sollst du suchen), Buchhaltung is great. Thanks for the
> writing.
>
> Stephen Frost schrieb am Mo., 5. Aug. 2019, 21:02:
>
>> Greetings,
>>
>> On Mon, Aug 5, 20
Buch (buchen sollst du suchen), Buchhaltung is great. Thanks for the
writing.
Stephen Frost schrieb am Mo., 5. Aug. 2019, 21:02:
> Greetings,
>
> On Mon, Aug 5, 2019 at 14:43 Tom Lane wrote:
>
>> Robert Haas writes:
>> > On Mon, Aug 5, 2019 at 2:29 PM Tom Lane wrote:
>> >> I think Stephen is
On Wed, Aug 21, 2019 at 12:25:22PM -0400, Stephen Frost wrote:
> That'd be the kind of thing that I was really hoping we could provide a
> common library for.
Indeed. There could be many use cases for that. Most of the parsing
logic is in guc-file.l. There is little dependency to elog() and
the
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> +
> + External tools may also
> + modify postgresql.auto.conf. It is not
> + recommended to do this while the server is running, since a
> + concurrent ALTER SYSTEM command could overwrite
> + such changes. Such tools mi
On 8/16/19 12:22 AM, Tom Lane wrote:
Stephen Frost writes:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
In hopes of moving this along, I've pushed Ian's last code change,
as there seems to be no real argument about that anymore.
As for the doc changes, how about the attached revision of what
I wrot
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> In hopes of moving this along, I've pushed Ian's last code change,
>> as there seems to be no real argument about that anymore.
>>
>> As for the doc changes, how about the attached revision of what
>> I wrote previously? It gives
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> Perhaps we could put some of these details into the Notes section of the
> >> ALTER SYSTEM ref page. But I wonder how much of this is needed at all.
>
> > I'd be alright wit
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Perhaps we could put some of these details into the Notes section of the
>> ALTER SYSTEM ref page. But I wonder how much of this is needed at all.
> I'd be alright with that too, but I'd be just as fine with even a README
> or som
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Ian Barwick writes:
> >>> I dislike the special-casing of ALTER SYSTEM here, where we're basically
> >>> saying that only ALTER SYSTEM is allowed to do this cleanup and that if
> >>> such cleanup is wanted then ALTER SYSTEM must be run.
>
> > T
Ian Barwick writes:
> On 8/6/19 11:16 AM, Stephen Frost wrote:
>>> Erm, those are duplicates though and we're saying that ALTER SYSTEM
>>> removes those... Seems like we should be normalizing the file to be
>>> consistent in this regard too.
> True. (Switches brain on)... Ah yes, with the patch
On 8/6/19 11:16 AM, Stephen Frost wrote:
> Greetings,
>
> * Ian Barwick (ian.barw...@2ndquadrant.com) wrote:
>> On 8/6/19 9:52 AM, Stephen Frost wrote:> Greetings,
>>> * Tom Lane (t...@sss.pgh.pa.us) wrote:
+
+ External tools might also
+ modify postgresql.auto.conf
On Mon, Aug 05, 2019 at 10:16:16PM -0400, Stephen Frost wrote:
> * Ian Barwick (ian.barw...@2ndquadrant.com) wrote:
>> On 8/6/19 9:52 AM, Stephen Frost wrote:> Greetings,
>>> * Tom Lane (t...@sss.pgh.pa.us) wrote:
Concretely, how about the attached?
(Digging around in config.sgml, I
Greetings,
* Ian Barwick (ian.barw...@2ndquadrant.com) wrote:
> On 8/6/19 9:52 AM, Stephen Frost wrote:> Greetings,
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> Robert Haas writes:
> >>> On Mon, Aug 5, 2019 at 2:42 PM Tom Lane wrote:
> I don't think we need to go on about it at great len
On 8/6/19 9:52 AM, Stephen Frost wrote:> Greetings,
>
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Robert Haas writes:
>>> On Mon, Aug 5, 2019 at 2:42 PM Tom Lane wrote:
I don't think we need to go on about it at great length, but it seems
to me that it'd be reasonable to point out that
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Robert Haas writes:
> > On Mon, Aug 5, 2019 at 2:42 PM Tom Lane wrote:
> >> I don't think we need to go on about it at great length, but it seems
> >> to me that it'd be reasonable to point out that (a) you'd be well
> >> advised not to touch t
On Mon, Aug 5, 2019 at 3:07 PM Tom Lane wrote:
> Concretely, how about the attached?
Works for me, for whatever that's worth.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Robert Haas writes:
> On Mon, Aug 5, 2019 at 2:42 PM Tom Lane wrote:
>> I don't think we need to go on about it at great length, but it seems
>> to me that it'd be reasonable to point out that (a) you'd be well
>> advised not to touch the file while the postmaster is up, and (b)
>> last setting w
Greetings,
On Mon, Aug 5, 2019 at 14:43 Tom Lane wrote:
> Robert Haas writes:
> > On Mon, Aug 5, 2019 at 2:29 PM Tom Lane wrote:
> >> I think Stephen is not being unreasonable to suggest that we need some
> >> documentation about what external tools may safely do to pg.auto.conf.
> >> So someb
Robert Haas writes:
> But that's not the problem. The problem is that ALTER SYSTEM modifies
> the first match instead of the last one, when it's a well-established
> principle that when reading from a PostgreSQL configuration file, the
> system adopts the value from the last match, not the first
Greetings,
On Mon, Aug 5, 2019 at 14:38 Robert Haas wrote:
> On Mon, Aug 5, 2019 at 2:29 PM Tom Lane wrote:
> > Robert Haas writes:
> > > All we need to do to resolve this issue is have Tom commit his patch.
> >
> > I think Stephen is not being unreasonable to suggest that we need some
> > doc
On Mon, Aug 5, 2019 at 2:35 PM Stephen Frost wrote:
> I dare say that if we had some documentation around what to expect and how to
> deal with it, for our own tools as well as external ones, then maybe we
> wouldn’t be in this situation in the first place. Clearly ALTER SYSTEM and
> the pg_ba
On Mon, Aug 5, 2019 at 2:42 PM Tom Lane wrote:
> I don't think we need to go on about it at great length, but it seems
> to me that it'd be reasonable to point out that (a) you'd be well
> advised not to touch the file while the postmaster is up, and (b)
> last setting wins. Those things are equa
Robert Haas writes:
> On Mon, Aug 5, 2019 at 2:29 PM Tom Lane wrote:
>> I think Stephen is not being unreasonable to suggest that we need some
>> documentation about what external tools may safely do to pg.auto.conf.
>> So somebody's got to write that.
> I mean, really? We're going to document
On Mon, Aug 5, 2019 at 2:29 PM Tom Lane wrote:
> Robert Haas writes:
> > All we need to do to resolve this issue is have Tom commit his patch.
>
> I think Stephen is not being unreasonable to suggest that we need some
> documentation about what external tools may safely do to pg.auto.conf.
> So s
Greetings,
On Mon, Aug 5, 2019 at 14:29 Tom Lane wrote:
> Robert Haas writes:
> > All we need to do to resolve this issue is have Tom commit his patch.
>
> I think Stephen is not being unreasonable to suggest that we need some
> documentation about what external tools may safely do to pg.auto.c
Robert Haas writes:
> All we need to do to resolve this issue is have Tom commit his patch.
I think Stephen is not being unreasonable to suggest that we need some
documentation about what external tools may safely do to pg.auto.conf.
So somebody's got to write that. But I agree that we could go
Greetings,
On Mon, Aug 5, 2019 at 14:11 Andres Freund wrote:
> On 2019-08-05 13:34:39 -0400, Stephen Frost wrote:
> > * Andres Freund (and...@anarazel.de) wrote:
> > > On 2019-08-05 12:43:24 -0400, Tom Lane wrote:
> > > > On the other hand, people have also opined that they want full error
> > >
On Mon, Aug 5, 2019 at 1:29 PM Stephen Frost wrote:
> No, that isn't the point of the controversy nor does it relate, at all,
> to what you quoted above, so I don't think there's much value in
> responding to the discussion about WARNING or not that you put together
> below.
Well, if that's not w
Hi,
On 2019-08-05 13:34:39 -0400, Stephen Frost wrote:
> * Andres Freund (and...@anarazel.de) wrote:
> > On 2019-08-05 12:43:24 -0400, Tom Lane wrote:
> > > On the other hand, people have also opined that they want full error
> > > checking on the inserted values, and that seems out of reach with
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2019-08-05 12:43:24 -0400, Tom Lane wrote:
> > On the other hand, people have also opined that they want full error
> > checking on the inserted values, and that seems out of reach with less
> > than a full running system (mumble extensio
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Aug 5, 2019 at 10:21 AM Stephen Frost wrote:
> > Just to be clear, I brought up this exact concern back in *November*:
> >
> > https://www.postgresql.org/message-id/20181127153405.GX3415%40tamriel.snowman.net
> >
> > And now becaus
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Robert Haas writes:
> > On Mon, Aug 5, 2019 at 12:25 PM Tom Lane wrote:
> >> Perhaps as a future improvement, but it's not happening for v12,
> >> at least not unless you accept "use ALTER SYSTEM in a standalone
> >> backend" as a usable answer
On Mon, Aug 5, 2019 at 10:21 AM Stephen Frost wrote:
> Just to be clear, I brought up this exact concern back in *November*:
>
> https://www.postgresql.org/message-id/20181127153405.GX3415%40tamriel.snowman.net
>
> And now because this was pushed forward and the concerns that I raised
> ignored, w
Hi,
On 2019-08-05 12:43:24 -0400, Tom Lane wrote:
> Yeah, good point. There are a lot of other cases where you really
> don't want system startup to happen, too.
Agreed.
> On the other hand, people have also opined that they want full error
> checking on the inserted values, and that seems out
Robert Haas writes:
> On Mon, Aug 5, 2019 at 12:25 PM Tom Lane wrote:
>> Perhaps as a future improvement, but it's not happening for v12,
>> at least not unless you accept "use ALTER SYSTEM in a standalone
>> backend" as a usable answer.
> I'm not sure that would even work for the cases at issue
On Mon, Aug 5, 2019 at 12:25 PM Tom Lane wrote:
> Perhaps as a future improvement, but it's not happening for v12,
> at least not unless you accept "use ALTER SYSTEM in a standalone
> backend" as a usable answer.
I'm not sure that would even work for the cases at issue ... because
we're talking a
David Fetter writes:
> On Mon, Aug 05, 2019 at 03:52:07PM +0900, Ian Barwick wrote:
>> On 8/4/19 1:59 AM, Tom Lane wrote:
>>> I think we should just accept the facts on the ground, which are that
>>> some tools modify pg.auto.conf by appending to it
>> +1. It's just a text file...
> So are cront
On Mon, Aug 05, 2019 at 03:52:07PM +0900, Ian Barwick wrote:
> On 8/4/19 1:59 AM, Tom Lane wrote:> Tomas Vondra
> writes:
> >> On Fri, Aug 02, 2019 at 06:08:02PM -0700, Andres Freund wrote:
> >>> We're WAY WAY past feature freeze. This isn't the time to rewrite guc.c,
> >>> guc-file.l to be suita
Re: Tomas Vondra 2019-08-03 <20190803124111.2aaddumd7url5wmq@development>
> If we really want to give external tools a sensible (and optional) API
> to access the file, a simple command-line tool seems much better. Say we
> have something like
>
> pg_config_file -f PATH --set KEY VALUE
> pg_co
Isaac Morland writes:
> Here's a radical suggestion: replace postgresql.auto.conf with a directory
> containing multiple files. Each file is named after a configuration
> parameter, and its content is the value of the parameter.
Hmm ... that seems like a lot of work and code churn --- in particul
Tomas Vondra writes:
> On Mon, Aug 05, 2019 at 10:21:39AM -0400, Stephen Frost wrote:
>> I'd be happier with one set of code at least being the recommended
>> approach to modifying the file and only one set of code in our codebase
>> that's messing with .auto.conf, so that, hopefully, it's done
>>
On Mon, Aug 05, 2019 at 10:21:39AM -0400, Stephen Frost wrote:
Greetings,
* Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
On Fri, Aug 02, 2019 at 06:38:46PM -0400, Stephen Frost wrote:
>On Fri, Aug 2, 2019 at 18:27 Tom Lane wrote:
>>Tomas Vondra writes:
>>> There seems to be a consensus
Here's a radical suggestion: replace postgresql.auto.conf with a directory
containing multiple files. Each file is named after a configuration
parameter, and its content is the value of the parameter.
So to remove a special configuration parameter, delete its file. To set it,
write the file, repla
Greetings,
* Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
> On Fri, Aug 02, 2019 at 06:38:46PM -0400, Stephen Frost wrote:
> >On Fri, Aug 2, 2019 at 18:27 Tom Lane wrote:
> >>Tomas Vondra writes:
> >>> There seems to be a consensus that this this not a pg_basebackup issue
> >>> (i.e. dupli
On 8/4/19 1:59 AM, Tom Lane wrote:> Tomas Vondra
writes:
>> On Fri, Aug 02, 2019 at 06:08:02PM -0700, Andres Freund wrote:
>>> We're WAY WAY past feature freeze. This isn't the time to rewrite guc.c,
>>> guc-file.l to be suitable for running outside of a backend environment.
>
>> Right. And even
On 8/4/19 4:13 AM, Tom Lane wrote:
Ian Barwick writes:
On 8/3/19 7:27 AM, Tom Lane wrote:
Tomas Vondra writes:
The main issue however is that no code was written yet.
Seems like it ought to be relatively simple ... but I didn't look.
The patch I originally sent does exactly this.
Ah,
Ian Barwick writes:
> On 8/3/19 7:27 AM, Tom Lane wrote:
>> Tomas Vondra writes:
>>> The main issue however is that no code was written yet.
>> Seems like it ought to be relatively simple ... but I didn't look.
> The patch I originally sent does exactly this.
Ah, you did send a patch, but that
Tomas Vondra writes:
> On Fri, Aug 02, 2019 at 06:08:02PM -0700, Andres Freund wrote:
>> We're WAY WAY past feature freeze. This isn't the time to rewrite guc.c,
>> guc-file.l to be suitable for running outside of a backend environment.
> Right. And even if we had the code, it's not quite backpat
On Fri, Aug 02, 2019 at 06:08:02PM -0700, Andres Freund wrote:
Hi,
On 2019-08-02 20:57:20 -0400, Stephen Frost wrote:
No, I’m saying that we already *have* a library and we can add a few
functions to it and if people want to leverage those functions then they
can write glue code to do so, just
Hi,
On 2019-08-02 20:57:20 -0400, Stephen Frost wrote:
> No, I’m saying that we already *have* a library and we can add a few
> functions to it and if people want to leverage those functions then they
> can write glue code to do so, just like was done with libpq. The argument
> that “we shouldn’t
Greetings,
On Fri, Aug 2, 2019 at 20:46 Andres Freund wrote:
> Hi,
>
> On 2019-08-02 20:27:25 -0400, Stephen Frost wrote:
> > On Fri, Aug 2, 2019 at 18:47 Tom Lane wrote:
> > > Stephen Frost writes:
> > > > On Fri, Aug 2, 2019 at 18:27 Tom Lane wrote:
> > > >>> The proposal seems to be to run
Hi,
On 2019-08-02 20:27:25 -0400, Stephen Frost wrote:
> On Fri, Aug 2, 2019 at 18:47 Tom Lane wrote:
> > Stephen Frost writes:
> > > On Fri, Aug 2, 2019 at 18:27 Tom Lane wrote:
> > >>> The proposal seems to be to run through the .auto.conf file, remove any
> > >>> duplicates, and append the n
Greetings,
On Fri, Aug 2, 2019 at 18:47 Tom Lane wrote:
> Stephen Frost writes:
> > On Fri, Aug 2, 2019 at 18:27 Tom Lane wrote:
> >>> The proposal seems to be to run through the .auto.conf file, remove any
> >>> duplicates, and append the new entry at the end. That seems reasonable.
>
> >> +1
Greetings,
On Fri, Aug 2, 2019 at 19:36 Ian Barwick
wrote:
> On 8/3/19 8:24 AM, Andres Freund wrote:
> > Hi,
> >
> > On 2019-08-03 08:22:29 +0900, Ian Barwick wrote:
> >> What I came up with shoehorned a stripped-down version of the backend
> >> config parser into fe_utils and provides a functio
On 8/3/19 8:24 AM, Andres Freund wrote:
Hi,
On 2019-08-03 08:22:29 +0900, Ian Barwick wrote:
What I came up with shoehorned a stripped-down version of the backend
config parser into fe_utils and provides a function to modify pg.auto.conf
in much the same way ALTER SYSTEM does, but with only the
Hi,
On 2019-08-03 08:22:29 +0900, Ian Barwick wrote:
> What I came up with shoehorned a stripped-down version of the backend
> config parser into fe_utils and provides a function to modify pg.auto.conf
> in much the same way ALTER SYSTEM does, but with only the basic syntax
> checking provided by
On 8/3/19 7:56 AM, Andres Freund wrote:
Hi,
On 2019-08-02 18:47:07 -0400, Tom Lane wrote:
Stephen Frost writes:
I disagree that this should only be addressed in alter system, as I’ve said
before and as others have agreed with. Having one set of code that can be
used to update parameters in t
On 8/3/19 8:09 AM, Tom Lane wrote:
I wrote:
Andres Freund writes:
I think a commandline tool to perform the equivalent of ALTER SYSTEM on
a shutdown cluster would be a great tool.
Perhaps, but ...
Obviously this is widely out of scope for v12.
... this.
Although, there's always
ech
I wrote:
> Andres Freund writes:
>> I think a commandline tool to perform the equivalent of ALTER SYSTEM on
>> a shutdown cluster would be a great tool.
> Perhaps, but ...
>> Obviously this is widely out of scope for v12.
> ... this.
Although, there's always
echo "alter system set work_mem =
Andres Freund writes:
> On 2019-08-02 18:47:07 -0400, Tom Lane wrote:
>> I don't find that to be necessary or even desirable. Many (most?) of the
>> situations where this would be important wouldn't have access to a running
>> backend, and maybe not to any PG code at all --- what if your tool isn
On Fri, Aug 02, 2019 at 06:38:46PM -0400, Stephen Frost wrote:
Greetings,
On Fri, Aug 2, 2019 at 18:27 Tom Lane wrote:
Tomas Vondra writes:
> There seems to be a consensus that this this not a pg_basebackup issue
> (i.e. duplicate values don't make the file invalid), and it should be
> handl
Hi,
On 2019-08-02 18:47:07 -0400, Tom Lane wrote:
> Stephen Frost writes:
> > I disagree that this should only be addressed in alter system, as I’ve said
> > before and as others have agreed with. Having one set of code that can be
> > used to update parameters in the auto.conf and then have tha
Hi,
On 2019-08-02 18:38:46 -0400, Stephen Frost wrote:
> On Fri, Aug 2, 2019 at 18:27 Tom Lane wrote:
>
> > Tomas Vondra writes:
> > > There seems to be a consensus that this this not a pg_basebackup issue
> > > (i.e. duplicate values don't make the file invalid), and it should be
> > > handled
Stephen Frost writes:
> On Fri, Aug 2, 2019 at 18:27 Tom Lane wrote:
>>> The proposal seems to be to run through the .auto.conf file, remove any
>>> duplicates, and append the new entry at the end. That seems reasonable.
>> +1
> I disagree that this should only be addressed in alter system, as
On 8/3/19 7:27 AM, Tom Lane wrote:
Tomas Vondra writes:
There seems to be a consensus that this this not a pg_basebackup issue
(i.e. duplicate values don't make the file invalid), and it should be
handled in ALTER SYSTEM.
Yeah. I doubt pg_basebackup is the only actor that can create such
sit
Greetings,
On Fri, Aug 2, 2019 at 18:27 Tom Lane wrote:
> Tomas Vondra writes:
> > There seems to be a consensus that this this not a pg_basebackup issue
> > (i.e. duplicate values don't make the file invalid), and it should be
> > handled in ALTER SYSTEM.
>
> Yeah. I doubt pg_basebackup is th
Tomas Vondra writes:
> There seems to be a consensus that this this not a pg_basebackup issue
> (i.e. duplicate values don't make the file invalid), and it should be
> handled in ALTER SYSTEM.
Yeah. I doubt pg_basebackup is the only actor that can create such
situations.
> The proposal seems to
Hi,
This thread discusses an issue that's tracked as an open item for pg12,
but it's been quiet for the last ~1 month. I think it's probably time to
decide what to do with it. The thread is a bit long, so let me sum what
the issue is and what options we have.
The problem is that ALTER SYSTEM doe
On Tue, Jun 25, 2019 at 12:42 AM Stephen Frost wrote:
>
> Greetings,
>
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > Robert Haas writes:
> > > On Fri, Jun 21, 2019 at 12:55 PM Tom Lane wrote:
> > >> Ah, got it. So it seems like the correct behavior might be for
> > >> ALTER SYSTEM to
> > >> (a)
On Tue, Jun 25, 2019 at 7:31 AM Ian Barwick wrote:
>
> > In particular, in order to consider it unexpected, you have to suppose
> >> that the content rules for postgresql.auto.conf are different from those
> >> for postgresql.conf (wherein we clearly allow last-one-wins). Can you
> >> point t
Hello
> But we already have ALTER SYSTEM, so why do we need to write it again?
> You just need to check whether the system is running: if it is, connect
> and do "ALTER SYSTEM". If it isn't, do `echo ALTER SYSTEM | postgres
> --single`.
Is this approach still possible for pg_basebackup --format=t
> In particular, in order to consider it unexpected, you have to suppose
>> that the content rules for postgresql.auto.conf are different from those
>> for postgresql.conf (wherein we clearly allow last-one-wins). Can you
>> point to any user-facing documentation that says that?
>
> The backend a
On 6/25/19 4:06 AM, Alvaro Herrera wrote:
> On 2019-Jun-24, Robert Haas wrote:
>
>> On Sat, Jun 22, 2019 at 5:13 PM Stephen Frost wrote:
>>> All that said, whatever code it is that we write for pg_basebackup to
>>> do this properly should go into our client side library, so other tools
>>> can le
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > Stephen and Magnus want a warning, because it's an indication that a
> > tool author, or *something* modified the file in an unexpected way, and
> > that we are having to do some kind of cleanup on the file because of i
Greetings,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> On 2019-Jun-24, Robert Haas wrote:
>
> > On Sat, Jun 22, 2019 at 5:13 PM Stephen Frost wrote:
> > > All that said, whatever code it is that we write for pg_basebackup to do
> > > this properly should go into our client side library
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Robert Haas writes:
> > On Fri, Jun 21, 2019 at 12:55 PM Tom Lane wrote:
> >> Ah, got it. So it seems like the correct behavior might be for
> >> ALTER SYSTEM to
> >> (a) run through the whole file and remove any conflicting lines;
> >> (b) ap
Stephen Frost writes:
> Stephen and Magnus want a warning, because it's an indication that a
> tool author, or *something* modified the file in an unexpected way, and
> that we are having to do some kind of cleanup on the file because of it.
But you're presuming something that not everybody agree
On 2019-Jun-24, Robert Haas wrote:
> On Sat, Jun 22, 2019 at 5:13 PM Stephen Frost wrote:
> > All that said, whatever code it is that we write for pg_basebackup to do
> > this properly should go into our client side library, so other tools can
> > leverage that and avoid having to write it them
* Robert Haas (robertmh...@gmail.com) wrote:
> On Sat, Jun 22, 2019 at 5:13 PM Stephen Frost wrote:
> > All that said, whatever code it is that we write for pg_basebackup to do
> > this properly should go into our client side library, so other tools can
> > leverage that and avoid having to writ
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Jun 21, 2019 at 12:55 PM Tom Lane wrote:
> > Ah, got it. So it seems like the correct behavior might be for
> > ALTER SYSTEM to
> > (a) run through the whole file and remove any conflicting lines;
> > (b) append new setting at the
Robert Haas writes:
> On Fri, Jun 21, 2019 at 12:55 PM Tom Lane wrote:
>> Ah, got it. So it seems like the correct behavior might be for
>> ALTER SYSTEM to
>> (a) run through the whole file and remove any conflicting lines;
>> (b) append new setting at the end.
> That is exactly the behavior fo
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Jun 21, 2019 at 11:24 AM Stephen Frost wrote:
> > That's not quite accurate, given that it isn't how the ALTER SYSTEM call
> > itself works, and clearly isn't how the authors of that feature expected
> > things to work or they woul
On Sat, Jun 22, 2019 at 5:13 PM Stephen Frost wrote:
> All that said, whatever code it is that we write for pg_basebackup to do this
> properly should go into our client side library, so other tools can leverage
> that and avoid having to write it themselves.
That is probably only going to help
On Fri, Jun 21, 2019 at 12:55 PM Tom Lane wrote:
> Ah, got it. So it seems like the correct behavior might be for
> ALTER SYSTEM to
> (a) run through the whole file and remove any conflicting lines;
> (b) append new setting at the end.
That is exactly the behavior for which I am arguing. Stephe
On Fri, Jun 21, 2019 at 11:24 AM Stephen Frost wrote:
> That's not quite accurate, given that it isn't how the ALTER SYSTEM call
> itself works, and clearly isn't how the authors of that feature expected
> things to work or they would have actually made it work. They didn't,
> and it doesn't actu
Greetings,
On Sat, Jun 22, 2019 at 17:43 Amit Kapila wrote:
> On Sun, Jun 23, 2019 at 2:43 AM Stephen Frost wrote:
> >
> > Greetings,
> >
> > On Sat, Jun 22, 2019 at 17:07 Amit Kapila
> wrote:
> >>
> >> On Fri, Jun 21, 2019 at 8:15 PM Robert Haas
> wrote:
> >> >
> >> > On Mon, Jun 17, 2019 at
On Sun, Jun 23, 2019 at 2:43 AM Stephen Frost wrote:
>
> Greetings,
>
> On Sat, Jun 22, 2019 at 17:07 Amit Kapila wrote:
>>
>> On Fri, Jun 21, 2019 at 8:15 PM Robert Haas wrote:
>> >
>> > On Mon, Jun 17, 2019 at 10:50 AM Ian Barwick
>> > wrote:
>> > > In Pg12, the code in pg_basebackup implies
Greetings,
On Sat, Jun 22, 2019 at 17:07 Amit Kapila wrote:
> On Fri, Jun 21, 2019 at 8:15 PM Robert Haas wrote:
> >
> > On Mon, Jun 17, 2019 at 10:50 AM Ian Barwick
> > wrote:
> > > In Pg12, the code in pg_basebackup implies the correct thing to do is
> append to .auto.conf,
> > > but as demo
On Fri, Jun 21, 2019 at 10:31 PM Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>
> > If anybody does complain, my first reaction would be to make ALTER
> > SYSTEM strip all comment lines too.
>
> Uh, I believe it already does?
>
Yeah, I also think so.
--
With Regards,
Amit Kapil
On Fri, Jun 21, 2019 at 8:15 PM Robert Haas wrote:
>
> On Mon, Jun 17, 2019 at 10:50 AM Ian Barwick
> wrote:
> > In Pg12, the code in pg_basebackup implies the correct thing to do is
> > append to .auto.conf,
> > but as demonstrated that can cause problems with duplicate entries.
>
> Yeah.
>
> T
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> I haven't been paying too close attention to this thread, but isn't
> >> that exactly what it does now and always has? guc.c, at least, certainly
> >> is going to interpret d
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> I haven't been paying too close attention to this thread, but isn't
>> that exactly what it does now and always has? guc.c, at least, certainly
>> is going to interpret duplicate entries that way.
> The issue isn't with reading th
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Robert Haas writes:
> > To me, forcing every tools author to use postgresql.conf parsing tools
> > rather than just appending to the file is a needless burden on tool
> > authors. I'd vote for just having ALTER SYSTEM silently drop all but
> >
Robert Haas writes:
> To me, forcing every tools author to use postgresql.conf parsing tools
> rather than just appending to the file is a needless burden on tool
> authors. I'd vote for just having ALTER SYSTEM silently drop all but
> the last of duplicated entries.
I haven't been paying too cl
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Jun 17, 2019 at 10:50 AM Ian Barwick
> wrote:
> > In Pg12, the code in pg_basebackup implies the correct thing to do is
> > append to .auto.conf,
> > but as demonstrated that can cause problems with duplicate entries.
>
> Yeah.
>
On Mon, Jun 17, 2019 at 10:50 AM Ian Barwick
wrote:
> In Pg12, the code in pg_basebackup implies the correct thing to do is append
> to .auto.conf,
> but as demonstrated that can cause problems with duplicate entries.
Yeah.
To me, forcing every tools author to use postgresql.conf parsing tools
On Wed, Jun 19, 2019 at 10:27 AM Ian Barwick
wrote:
>
> n 6/18/19 12:41 AM, Stephen Frost wrote:
> > Greetings,
> >
> > * Ian Barwick (ian.barw...@2ndquadrant.com) wrote
> (...)
>
> >> I suggest explicitly documenting postgresql.auto.conf behaviour (and the
> circumstances
> >> where it's ac
On Wed, Jun 19, 2019 at 10:09 AM Ian Barwick
wrote:
>
> On 6/19/19 12:46 PM, Amit Kapila wrote:
> > On Mon, Jun 17, 2019 at 8:20 PM Ian Barwick
> > wrote:
> >> On 6/15/19 1:08 AM, Stephen Frost wrote:
> >> > * Amit Kapila (amit.kapil...@gmail.com) wrote:
> >> >> Right. I think if possible,
n 6/18/19 12:41 AM, Stephen Frost wrote:
> Greetings,
>
> * Ian Barwick (ian.barw...@2ndquadrant.com) wrote
(...)
>> I suggest explicitly documenting postgresql.auto.conf behaviour (and the
circumstances
>> where it's acceptable to modify it outside of ALTER SYSTEM calls) in the
documentation
>
On 6/19/19 12:46 PM, Amit Kapila wrote:
On Mon, Jun 17, 2019 at 8:20 PM Ian Barwick wrote:
On 6/15/19 1:08 AM, Stephen Frost wrote:
> * Amit Kapila (amit.kapil...@gmail.com) wrote:
>> Right. I think if possible, it should use existing infrastructure to
>> write to postgresql.auto.conf ra
1 - 100 of 116 matches
Mail list logo
