SMgrRelation hashtable corrupted

[Chris Ochs]

On 8 beta1 I get 'SMgrRelation hashtable corrupted' *sometimes* when
executing the following, but only when there are other clients connecting to
the same database.

ALTER TABLE declines
ALTER COLUMN comp_name TYPE varchar(128),
ALTER COLUMN f_name1 TYPE varchar(48),
ALTER COLUMN l_name1 TYPE varchar(48),
ALTER COLUMN country TYPE varchar(48);
Chris

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

[Tom Lane]

"Chris Ochs" <ch***@paymento nline.com> writes:

On 8 beta1 I get 'SMgrRelation hashtable corrupted' *sometimes* when
executing the following, but only when there are other clients connecting to
the same database.

Hmm. The SMgrRelation hashtable is local in each backend, so I'm not
sure I believe the correlation to other backends being active, but ...

What I'd suggest doing is changing the elog(ERROR) to elog(PANIC)
(in smgrclose in src/backend/storage/smgr/smgr.c), rebuilding with
--enable-debug if you didn't already, and then getting a debugger
stack trace from the core dump next time it happens.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

[Tom Lane]

"Chris Ochs" <ch***@paymento nline.com> writes:

On 8 beta1 I get 'SMgrRelation hashtable corrupted' *sometimes* when
executing the following, but only when there are other clients connecting to
the same database.

FWIW, I tried to reproduce this with no success.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match