Re: [WIP PATCH v2] Implement "pg_restore --data-only --clean" as a way to skip WAL

From: Dimitrios Apostolou <jimis(at)gmx(dot)net>
To: Greg Sabino Mullane <htamfids(at)gmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: [WIP PATCH v2] Implement "pg_restore --data-only --clean" as a way to skip WAL
Date: 2025-07-23 21:43:15
Message-ID: s095p867-1126-r718-248p-2q5sro843927@tzk.arg
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Friday 2025-06-13 03:42, Greg Sabino Mullane wrote:

>
>I think the overall idea is sound. But we need a better solution for the truncate fk failure. Can we introspect somehow and do a truncate or do a delete as necessary? I don't like the idea of simply ignoring the constraint, or of throwing an error.

Sorry I haven't answered, but I don't really know how to catch the error
of TRUNCATE in the C code and do a DELETE instead. I was hoping someone
would chime in and suggest an approach.

Furthermore, silently replacing the TRUNCATE with DELETE will negate all
the performance benefits we are aiming for with this patch (avoiding WAL
logging).

In pg_restore AFAICT the suggested way to handle similar FK errors is to
add another option: --disable-triggers. This works for other operations
besides TRUNCATE, and one can break referential integrity in order to
speed up loading of data.

As such, I think the proper solution would be to change TRUNCATE
implementation in the backend, in order to ignore FK constraints when
the triggers are off. How correct do you think this is? And any ideas on
how to approach the implementation?

Thanks,
Dimitris

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2025-07-23 21:46:42 Re: simple patch for discussion
Previous Message Andres Freund 2025-07-23 21:42:35 Re: trivial grammar refactor