pg_basebackup + SSL error: bad length
Hello, I would like to create a streaming replication, when I'm trying the basebackup from the node1, I've the following errors: pg_basebackup -P -v -D ./main -h node1 -p 5432 -U repmgr pg_basebackup: initiating base backup, waiting for checkpoint to complete pg_basebackup: checkpoint completed pg_basebackup: write-ahead log start point: 2/1328 on timeline 1 pg_basebackup: directory "/srv/pgdata/tbs_int302" exists but is not empty pg_basebackup: removing data directory "./main" In the node1 postgresql.log: LOG: could not send data to client: Connection reset by peer ERROR: base backup could not send data, aborting backup LOG: SSL error: bad length LOG: SSL error: bad length FATAL: connection to client lost When I set off the SSL in the postgresql.conf, i've the folloving error message when I try use the pg_basebackup command: LOG: could not send data to client: Broken pipe FATAL: connection to client lost Have you got any information, suggestion how can I solve this errors? My area: - Updated Debian GNU/Linux 9 - PostgreSQL 10.5 (Debian 10.5-1.pgdg90+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516, 64-bit Thx, Csaba
Re: pg_basebackup + SSL error: bad length
2018-08-27 16:08 GMT+02:00 Adrian Klaver : > Can you connect to node1 using psql with and without SSL? > > Where is node1 relative to the machine you are running pg_basebackup from? > > Just to be clear both Postgres instances are running 10.5, correct? > >> >> Every instances are same (10.5) version, and every servers are in the common VMWARE subnet. The psql connection is working fine with sslmode or without sslmode. When I try run it on the localhost (node1), I've same errors too: pg_basebackup -P -v -D /tmp/main -h localhost -p 5432 -U repmgr Thx, Csaba
Re: pg_basebackup + SSL error: bad length
Hello, Only one copy is from the pg_basebackup on the machines. I have only a tablespace only a different location: /srv/pgdata/tbs_int303 I think I solved the problem: When I delete manually the /srv/pgdata/tbs_int303 folder, the pg_basebackup is running fine. Thank you for your help, Csaba 2018-08-28 4:49 GMT+02:00 Michael Paquier : > On Mon, Aug 27, 2018 at 04:40:34PM -0700, Adrian Klaver wrote: > > Is there more then one copy of pg_basebackup on the machines? > > Or this user has created a tablespace directly in the main data folder, > which can cause pg_basebackup to fail because of recursion issues. It > is no wonder that a WARNING is created during a CREATE TABLESPACE if you > do that. > -- > Michael >
PG8.3->10 migration data differences
Hello, We would like to migrate our old databases to new postgres server, with the simple backup-restore process. The process run fine without errors but when we're checking the source and the migrated datas as field level, we found the following differences: For example: Field type: TIMESTAMP WITHOUT TIME ZONE NOT NULL pg93: 2015-08-28 21:25:07.70 pg10: 2015-08-28 21:25:07.7 Field type: REAL pg93: 2.2 pg10: 2.2005 When I check the 8.3 pg_dump file, it contains the pg83 correct values. Do you have any ideas, why different this values? Thx, Csaba
Re: PG8.3->10 migration data differences
I think I found the solution. When I set this parameter on the pg10 client connection, the pg10 REAL value format same as the pg83 value: SET extra_float_digits = 0; Interesting, because the default value is 0 in the postgresql.conf: #extra_float_digits = 0 # min -15, max 3 Do you have any ideas how can I format the miliseconds too? Thx, Csaba 2018-09-10 12:00 GMT+02:00 Peter J. Holzer : > On 2018-09-10 11:57:42 +0300, Achilleas Mantzios wrote: > > On 10/09/2018 11:22, Csaba Ragasits wrote: > > Hello, > > > > We would like to migrate our old databases to new postgres server, > > with the simple backup-restore process. The process run fine > > without errors but when we're checking the source and the > > migrated datas as field level, we found the following differences: > [...] > > > > Field type: REAL > > pg93: 2.2 > > pg10: 2.2005 > > > > > > Those have to do with rounding. Precision for real is 6 decimal > > digits. Your difference is on the 8-th digit. > > Nitpick: Precision is 24 binary digits which is *about* 6 decimal > digits. The number which is actually stored (on both pg93 and pg10) is > actually 2.200476837158203125 (1.00011001100110011001101 * 2^1 in > binary). Apparently Pg9.3 rounds this to "2.2" on output while Pg10 > prints the more precise (but still not exact) "2.2005". > > (I would argue that the Pg9.3 output is better, since it represents the > same value in fewer digits, but always printing the minimum number of > digits necessary is surprisingly difficult.) > > hp > > -- >_ | Peter J. Holzer| we build much bigger, better disasters now > |_|_) || because we have much more sophisticated > | | | h...@hjp.at | management tools. > __/ | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/> >
Re: PG8.3->10 migration data differences
Hello,
We would like to migrate from 8.3 to 10 version. We've hundreds databases
with different structures. That reason we're working on an automatic data
comparing process.
I've found the following storage settings:
- pg83: Date/time type storage: 64-bit integers
- pg10: Date/time type storage: 64-bit integers
When I running the following select from psql (Select '09/10/18
07:10:25.110'::timestamp;)
The results are same:
-pg83: 2018-09-10 07:10:25.11
-pg10: 2018-09-10 07:10:25.11
When I select it from a table (Select v.entry_timestamp from t_vis v):
The results are different:
- pg83: 2015-08-28 21:25:07.70
- pg10: 2015-08-28 21:25:07.7
The field type:
entry_timestamp TIMESTAMP WITHOUT TIME ZONE NOT NULL,
Our difference every time the last 0 values. The time values are same, but
our field based data comparing mechanism every time mark it as error.
thx,
Csaba
2018-09-10 16:21 GMT+02:00 Adrian Klaver :
> On 9/10/18 6:43 AM, Csaba Ragasits wrote:
>
>> I think I found the solution.
>>
>> When I set this parameter on the pg10 client connection, the pg10 REAL
>> value format same as the pg83 value:
>>
>> SET extra_float_digits = 0;
>>
>> Interesting, because the default value is 0 in the postgresql.conf:
>> #extra_float_digits = 0 # min -15, max 3
>>
>> Do you have any ideas how can I format the miliseconds too?
>>
>
> select version();
>version
>
>
> PostgreSQL 10.5 on x86_64-pc-linux-gnu, compiled by gcc (SUSE Linux)
> 4.8.5, 64-bit
>
> test=# select '09/10/18 07:10:25.100'::timestamp;
>timestamp
> ---
> 2018-09-10 07:10:25.1
> (1 row)
>
> test=# select '09/10/18 07:10:25.111'::timestamp;
> timestamp
> -
> 2018-09-10 07:10:25.111
>
> Milliseconds will display if they are significant.
>
>
> If you want to format the output:
>
> test=# select to_char('09/10/18 07:10:25.100'::timestamp, 'MM/DD/YY HH:MI:
> SS.MS');
> to_char
> ---
> 09/10/18 07:10:25.100
> (1 row)
>
>
>
>> Thx,
>> Csaba
>>
>> 2018-09-10 12:00 GMT+02:00 Peter J. Holzer > hjp-pg...@hjp.at>>:
>>
>> On 2018-09-10 11:57:42 +0300, Achilleas Mantzios wrote:
>> > On 10/09/2018 11:22, Csaba Ragasits wrote:
>> > Hello,
>> > > We would like to migrate our old databases to new
>> postgres server,
>> > with the simple backup-restore process. The process run fine
>> > without errors but when we're checking the source and the
>> > migrated datas as field level, we found the following
>> differences:
>> [...]
>> > > Field type: REAL
>> > pg93: 2.2
>> > pg10: 2.2005
>> > > > Those have to do with rounding. Precision for real is 6
>> decimal
>> > digits. Your difference is on the 8-th digit.
>>
>> Nitpick: Precision is 24 binary digits which is *about* 6 decimal
>> digits. The number which is actually stored (on both pg93 and pg10) is
>> actually 2.200476837158203125 (1.00011001100110011001101 * 2^1 in
>> binary). Apparently Pg9.3 rounds this to "2.2" on output while Pg10
>> prints the more precise (but still not exact) "2.2005".
>>
>> (I would argue that the Pg9.3 output is better, since it represents
>> the
>> same value in fewer digits, but always printing the minimum number of
>> digits necessary is surprisingly difficult.)
>>
>> hp
>>
>> -- _ | Peter J. Holzer| we build much bigger, better
>> disasters now
>> |_|_) || because we have much more sophisticated
>> | | | h...@hjp.at <mailto:h...@hjp.at> | management tools.
>> __/ | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>
>>
>>
>>
>
> --
> Adrian Klaver
> adrian.kla...@aklaver.com
>
