Is a syscache tuple more like an on-disk tuple or a freshly made one?

Chapman Flack wrote:

I am tempted to apply HeapTupleGetDatum to a tuple retrieved from
the syscache (as I already have code for processing a tuple presented
as a Datum).

But I see a comment on HeapTupleHeaderGetDatum: "This must *not* get
applied to an on-disk tuple; the tuple should be freshly made by
heap_form_tuple or some wrapper ..."

I suppose you could create a copy of the tuple (SysCacheSearchCopy) and
use that for HeapTupleGetDatum. The problem with the syscache tuple is
that it can go away as soon as you do the ReleaseSysCache -- it lives in
shared_buffers memory, so when it's released the buffer might get
evicted.

heap_form_tuple returns a newly palloc'd tuple, which is what you want.

... and here I confess I'm unsure whether a tuple retrieved from
the syscache is more like an on-disk one, or a freshly-made one,
for purposes of the warning in that comment.

A "syscache tuple" is definitely an on-disk tuple.

--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Chapman Flack <chap@anastigmatix.net> writes:

I am tempted to apply HeapTupleGetDatum to a tuple retrieved from
the syscache (as I already have code for processing a tuple presented
as a Datum).

But I see a comment on HeapTupleHeaderGetDatum: "This must *not* get
applied to an on-disk tuple; the tuple should be freshly made by
heap_form_tuple or some wrapper ..."

... and here I confess I'm unsure whether a tuple retrieved from
the syscache is more like an on-disk one, or a freshly-made one,
for purposes of the warning in that comment.

A tuple from syscache is an on-disk tuple for this purpose; it has
the original catalog row's header fields, not the header fields
appropriate for a Datum. So no, that will *not* work, even disregarding
the question of whether it'd be safe to pass a pointer into syscache
to some random function.

Is there a conventional proper way to pass a tuple retrieved from
syscache to code that accepts a tuple as a Datum?

You could use heap_copy_tuple_as_datum(). See SPI_returntuple()
for an example.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 04/15/16 18:03, Alvaro Herrera wrote:

I suppose you could create a copy of the tuple (SysCacheSearchCopy) and
use that for HeapTupleGetDatum. The problem with the syscache tuple is
that it can go away as soon as you do the ReleaseSysCache -- it lives in
shared_buffers memory, so when it's released the buffer might get
evicted.

Sure ... I wasn't going to call ReleaseSysCache until I was all done
with it anyway, should only take microseconds ... thought I'd be
clever and avoid making a copy, and pass it to existing code expecting
a Datum, but I guess that's more trouble than it's worth.

A "syscache tuple" is definitely an on-disk tuple.

Got it. Thanks!

On 04/15/16 18:13, Tom Lane wrote:

You could use heap_copy_tuple_as_datum().

Thanks, that looks like what the doctor ordered.

For pre-9.4, would the equivalent be basically
heap_form_tuple applied to the results of heap_deform_tuple ?

-Chap

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Chapman Flack <chap@anastigmatix.net> writes:

On 04/15/16 18:13, Tom Lane wrote:

You could use heap_copy_tuple_as_datum().

Thanks, that looks like what the doctor ordered.

For pre-9.4, would the equivalent be basically
heap_form_tuple applied to the results of heap_deform_tuple ?

You could do that, or you could do what heap_copy_tuple_as_datum
does, ie copy the tuple and then poke the appropriate header
field values into it.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers