DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=Yahoo.com;
	h=Received:Received:Message-ID:Date:From:User-Agent:X-Accept-Language:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding;
	b=CHlrzFI98F9d7+V3EKGHc5dh/WsppCeuPwzkxxV7Wg3gRegHdh8Dc+5lImr+b3RKa27OuVn+EifRKnNVt62K/nzb4oBLVm7/2dEStiNM5UgmwF3ASRExPF2YYGAiCcN/AcuKxeTOlOvM5Q12q//GUTnsCmj6SLtgt5tft1lsNIk=
	;
Message-ID: <44B3DADF.2040609@Yahoo.com>
Date: Tue, 11 Jul 2006 13:07:43 -0400
From: Jan Wieck <JanWieck@Yahoo.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.7.1) Gecko/20040707
MIME-Version: 1.0
To: Scott Marlowe <smarlowe@g2switchworks.com>
CC: Alex Turner <armtuk@gmail.com>, Jason McManus <mcmanus.jason@gmail.com>,
	pgsql general <pgsql-general@postgresql.org>
Subject: Re: Notes on converting from MySQL 5.0.x to PostgreSQL
References: <b0f0a0e00606300617j2ed6dd4cub7bc2db972f6211a@mail.gmail.com>	
	<1151680333.13129.55.camel@state.g2switchworks.com>	
	<44B2E595.9060209@Yahoo.com>	
	<33c6269f0607101900s3ba3ad21ncb1dd1df4cf52315@mail.gmail.com>	
	<44B3C79B.5080006@Yahoo.com>
	<1152633439.6540.65.camel@state.g2switchworks.com>
In-Reply-To: <1152633439.6540.65.camel@state.g2switchworks.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

On 7/11/2006 11:57 AM, Scott Marlowe wrote:

> On Tue, 2006-07-11 at 10:45, Jan Wieck wrote:
>> On 7/10/2006 10:00 PM, Alex Turner wrote:
>> 
>> > http://dev.mysql.com/doc/refman/5.1/en/replication-row-based.html
>> > 
>> > 5.1
>> 
>> Ah, thanks. So I guess 5.1.5 and 5.1.8 must be considered major feature 
>> minor/bugfix releases. I still don't understand how people can use 
>> software in production that has literally zero bugfix upgrade path 
>> without the risk of incompatibility due to new features. I consider 
>> every IT manager, who makes that choice, simply overpaid.
> 
> Dear god!  That page made my eyes bleed.
> 
> Individual users can choose the method of replication for their
> sessions?
> 
> There's a mixed method that switches back and forth?

It is totally unclear from that page what would make the server decide 
when to pick one or the other method. It seems to me that this is mainly 
an optimization for many single inserts in order to get a smaller 
binlog. Note that according to this page

http://dev.mysql.com/doc/internals/en/replication-prepared-statements.html

the master currently substitutes the parameters as literals into the 
query for prepared statements.

What also is totally unclear, maybe someone with more MySQL experience 
can answer this question, is if the binary format actually does solve 
the problems discussed. Namely timestamps and also autoincrement. What 
exactly happens if an insert doesn't provide a value for an autoinc or 
timestamp column? Is the server chosen value placed into the binlog when 
using row format or not?


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #