Re: pg_restore enhancements

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Efrain J(dot) Berdecia" <ejberdecia(at)yahoo(dot)com>
Cc: "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
Subject: Re: pg_restore enhancements
Date: 2023-11-22 19:27:52
Message-ID: 2298671.1700681272@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

"Efrain J. Berdecia" <ejberdecia(at)yahoo(dot)com> writes:
> Thanks, the issue we've run into, which I guess could be really a setup issue, with running a COPY command while executing pg_restore, is that if we are restoring a large table (bigger than 500GB) our WAL directory can grow to be very large.
> I would think that if the pg_restore or COPY command was able to support a batch-size option, this should allow postgres to either archive or remove wal files and prevent having to re-size the WAL directory for a one time refresh operation.
> I'm trying to gage how feasible would be to start looking at contributing to add such a feature to either the COPY command or pg_restore.

Given the shortage of other complaints, I tend to agree with Adrian
that there's not likely to be much interest in adding complexity
to pg_restore (or COPY) to address this. You should probably look
harder at the idea that you have some configuration problem that's
triggering your WAL bloat. If COPY can run you out of WAL space,
then so could any future bulk insert or update.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Ron Johnson 2023-11-22 20:04:06 Re: pg_restore enhancements
Previous Message Adrian Klaver 2023-11-22 18:36:22 Re: strange behavior of pg_hba.conf file