MySQL Bugs: #33553: getEvent() fails on the first two event entries returned by listEvents()

Bug #33553	getEvent() fails on the first two event entries returned by listEvents()
Submitted:	28 Dec 2007 14:54	Modified:	28 Dec 2007 16:42
Reporter:	Hartmut Holzgraefe	Email Updates:
Status:	Verified	Impact on me:	None
Category:	MySQL Cluster: NDB API	Severity:	S3 (Non-critical)
Version:	mysql-5.1-telco-6.3	OS:	Linux
Assigned to:		CPU Architecture:	Any
Tags:	ndb-6.3.6

Description:
Dictionary::listEvents() returns a List of Elements containing Event names.

Dictionary::getEvent() returns a pointer to an Event given an Event name.

I would assume that all event names returned by listEvents() would be accepted by getEvent() but it actually fails on the first two Elements in the List returned by listEvents() if the cluster is configured as a replication master:

The error returned from getEvent() for the 1st replication event entry is:

  Event name: REPL$mysql/ndb_schema
  error: No such table existed (723)

On the 2nd replication event the result is even worse, here i got:

  Event name: NDB$BLOBEVENT_REPL$mysql/ndb_schema_3
  ndb_show_events: DictCache.cpp:161: NdbTableImpl* GlobalDictCache::get(const char*, int*): Assertion `! is_ndb_blob_table(name)' failed.
  Aborted

For the 3rd replication event REPL$mysql/ndb_apply_status getEvent() returns an Event pointer just fine, the same is true for any additional replication events on regular cluster tables.

When creating a cluster table with BLOB or TEXT fields i'm getting the same failure as on the NDB$BLOBEVENT_REPL$mysql/ndb_schema_3 event though

How to repeat:
test program will be attached later

Suggested fix:
getEvent() should return a valid Event pointer on any event name returned by listEvents(). Returning a NULL pointer on a system event like REPL$mysql/ndb_schema *may* be acceptable if documented properly, but failing with an assertion on a lookup definitely isn't. There is no real way to detect whether getEvent() would work on a given event name up front (even though for the replication events on tables containing BLOB fields it could be detected from the naming convention).

To reproduce:

- start a fresh cluster with binary logging enabled on at least one mysqld
- create two test tables, one simple, one with a blob:
    CREATE TABLE t1(i int primary key) engine=ndb;
    CREATE TABLE t2(i int primary key, b blob) engine=ndb;
- compile the example program from the "Files" section:
    ./configure --with-mysql=/mysql/install/prefix
    make
    ./ndb_show_events
- the binary will use listEvents() to get and print a list of events:

    1: REPL$mysql/ndb_schema
    2: NDB$BLOBEVENT_REPL$mysql/ndb_schema_3
    3: NDB$BLOBEVENT_REPL$test/t2_1
    4: REPL$test/t2
    5: REPL$mysql/ndb_apply_status
    6: REPL$test/t1

    Event number for details, [ENTER] to reload, Q to quit

- entries 1, 2 and 5 are related to replication,
  entry 6 is for t1,
  entries 4 and 3 are for t2
  (funny order, isn't it? this is how listEvents() returns them ...)

- on entry 1 you'll get a "No such table existed (723)" error on getEvent("REPL$mysql/ndb_schema")

- on entries 2 and 3 getEvent() will fail with:

  ndb_show_events: DictCache.cpp:161: NdbTableImpl* GlobalDictCache::get(const char*, int*): Assertion `! is_ndb_blob_table(name)' failed.
  Aborted

- entries 4 to 6 will produce proper event detail information

test tool source project

Attachment: ndb_show_events-0.1.tar.gz (application/x-gzip, text), 300.52 KiB.

Addition: shouldn't getEvent() fail with "Event not found (4710)" instead of "No such table existed (723)"?