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