| From: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
|---|---|
| To: | zhxpgh <zhxpgh(at)foxmail(dot)com>, pgsql-bugs <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: two bugs |
| Date: | 2023-02-25 13:37:39 |
| Message-ID: | 5dfefe9d-c03b-d831-2a16-8baa61d18b46@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
I don't think any of this a bug, it's the expected behavior. It would be
better if you also shared some reasoning why you think these are bugs.
1) DISABLE TRIGGER ALL disables all triggers, including those for
referential integrity. So it's not surprising some of the data violates
the FK on restore.
2) Similarly for the materialized view - you create a unique index on
the MV at a point when there's no duplicates. But then you insert data
into the source tables. If you tried to refresh the MV at this point,
it'd fail - which is expected. And restore first loads all the data and
then builds the materialized view. We don't have the capability to
dump/restore the MV data directly, we have to run the query.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dean Rasheed | 2023-02-25 15:08:25 | Re: BUG #17803: Rule "ALSO INSERT ... SELECT ..." fails to substitute default values |
| Previous Message | Michael Paquier | 2023-02-25 03:39:11 | Re: BUG #17744: Fail Assert while recoverying from pg_basebackup |