Re: Any reason to keep HEAP_HASOID_OLD? - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Any reason to keep HEAP_HASOID_OLD?
Date
Msg-id 4hvs4bhasxfwxvwelpodetdlhl2tjhqk3r4snknyktyzxlcx7e@jxzhlkjxt7s6
Whole thread
In response to Any reason to keep HEAP_HASOID_OLD?  (David Rowley <dgrowleyml@gmail.com>)
List pgsql-hackers
Hi,

On 2026-04-28 16:27:59 +1200, David Rowley wrote:
> Andres mentioned to me that I might want to look at
> HeapTupleHeaderGetOidOld() as there's a comment and some code there
> that would lead you to believe we can still have tuples with oids. If
> that were true, the code I recently added for getting 'tp' in
> slot_selectively_deform_heap_tuple() is wrong.
> 
> #define HEAP_HASOID_OLD 0x0008 /* has an object-id field */
> 
> On 11.22, I tried:
> 
> create extension pageinspect;
> create table t1 (a int) with oids;
> insert into t1 select generate_Series(1,1000);
> select count(*) from heap_page_items(get_raw_page('public.t1',0))
> where t_infomask & 8 <> 0;
> 
>  count
> -------
>    185
> 
> alter table t1 set without oids;
> 
> select count(*) from heap_page_items(get_raw_page('public.t1',0))
> where t_infomask & 8 <> 0;
>  count
> -------
>      0

Yea, it seems we've started rewriting tables for SET WITHOUT OIDS a long time
ago:
    /*
     * If we dropped the OID column, must adjust pg_class.relhasoids and tell
     * Phase 3 to physically get rid of the column.  We formerly left the
     * column in place physically, but this caused subtle problems.  See
     * http://archives.postgresql.org/pgsql-hackers/2009-02/msg00363.php
     */
    if (attnum == ObjectIdAttributeNumber)


I also verified that we don't allow SET WITHOUT OIDS when it's used as a row
type in another table.



> And also, if I try to pg_upgrade before SET WITHOUT OIDS, I get:
> 
> $ pg_upgrade -d pgdata11 -D pgdata -b ~/pg11/bin -B ~/pg/bin
> Performing Consistency Checks
> -----------------------------
> Checking cluster versions                                   ok
> Checking database user is the install user                  ok
> Checking database connection settings                       ok
> Checking for prepared transactions                          ok
> Checking for system-defined composite types in user tables  ok
> Checking for reg* data types in user tables                 ok
> Checking for contrib/isn with bigint-passing mismatch       ok
> Checking for user-defined encoding conversions              ok
> Checking for user-defined postfix operators                 ok
> Checking for incompatible polymorphic functions             ok
> Checking for tables WITH OIDS                               fatal
> 
> So, I'm not following how we could get a tuple with OIDs in versions after 11.

I don't see it either.  Wonder why I / decided to leave it :/.


> Should we get rid of HEAP_HASOID_OLD and the code that relates to it?

Looks like it.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Henrik TJ
Date:
Subject: Fix background writer processing locking in README
Next
From: "Greg Burd"
Date:
Subject: Re: [PATCH] Batched clock sweep to reduce cross-socket atomic contention