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: pgsql-general-owner@postgresql.org
[mailto:pgsql-general-owner@postgresql.org] On Behalf Of Tom Lane
Sent: Tuesday, January 20, 2004 9:05 AM
To: Jared Carr
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Getting rid of duplicate tables.
Jared Carr <jared@89glass.com> 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