Hi Guys, Do you know any companies in the San Diego Area(or nearby) who can give consulting expertise. This is for getting us up and running with postGresql
I would appreciate if I can get emails addresses/compnaies names who do this .. Thx Deep -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane Sent: Tuesday, January 20, 2004 9:05 AM To: Jared Carr Cc: [EMAIL PROTECTED] Subject: Re: [GENERAL] Getting rid of duplicate tables. Jared Carr <[EMAIL PROTECTED]> writes: > Item 2 -- Length: 148 Offset: 6860 (0x1acc) Flags: USED > XID: min (46034931) CMIN|XMAX: 2 CMAX|XVAC: 0 > Block Id: 27 linp Index: 2 Attributes: 23 Size: 28 > infomask: 0x2910 (HASOID|XMIN_COMMITTED|XMAX_INVALID|UPDATED) > Item 43 -- Length: 148 Offset: 8044 (0x1f6c) Flags: USED > XID: min (8051642) CMIN|XMAX: 46034931 CMAX|XVAC: 2 > Block Id: 27 linp Index: 2 Attributes: 23 Size: 28 > infomask: 0x2910 (HASOID|XMIN_COMMITTED|XMAX_INVALID|UPDATED) Well, there's the smoking gun ... somebody marked (27,2) as XMIN_COMMITTED, showing that they thought 46034931 was committed, while someone else marked (27,43) as XMAX_INVALID, showing that they thought 46034931 was aborted. So we have some kind of very-infrequent breakage in transaction commit-state lookup. Or a hardware problem, but I suspect we are looking at a bug. Could you check out what pg_clog has for transaction 46034931? This would be pg_clog/002B (which dates your problem to Dec 29 BTW), byte at offset 39BFC hex or 236540 decimal. I forget which way the bits run within the byte but will look it up if you can get me the value of that byte. I'm off to take a real close look at what was done to the pg_clog code during the 7.4 cycle ... regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend