Re: Pg_basebackup failed or completed?

Put wal log in the restore directory and check during start postgresql consumed or not. If consumed then no issue. Instead of risk free create recovery.conf or standby.signal and put restore_command in that above file and see whether consumed or not. If consumed its ok. On Mon, Nov 25, 2024 at 11:

Re: pg_basebackup Restore problem

Thank You very much for your time. On Wed, Jan 17, 2024 at 4:51 PM Ron Johnson wrote: > Perfectly understandable, but tar *did* fail. Time to start debugging > your shell script. > > On Wed, Jan 17, 2024 at 4:26 PM Johnathan Tiamoh < > johnathantia...@gmail.com> wrote: > >> Ok. >> >> I'm a litt

Re: pg_basebackup Restore problem

Perfectly understandable, but tar *did* fail. Time to start debugging your shell script. On Wed, Jan 17, 2024 at 4:26 PM Johnathan Tiamoh wrote: > Ok. > > I'm a little confused because has always work > > On Wed, Jan 17, 2024 at 4:11 PM Ron Johnson > wrote: > >> Then you've got a bug somewhere

Re: pg_basebackup Restore problem

Ok. I'm a little confused because has always work On Wed, Jan 17, 2024 at 4:11 PM Ron Johnson wrote: > Then you've got a bug somewhere in: > tar -h -zxvf $PATH_FOLDER/* .tar.gz > ls $PATH_FOLDER/*.tar.gz | xargs -I {} tar -h -zxvf {} > > On Wed, Jan 17, 2024 at 4:07 PM Johnathan Tiamoh <

Re: pg_basebackup Restore problem

Then you've got a bug somewhere in: tar -h -zxvf $PATH_FOLDER/* .tar.gz ls $PATH_FOLDER/*.tar.gz | xargs -I {} tar -h -zxvf {} On Wed, Jan 17, 2024 at 4:07 PM Johnathan Tiamoh wrote: > Yes. > > I am trying to restore the backups on a standby > > On Wed, Jan 17, 2024 at 4:04 PM Ron Johnson

Re: pg_basebackup Restore problem

Yes. I am trying to restore the backups on a standby On Wed, Jan 17, 2024 at 4:04 PM Ron Johnson wrote: > Wait a minute... *tar* is throwing the errors, not pg_basebackup, no? > > On Wed, Jan 17, 2024 at 3:27 PM Johnathan Tiamoh < > johnathantia...@gmail.com> wrote: > >> 1. What's in $PATH_FOLD

Re: pg_basebackup Restore problem

Wait a minute... *tar* is throwing the errors, not pg_basebackup, no? On Wed, Jan 17, 2024 at 3:27 PM Johnathan Tiamoh wrote: > 1. What's in $PATH_FOLDER? > > /tnt/backup/current > > 2. What pg_basebackup command did you use? > > pg_basebackup -D "$baseback_dir" --format=tar \ >

Re: pg_basebackup Restore problem

1. What's in $PATH_FOLDER? /tnt/backup/current 2. What pg_basebackup command did you use? pg_basebackup -D "$baseback_dir" --format=tar \ "${comp_opts[@]}" --wal-method=stream --no-password --verbose "${PG_DUMP_OPTS[@]}" /bin/mv "$baseback_dir"/* "/enf/backup/current/"

Re: pg_basebackup Restore problem

1. What's in $PATH_FOLDER? 2. What pg_basebackup command did you use? 3. Why aren't you letting pg_basebackup maintain the WAL files it needs? On Wed, Jan 17, 2024 at 11:27 AM Johnathan Tiamoh wrote: > You need to tell us the PG version number *and* show us the full command > you ran. ? > > Post

Re: pg_basebackup Restore problem

You need to tell us the PG version number *and* show us the full command you ran. ? Postgresql Version 14.10 tar -h -zxvf $PATH_FOLDER/* .tar.gz ls $PATH_FOLDER/*.tar.gz | xargs -I {} tar -h -zxvf {} What user are you running pg_basebackup as? I ran it as postgres and now I'm restoring

Re: pg_basebackup Restore problem

On Wed, Jan 17, 2024 at 11:11 AM Johnathan Tiamoh wrote: > Hello, > > I am trying to restore a pg_basebackup and have the following errors. > > You need to tell us the PG version number *and* show us the full command you ran. > nohup: ignoring input > tar: /tnt/backup/current/7400.tar.gz: Not f

Re: pg_basebackup

## Matthias Apitz (g...@unixarea.de): > 2023-11-16 20:34:13.538 CET [6250] LOG: terminating walsender process due to > replication timeout Besides "what Lauenz said" (especially about the horribly ooutdated PostgreSQL version): check IO speed and saturation during backup and make sure you're no

Re: pg_basebackup

On Mon, 2023-11-20 at 07:30 +0100, Matthias Apitz wrote: > We're facing in a customer installation (PostgreSQL 13.1 on Linux) the > following problem for the first time and not reproducible: 13.1? Your immediate reaction should be "update to the latest minor release". > ${BINDIR}/pg_basebackup -

Re: pg_basebackup / recovery

Στις 13/4/23 01:31, ο/η Michael Paquier έγραψε: On Wed, Apr 12, 2023 at 01:45:56PM +0300, Achilleas Mantzios - cloud wrote: On 4/12/23 12:32, Fabrice Chapuis wrote: During recovery process of a self contained backup, how postgres know to stop reading wal when consistency is reached? Because it

Re: pg_basebackup / recovery

On Wed, Apr 12, 2023 at 01:45:56PM +0300, Achilleas Mantzios - cloud wrote: > On 4/12/23 12:32, Fabrice Chapuis wrote: >> During recovery process of a self contained backup, how postgres know to >> stop reading wal when consistency is reached? > > Because it knows the full packup info. It will obs

Re: pg_basebackup / recovery

On 4/12/23 12:32, Fabrice Chapuis wrote: During recovery process of a self contained backup, how postgres know to stop reading wal when consistency is reached? Because it knows the full packup info. It will observe the STOP WAL LOCATION: 3BC7/4B000130 (file 00023BC7004B) inside

Re: pg_basebackup with hostssl ?

Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Wednesday, February 2nd, 2022 at 17:20, Adrian Klaver wrote: > > Before you do that I would establish that you are connecting to the > > correct Postgres instance. > > Good news, all up and running ! The new "postgresq

Re: pg_basebackup with hostssl ?

On 2/2/22 09:18, Laura Smith wrote: Seems like I was looking for the wrong words on the right page ! Thanks, will try that. Before you do that I would establish that you are connecting to the correct Postgres instance. -- Adrian Klaver adrian.kla...@aklaver.com

Re: pg_basebackup with hostssl ?

Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Wednesday, February 2nd, 2022 at 16:50, Adrian Klaver wrote: > Not completely: > > https://www.postgresql.org/docs/current/app-pgbasebackup.html > > -d connstr > > --dbname=connstr > > Specifies parameters used to connec

Re: pg_basebackup with hostssl ?

On Wed, Feb 2, 2022 at 9:37 AM Laura Smith < n5d9xq3ti233xiyif...@protonmail.ch> wrote: > The point I am making is that pg_basebackup is connecting without > encryption and I want to know how to tell it to use encryption. The docs > are silent on the subject. > It is a client application that tal

Re: pg_basebackup with hostssl ?

On 2/2/22 08:37, Laura Smith wrote: Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Wednesday, February 2nd, 2022 at 16:30, Adrian Klaver wrote: I am not following. pg_basebackup is a stand alone client that is not involved in replication other then establishing a

Re: pg_basebackup with hostssl ?

Forgot to add that I also have : "hostsslallall10.0.0.0/8md5"

Re: pg_basebackup with hostssl ?

Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Wednesday, February 2nd, 2022 at 16:30, Adrian Klaver wrote: > I am not following. pg_basebackup is a stand alone client that is not > > involved in replication other then establishing a starting point from > > which to

Re: pg_basebackup with hostssl ?

On 2/2/22 07:48, Laura Smith wrote: I've had a quick glance through the man page for pg_basebackup but can't see any flags to set ssl. Long story short, I've got the following in pg_hba.conf of the master: hostsslreplicationall10.0.0.0/8md5 But the slave is complaining: FATAL:

Re: pg_basebackup fails with "COPY stream ended"

On Tue, Jun 15, 2021 at 09:53:45PM -0700, Dipanjan Das wrote: > > I am running "pg_basebackup -h -U postgres -D -X stream". It > fails with either of the following two error messages: > [...] > WARNING: terminating connection because of crash of another server process > DETAIL: The postmaster

Re: pg_basebackup + delta base backups

Greetings, * Christopher Pereira (krip...@imatronix.cl) wrote: > On 26-May-20 10:20, Stephen Frost wrote: > >"out of sync" is a bit of an odd concept, but having a replica fall > >behind a long way is certainly something that can happen and may require > >a rebuild from a backup (or from a new syn

Re: pg_basebackup + delta base backups

On 26-May-20 10:20, Stephen Frost wrote: [...] "out of sync" is a bit of an odd concept, but having a replica fall behind a long way is certainly something that can happen and may require a rebuild from a backup (or from a new sync off of the primary in some other way, as you suggest below). In

Re: pg_basebackup + incremental base backups

Greetings, * Christopher Pereira (krip...@imatronix.cl) wrote: > On 24-May-20 15:48, Stephen Frost wrote: > >That really shouldn't be possible. I'm very curious as to exactly what > >happened that resulted in your primary/replica being 'out of sync', as > >you say. > > Actually this was more a h

Re: pg_basebackup + incremental base backups

On 24-May-20 15:48, Stephen Frost wrote: That really shouldn't be possible. I'm very curious as to exactly what happened that resulted in your primary/replica being 'out of sync', as you say. Hi Stephen, Actually this was more a hypothetical question to find a solution in case some day one

Re: pg_basebackup + incremental base backups

Greetings, * Christopher Pereira (krip...@imatronix.cl) wrote: > Ok, we want to use pgbackrest to *rebuild a standby that has fallen behind* > (where pg_rewind won't work). After reading the docs, we believe we should > use this setup: > > a) Primary host: primary cluster > > b) Repository host:

Re: pg_basebackup + incremental base backups

We've contemplated adding support for something like this to pgbackrest, since all the pieces are there, but there hasn't been a lot of demand for it and it kind of goes against the idea of having a proper backup solution, really.. It'd also create quite a bit of load on the primary to checksum

Re: pg_basebackup + incremental base backups

On 21-May-20 08:43, Stephen Frost wrote: * Christopher Pereira (krip...@imatronix.cl) wrote: [...] Is there some way to rebuild the standby cluster by doing a differential backup of the primary cluster directly? We've contemplated adding support for something like this to pgbackrest, since a

Re: pg_basebackup + incremental base backups

Greetings, * Christopher Pereira (krip...@imatronix.cl) wrote: > On 21-May-20 08:43, Stephen Frost wrote: > >* Christopher Pereira (krip...@imatronix.cl) wrote: > >>Is there some way to rebuild the standby cluster by doing a differential > >>backup of the primary cluster directly? > >We've contemp

Re: pg_basebackup + incremental base backups

Greetings, * Christopher Pereira (krip...@imatronix.cl) wrote: > >>In case of big databases, can we do incremental backups with pg_basebackup? > >pg_basebackup doesn't support incremental backups, though there's been > >discussion of adding some kind of support for it, check -hackers if > >you're

Re: pg_basebackup + incremental base backups

In case of big databases, can we do incremental backups with pg_basebackup? pg_basebackup doesn't support incremental backups, though there's been discussion of adding some kind of support for it, check -hackers if you're curious. Is there any alternative? There's a few different alternativ

Re: pg_basebackup cannot compress to STDOUNT

On 5/8/2020 11:51 PM, Paul Förster wrote: Hi Admin, On 08. May, 2020, at 21:31, Support wrote: 2) Command run? ssh postgres@nodeXXX "pg_basebackup -h /run/postgresql -Ft -D- | pigz -c -p2 " | pigz -cd -p2 | tar -xf- -C /usr/local/pgsql/data I don't get it, sorry. Do I understand you correct

Re: pg_basebackup cannot compress to STDOUNT

Hi Admin, > On 08. May, 2020, at 21:31, Support wrote: > 2) Command run? > ssh postgres@nodeXXX "pg_basebackup -h /run/postgresql -Ft -D- | pigz -c -p2 > " | pigz -cd -p2 | tar -xf- -C /usr/local/pgsql/data I don't get it, sorry. Do I understand you correctly here that you want an online backu

Re: pg_basebackup cannot compress to STDOUNT

On 5/8/20 1:42 PM, Support wrote: On 5/8/2020 1:24 PM, Adrian Klaver wrote: On 5/8/20 12:31 PM, Support wrote: On 5/8/2020 12:18 PM, Adrian Klaver wrote: On 5/8/20 12:14 PM, Support wrote: Hi, Despite of the --help saying that it's possible to gzip to STDOUT and pipe it for another proce

Re: pg_basebackup cannot compress to STDOUNT

On 5/8/2020 1:24 PM, Adrian Klaver wrote: On 5/8/20 12:31 PM, Support wrote: On 5/8/2020 12:18 PM, Adrian Klaver wrote: On 5/8/20 12:14 PM, Support wrote: Hi, Despite of the --help saying that it's possible to gzip to STDOUT and pipe it for another process pg_basebackup fails saying tha

Re: pg_basebackup cannot compress to STDOUNT

On 5/8/20 12:31 PM, Support wrote: On 5/8/2020 12:18 PM, Adrian Klaver wrote: On 5/8/20 12:14 PM, Support wrote: Hi, Despite of the --help saying that it's possible to gzip to STDOUT and pipe it for another process pg_basebackup fails saying that it's not possible to gzip to STDOUT. 1) Po

Re: pg_basebackup cannot compress to STDOUNT

On 5/8/2020 12:18 PM, Adrian Klaver wrote: On 5/8/20 12:14 PM, Support wrote: Hi, Despite of the --help saying that it's possible to gzip to STDOUT and pipe it for another process pg_basebackup fails saying that it's not possible to gzip to STDOUT. 1) Postgres version? 2) Command run? 3

Re: pg_basebackup cannot compress to STDOUNT

On 5/8/20 12:14 PM, Support wrote: Hi, Despite of the --help saying that it's possible to gzip to STDOUT and pipe it for another process pg_basebackup fails saying that it's not possible to gzip to STDOUT. 1) Postgres version? 2) Command run? 3) Error reported? Who to believe then?

RE: pg_basebackup inconsistent performance

em stats, nothing changed, just the backups running extremely long. Was looking into pgbackrest, just haven't gotten it configured yet -Original Message- From: Stephen Frost Sent: Wednesday, May 6, 2020 12:30 PM To: Jasen Lentz Cc: Adrian Klaver ; pgsql-general@lists.postgresql.

Re: pg_basebackup inconsistent performance

Greetings, * Jasen Lentz (jle...@sescollc.com) wrote: > Where are the machines you are backing up from/to relative to each on the > network? > Direct ethernet connection between 10G network interfaces Is the backup server shared among other systems..? > Is there increased activity on the databa

RE: pg_basebackup inconsistent performance

Sent: Wednesday, May 6, 2020 10:28 AM To: Jasen Lentz ; pgsql-general@lists.postgresql.org Subject: Re: pg_basebackup inconsistent performance On 5/6/20 5:44 AM, Jasen Lentz wrote: > We have pg_basebackup running on two of our DB servers that are > replicated.  We are running postgres 11, and it s

Re: pg_basebackup inconsistent performance

On 5/6/20 5:44 AM, Jasen Lentz wrote: We have pg_basebackup running on two of our DB servers that are replicated.  We are running postgres 11, and it seems we are getting inconsistent performance from the backups and unsure as of why.  We start out at 5-6 hours over a dedicated 10G port for 7TB

Re: pg_basebackup inconsistent performance

On 5/6/20 5:44 AM, Jasen Lentz wrote: We have pg_basebackup running on two of our DB servers that are replicated.  We are running postgres 11, and it seems we are getting inconsistent performance from the backups and unsure as of why.  We start out at 5-6 hours over a dedicated 10G port for 7TB

Re: pg_basebackup && long time storage of wal_archive/ content

On 4/14/20 11:16 PM, Matthias Apitz wrote: El día Dienstag, April 14, 2020 a las 08:28:35 -0700, Adrian Klaver escribió: On 4/14/20 8:00 AM, Matthias Apitz wrote: Hello, The run (as user 'postgres') on the server of the cmd: pg_basebackup -U ${DBSUSER} -Ft -z -D /data/postgresql11/backup-w

Re: pg_basebackup && long time storage of wal_archive/ content

On Wed, 2020-04-15 at 08:16 +0200, Matthias Apitz wrote: > > > The run (as user 'postgres') on the server of the cmd: > > > > > > pg_basebackup -U ${DBSUSER} -Ft -z -D > > > /data/postgresql11/backup-wal_archive-20200414-1/ > > > > > > produces correctly the following situtation on the server:

Re: pg_basebackup && long time storage of wal_archive/ content

El día Dienstag, April 14, 2020 a las 08:28:35 -0700, Adrian Klaver escribió: > On 4/14/20 8:00 AM, Matthias Apitz wrote: > > > > Hello, > > > > The run (as user 'postgres') on the server of the cmd: > > > > pg_basebackup -U ${DBSUSER} -Ft -z -D > > /data/postgresql11/backup-wal_archive-202004

Re: pg_basebackup && long time storage of wal_archive/ content

On 4/14/20 8:00 AM, Matthias Apitz wrote: Hello, The run (as user 'postgres') on the server of the cmd: pg_basebackup -U ${DBSUSER} -Ft -z -D /data/postgresql11/backup-wal_archive-20200414-1/ produces correctly the following situtation on the server: srap32dxr1:/data/postgresql11 # ls -ltrh

Re: pg_basebackup connection closed unexpectedly...

On Wed, Feb 12, 2020 at 4:09 PM Tom Lane wrote: > =?UTF-8?Q?Mladen_Marinovi=C4=87?= writes: > > Recently I am having some strange problems with pg_basebackup. About > once a > > week the backup process ends with an error message like this: > > 2020-02-11 23:25:40 UTC [25790]: [1-1] user=replicat

Re: pg_basebackup connection closed unexpectedly...

=?UTF-8?Q?Mladen_Marinovi=C4=87?= writes: > Recently I am having some strange problems with pg_basebackup. About once a > week the backup process ends with an error message like this: > 2020-02-11 23:25:40 UTC [25790]: [1-1] user=replicator,db=[unknown] LOG: > could not send data to client: Conne

Re: pg_basebackup

On Mon, Dec 23, 2019 at 4:13 AM Kyotaro Horiguchi wrote: > Hello. > > At Mon, 23 Dec 2019 03:38:12 +, Daulat Ram > wrote in > > thanks Adrian, what about the > > postmaster.opts file, this file was also skipped in backup. > > The file is overwritten at startup so there's no point in having i

Re: pg_basebackup

Hello. At Mon, 23 Dec 2019 03:38:12 +, Daulat Ram wrote in > thanks Adrian, what about the > postmaster.opts file, this file was also skipped in backup. The file is overwritten at startup so there's no point in having it in a backup. Thus, it is deliberately excluded from a backup. regard

Re: pg_basebackup

thanks Adrian, what about the postmaster.opts file, this file was also skipped in backup. We have single cluster running on the VM. Thanks. On 22-Dec-2019 11:19 PM, Adrian Klaver wrote: On 12/22/19 1:56 AM, Daulat Ram wrote: > Hello, > > I am taking pg_basebackup of primary db (docker containe

Re: pg_basebackup

On 12/22/19 1:56 AM, Daulat Ram wrote: Hello, I am taking pg_basebackup of primary db (docker container env.) using the below command : pg_basebackup -x -h vmzti -U replication -D /etc/postgresql/9.5/main/pg_basebkp/basekp1224 -Ft -z -P Password: WARNING:  skipping special file "./postgre

Re: pg_basebackup + incremental base backups

Greetings, * Christopher Pereira (krip...@imatronix.cl) wrote: > Our stream replication slave server got out of sync so we need to base > backup again. If you do WAL archiving instead of depending on the WAL to exist on the primary then a replica can catch up using WAL. Having a WAL archive also

Re: pg_basebackup + incremental base backups

On Fri, Nov 29, 2019 at 04:57:11PM -0300, Christopher Pereira wrote: > Our stream replication slave server got out of sync so we need to base > backup again. > > In case of big databases, can we do incremental backups with pg_basebackup? I know of two ways to define such backups, one being actual

RE: pg_basebackup exit codes

Thanks a lot Magnus! I should have known better … ☺ But thanks for the PIPESTATUS hint which comes in uttermost handy Regards, John Van: Magnus Hagander Verzonden: maandag 19 augustus 2019 13:46 Aan: John Donath CC: pgsql-general@lists.postgresql.org Onderwerp: Re: pg_basebackup exit codes

Re: pg_basebackup exit codes

On Mon, Aug 19, 2019 at 12:18 PM John Donath wrote: > Hi, > > > > I was unpleasantly surprised to see that pg_basebackup will return a zero > (Success) exit code even when it has actually failed like below: > > > > pg_basebackup: could not write to compressed file > "/var/lib/pgsql/10/inst1/backu

Re: pg_basebackup from 9.4-bdr to 9.4 results in corrupt index

Managed to find following in the announcement of BDR on 9.6: "BDR has always been an extension, but *on 9.4 it required a heavily patched PostgreSQL, one that isn’t fully on-disk-format compatible with stock community PostgreSQL 9.4.* The goal all along has been to allow it to run as an extension o

Re: pg_basebackup from 9.4-bdr to 9.4 results in corrupt index

On 5/25/19 11:46 AM, Jānis Pūris wrote: Hi Ron, I can not reproduce this error on BDR_Node_2 (it is not BDR_Node_1 as stated before. Typo) I've been successful in transferring the data with pg_dump on BDR_Node_2 and then restoring it on Regular_Node_1. Then running "select * from informatio

Re: pg_basebackup from 9.4-bdr to 9.4 results in corrupt index

Hi Ron, I can not reproduce this error on BDR_Node_2 (it is not BDR_Node_1 as stated before. Typo) I've been successful in transferring the data with pg_dump on BDR_Node_2 and then restoring it on Regular_Node_1. Then running "select * from information_schema.sequences;" all is OK. The problem w

Re: pg_basebackup from 9.4-bdr to 9.4 results in corrupt index

Hi, Adrian Apologies, it is a typo. pg_basebackup was taken from BDR_Node_2, not BDR_Node_1 Thank you in advance. Best regards, Janis Puris On 25 May 2019 at 19:27:42, Adrian Klaver (adrian.kla...@aklaver.com) wrote: I am not clear about above: 1) You removed BDR_Node_2 from cluster 2) You t

Re: pg_basebackup from 9.4-bdr to 9.4 results in corrupt index

On 5/25/19 9:49 AM, Jānis Pūris wrote: Hello, I'm working with a 9.4-bdr cluster and want to move away from BDR tech all together. So my idea was to follow instructions on http://bdr-project.org/docs/stable/ to first strip the node from BDR making it into "regular" node and then moving the da

Re: pg_basebackup from 9.4-bdr to 9.4 results in corrupt index

On 5/25/19 11:49 AM, Jānis Pūris wrote: Hello, I'm working with a 9.4-bdr cluster and want to move away from BDR tech all together. So my idea was to follow instructions on http://bdr-project.org/docs/stable/ to first strip the node from BDR making it into "regular" node and then moving the d

Re: pg_basebackup: could not receive data from WAL stream

wal_sender_timeout should be as long as necessary. Each wal file is 16MB, so it should be *at least* as long as the time needed to transfer 16MB*wal_keep_segments. Take a look at the size of your pg_xlog folder. On Sun, Sep 2, 2018 at 3:41 PM Adrian Klaver wrote: > On 09/01/2018 09:06 PM, greigw

Re: pg_basebackup: could not receive data from WAL stream

On 09/01/2018 09:06 PM, greigwise wrote: Hello. On postgresql 10.5, my pg_basebackup is failing with this error: pg_basebackup: could not receive data from WAL stream: server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the r

Re: pg_basebackup: could not receive data from WAL stream

I should also add that when it fails, it's always right at the very end of the backup when it's very nearly done or maybe even after it's done. Thanks again. Greig -- Sent from: http://www.postgresql-archive.org/PostgreSQL-general-f1843780.html

Re: pg_basebackup + SSL error: bad length

On 08/28/2018 01:58 AM, Csaba Ragasits wrote: 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 i

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

Re: pg_basebackup + SSL error: bad length

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

Re: pg_basebackup + SSL error: bad length

On 08/27/2018 07:38 AM, Csaba Ragasits wrote: 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 b

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) vers

Re: pg_basebackup + SSL error: bad length

On 08/27/2018 02:00 AM, Csaba Ragasits wrote: 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 checkpoi

Re: pg_basebackup failed to read a file

On Tue, Aug 14, 2018 at 12:14:59PM -0400, Tom Lane wrote: > That seems like a pretty expensive thing to do, if there are lots of > files ... and you'd still end up failing, so it's not moving the ball > very far. Yeah, I would think that with many small relations it is going to have a measurable p

Re: pg_basebackup failed to read a file

On 08/14/2018 09:14 AM, Tom Lane wrote: Mike Cardwell writes: It'd be nice to have a more coherent theory about what needs to be copied or not, and not fail on files that could simply be ignored. Up to now we've resisted having any centrally defined knowledge of what can be inside a PG data di

Re: pg_basebackup failed to read a file

Greetings, * Ron (ronljohnso...@gmail.com) wrote: > On 08/14/2018 11:14 AM, Tom Lane wrote: > >Mike Cardwell writes: > >>pg_basebackup: could not get write-ahead log end position from server: > >>ERROR:  could not open file "./postgresql.conf~": Permission denied > >>Now, I know what this error m

Re: pg_basebackup failed to read a file

On 08/14/2018 12:14 PM, Ron wrote: > Why is checking a bunch of file permissions anywhere close to being as > expensive as transferring 1.5TB over a WAN link? Normally it shouldn't be but I recently had postgres create ~13M .snap files and just opendir() took longer than anyone would care to wait

Re: pg_basebackup failed to read a file

On 08/14/2018 11:14 AM, Tom Lane wrote: Mike Cardwell writes: pg_basebackup: could not get write-ahead log end position from server: ERROR:  could not open file "./postgresql.conf~": Permission denied Now, I know what this error means. There was a root owned file at "/var/lib/pgsql/10/data/p

Re: pg_basebackup failed to read a file

Mike Cardwell writes: > pg_basebackup: could not get write-ahead log end position from server: > ERROR:  could not open file "./postgresql.conf~": Permission denied > Now, I know what this error means. There was a root owned file at > "/var/lib/pgsql/10/data/postgresql.conf~" which contained an o

Re: pg_basebackup without copying the logs

>Not that I know of. Ok, Thanks for attention. De: Adrian Klaver Enviado: terça-feira, 31 de julho de 2018 19:05 Para: Johnes Castro Cc: pgsql-general Assunto: Re: pg_basebackup without copying the logs On 07/31/2018 01:59 PM, Johnes Castro wrote: Please re

Re: pg_basebackup without copying the logs

a, 31 de julho de 2018 18:57 *Para:* Johnes Castro; pgsql-gene...@postgresql.org *Assunto:* Re: pg_basebackup without copying the logs On 07/31/2018 01:42 PM, Johnes Castro wrote: Hi is there any way to do pg_basebackup without copying the logs? Are you talking about the transaction logs(WAL) o

Re: pg_basebackup without copying the logs

; pgsql-gene...@postgresql.org *Assunto:* Re: pg_basebackup without copying the logs On 07/31/2018 01:42 PM, Johnes Castro wrote: Hi is there any way to do pg_basebackup without copying the logs? Are you talking about the transaction logs(WAL) or the logging messages? Best Regards, Johnes

Re: pg_basebackup without copying the logs

logging messages. I've noticed that in version 10, you have the -X none option. De: Adrian Klaver Enviado: terça-feira, 31 de julho de 2018 18:57 Para: Johnes Castro; pgsql-gene...@postgresql.org Assunto: Re: pg_basebackup without copying the logs On

Re: pg_basebackup without copying the logs

On 07/31/2018 01:42 PM, Johnes Castro wrote: Hi is there any way to do pg_basebackup without copying the logs? Are you talking about the transaction logs(WAL) or the logging messages? Best Regards, Johnes Castro Tecnisys -- Adrian Klaver adrian.kla...@aklaver.com

Re: pg_basebackup restore a single table

Thank you! -- Sent from: http://www.postgresql-archive.org/PostgreSQL-general-f1843780.html

Re: pg_basebackup restore a single table

On Wed, Apr 11, 2018 at 8:22 AM, Ron wrote: > On 04/11/2018 10:21 AM, Andreas Kretschmer wrote: >> >> Am 11.04.2018 um 15:53 schrieb camarillo: >> >>> Can I do a restore of a single table or single base using the archive >>> generated for the basebackup without having to delete the filesystem >>>

Re: pg_basebackup restore a single table

On Wed, Apr 11, 2018 at 11:22 AM, Ron wrote: > > > On 04/11/2018 10:21 AM, Andreas Kretschmer wrote: > >> >> >> Am 11.04.2018 um 15:53 schrieb camarillo: >> >>> Can I do a restore of a single table or single base using the archive >>> generated for the basebackup without having to delete the file

Re: pg_basebackup restore a single table

On 04/11/2018 10:21 AM, Andreas Kretschmer wrote: Am 11.04.2018 um 15:53 schrieb camarillo: Can I do a restore of a single table or single base using the archive generated for the basebackup without having to delete the filesystem (/var/lib/pgsql/9.5/*)?. No, but you can use a spare machin

Re: pg_basebackup restore a single table

Am 11.04.2018 um 15:53 schrieb camarillo: Can I do a restore of a single table or single base using the archive generated for the basebackup without having to delete the filesystem (/var/lib/pgsql/9.5/*)?. No, but you can use a spare machine to restore the hole database (point-in-time-recove

Re: pg_basebackup or dump for starting replication process

PegoraroF10 wrote: > For replication purposes only, there are any difference between pg_basebackup > or dump to copy data from Master to Slave ? > On Docs is written that pg_basebackup can be used both for point-in-time > recovery and as the starting point for a log shipping or streaming > replicat

RE: pg_basebackup is taking more time than expected

> According to our previous discussion, pg_basebackup is not depend on any of > the postgresql configuration parameters. If I go for gzip format we need to > compromise on time. You do not necessarily compromise on time when compressing. Actually, a speed gain compared to uncompressed is possib

Re: pg_basebackup is taking more time than expected

On Mon, Jan 15, 2018 at 7:57 AM, Raghavendra Rao J S V < raghavendra...@gmail.com> wrote: > I am looking for the help to minimise the time taken by the pg_basebackup > utility. > > As informed Earlier we are taking the backup of the database using > pg_basbackup utility using below command. > > $P

Re: pg_basebackup is taking more time than expected

I am looking for the help to minimise the time taken by the pg_basebackup utility. As informed Earlier we are taking the backup of the database using pg_basbackup utility using below command. $PGHOME/bin/pg_basebackup -p 5433 -U postgres -P -v -x --format=tar --gzip --compress=6 --pgdata=- -D /op

Re: pg_basebackup is taking more time than expected

Greetings, * Raghavendra Rao J S V (raghavendra...@gmail.com) wrote: > I am asking in my previous mail as, Does the pg_basebackup depends on any > of the postgres configuration parameters likes shared > buffer/maintanance_work_memory etc? If yes, which are those configuration > parameters, I need

Re: pg_basebackup is taking more time than expected

Thank you very much for your prompt response. I am asking in my previous mail as, Does the pg_basebackup depends on any of the postgres configuration parameters likes shared buffer/maintanance_work_memory etc? If yes, which are those configuration parameters, I need to take care/increase the value

Re: pg_basebackup is taking more time than expected

Please let me know below details. pg_basebackup utility depends on which are the parameters? Is there any possibility to run the pg_basebackup in multi thread? To improve the speed of the backup of database using pg_basebackup utility we shutdown the database and started alone database services

Re: pg_basebackup is taking more time than expected

Greetings, Please don't top-post on the PG mailing lists. * Raghavendra Rao J S V (raghavendra...@gmail.com) wrote: > pg_basebackup utility depends on which are the parameters? I'm not sure what you're asking here. > Is there any possibility to run the pg_basebackup in multi thread? No, not t

  1   2   >