Re: Patch: dumping tables data in multiple chunks in pg_dump

Hannu Krosing <hannuk@google.com>

From: Hannu Krosing <hannuk@google.com>
To: Andres Freund <andres@anarazel.de>
Cc: David Rowley <dgrowleyml@gmail.com>, Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Nathan Bossart <nathandbossart@gmail.com>
Date: 2026-01-14T21:46:07Z
Lists: pgsql-hackers
On Wed, Jan 14, 2026 at 10:40 PM Andres Freund <andres@anarazel.de> wrote:
>
> On 2026-01-14 11:52:54 +0100, Hannu Krosing wrote:
> > On Tue, Jan 13, 2026 at 3:32 AM David Rowley <dgrowleyml@gmail.com> wrote:
> > >
> > > On Fri, 14 Nov 2025 at 09:34, Hannu Krosing <hannuk@google.com> wrote:
> > > > Added to https://commitfest.postgresql.org/patch/6219/
> > >
> > > I see you added the "Backport" tag in the CF. This isn't the sort of
> > > thing that we'd do that for. Was that a mistake?
> >
> > Just wanted to mark it as something that might be backported later as
> > one of the important cases for pg_dump is dumping older databases .
>
> I think it's obvious that nothing that's being discussed here has any business
> being considered for backporting.

Do we have clear written guidelines about what can and can not be backported ?
And do we distinguish between the core database, extensions and tools for this?

> Nor can I follow the argument that dumping of old databases would be an
> argument, as the proposed change is in pg_dump, not the server, so a new
> pg_dump will suffice to get the benefit, no?

I was not sure if pg_restore is backwards compatible enough to be able
to restore from newer pg_dump versions.

----
Hannu