postGresql Consulting ??

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

Jared Carr <jared(at)89glass(dot)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