| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | CG <cgg007(at)yahoo(dot)com> |
| Cc: | "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>, Achilleas Mantzios <a(dot)mantzios(at)cloud(dot)gatewaynet(dot)com> |
| Subject: | Re: Removing oids with pg_repack |
| Date: | 2023-11-22 14:59:07 |
| Message-ID: | 1674346.1700665147@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
CG <cgg007(at)yahoo(dot)com> writes:
> I have the fallback position for the Percona ETL strategy. But I feel like I'm REALLY close with pg_repack and I just don't understand enough about the system internals to nudge it to correctness and need some expert assistance to tap it in the hole.
The only "system metadata" that would need changing is
pg_class.relhasoids. However, it's certainly necessary to rewrite
all the physical table rows (and hence all the table's indexes).
I don't know a lot about pg_repack, but I'm a bit skeptical that
it can really make that transparent. I'm even more skeptical that
it could almost support it except this obvious use-case never
occurred to the developers. I suspect that either the support
already exists but you missed it, or else there's some fundamental
stumbling block. Maybe go discuss this with the pg_repack
developers? (Maybe they read pgsql-general, but I wouldn't count
on it.)
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hans Schou | 2023-11-22 15:41:24 | Feature request: pg_get_tabledef(text) |
| Previous Message | Ron Johnson | 2023-11-22 14:53:52 | Re: Removing oids with pg_repack |