Re: Parallel safety of CURRENT_* family

On Thu, Dec 1, 2016 at 3:46 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Thu, Dec 1, 2016 at 2:32 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> ... well, they would be if we passed down xactStartTimestamp to parallel
>>> workers, but I can't find any code that does that. In view of the fact that
>>> transaction_timestamp() is marked as parallel-safe, this is a bug in 9.6.
>
>> Yeah. Do you think we should arrange to pass that down, or change the marking?
>
> We can't fix the marking in existing 9.6 installations, so I think we
> have to pass it down. (Which would be a better response anyway.)

I happened across this thread today and took a look at what it would
take to fix this. I quickly ran up against the fact that
SerializeTransactionState() and RestoreTransactionState() are not
exactly brilliantly designed, relying on the notion that each
individual value that we want to serialize will be no wider than a
TransactionId, which won't be true for timestamps. Even apart from
that, the whole design of those functions is pretty lame, and I'm
pretty sure I wrote all of that code myself, so I have nobody to blame
but me. Anyway, here's a proposed patch to refactor that code into
something a little more reasonable. It doesn't fix the actual problem
here, but I think it's a good first step.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company