On 4/2/21 3:43 AM, Michael Paquier wrote:
On Thu, Apr 01, 2021 at 09:56:02AM +0900, Michael Paquier wrote:
Okay, that sounds good to me.
Applied and backpatched then as 6fb66c26 & co.
Thank you!
--
-David
da...@pgmasters.net
On Thu, Apr 01, 2021 at 09:56:02AM +0900, Michael Paquier wrote:
> Okay, that sounds good to me.
Applied and backpatched then as 6fb66c26 & co.
--
Michael
signature.asc
Description: PGP signature
On Wed, Mar 31, 2021 at 09:33:25AM -0400, David Steele wrote:
> Agreed. New patch attached.
Thanks, David.
> diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml
> index c5557d5444..8c9186d277 100644
> --- a/doc/src/sgml/backup.sgml
> +++ b/doc/src/sgml/backup.sgml
> @@ -913,7 +913,8
On 3/29/21 4:34 AM, Magnus Hagander wrote:
On Mon, Mar 29, 2021 at 7:01 AM Michael Paquier wrote:
On Sun, Mar 28, 2021 at 09:29:10AM -0400, Andrew Dunstan wrote:
- vital to the backup working, and must be written without modification.
+ vital to the backup working and must be written
On Mon, Mar 29, 2021 at 7:01 AM Michael Paquier wrote:
>
> On Sun, Mar 28, 2021 at 09:29:10AM -0400, Andrew Dunstan wrote:
> > - vital to the backup working, and must be written without modification.
> > + vital to the backup working and must be written without
> > modification, which
> >
On Sun, Mar 28, 2021 at 09:29:10AM -0400, Andrew Dunstan wrote:
> - vital to the backup working, and must be written without modification.
> + vital to the backup working and must be written without
> modification, which
> + may include opening the file in binary mode.
+= "on Windows"?
On 3/26/21 2:45 PM, David Steele wrote:
> On 3/26/21 1:20 PM, Magnus Hagander wrote:
>> On Fri, Mar 26, 2021 at 5:52 PM Andrew Dunstan
>> wrote:
>>> On 3/26/21 10:19 AM, David Steele wrote:
> No, the problem is you are using copy/paste and in doing so you are
> *changing'* the value
Hi,
David Steele wrote:
>On 3/26/21 1:20 PM, Magnus Hagander wrote:
>> On Fri, Mar 26, 2021 at 5:52 PM Andrew Dunstan wrote:
>>> On 3/26/21 10:19 AM, David Steele wrote:
> No, the problem is you are using copy/paste and in doing so you are
> *changing'* the value that is being retur
On 3/26/21 1:20 PM, Magnus Hagander wrote:
On Fri, Mar 26, 2021 at 5:52 PM Andrew Dunstan wrote:
On 3/26/21 10:19 AM, David Steele wrote:
No, the problem is you are using copy/paste and in doing so you are
*changing'* the value that is being returned. You'll either need to
update your copy/p
On Fri, Mar 26, 2021 at 5:52 PM Andrew Dunstan wrote:
>
>
> On 3/26/21 10:19 AM, David Steele wrote:
> >
> >> No, the problem is you are using copy/paste and in doing so you are
> >> *changing'* the value that is being returned. You'll either need to
> >> update your copy/paste procedure to not me
On 3/26/21 10:19 AM, David Steele wrote:
>
>> No, the problem is you are using copy/paste and in doing so you are
>> *changing'* the value that is being returned. You'll either need to
>> update your copy/paste procedure to not mess with the newlines, or to
>> use a better way to get the data out
On 3/21/21 10:40 AM, Magnus Hagander wrote:
On Sat, Mar 20, 2021 at 3:10 AM wangsh.f...@fujitsu.com
wrote:
David Steele wrote:
It's not clear to me what text editors have to do with this? Are you
editing the file manually?
When I execute SELECT * FROM pg_stop_backup(false, true) in psql.
On Sat, Mar 20, 2021 at 3:10 AM wangsh.f...@fujitsu.com
wrote:
>
> David Steele wrote:
>
> > It's not clear to me what text editors have to do with this? Are you
> > editing the file manually?
>
> When I execute SELECT * FROM pg_stop_backup(false, true) in psql.
>
> The results will be shown like
David Steele wrote:
> It's not clear to me what text editors have to do with this? Are you
> editing the file manually?
When I execute SELECT * FROM pg_stop_backup(false, true) in psql.
The results will be shown like:
lsn| labelfile
On 3/19/21 6:11 AM, wangsh.f...@fujitsu.com wrote:
David Steele wrote:
I'm not sure how I feel about this patch (not really a Windows person)
but I do think that you shouldn't modify the backup_label when writing
it, i.e. you should be writing backup_label in binary mode to avoid this
issue.
Hi,
David Steele wrote:
> I'm not sure how I feel about this patch (not really a Windows person)
> but I do think that you shouldn't modify the backup_label when writing
> it, i.e. you should be writing backup_label in binary mode to avoid this
> issue.
IMO, I don't modify backup_lable,
On 1/14/21 10:50 PM, Wang, Shenhao wrote:
Please feel free to, under the section "Bug fixes". This way, it
won't get lost in the traffic of this list.
--
Michael
Thank you for your advise, added it
I'm not sure how I feel about this patch (not really a Windows person)
but I do think that
Hi, Michael
>Please feel free to, under the section "Bug fixes". This way, it
>won't get lost in the traffic of this list.
>--
>Michael
Thank you for your advise, added it
Best Regards,
Shenhao Wang
On Fri, Jan 15, 2021 at 03:29:57AM +, Wang, Shenhao wrote:
> On windows, if a backup_label file contains a windows(CRLF) line ending.
> Recovering from this backup will failed.
>
> I think this is a problem, can I add this to commitfest?
Please feel free to, under the section "Bug fixes". Th
PM
To: pgsql-hackers@lists.postgresql.org
Subject: invalid data in file backup_label problem on windows
Hi hackers.
When I using a Non-Exclusive Low-Level Backup on windows, "invalid data in file
backup_label" will be shown.
The code are listed below
if (fscanf(lfp, "STA
Hi hackers.
When I using a Non-Exclusive Low-Level Backup on windows, "invalid data in file
backup_label" will be shown.
The code are listed below
if (fscanf(lfp, "START WAL LOCATION: %X/%X (file %08X%16s)%c",
&hi, &lo, &tli_from_walseg, startxlogfilename, &ch
21 matches
Mail list logo
