Life cycles of tuple descriptors - Mailing list pgsql-hackers

From Chapman Flack
Subject Life cycles of tuple descriptors
Date
Msg-id 61B901A4.1050808@anastigmatix.net
Whole thread Raw
Responses Re: Life cycles of tuple descriptors  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Defining (and possibly skipping) useless VACUUM operations
Next
From: Peter Eisentraut
Date:
Subject: Re: Remove pg_strtouint64(), use strtoull() directly