Re: In-order pg_dump (or in-order COPY TO)
| От | Ron Johnson |
|---|---|
| Тема | Re: In-order pg_dump (or in-order COPY TO) |
| Дата | |
| Msg-id | CANzqJaAO1qzsMxUPm2z-JnZxGTUpopbC3TQ8Dq9NDo2A+a0miw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: In-order pg_dump (or in-order COPY TO) (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-general |
On Wed, Aug 27, 2025 at 10:42 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Ron Johnson <ronljohnsonjr@gmail.com> writes:
> On Wed, Aug 27, 2025 at 10:16 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Don't use --format=custom (and not -v either). That causes pg_dump to
>> include the OIDs and pg_dump object IDs of all the tables and other
>> objects,
> That's interesting. Why? (Since isn't it supposed to be Bad to rely on
> OIDs?)
-v in a text-format dump includes that data for debugging purposes:
--
-- TOC entry 1401 (class 1255 OID 16499)
-- Name: fipshash(text); Type: FUNCTION; Schema: public; Owner: postgres
--
(The "TOC entry" comment line wouldn't be there without -v.)
Then custom format has to store the same info so that pg_restore
can produce this identical text output on demand.
Ah, so the culprit is "-v". I like using -v, redirecting it to a log file (more info is almost always better), but then I rarely use pg_dump, and never pipe it to de-duplicators. (ExaGrid is supposed to deduplicate, but that's not going to stop me from using pgbackrest, compression and encryption; PCI auditors care about that, not deduplication.)
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!
В списке pgsql-general по дате отправления: