← Back to team overview

pbxt-discuss team mailing list archive

Re: free_table_share() != drizzle

 

Hi Brian,

As you know, most engines that need a Table object use the one connected to the Cursor object ("table" below):

class Cursor :public memory::SqlAlloc
{
protected:
  TableShare *table_share;   /* The table definition */
  Table *table;               /* The current open table */
  ....

Here the engine will follow the "table" pointer to the "field" array, where it uses the offsets of the data in a record, in order to copy data in and out of the record.

PBXT also uses information like length and type of the fields, and the collation sequence if the column has one.

The main difference between PBXT and other engines, is that it needs this information during recovery (the field information on the Table object), and PBXT has background threads (that do not have a Cursor), which need this information as well.

This means PBXT needs to create it own Table objects for these threads.

On May 14, 2010, at 6:12 PM, Brian Aker wrote:

Hi!

What are you using Table for? The table definition should have everything you need in it for defining the table. "Table" in drizzle is just a collection of caches used by a Cursor. TableShare, beyond its uses in locking, is just an interface to the information found in the table definition.

Cheers,
	-Brian

On May 14, 2010, at 12:38 AM, Paul McCullagh wrote:

Hi Brian,

As far as I know, getTableDefinition() just returns the protobuf of the table.

What I need is a "class Table" (table.h) reference.

This structure is usually one per thread (i.e. some methods use instance variables).

However, I share one pointer between all threads, because I don't use any of the methods that address instance variables.

(Of course it would make more sense to move the methods that independent of instance variables to TableShare).

On May 11, 2010, at 2:43 AM, Brian Aker wrote:

Hi!

If you know the table name you can do a getTableDefinition() for the table and get back the definition. Do you need anything beyond that?

Cheers,
	-Brian

On May 10, 2010, at 1:20 AM, Paul McCullagh wrote:

Yup, This is a C hack, so I agree it should be done differently for Drizzle.

my_close_table() is only used to close "tables" opened by my_open_table().

In my_open_table() we have:

	if (!(buffer = (char *) xt_malloc(self, size)))
		return NULL;
	table = (TABLE *) buffer;
	buffer += sizeof(TABLE);
	share = (TABLE_SHARE *) buffer;

So things have been setup so that:

share == (TABLE_SHARE *) ((char *) table + sizeof(TABLE))

To get rid of this hack, we need to look at the purpose of this code:

PBXT requires a reference (or a copy of) the internal MySQL/ Drizzle data dictionary (i.e. the structure that is created when a .frm file is loaded).

This is required for 2 purposes:

1. To determine the internal MySQL row and key structures.
2. PBXT uses reference to MySQL collation sequence based comparison routines.

MySQL/Drizzle supply this reference when opening a table handler. However, for PBXT this is not good enough, because there are background threads (like the recovery thread) that need the information as well.

Ideally Drizzle would supply a set of callback services. One of these would be to get a reference to Drizzle data dictionary for a table, and another would be a function to release the reference.

Then I could remove the hack for the Drizzle case entirely.

On May 9, 2010, at 1:24 AM, Brian Aker wrote:

Hi!

This code:

static void my_close_table(TABLE *table)
{
#ifdef DRIZZLED
   TABLE_SHARE     *share;

   share = (TABLE_SHARE *) ((char *) table + sizeof(TABLE));
   share->free_table_share();
#else
delete_table(table, true); // TODO: Q, why did Stewart remove this?
#endif
   xt_free_ns(table);
}


This is not going to go well in Drizzle, since we the assumption that the memory allocation will be aligned this way is wrong. In my local tree I am going to drop the free_table_share().

I'm not really sure what to do though. I believe what you will be wanting to do is call delete on table->s, though if what you are using is an TableInstance then it should clean up just fine on its own.

Is there something I can do to make this code a bit more straightforward for you?

Cheers,
	-Brian






_______________________________________________
Mailing list: https://launchpad.net/~pbxt-discuss
Post to     : pbxt-discuss@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~pbxt-discuss
More help   : https://help.launchpad.net/ListHelp



--
Paul McCullagh
PrimeBase Technologies
www.primebase.org
www.blobstreaming.org
pbxt.blogspot.com







--
Paul McCullagh
PrimeBase Technologies
www.primebase.org
www.blobstreaming.org
pbxt.blogspot.com







--
Paul McCullagh
PrimeBase Technologies
www.primebase.org
www.blobstreaming.org
pbxt.blogspot.com






Follow ups

References