Search Postgresql Archives

Re: Pass-by-reference UDTs and volatility

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hmm, that might work - so allocate the values in a transaction-scoped memory context?
But how would the hash table keys themselves be deleted? Is there some callback API to
hook transaction completion?


On Wed, Jun 12, 2013 at 1:07 PM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote:
Stephen Scheck <singularsyntax@xxxxxxxxx> writes:
> "Never modify the contents of a pass-by-reference input value. If you do so
> you are likely to corrupt on-disk data, since the pointer you are given
> might point directly into a disk buffer. The sole exception to this rule is
> explained in Section 35.10."

> If the UDTs the extension defines are the sole producer/consumer of the
> data type and are consistent in the way they manipulate the in-memory data
> structure for the type, can the above rule be safely ignored?

No.

> Or could the
> backend do something like try to persist intermediate return values from
> functions to temporary hard storage as it proceeds with execution of a
> query plan?

It might well do that; you really do not have the option to create Datum
values that can't be copied by datumCopy().  Even more directly, if you
do something like

select foo('...'::pass_by_ref_type)

and foo elects to scribble on its input, it will be corrupting a Const
node in the query plan.  You'd probably not notice any bad effects from
that in the case of a one-shot plan, but it would definitely break
cached plans.

Just brainstorming here, but: you might consider keeping the actual
value(s) in private storage, perhaps a hashtable, and making the Datums
that Postgres passes around be just tokens referencing hashtable
entries.  This would for one thing give you greatly more security
against user query-structure errors than what you're sketching.
The main thing that might be hard to deal with is figuring out when it's
safe to reclaim a no-longer-referenced value.  You could certainly do so
at top-level transaction end, but depending on what your app is doing,
that might not be enough.

                        regards, tom lane


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux