Re: automatically assigning catalog toast oids - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: automatically assigning catalog toast oids
Date
Msg-id 20181215015414.f4mx6zcykks4jcnt@alvherre.pgsql
Whole thread Raw
In response to Re: automatically assigning catalog toast oids  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: automatically assigning catalog toast oids
List pgsql-hackers
On 2018-Dec-13, Tom Lane wrote:

> We could take it a bit further and not make the 'p' entries for such
> OIDs in the first place, greatly reducing the size of pg_depend in
> typical installations.  Perhaps that'd confuse clients that look at
> that catalog, though.

The number of 'p' entries in pg_depend is often annoying when manually
querying it.  I support the idea of special-casing such entries.

> Looking at the existing entries, it seems like we'd have to have
> one special case: schema public has OID 2200 but is intentionally
> not pinned.  I wouldn't have a hard time with teaching isObjectPinned
> about that; though if it turns out that many places need to know
> about it, maybe it's not workable.

Why not just move that OID outside the Genbki special range?  I have
seen quite a few installs where schema public was removed and later
re-added.  I've never seen a query hardcode OID 2200, and I'd call one
which does buggy.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Computing the conflict xid for index page-level-vacuum on primary
Next
From: Andres Freund
Date:
Subject: Re: automatically assigning catalog toast oids