Re: [HACKERS] Re: [COMMITTERS] pgsql: pg_rewind: Fix some problems when copying files >2GB.
Peter Eisentraut wrote: > On 9/4/17 06:03, Alvaro Herrera wrote: > > Tom Lane wrote: > >> Michael Paquier writes: > >>> I don't like breaking the abstraction of pg_log() with the existing > >>> flags with some kind of pg_debug() layer. The set of APIs present now > >>> in pg_rewind for logging is nice to have, and I think that those debug > >>> messages should be translated. So what about the attached? > >> > >> Your point about INT64_FORMAT not necessarily working with fprintf > >> is an outstanding reason not to keep it like it is. I've not reviewed > >> this patch in detail but I think this is basically the way to fix it. > > > > Actually this code goes throgh vsnprintf, not fprintf, which should be > > safe, so I removed that part of the comment, and pushed. > > Is there a reason this was not backpatched to 9.5? Done. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: pg_rewind: Fix some problems when copying files >2GB.
Peter Eisentraut wrote: > On 9/4/17 06:03, Alvaro Herrera wrote: > > Tom Lane wrote: > >> Michael Paquier writes: > >>> I don't like breaking the abstraction of pg_log() with the existing > >>> flags with some kind of pg_debug() layer. The set of APIs present now > >>> in pg_rewind for logging is nice to have, and I think that those debug > >>> messages should be translated. So what about the attached? > >> > >> Your point about INT64_FORMAT not necessarily working with fprintf > >> is an outstanding reason not to keep it like it is. I've not reviewed > >> this patch in detail but I think this is basically the way to fix it. > > > > Actually this code goes throgh vsnprintf, not fprintf, which should be > > safe, so I removed that part of the comment, and pushed. > > Is there a reason this was not backpatched to 9.5? No, I'll backpatch later. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: pg_rewind: Fix some problems when copying files >2GB.
On Thu, Sep 7, 2017 at 10:11 AM, Peter Eisentraut wrote: > On 9/4/17 06:03, Alvaro Herrera wrote: >> Tom Lane wrote: >>> Michael Paquier writes: I don't like breaking the abstraction of pg_log() with the existing flags with some kind of pg_debug() layer. The set of APIs present now in pg_rewind for logging is nice to have, and I think that those debug messages should be translated. So what about the attached? >>> >>> Your point about INT64_FORMAT not necessarily working with fprintf >>> is an outstanding reason not to keep it like it is. I've not reviewed >>> this patch in detail but I think this is basically the way to fix it. >> >> Actually this code goes throgh vsnprintf, not fprintf, which should be >> safe, so I removed that part of the comment, and pushed. > > Is there a reason this was not backpatched to 9.5? Indeed. Please note that cherry-picking the fix from 23c1f0a works just fine. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: pg_rewind: Fix some problems when copying files >2GB.
On 9/4/17 06:03, Alvaro Herrera wrote: > Tom Lane wrote: >> Michael Paquier writes: >>> I don't like breaking the abstraction of pg_log() with the existing >>> flags with some kind of pg_debug() layer. The set of APIs present now >>> in pg_rewind for logging is nice to have, and I think that those debug >>> messages should be translated. So what about the attached? >> >> Your point about INT64_FORMAT not necessarily working with fprintf >> is an outstanding reason not to keep it like it is. I've not reviewed >> this patch in detail but I think this is basically the way to fix it. > > Actually this code goes throgh vsnprintf, not fprintf, which should be > safe, so I removed that part of the comment, and pushed. Is there a reason this was not backpatched to 9.5? -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: pg_rewind: Fix some problems when copying files >2GB.
Tom Lane wrote: > Michael Paquier writes: > > I don't like breaking the abstraction of pg_log() with the existing > > flags with some kind of pg_debug() layer. The set of APIs present now > > in pg_rewind for logging is nice to have, and I think that those debug > > messages should be translated. So what about the attached? > > Your point about INT64_FORMAT not necessarily working with fprintf > is an outstanding reason not to keep it like it is. I've not reviewed > this patch in detail but I think this is basically the way to fix it. Actually this code goes throgh vsnprintf, not fprintf, which should be safe, so I removed that part of the comment, and pushed. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: pg_rewind: Fix some problems when copying files >2GB.
On Thu, Aug 31, 2017 at 8:39 AM, Alvaro Herrera wrote: > Michael Paquier wrote: >> So, perhaps it would be better to fix that before the next point release? > > Sure, I'll get it done on Friday, or tomorrow if I can manage it. Thanks, Álvaro. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: pg_rewind: Fix some problems when copying files >2GB.
Michael Paquier wrote: > On Tue, Aug 29, 2017 at 11:26 AM, Tom Lane wrote: > > Michael Paquier writes: > >> I don't like breaking the abstraction of pg_log() with the existing > >> flags with some kind of pg_debug() layer. The set of APIs present now > >> in pg_rewind for logging is nice to have, and I think that those debug > >> messages should be translated. So what about the attached? > > > > Your point about INT64_FORMAT not necessarily working with fprintf > > is an outstanding reason not to keep it like it is. I've not reviewed > > this patch in detail but I think this is basically the way to fix it. > > So, perhaps it would be better to fix that before the next point release? Sure, I'll get it done on Friday, or tomorrow if I can manage it. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: pg_rewind: Fix some problems when copying files >2GB.
On Tue, Aug 29, 2017 at 11:26 AM, Tom Lane wrote: > Michael Paquier writes: >> I don't like breaking the abstraction of pg_log() with the existing >> flags with some kind of pg_debug() layer. The set of APIs present now >> in pg_rewind for logging is nice to have, and I think that those debug >> messages should be translated. So what about the attached? > > Your point about INT64_FORMAT not necessarily working with fprintf > is an outstanding reason not to keep it like it is. I've not reviewed > this patch in detail but I think this is basically the way to fix it. So, perhaps it would be better to fix that before the next point release? -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: pg_rewind: Fix some problems when copying files >2GB.
Michael Paquier writes: > I don't like breaking the abstraction of pg_log() with the existing > flags with some kind of pg_debug() layer. The set of APIs present now > in pg_rewind for logging is nice to have, and I think that those debug > messages should be translated. So what about the attached? Your point about INT64_FORMAT not necessarily working with fprintf is an outstanding reason not to keep it like it is. I've not reviewed this patch in detail but I think this is basically the way to fix it. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: pg_rewind: Fix some problems when copying files >2GB.
On Mon, Aug 28, 2017 at 11:24 PM, Robert Haas wrote: > On Mon, Aug 28, 2017 at 10:16 AM, Alvaro Herrera > wrote: >>> I am fine with however you want to handle it, but it seems odd to me >>> that we don't have a way of embedding INT64_FORMAT in a translatable >>> string. Surely that's going to be a problem in some case, sometime, >>> isn't it? >> >> The way we do that elsewhere is to print out the value to a string >> variable and then use %s in the translatable message. > > Hmm. OK. That doesn't sound great, but if there's no better option... I don't like breaking the abstraction of pg_log() with the existing flags with some kind of pg_debug() layer. The set of APIs present now in pg_rewind for logging is nice to have, and I think that those debug messages should be translated. So what about the attached? -- Michael rewind-int64-log.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers