Re: PANIC: unexpected hash relation size - Mailing list pgsql-general

Tom Lane writes:
> Csaba Kalman <csaba818@freemail.hu> writes:
>> I frequently get this error message:
>> PANIC: unexpected hash relation size: X, should be Y
>> There is no specific point where I get this error, it can occur anytime
>> after a SELECT/INSERT/UPDATE. I've never got it after DELETE so far.
>
> AFAICS this should only happen in INSERT/UPDATE, since it must be coming
> from an attempt to insert an entry in a hash index.  What's the exact
> schema of this table including indexes?
>
>> Is it a bug, or I'm doing something wrong?
>
> It's a bug, but you've not provided enough information to let anyone
> reproduce or fix it.
>

Sorry for not being specific.

Here is the CREATE script of the table which is most likely to be one
source of the error. The last error happened after an insert into this
table.


CREATE TABLE munkalap (
     pk character(12) NOT NULL,
     statusz_pk character(12) NOT NULL,
     ugyfel_pk character(12) NOT NULL,
     ellenor_pk character(12),
     szamla_pk character(12),
     cim_pk character(12),
     napi_munka_pk character(12),
     vonalkod character varying(10),
     teljesites_datum date,
     archivalas_datum timestamp without time zone,
     visszavetel_megjegyzes character varying(600),
     nyomtatva bit(1) NOT NULL,
     csere_oka character varying(100),
     operator_pk_rogzitette character(12) NOT NULL,
     kapcsolat_nev character varying(100),
     kapcsolat_tel character varying(20),
     vizmero_tipus character(1),
     operator_megjegyzes character varying(600),
     kiszallas_napszak character(1),
     rogzites_datum timestamp without time zone,
     merok_szama smallint,
     merok_atmero character varying(50),
     visszavetel_idopont timestamp without time zone,
     leadhatosag_pk character(12),
     leadas_datum date,

     CONSTRAINT munkalap_tabla_pk PRIMARY KEY (pk),

     CONSTRAINT munkalap_cim_pk_fkey FOREIGN KEY (cim_pk)
         REFERENCES cim(pk),
     CONSTRAINT munkalap_ellenor_pk_fkey FOREIGN KEY (ellenor_pk)
         REFERENCES alkalmazott(pk) ON DELETE SET NULL,
     CONSTRAINT munkalap_leadhatosag_statusz_pk_fkey
         FOREIGN KEY (leadhatosag_pk)
         REFERENCES munkalap_leadhatosag_statusz(pk) ON DELETE RESTRICT,
     CONSTRAINT munkalap_napi_munka_pk_fkey FOREIGN KEY (napi_munka_pk)
         REFERENCES napi_munka(pk) ON DELETE SET NULL,
     CONSTRAINT munkalap_rogzito_fkey
         FOREIGN KEY (operator_pk_rogzitette)
         REFERENCES alkalmazott(pk),
     CONSTRAINT munkalap_statusz_pk_fkey FOREIGN KEY (statusz_pk)
         REFERENCES munkalap_statusz(pk),
     CONSTRAINT munkalap_szamla_pk_fkey FOREIGN KEY (szamla_pk)
         REFERENCES szamla(pk),
     CONSTRAINT munkalap_ugyfel_pk_fkey FOREIGN KEY (ugyfel_pk)
         REFERENCES ugyfel(pk)
);
CREATE INDEX munkalap_cim_pk_index ON munkalap
     USING btree (cim_pk);
CREATE INDEX munkalap_ellenor_pk_index ON munkalap
     USING btree (ellenor_pk);
CREATE INDEX munkalap_napi_munka_pk_index ON munkalap
     USING hash (napi_munka_pk);
CREATE INDEX munkalap_statusz_pk_index ON munkalap
     USING hash (statusz_pk);
CREATE INDEX munkalap_szamla_pk_index ON munkalap
     USING btree (szamla_pk);
CREATE INDEX munkalap_teljesites_index ON munkalap
     USING hash (teljesites_datum);
CREATE INDEX munkalap_ugyfel_pk_index ON munkalap
     USING btree (ugyfel_pk);


(Funny thing is, while copy-pasting this script, I noticed that I
created hash indexes. It was not my intention, I always use B-tree. I
must have accidentally clicked on hash when I was creating the indexes
with the wizard. Shame on me.
I did not understand why the error said unexpected _hash_ relation size,
because I was sure there are no hash indexes. I know hash index use is
discouraged. I'm going to check all my indexes, and correct these
mistakes if there are more.)

Anyway, I can't make a list of steps to reproduce the error. Once I
inserted 100000 rows and succeeded, but another time I inserted less
than a hundred (to an empty table) and I got the error.

Thanks,
Csaba