A Lightweight SQL Database for Cloud Infrastructure and Web Applications

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

Reported by Joe Daly on 2010-10-13
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Drizzle
Medium
David Shrewsbury
7.0
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)

Joe Daly (skinny.moey) on 2010-10-13
tags: added: replication
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. :(

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.

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  Edit
Everyone can see this information.

Other bug subscribers

Related blueprints