transaction log udfs do not report all data if server is stopped and started

Bug #659637 reported by Joe Daly
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Drizzle
Won't Fix
Medium
David Shrewsbury
7.0
Won't Fix
Medium
David Shrewsbury

Bug Description

This may be related to https://bugs.launchpad.net/drizzle/+bug/659633 but the udfs are not showing any transaction information prior to a restart of the server

drizzle> select * from TRANSACTION_LOG_ENTRIES;
+--------------+-------------+--------------+
| ENTRY_OFFSET | ENTRY_TYPE | ENTRY_LENGTH |
+--------------+-------------+--------------+
| 1087 | TRANSACTION | 40 |
| 1127 | TRANSACTION | 91 |
+--------------+-------------+--------------+
2 rows in set (0 sec)

drizzle> select * from TRANSACTION_LOG_TRANSACTIONS;
+--------------+----------------+-----------+------------------+------------------+----------------+----------+
| ENTRY_OFFSET | TRANSACTION_ID | SERVER_ID | START_TIMESTAMP | END_TIMESTAMP | NUM_STATEMENTS | CHECKSUM |
+--------------+----------------+-----------+------------------+------------------+----------------+----------+
| 1087 | 1 | 1 | 1286936975431616 | 1286936975431617 | 0 | 0 |
| 1127 | 2 | 1 | 1286937354269769 | 1286937354304734 | 1 | 0 |
+--------------+----------------+-----------+------------------+------------------+----------------+----------+
2 rows in set (0 sec)

Tags: replication
Joe Daly (skinny.moey)
tags: added: replication
Revision history for this message
David Shrewsbury (dshrews) wrote :

Well, this seems to be an intentional design decision.

The tables mentioned are generated on the fly using the TableFunction interface, if I'm understanding it all correctly. Each time the tables are read, they are "created" and "populated" from another data source. In the transaction log's case, this source is an in-memory object containing all information related to the TL since server startup. It is transient and not persistent across restarts.

Also, this object seems to grow without bounds. :(

Revision history for this message
Joe Daly (skinny.moey) wrote :

we may want to add a blueprint to rework these now that the transaction ids go across a restart. The problem with the existing udf is if you wanted to check the last thing in the log before a crash or restart you could not with the udf.

Revision history for this message
David Shrewsbury (dshrews) wrote :

The InnoDB trx log is the standard.

Changed in drizzle:
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Related blueprints

Remote bug watches

Bug watches keep track of this bug in other bug trackers.