Обсуждение: BUG #5876: Incorrectly reported column value

Поиск
Список
Период
Сортировка

BUG #5876: Incorrectly reported column value

От
"Dag Lem"
Дата:
The following bug has been logged online:

Bug reference:      5876
Logged by:          Dag Lem
Email address:      dag@nimrod.no
PostgreSQL version: 9.0.3
Operating system:   CentOS release 5.5, i686
Description:        Incorrectly reported column value
Details:

The effect of this (pretty serious) bug is that I am able to insert a value
into an integer column and consistently get an entirely different value read
out later.

Unfortunately this happens on a large data set (3.6M rows), and I am not
able to either reproduce with a smaller data set nor provide the data set. I
realize that this is asking you to find a needle in the haystack. However at
least now you're made aware of the bug - please let me know if there's
anything I can do to help isolate it.

The table definition is attached to the end of this report.

I have used batch inserts of 10 000 rows each, commiting after each batch
insert (via DBD::Pg 2.17.1).
The incorrect row is row number 1601050 in the data set, i.e. the 1050th row
in a batch insert.

This is how the bug manifests itself (election_event_pk is always 2 on
insert):

evote=> select distinct election_event_pk from voter where election_event_pk
= 2;
 election_event_pk
-------------------
                 2
(1 row)

evote=> select election_event_pk, count(*) from voter where
election_event_pk = 2 group by election_event_pk;
 election_event_pk |  count
-------------------+---------
                 2 | 3611505
(1 row)

evote=> select election_event_pk from voter where election_event_pk = 2 and
voter_id = '<11 digit ssn>';
 election_event_pk
-------------------
            262146
(1 row)

As you can see, the reported column value is different from what is inserted
(and indexed).

I should mention that I got another problem with the same data set on
PostgreSQL 9.0.2, IIRC "unrecognized rbtree node state: 87" (not 100% sure
about the state number since I immediately upgraded to 9.0.3 and got the
present bug instead).

Again, please let me know if there is anything I can do to help isolate the
bug - table definition below.

Best regards,

Dag Lem

                                               Table "admin.voter"
          Column           |           Type           |
  Modifiers
---------------------------+--------------------------+---------------------
-------------------------------------
 voter_pk                  | bigint                   | not null default
nextval('voter_voter_pk_seq'::regclass)
 audit_oplock              | integer                  | not null default 0
 audit_user                | character varying(64)    | not null
 audit_operator            | character varying(64)    |
 audit_operation           | character(1)             | not null
 audit_timestamp           | timestamp with time zone | not null
 election_event_pk         | integer                  | not null
 voter_id                  | character varying(11)    | not null
 date_of_birth             | date                     |
 voter_number              | integer                  |
 import_batch_number       | integer                  |
 country_id                | character(2)             | not null
 county_id                 | character(2)             | not null
 municipality_id           | character(4)             | not null
 borough_id                | character(6)             | not null
 polling_district_id       | character(4)             | not null
 mv_area_pk                | integer                  |
 eligible                  | boolean                  | not null
 name_line                 | character varying(152)   | not null
 first_name                | character varying(50)    | not null
 middle_name               | character varying(50)    |
 last_name                 | character varying(50)    | not null
 address_line1             | character varying(50)    |
 address_line2             | character varying(50)    |
 address_line3             | character varying(50)    |
 postal_code               | character varying(4)     |
 post_town                 | character varying(50)    |
 email                     | character varying(129)   |
 telephone_number          | character varying(35)    |
 mailing_address_specified | boolean                  |
 mailing_address_line1     | character varying(50)    |
 mailing_address_line2     | character varying(50)    |
 mailing_address_line3     | character varying(50)    |
 mailing_country_code      | character varying(50)    |
 approval_request          | character varying(150)   |
 approved                  | boolean                  | not null default
false
 date_time_submitted       | timestamp with time zone | not null
 aarsakskode               | character(2)             |
 endringstype              | character(1)             |
 statuskode                | character(1)             |
 reg_dato                  | date                     |
 spes_reg_type             | character(1)             |
 electoral_roll_page       | integer                  |
 electoral_roll_line       | integer                  |
Indexes:
    "voter_pkey" PRIMARY KEY, btree (voter_pk)
    "nk_voter" UNIQUE, btree (election_event_pk, voter_id)
    "uk_voter_voter_number" UNIQUE, btree (mv_area_pk, voter_number)
    "ix_voter_address" btree (election_event_pk, postal_code,
upper(address_line1::text) text_pattern_ops, upper(address_line2::text)
text_pattern_ops, upper(address_line3::text) text_pattern_ops) WITH
(fillfactor=70)
    "ix_voter_date_of_birth" btree (election_event_pk, date_of_birth) WITH
(fillfactor=70)
    "ix_voter_polling_district" btree (mv_area_pk) WITH (fillfactor=70)
    "ix_voter_tsvector" gin (soundex_tsvector(election_event_pk,
name_line::text)) WITH (fastupdate=on)
Foreign-key constraints:
    "fk_voter_x_election_event" FOREIGN KEY (election_event_pk) REFERENCES
election_event(election_event_pk) ON DELETE CASCADE
    "fk_voter_x_mv_area" FOREIGN KEY (mv_area_pk) REFERENCES
mv_area(mv_area_pk) ON DELETE SET NULL
Referenced by:
    TABLE "voting" CONSTRAINT "fk_voting_x_voter" FOREIGN KEY (voter_pk)
REFERENCES voter(voter_pk) ON DELETE CASCADE
Triggers:
    voter_insert BEFORE INSERT ON voter FOR EACH ROW EXECUTE PROCEDURE
voter_insert()
    voter_update BEFORE UPDATE ON voter FOR EACH ROW EXECUTE PROCEDURE
voter_update()
    voter_z_audit BEFORE INSERT OR DELETE OR UPDATE ON voter FOR EACH ROW
EXECUTE PROCEDURE audit_voter()

Re: BUG #5876: Incorrectly reported column value

От
Tom Lane
Дата:
"Dag Lem" <dag@nimrod.no> writes:
> The effect of this (pretty serious) bug is that I am able to insert a value
> into an integer column and consistently get an entirely different value read
> out later.

> Unfortunately this happens on a large data set (3.6M rows), and I am not
> able to either reproduce with a smaller data set nor provide the data
> set.

Maybe you can duplicate the problem with a synthesized or anonymized
data set?  It's unlikely anybody will spend much time on such a vague
report as this.

> I should mention that I got another problem with the same data set on
> PostgreSQL 9.0.2, IIRC "unrecognized rbtree node state: 87" (not 100% sure
> about the state number since I immediately upgraded to 9.0.3 and got the
> present bug instead).

Not the same query, surely?  AFAIR the rbtree code is only used in GIN
indexes at the moment, so this would presumably be related to an update
of that GIN index.  But again, it's hard to expect somebody to go
looking for this without a more definite way of producing the problem.

            regards, tom lane

Re: BUG #5876: Incorrectly reported column value

От
Dag Lem
Дата:
Tom Lane <tgl@sss.pgh.pa.us> writes:

> Maybe you can duplicate the problem with a synthesized or anonymized
> data set?  It's unlikely anybody will spend much time on such a vague
> report as this.

I reloaded the same data set overnight, and I could not reproduce the
error (which was present in one in 3.6 million rows). However, I got a
"duplicate key value violates unique constrant" on another table,
without actually duplicating any key value on insert (this was for one
row in 3.3 million).

Because of this inconsistency and the fact that I ran these tests on a
laptop (no ECC), on a hunch I ran memtest86+. And lo and behold:
Faulty memory :-/

> Not the same query, surely?  AFAIR the rbtree code is only used in GIN
> indexes at the moment, so this would presumably be related to an update
> of that GIN index.  But again, it's hard to expect somebody to go
> looking for this without a more definite way of producing the problem.

Right, this error occured on insert.

The problems I reported were most probably caused by memory errors,
and I apologize for posting a bug report without checking that first.

I also apologize for the vague report; however unfortunately it's
quite difficult to construct a test case if you can't reliably
reproduce the error, and the (rather big) data set which caused it in
the first place cannot be shared.

In any case, I'll try to do my homework better before posting another
bug report :-)

I'd like to use this opportunity to commend you and the other
developers for your excellent work on PostgreSQL!

--
Best regards,

Dag Lem