On 25/11/14 16:23, Alvaro Herrera wrote:
> Robert Haas wrote:
>> On Tue, Nov 25, 2014 at 9:19 AM, Alvaro Herrera
>> <alvherre@2ndquadrant.com> wrote:
>>> Fujii Masao wrote:
>>>> On Tue, Nov 25, 2014 at 7:58 AM, Alvaro Herrera
>>>> <alvherre@2ndquadrant.com> wrote:
>>>>>> And here is v10 which fixes conflicts with Heikki's WAL API changes (no
>>>>>> changes otherwise).
>>>>>
>>>>> After some slight additional changes, here's v11, which I intend to
>>>>> commit early tomorrow. The main change is moving the test module from
>>>>> contrib to src/test/modules.
>>>>
>>>> When I specify the XID of the aborted transaction in pg_xact_commit_timestamp(),
>>>> it always returns 2000-01-01 09:00:00+09. Is this intentional?
>>>
>>> Well, when a transaction has not committed, nothing is written so on
>>> reading we get all zeroes which corresponds to the timestamp you give.
>>> So yeah, it is intentional. We could alternatively check pg_clog and
>>> raise an error if the transaction is not marked either COMMITTED or
>>> SUBCOMMITTED, but I'm not real sure there's much point.
>>
>> Maybe 0 should get translated to a NULL return, instead of a bogus timestamp.
>
> That's one idea --- surely no transaction is going to commit at 00:00:00
> on 2000-01-01 anymore. Yet this is somewhat discomforting.
>
I solved it for xids that are out of range by returning -infinity and
then changing that to NULL in sql interface, but no idea how to do that
for aborted transactions.
-- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training &
Services
