Re: [Postgres-xc-general] JDBC driver for 0.9.4

[Lionel F. <lio...@gm...>]

Hi,

Vacuum did not solve the problem.

I did a workaround for the problem by loading directly files through "copy
<table> from <file.csv>" from coordinator, problem did not appear again (and
data is distributed correctly imho).

Should I enter a bug anyway regarding jdbc bulk/quick inserts ?

Thx for your help

Lionel F.


2011/6/7 Lionel Frachon <lio...@gm...>

> Hello,
>
> ran gtm with -x 1025, the same problem appears.
> (ERROR:  prepared transaction with identifier "T1530" does not exist
> STATEMENT:  COMMIT PREPARED 'T1530')
>
> I'm shutting down autovacuum on nodes to see if problem persists (and
> re-enable debug1 tracing)
>
> Regards
>
> Lionel F.
>
>
>
> 2011/6/7 Michael Paquier <mic...@gm...>
>
>>
>>
>> On Mon, Jun 6, 2011 at 9:39 PM, Lionel Frachon <lio...@gm...>wrote:
>>
>>> Hello,
>>>
>>> looking at the debug1 mode log on datanode3, I found some interesting
>>> points hereafter (vacuum on, max_prepared_transactions=5000):
>>>
>>> (with normal inserts)
>>> [....]
>>> DEBUG:  unset snapshot info
>>> DEBUG:  global snapshot info: gxmin: 101, gxmax: 101, gxcnt: 0
>>> DEBUG:  unset snapshot info
>>> DEBUG:  global snapshot info: gxmin: 101, gxmax: 101, gxcnt: 0
>>> DEBUG:  unset snapshot info
>>> DEBUG:  [re]setting xid = 0, old_value = 0
>>> DEBUG:  unset snapshot info
>>> DEBUG:  Received new gxid 102
>>> DEBUG:  [re]setting xid = 102, old_value = 0
>>> DEBUG:  TransactionId = 102
>>> DEBUG:  xid (102) does not follow ShmemVariableCache->nextXid (665)
>>> DEBUG:  Record transaction commit 101
>>> DEBUG:  Record transaction commit 102
>>> DEBUG:  [re]setting xid = 0, old_value = 0
>>> DEBUG:  unset snapshot info
>>> DEBUG:  Received new gxid 103
>>> DEBUG:  [re]setting xid = 103, old_value = 0
>>> DEBUG:  unset snapshot info
>>> DEBUG:  global snapshot info: gxmin: 103, gxmax: 103, gxcnt: 0
>>> DEBUG:  TransactionId = 103
>>> DEBUG:  xid (103) does not follow ShmemVariableCache->nextXid (665)
>>> DEBUG:  unset snapshot info
>>> DEBUG:  global snapshot info: gxmin: 103, gxmax: 103, gxcnt: 0
>>>
>>> While inserting with dsitrubuted hashed keys :
>>>
>>> [...]
>>> DEBUG:  [re]setting xid = 0, old_value = 0
>>> DEBUG:  unset snapshot info
>>> DEBUG:  Received new gxid 522
>>> DEBUG:  [re]setting xid = 522, old_value = 0
>>> DEBUG:  TransactionId = 522
>>> DEBUG:  xid (522) does not follow ShmemVariableCache->nextXid (665)
>>> DEBUG:  Record transaction commit 521
>>> DEBUG:  Record transaction commit 522
>>> DEBUG:  [re]setting xid = 0, old_value = 0
>>> DEBUG:  unset snapshot info
>>> DEBUG:  Received new gxid 524
>>> DEBUG:  [re]setting xid = 524, old_value = 0
>>> ERROR:  prepared transaction with identifier "T523" does not exist
>>> STATEMENT:  COMMIT PREPARED 'T523'
>>> DEBUG:  [re]setting xid = 0, old_value = 524
>>> DEBUG:  unset snapshot info
>>> DEBUG:  Received new gxid 526
>>> DEBUG:  [re]setting xid = 526, old_value = 0
>>> ERROR:  prepared transaction with identifier "T525" does not exist
>>> STATEMENT:  COMMIT PREPARED 'T525'
>>> DEBUG:  [re]setting xid = 0, old_value = 526
>>> DEBUG:  unset snapshot info
>>> DEBUG:  Received new gxid 528
>>> DEBUG:  [re]setting xid = 528, old_value = 0
>>> ERROR:  prepared transaction with identifier "T527" does not exist
>>> [...]
>>>
>> You are right.
>> But this log:
>>
>> DEBUG:  Received new gxid 103
>> means that GTM is feeding cluster in transaction ID to a very low value.
>> This may lead to visibility problems.
>> You should start GTM with an option like -x 1000 to be sure that it
>> doesn't feed transaction IDs lower than 628.
>> --
>> Michael Paquier
>> http://michael.otacoo.com
>>
>
>