public inbox for [email protected]
help / color / mirror / Atom feedAny reason to keep HEAP_HASOID_OLD?
2+ messages / 2 participants
[nested] [flat]
* Any reason to keep HEAP_HASOID_OLD?
@ 2026-04-28 04:27 David Rowley <[email protected]>
0 siblings, 1 reply; 2+ messages in thread
From: David Rowley @ 2026-04-28 04:27 UTC (permalink / raw)
To: PostgreSQL Developers <[email protected]>; +Cc: Andres Freund <[email protected]>
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
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.
Should we get rid of HEAP_HASOID_OLD and the code that relates to it?
David
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: Any reason to keep HEAP_HASOID_OLD?
@ 2026-04-28 14:27 Andres Freund <[email protected]>
parent: David Rowley <[email protected]>
0 siblings, 0 replies; 2+ messages in thread
From: Andres Freund @ 2026-04-28 14:27 UTC (permalink / raw)
To: David Rowley <[email protected]>; +Cc: PostgreSQL Developers <[email protected]>
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
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2026-04-28 14:27 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-04-28 04:27 Any reason to keep HEAP_HASOID_OLD? David Rowley <[email protected]>
2026-04-28 14:27 ` Andres Freund <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox