pgsql-hackers
❮
Any reason to keep HEAP_HASOID_OLD?
- Jump to comment-1David Rowley<dgrowleyml@gmail.com>Apr 28, 2026, 4:28 AM UTCAndres 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
slotselectivelydeformheaptuple() is wrong.
#define HEAPHASOIDOLD 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 heappageitems(getrawpage('public.t1',0))
where t_infomask & 8 <> 0;
count-------
alter table t1 set without oids;185
select count(*) from heappageitems(getrawpage('public.t1',0))
where t_infomask & 8 <> 0;
count-------
And also, if I try to pg_upgrade before SET WITHOUT OIDS, I get:0
$ 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.
Should we get rid of HEAPHASOIDOLD and the code that relates to it?
David- Jump to comment-1Andres Freund<andres@anarazel.de>Apr 28, 2026, 2:27 PM UTCHi,
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
slotselectivelydeformheaptuple() is wrong.
#define HEAPHASOIDOLD 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 heappageitems(getrawpage('public.t1',0))where t_infomask & 8 <> 0;
count
-------
185
alter table t1 set without oids;
select count(*) from heappageitems(getrawpage('public.t1',0))where t_infomask & 8 <> 0;
count
Yea, it seems we've started rewriting tables for SET WITHOUT OIDS a long time
-------
0
ago:
I also verified that we don't allow SET WITHOUT OIDS when it's used as a row/* * 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)
type in another table.And also, if I try to pg_upgrade before SET WITHOUT OIDS, I get:
I don't see it either. Wonder why I / decided to leave it :/.
$ 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.Should we get rid of HEAPHASOIDOLD and the code that relates to it?
Looks like it.
Greetings,
Andres Freund