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
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 |