Thomas Munro writes:
> On Thu, Dec 16, 2021 at 11:51 AM Tom Lane wrote:
>> Here's a draft patch for this.
> LGTM.
Pushed, thanks for looking.
regards, tom lane
On 12/15/21 17:50, Tom Lane wrote:
> Here's a draft patch for this. There are several places that are
> directly using DecrTupleDescRefCount after lookup_rowtype_tupdesc
> or equivalent, which'd now be forbidden. I think they are all safe
> given the assumption that the typcache's tupdescs for n
On Thu, Dec 16, 2021 at 11:51 AM Tom Lane wrote:
> Here's a draft patch for this. There are several places that are
> directly using DecrTupleDescRefCount after lookup_rowtype_tupdesc
> or equivalent, which'd now be forbidden. I think they are all safe
> given the assumption that the typcache's
I wrote:
> Chapman Flack writes:
>> Oh, hmm, maybe one thing in that API comment ought to be changed. It says
>> I must call ReleaseTupleDesc *or* DecrTupleDescRefCount. Maybe that dates
>> from before the shared registry? ReleaseTupleDesc is safe, but anybody who
>> uses DecrTupleDescRefCount on
Chapman Flack writes:
> On 12/14/21 20:02, Tom Lane wrote:
>> The API contract for lookup_rowtype_tupdesc specifies that you must "call
>> ReleaseTupleDesc or DecrTupleDescRefCount when done using the tupdesc".
>> It's safe to assume that the tupdesc will stick around as long as you
>> haven't don
On 12/14/21 20:02, Tom Lane wrote:
> The API contract for lookup_rowtype_tupdesc specifies that you must "call
> ReleaseTupleDesc or DecrTupleDescRefCount when done using the tupdesc".
> It's safe to assume that the tupdesc will stick around as long as you
> haven't done that.
I think what threw m
Chapman Flack writes:
> But if I have gone straight to the typcache to ask for a RECORD tupdesc,
> and the one it gives me has -1 refcount, is it reasonable to assume
> I can retain a reference to that without the defensive copy?
The API contract for lookup_rowtype_tupdesc specifies that you must
On 12/14/21 18:03, Tom Lane wrote:
> Tupdescs for RECORD types are a different story: ... Refcounting
> isn't terribly necessary in that case; and at least for the shared
> tupdesc case, we don't do it, to avoid questions of modifying a
> piece of shared state.
Ok, that's kind of what I was getti
Chapman Flack writes:
> 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?
Tupdescs for named composite types should be, since those are
potentially mod
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
10 matches
Mail list logo
