You can subscribe to this list here.
2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
(6) |
Sep
|
Oct
(19) |
Nov
(1) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2011 |
Jan
(12) |
Feb
(1) |
Mar
(4) |
Apr
(4) |
May
(32) |
Jun
(12) |
Jul
(11) |
Aug
(1) |
Sep
(6) |
Oct
(3) |
Nov
|
Dec
(10) |
2012 |
Jan
(11) |
Feb
(1) |
Mar
(3) |
Apr
(25) |
May
(53) |
Jun
(38) |
Jul
(103) |
Aug
(54) |
Sep
(31) |
Oct
(66) |
Nov
(77) |
Dec
(20) |
2013 |
Jan
(91) |
Feb
(86) |
Mar
(103) |
Apr
(107) |
May
(25) |
Jun
(37) |
Jul
(17) |
Aug
(59) |
Sep
(38) |
Oct
(78) |
Nov
(29) |
Dec
(15) |
2014 |
Jan
(23) |
Feb
(82) |
Mar
(118) |
Apr
(101) |
May
(103) |
Jun
(45) |
Jul
(6) |
Aug
(10) |
Sep
|
Oct
(32) |
Nov
|
Dec
(9) |
2015 |
Jan
(3) |
Feb
(5) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(9) |
Aug
(4) |
Sep
(3) |
Oct
|
Nov
|
Dec
|
2016 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(4) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
S | M | T | W | T | F | S |
---|---|---|---|---|---|---|
|
|
|
1
(1) |
2
(2) |
3
(2) |
4
|
5
|
6
(4) |
7
(3) |
8
|
9
|
10
|
11
|
12
|
13
|
14
|
15
|
16
|
17
|
18
|
19
|
20
|
21
|
22
|
23
|
24
|
25
|
26
|
27
|
28
|
29
|
30
|
|
|
From: Michael P. <mic...@gm...> - 2011-06-07 23:15:43
|
On Tue, Jun 7, 2011 at 11:35 PM, Lionel Frachon <lio...@gm...>wrote: > Hi, > > Vacuum did not solve the problem. > I looks to be a deeper problem than I expected related to prepared transactions in JDBC. > > 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 ? > Yes. If you could fill in a bug report in the bug tracker of the project, it is definitely helpful. Just don't forget to add the tests you used, the steps you made to reproduce the problem and what are the problems. -- Michael Paquier http://michael.otacoo.com |
From: Lionel F. <lio...@gm...> - 2011-06-07 14:36:01
|
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 >> > > |
From: Lionel F. <lio...@gm...> - 2011-06-07 08:04:09
|
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 > |