Re:

From: hubert depesz lubaczewski <depesz(at)depesz(dot)com>
To: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
Cc: Ron <ronljohnsonjr(at)gmail(dot)com>, pgsql-general(at)lists(dot)postgresql(dot)org, raghuldrag(at)gmail(dot)com
Subject: Re:
Date: 2022-07-27 06:08:29
Message-ID: 20220727060829.GA12917@depesz.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Tue, Jul 26, 2022 at 10:48:47AM -0700, Adrian Klaver wrote:
> On 7/26/22 9:29 AM, Ron wrote:
> > On 7/26/22 10:22, Adrian Klaver wrote:
> > > On 7/26/22 08:15, Rama Krishnan wrote:
> > > > Hi Adrian
> > > >
> > > >
>
> > > > What is size of table?
> > > >
> > > > I m having two Database example
> > > >
> > > > 01. Cricket 320G
> > > > 02.badminton 250G
> > >
> > > So you are talking about an entire database not a single table, correct?
> >
> > In a private email, he said that this is what he's trying:
> > Pg_dump -h endpoint -U postgres Fd - d cricket | aws cp -
> > s3://dump/cricket.dump
> >
> > It failed for obvious reasons.
> From what I gather it did not fail, it just took a long time. Not sure
> adding -j to the above will improve things, pretty sure the choke point is
> still going to be aws cp.

It's really hard to say what is happening, because the command, as shown
wouldn't even work.

Starting from Pg_dump vs. pg_dump, space between `-` and `d`, "Fd" as
argument, or even the idea that you *can* make -Fd dumps to stdout and
pass it to aws cp.

depesz

In response to

  • Re: at 2022-07-26 17:48:47 from Adrian Klaver

Responses

  • Re: at 2022-07-27 18:19:55 from Alicja Kucharczyk

Browse pgsql-general by date

  From Date Subject
Next Message Rory Campbell-Lange 2022-07-27 10:52:40 monitor health of native logical replication
Previous Message Adrian Klaver 2022-07-26 17:48:47 Re: