| From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, Stephen Frost <sfrost(at)snowman(dot)net>, John Naylor <jcnaylor(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: automatically assigning catalog toast oids |
| Date: | 2018-12-15 01:54:14 |
| Message-ID: | 20181215015414.f4mx6zcykks4jcnt@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2018-12-15 02:01:59 | Re: automatically assigning catalog toast oids |
| Previous Message | Peter Geoghegan | 2018-12-15 01:50:56 | Re: Computing the conflict xid for index page-level-vacuum on primary |