Re: psql dones't reflect exit status if input command via stdin

On Mon, 2019-05-13 at 23:39 -0700, David G. Johnston wrote: > On Mon, May 13, 2019 at 11:24 PM magodo wrote: > > I found when running command like `# echo "xxx" | psql postgres > > > > postgres`, the return code is always 0 even though the command > > ("xxx") > > > > here is of invalid syntax. W

Re: perl path issue

Hi Adrian, Yes correct am trying to restore the single database using pgbackrest command in dev. Note - if am taking same prod single database backup and restore in new cluster no use for us and it will take more time. so business and team they need every 3 weeks for restore in dev server one sin

Re: perl path issue

> > Note - if am taking same prod single database backup and restore in new > cluster no use for us and it will take more time. > so business and team they need every 3 weeks for restore in dev server one > single database and cant we do it in pg_dump and restore . > They want using pgbackrest t

Re: perl path issue

Hi Ravi, Not , am saying we have the daily backup and full backup in prod server only and there is one database like a4 the db size is 1.5TB. so am not restore again in prod . Am taking directly single backup restore in dev its means in dev server only restore the database in new cluster. existing

Re: perl path issue

> > > Not , am saying we have the daily backup and full backup in prod server only > and there is one database like a4 the db size is 1.5TB. > so am not restore again in prod . > Am taking directly single backup restore in dev its means in dev server only > restore the database in new cluster.

Re: perl path issue

Which part confused you Ravi? Here’s my take > On May 14, 2019, at 4:06 AM, Ravi Krishna wrote: > >> >> >> Not , am saying we have the daily backup and full backup in prod server only >> and there is one database like a4 the db size is 1.5TB. >> so am not restore again in prod . Production s

Re: perl path issue

--- Original Message -- > On May 14, 2019, at 9:06 AM, Rob Sargent wrote: > > > Which part confused you Ravi? Same as you, this one "Am taking directly single backup restore in dev its means in dev server only restore the databa

Re: perl path issue

On 5/14/19 2:51 AM, Prakash Ramakrishnan wrote: Hi Ravi, Not , am saying we have the daily backup and full backup in prod server only and there is one database like a4 the db size is 1.5TB. so am not restore again in prod . Am taking directly single backup restore in dev its means in dev serve

Re: perl path issue

Yes, that is correct. On Tue, May 14, 2019 at 7:54 PM Adrian Klaver wrote: > On 5/14/19 2:51 AM, Prakash Ramakrishnan wrote: > > Hi Ravi, > > > > Not , am saying we have the daily backup and full backup in prod server > > only and there is one database like a4 the db size is 1.5TB. > > so am not

Re: perl path issue

On 5/14/19 7:28 AM, Prakash Ramakrishnan wrote: Yes, that is correct. How about graphical layout of your backup/restore procedure? On Tue, May 14, 2019 at 7:54 PM Adrian Klaver > wrote: On 5/14/19 2:51 AM, Prakash Ramakrishnan wrote: > Hi Ravi,

Re: perl path issue

Hi Adrian, Prod server retention periods , [global] repo1-path=/pgBACKUP/A4_sydcosafpp001 *retention-diff=3* *retention-full=1* *retention-archive=2* start-fast=y process-max=12 archive-async=y Dev server currently we dont have only restore need to do prod to dev. Regards, Prakash.R On Tue, M

Re: perl path issue

On 5/14/19 7:40 AM, Prakash Ramakrishnan wrote: Hi Adrian, Prod server retention periods , [global] repo1-path=/pgBACKUP/A4_sydcosafpp001 *retention-diff=3* *retention-full=1* *retention-archive=2* start-fast=y process-max=12 archive-async=y Dev server currently we dont have only restore need

Re: terminating walsender process due to replication timeout

To detect network issues maybe you could monitor replication delay. On Mon, May 13, 2019 at 6:42 AM wrote: > Hello PostgreSQL Community! > > I faced an issue on my linux machine using Postgres 11.3 . > I have 2 nodes in db cluster: master and standby. > I tried to perform a plenty of long-runnin

Table update: restore or replace?

I just updated a column in a table (postgresql-10.5) and accidently applied it to all 185 rows rather than just one. There is no active transaction to roll back. Each night I do a backup and just started working on the database a few minutes ago. If I restore all contents of /var/lib/pgsql/10/dat

Re: Table update: restore or replace?

On Tue, 14 May 2019, Adrian Klaver wrote: A file level backup or database dump? Adrian, File level. April 20th is my most recent database dump because I forgot to run it last Friday afternoon. Rich

Re: Table update: restore or replace?

On 5/14/19 1:59 PM, Rich Shepard wrote: On Tue, 14 May 2019, Adrian Klaver wrote: A file level backup or database dump? Adrian, File level. April 20th is my most recent database dump because I forgot to run it last Friday afternoon. Does the table you overwrote the data change much? If no

Re: Table update: restore or replace?

On 5/14/19 1:46 PM, Rich Shepard wrote: I just updated a column in a table (postgresql-10.5) and accidently applied it to all 185 rows rather than just one. There is no active transaction to roll back. Each night I do a backup and just started working on the database a few A file level backup

Re: Table update: restore or replace?

Adrian Klaver writes: > If you where to restore at the file level I would: > 1) Stop the server. > 2) Move the existing content of /var/lib/pgsql/10/data/ somewhere else > just to be safe. > 3) Copy in the backup. Yeah. You can't just selectively copy files, because the data files are dependent

Re: Table update: restore or replace?

On Tue, 14 May 2019, Adrian Klaver wrote: Does the table you overwrote the data change much? Adrian, Yes. It's in my business tracking database so it's updated almost every day. If not it might be safer to just fetch it from the April 20th dump and then apply the changes since then. The c

Re: Table update: restore or replace?

On Tue, 14 May 2019, Tom Lane wrote: Yeah. You can't just selectively copy files, because the data files are dependent on the contents of the pg_xact transaction log; it's all or nothing. Tom, That's why I thought of copying the entire data/ directory. Also, I don't know what method you've

Re: Re: Table update: restore or replace?

> From: Rich Shepard > To: pgsql-general@lists.postgresql.org > Date: 05/14/2019 05:19 PM > Subject: [EXTERNAL] Re: Table update: restore or replace? > And I think I'll set up a cron job to do a database dump each day with the > date appended to the file name in the bash shell script. Might I su

Re: Table update: restore or replace?

On 5/14/19 2:19 PM, Rich Shepard wrote: On Tue, 14 May 2019, Adrian Klaver wrote: Does the table you overwrote the data change much? Adrian, Yes. It's in my business tracking database so it's updated almost every day. If not it might be safer to just fetch it from the April 20th dump and

Re: Table update: restore or replace?

On 5/14/19 3:59 PM, Rich Shepard wrote: On Tue, 14 May 2019, Adrian Klaver wrote: A file level backup or database dump? Adrian, File level. April 20th is my most recent database dump because I forgot to run it last Friday afternoon. Note that referring to file level copies as dumps can be

Re: Re: Table update: restore or replace?

On Tue, 14 May 2019, Brad Nicholson wrote: Might I suggest you setup proper backups with continuous archiving instead? If you had those, you would be able to restore this database back to the point right before you issued the bad update statement. I'd highly recommend pgBackRest for the task.

Re: Table update: restore or replace?

On Tue, 14 May 2019, Adrian Klaver wrote: Or just fetch them from the table data you have saved in the dump file. Adrian, Sigh. I should have thought of that. A great time saver. Thanks, Rich

Re: Table update: restore or replace? [RESOLVED]

On Tue, 14 May 2019, Adrian Klaver wrote: Or just fetch them from the table data you have saved in the dump file. Adrian, This did save a lot of time! Thanks for the pointer. And I think I'll set up a cron job to do a database dump each day with the date appended to the file name in the bas

Re: Table update: restore or replace?

Greetings, * Rich Shepard (rshep...@appl-ecosys.com) wrote: > That's why I thought of copying the entire data/ directory. That isn't going to work because things change in the data directory... > >Also, I don't know what method you've been using to make file-level > >backups, but they're really