Jared Carr <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>>> Yes, it does appear that there was a backend crash/(operator stupidly
>>> kill -9 'ing possibly) on the 29th.
>>
>> Hmm ... could you send me that area of the log?
> Dec 29 16:31:54 penguin postgres[1714]: [3-1] LOG: received smart
>
Jared Carr <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> 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 w
Tom Lane wrote:
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)
I
First I wish I knew how this was caused but here is our problem.
Sometime in the recent past we got a duplicate table. Here is the
result of a pg_dump with a pg_restore for just that table.
--
-- TOC entry 59 (OID 11462032)
-- Name: order_to_do; Type: TABLE; Schema: public; Owner: www
-- Data Pos
