Thanks for the help. I'd seen the heap_page_items functions, but wanted to avoid the superuser requirement and wondered if this was going to be a performant method of finding the freeze column (we're scanning some billions of rows).
Fwiw, we think we'll probably go with a tiny extension that exposes the frozen state exactly. For reference, this is the basic sketch:
Datum
frozen(PG_FUNCTION_ARGS)
{
Oid reloid = PG_GETARG_OID(0);
ItemPointertid=PG_GETARG_ITEMPOINTER(1);
Relationrel;
HeapTupleDatatuple;
Buffer buf;
int result;
//Opentableandsnapshot-ensuringwelaterclosethem
rel=heap_open(reloid,AccessShareLock);
// Initialise the tuple data with a tid that matches our input
ItemPointerCopy(tid,&(tuple.t_self));
#ifPG_MAJOR<12
if (!heap_fetch(rel, SnapshotAny, &tuple, &buf, true, NULL))
On Mon, Jul 20, 2020 at 9:07 PM Lawrence Jones <lawrence@gocardless.com> wrote: > > > So we hit the question: how can we identify if a tuple is frozen? I know the tuple has both committed and aborted hint bits set, but accessing those bits seems to require superuser functions and are unlikely to be that fast. > > Are there system columns (similar to xmin, tid, cid) that we don't know about? >
I think the way to get that information is to use pageinspect extension and use some query like below but you are right that you need superuser privilege for that:
SELECT t_ctid, raw_flags, combined_flags FROM heap_page_items(get_raw_page('pg_class', 0)), LATERAL heap_tuple_infomask_flags(t_infomask, t_infomask2) WHERE t_infomask IS NOT NULL OR t_infomask2 IS NOT NULL;