Merge hundin:/my/mysql-4.0 into bitch.mysql.fi:/my/mysql-4.0

The following configure line should work:

@example

CFLAGS="-DHPUX -I/opt/dce/include" CXXFLAGS="-DHPUX -I/opt/dce/include -felide-constructors -fno-exceptions -fno-rtti" CXX=gcc ./configure --with-pthread --with-named-thread-libs='-ldce' --prefix=/usr/local/mysql --disable-shared

CFLAGS="-DHPUX -I/opt/dce/include -fpic" CXXFLAGS="-DHPUX -I/opt/dce/include -felide-constructors -fno-exceptions -fno-rtti" CXX=gcc ./configure --with-pthread --with-named-thread-libs='-ldce' --prefix=/usr/local/mysql --disable-shared

@end example

If you are compiling @code{gcc} 2.95 yourself, you should NOT link it with

If you supply an extension to @code{--log-bin=filename.extension}, the

extension will be silenty removed.

To the binary log filename @code{mysqld} will append an extension that is a

number that is incremented each time you execute @code{mysqladmin

refresh}, execute @code{mysqladmin flush-logs}, execute the @code{FLUSH LOGS}

statement or restart the server. 

To the binary log filename @code{mysqld} will append an extension that

is a number that is incremented each time you execute @code{mysqladmin

refresh}, execute @code{mysqladmin flush-logs}, execute the @code{FLUSH

LOGS} statement or restart the server. A new binary log will also

automaticly be created when it reaches @code{max_bin_log_size}. You can

delete all not active binary log files with the @code{RESET MASTER}

command. @xref{RESET}.

You can use the following options to @code{mysqld} to affect what is logged

to the binary log:

Following are some performance data for the query cache

(We got these by running the MySQL benchmark suite on a Linux Alpha

2x500 MHz with 2GB RAM and a 64MB query cache).

2x500 MHz with 2GB RAM and a 64MB query cache):

@itemize @bullet

@item

If want to disable the query cache code set @code{query_cache_size=0}.

If you want to disable the query cache code set @code{query_cache_size=0}.

By disabling the query cache code there is no noticeable overhead.

@item

If all of the queries you're preforming are simple (such as selecting a

If a table changes (@code{INSERT}, @code{UPDATE}, @code{DELETE},

@code{TRUNCATE}, @code{ALTER} or @code{DROP TABLE|DATABASE}),

then all cached queries that used this table (possibly through a

MRG_MyISAM table!) become invalid and are removed from the cache.

@code{MRG_MyISAM} table!) become invalid and are removed from the cache.

Currently all @code{InnoDB} tables are invalidated on @code{COMMIT},

in the future this will be changed so only tables changed in the

@item @code{Qcache_inserts}

 @tab Number of queries added to the cache.

@item @code{Qcache_hits}

 @tab Number of cache hits

 @tab Number of cache hits.

@item @code{Qcache_not_cached}

 @tab Number of non-cached queries

 (not cachable, or due to SQL_QUERY_CACHE_TYPE)

 (not cachable, or due to @code{SQL_QUERY_CACHE_TYPE}).

@item @code{Qcache_free_memory}

 @tab Amount of free memory for query cache.

@item @code{Qcache_total_blocks}

 @tab Total number of blocks in query cache.

@item @code{Qcache_free_blocks}

 @tab Number of free memory blocks in query cache.

@end multitable

Please note:

Total number of queries =

@code{Qcache_inserts} + @code{Qcache_hits} + @code{Qcache_not_cached}.

The query cache uses variable length blocks, so @code{Qcache_total_blocks}

and @code{Qcache_free_blocks} may indicate query cache memory fragmentation.

After @code{FLUSH QUERY CACHE} only a single (big) free block remains.

Note: Every query needs a minimum of two blocks (one for the query text

and one or more for the query results). Also, every table that is used

by a query needs one block, but if two or more queries use same table

only one block needs to be allocated.

@node Table types, Clients, Reference, Top

@chapter MySQL Table Types

@appendixsubsec Changes in release 3.23.47

@itemize @bullet

@item

InnoDB now supports @code{NULL} in keys.

@item

Fixed shutdown problem on HPUX. (Introduced in 3.23.46)

@item

Added 'DO expression' command.

@item

Fixed core-dump bug in replication when using SELECT RELEASE_LOCK();

@item

Added new statement DO expression,[expression].

    (void) tee_fputs("\n  <row>\n", PAGER);

    for (uint i=0; i < mysql_num_fields(result); i++)

    {

      char *data;

      ulong *lengths=mysql_fetch_lengths(result);

      tee_fprintf(PAGER, "\t<%s>", (fields[i].name ?

				  (fields[i].name[0] ? fields[i].name :

#if defined(HPUX) && !defined(DONT_REMAP_PTHREAD_FUNCTIONS)

#define pthread_cond_timedwait(a,b,c) my_pthread_cond_timedwait((a),(b),(c))

#define pthread_mutex_trylock(a) my_pthread_mutex_trylock((a)) 

int my_pthread_cond_timedwait(pthread_cond_t *cond, pthread_mutex_t *mutex,

			      struct timespec *abstime);

int my_pthread_mutex_trylock(pthread_mutex_t *mutex);

#endif

	/* safe_mutex adds checking to mutex for easier debugging */

#define THR_SERVER_ALARM SIGALRM

#endif

#if defined(DONT_USE_THR_ALARM)

#if defined(DONT_USE_THR_ALARM) || !defined(THREAD)

#define USE_ALARM_THREAD

#undef USE_ONE_SIGNAL_HAND

typedef struct st_thr_alarm_entry

{

  uint crono;

} thr_alarm_entry;

typedef my_bool thr_alarm_t;

typedef my_bool ALARM;

#define thr_alarm_init(A)   (A)->crono=0

#define thr_alarm_in_use(A) (A)->crono

#define thr_alarm_init(A) (*(A))=0

#define thr_alarm_in_use(A) (*(A) != 0)

#define thr_end_alarm(A)

#define thr_alarm(A,B,C) ((*(A)=1)-1)

/* The following should maybe be (*(A)) */

#define thr_got_alarm(A) 0 

#define init_thr_alarm(A)

#define thr_alarm_kill(A)

#define end_thr_alarm()

#define thr_alarm(A,B) (((A)->crono=1)-1)

#define thr_got_alarm(A) (A)->crono

#define thr_end_alarm(A)

#else

#if defined(__WIN__)

	} else if (type <= MLOG_WRITE_STRING) {

		new_ptr = mlog_parse_string(ptr, end_ptr, page);

	} else {

		new_ptr = NULL; /* Eliminate compiler warning */

		ut_error;

		new_ptr = NULL;

	        fprintf(stderr,

		 "InnoDB: WARNING: the log file may have been corrupt and it\n"

		 "InnoDB: is possible that the log scan did not proceed\n"

		 "InnoDB: far enough in recovery. Please run CHECK TABLE\n"

		 "InnoDB: on your InnoDB tables to check that they are ok!\n"

		 "InnoDB: Corrupt log record type %lu\n",

			                                  (ulint)type);

	}

	ut_ad(!page || new_ptr);

	new_ptr = mlog_parse_initial_log_record(ptr, end_ptr, type, space,

								page_no);

	/* If the operating system writes to the log complete 512-byte

	blocks, we should not get the warnings below in recovery.

        A warning means that the header and the trailer appeared ok

	in a 512-byte block, but in the middle there was something wrong.

	TODO: (1) add similar warnings in the case there is an incompletely

	written log record which does not extend to the boundary of a

	512-byte block. (2) Add a checksum to a log block. */

	if (!new_ptr) {

	        return(0);

	}

	/* Check that space id and page_no are sensible */

	if (!new_ptr || *space != 0 || *page_no > 0x8FFFFFFF) {

	if (*space != 0 || *page_no > 0x8FFFFFFF) {

	        fprintf(stderr,

		 "InnoDB: WARNING: the log file may have been corrupt and it\n"

		 "InnoDB: is possible that the log scan did not proceed\n"

		 "InnoDB: far enough in recovery. Please run CHECK TABLE\n"

		 "InnoDB: on your InnoDB tables to check that they are ok!\n"

	   "InnoDB: Corrupt log record type %lu, space id %lu, page no %lu\n",

			(ulint)(*type), *space, *page_no);

		return(0);

	}