Emre Hasegeli writes:
>> + /*
>> +* If the row is hinted as committed, it's surely safe. This provides a
>> +* fast path for all normal use-cases.
>> +*/
>> + if (HeapTupleHeaderXminCommitted(enumval_tup->t_data))
>> + return;
>> +
>> + /*
>> +* Usually, a row would ge
> Got around to looking at this. Attached is a revised version that I think
> is in committable shape. The main non-cosmetic change is that the test
> for "type was created in same transaction as new value" now consists of
> comparing the xmins of the pg_type and pg_enum rows, without consulting
Andrew Dunstan writes:
> OK, did that. Here is a patch that is undocumented but I think is
> otherwise complete. It's been tested a bit and we haven't been able to
> break it. Comments welcome.
Got around to looking at this. Attached is a revised version that I think
is in committable shape.
On 04/02/2016 01:20 PM, Tom Lane wrote:
Andrew Dunstan writes:
Looking at this briefly. It looks like the check should be called from
enum_in() and enum_recv(). What error should be raised if the enum row's
xmin isn't committed? ERRCODE_FEATURE_NOT_SUPPORTED? or maybe
ERRCODE_DATA_EXCEPTION?
Andrew Dunstan writes:
> Looking at this briefly. It looks like the check should be called from
> enum_in() and enum_recv(). What error should be raised if the enum row's
> xmin isn't committed? ERRCODE_FEATURE_NOT_SUPPORTED? or maybe
> ERRCODE_DATA_EXCEPTION? I don't see anything that fits ver
On 03/29/2016 04:56 PM, Andrew Dunstan wrote:
On 03/27/2016 10:20 AM, Tom Lane wrote:
Andrew Dunstan writes:
The more I think about this the more I bump up against the fact that
almost anything we do might want to do to ameliorate the situation is
going to be rolled back. The only approach
