Life cycles of tuple descriptors

From: Chapman Flack <chap(at)anastigmatix(dot)net>
To: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Life cycles of tuple descriptors
Date: 2021-12-14 20:42:12
Message-ID: 61B901A4.1050808@anastigmatix.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

There are some things about the life cycle of the common TupleDesc
that I'm not 100% sure about.

1. In general, if you get one from relcache or typcache, it is
reference-counted, right?

2. The only exception I know of is if you ask the typcache for
a blessed one (RECORD+typmod), and it is found in the shared-memory
cache. It is not refcounted then. If it is found only locally,
it is refcounted.

3. Is that shared case the only way you could see a non-refcounted
TupleDesc handed to you by the typcache?

4. How long can such a non-refcounted TupleDesc from the typcache
be counted on to live?

There is a comment in expandedrecord.c: "It it's not refcounted, just
assume it will outlive the expanded object."

That sounds like confidence, but is it confidence in the longevity
of shared TupleDescs, or in the fleeting lives of expanded records?

The same comment says "(This can happen for shared record types,
for instance.)" Does the "for instance" mean there are now, or just
in future might be, other cases where the typcache hands you
a non-refcounted TupleDesc?

5. When a constructed TupleDesc is blessed, the copy placed in the cache
by assign_record_type_typmod is born with a refcount of 1. Assuming every
later user of that TupleDesc plays nicely with balanced pin and release,
what event(s), if any, could ever occur to decrease that initial 1 to 0?

Thanks for any help getting these points straight!

Regards,
-Chap

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2021-12-14 20:42:42 Re: Remove pg_strtouint64(), use strtoull() directly
Previous Message Peter Geoghegan 2021-12-14 20:38:00 Re: Defining (and possibly skipping) useless VACUUM operations