Buglist

On 19 Aug 2003 at 13:32, Bo Lorentsen wrote:

Hi ...

I'm trying to convince my boss to use posgresql (I need RI, transactions
and views), but he keeps comparing the project to mysql. Until now, I
found the answers to he's questions on the www.postgresql.org page, but
now I'm lost :-)

Where do I find a list of bugs both found and solved, or will I need to
ask on the pgsql-bugs list to know the answer ?

Well, you could look at release notes. That contains lot of information. Of
course archives of pgsql-bugs and pgsql-patches are the ultimate unless you
plan to delve into CVS history and sources..

Also have anyone tryed to compare the new transaction model in MySQL 4.x
to PostgreSQL ?

Check this.. http://www.mysql.com/doc/en/ANSI_diff_Transactions.html

To me, it seems that their definition of transaction is limited to preventing
two guys writing to same row simaltenously, which is of course a limited view
of things.

Few major differences I can see right here. Correct me on mysql side.

- WAL log
- Transactabl DDLs
- Nested transactions coming soon to PG
- PITR coming soon to PG

I would love to see entire checklist but don't have any time to devote to
mysql.

Bye
Shridhar

--
Vulcans never bluff. -- Spock, "The Doomsday Machine", stardate 4202.1

On 19 Aug 2003, Bo Lorentsen wrote:

Also have anyone tryed to compare the new transaction model in MySQL 4.x
to PostgreSQL ?

Bo, I've recently started having to deal with MySQL. (Web sites
wanting/using php _need/have-to-have_ MySQL. Their words not mine.) And
from going from a "I dislike MySQL" to "I'm really hating MySQL" has been
getting easier and easier.
My dealings with MySQL are for the 3.xx version but I semi-followed a
thread on this several months ago so feel fully qualified to to throw in
my views. :-) My take on others research was that MySQL transaction
model is a bubble gum and bailing wire add on not an integral part of
MySQL. It _was_ tacked onto the top of the database so if either it or
MySQL failed you were likely to loose data.

I'm looking forward to recive even more constructive arguements :-)

How about "Friends don't let friends use MySQL"?

Hopefully others with a stonger knowledge will provide this.

Rod
--
"Open Source Software - Sometimes you get more than you paid for..."

On Tue, 2003-08-19 at 14:31, Shridhar Daithankar wrote:

Well, you could look at release notes. That contains lot of information. Of
course archives of pgsql-bugs and pgsql-patches are the ultimate unless you
plan to delve into CVS history and sources..

Ok, I just liked to find something like bugzilla, or an explanation to
how bugs are garantied to be visible. My boos like to compare this to
the Mysql model found on : http://bugs.mysql.com/bugstats

Check this.. http://www.mysql.com/doc/en/ANSI_diff_Transactions.html

Hmm, it sound like they have transactions on OmniDB tables, but these
are really slow, and therefor they put much energy into advetising for
the MyISAM files (non transactional). Or, am I missing something.

To me, it seems that their definition of transaction is limited to preventing
two guys writing to same row simaltenously, which is of course a limited view
of things.

This sounds like there MyISAM tables, or ???

Few major differences I can see right here. Correct me on mysql side.

- WAL log
- Transactabl DDLs

Yes and lets add :
- Views
- subselects
- plperl, plsql, plpython, plXXX

- Nested transactions coming soon to PG
- PITR coming soon to PG

Not good for argumenting with my boss about future :-)

I would love to see entire checklist but don't have any time to devote to
mysql.

I do understand, and its no pleasure either :-)

/BL

On Tue, 2003-08-19 at 14:37, Roderick A. Anderson wrote:

Bo, I've recently started having to deal with MySQL. (Web sites
wanting/using php _need/have-to-have_ MySQL. Their words not mine.) And
from going from a "I dislike MySQL" to "I'm really hating MySQL" has been
getting easier and easier.

Been there too :-)

My dealings with MySQL are for the 3.xx version but I semi-followed a
thread on this several months ago so feel fully qualified to to throw in
my views. :-) My take on others research was that MySQL transaction
model is a bubble gum and bailing wire add on not an integral part of
MySQL. It _was_ tacked onto the top of the database so if either it or
MySQL failed you were likely to loose data.

But this goes for 3.x have you tried 4.x and there InnoDB tables ?

How about "Friends don't let friends use MySQL"?

Nice thanks, but me boss dont by that ... yet.

/BL

"Shridhar Daithankar" <shridhar_daithankar@persistent.co.in> writes:

On 19 Aug 2003 at 13:32, Bo Lorentsen wrote:

Where do I find a list of bugs both found and solved, or will I need to
ask on the pgsql-bugs list to know the answer ?

Well, you could look at release notes. That contains lot of information. Of
course archives of pgsql-bugs and pgsql-patches are the ultimate unless you
plan to delve into CVS history and sources..

Also the pgsql-committers archives. (Personally, when I want to look at
a change history, I use cvs2cl to extract one from the CVS server.) The
release notes are a good high-level view, but if you want details you
need to look to the mailing list archives or CVS logs.

BTW, lots of people have the bad habit of reporting bugs on -general or
-hackers; there are significant bug fixes that never get a mention in
the -bugs list. So you really have to troll all the archives if you are
going to use the archives as your primary source. CVS change history
might be a better starting point.

regards, tom lane

On Tuesday 19 August 2003 18:59, Bo Lorentsen wrote:

My dealings with MySQL are for the 3.xx version but I semi-followed a
thread on this several months ago so feel fully qualified to to throw in
my views. :-) My take on others research was that MySQL transaction
model is a bubble gum and bailing wire add on not an integral part of
MySQL. It _was_ tacked onto the top of the database so if either it or
MySQL failed you were likely to loose data.

But this goes for 3.x have you tried 4.x and there InnoDB tables ?

Well, if you have some time and hardware to play around, I am sure we can
easily test them side by side.

Interested? This could take couple of weeks taking things to real world
workloads but could provide some insight to community.

If you have mysql 4.x and postgresql 7.4beta installed, you can easily setup
these things..

Shridhar

I learned MySQL then went on to Postgres. I chose postgres for my in
house project just because of the row locking and transactions. Looking
back I could have used MySQL. I have yet to use stored procedures or
many of the high level functions of Postgres however transactions make
things so much cleaner. I do not think MySQL is a bad system. It works
well for many people in many situations. I think that MySQL and SAP
getting together could be very exciting. When it comes to SQL databases
I would say we have a wealth good choices. This if I use PHP I have to
use MySQL is a load of tripe. PHP can work just fine with Postgres. I
hate to even suggest this but has anyone thought of adding PHP to the
languages that you can use to write stored procedures in Postgres?

Roderick A. Anderson wrote:

On Tuesday 19 August 2003 19:12, Tom Lane wrote:

BTW, lots of people have the bad habit of reporting bugs on -general or
-hackers; there are significant bug fixes that never get a mention in
the -bugs list. So you really have to troll all the archives if you are
going to use the archives as your primary source. CVS change history
might be a better starting point.

Making pgsql-bugs a open to non-subscription but moderated list might be a
good idea. It really does not matter if a bug gets filed couple of days late
but having to have subscribe to another list could be ditterent.

Or have bugzilla setup somewhere. That way the tracking will be hell lot
visible to outside world..

Shridhar

On Tue, 2003-08-19 at 07:32, Bo Lorentsen wrote:

Hi ...

I'm trying to convince my boss to use posgresql (I need RI, transactions
and views), but he keeps comparing the project to mysql. Until now, I
found the answers to he's questions on the www.postgresql.org page, but
now I'm lost :-)

Where do I find a list of bugs both found and solved, or will I need to
ask on the pgsql-bugs list to know the answer ?

search the bugs forum. for a list of bugs/missing features, the TODO
list is your best bet.

Also have anyone tryed to compare the new transaction model in MySQL 4.x
to PostgreSQL ?

The biggest problem I see with the mysql transactional model is that it
violates relational theory, namely the separation of the physical and
logical model, but allowing both myisam and innodb tables to coexist.
I think it was stephen szabo who posted the best example of this which
involves starting a transaction, updating both a myisam table and an
innodb table, then rolling back the transaction. in this case the myisam
table will be updated and the innodb table wont, which means that app
writers can't simple know what information is contained in a table, they
have to know how tables are physically created and stored in order to
work with them, which tends to increase development time.

I'm looking forward to recive even more constructive arguements :-)

a few links for your perusal:
http://faemalia.org/wiki/view/Technical/PostgreSQLvsMySQL
http://forums.devshed.com/archive/46/2002/10/3/35171
http://www.phpbuilder.com/columns/tim20001112.php3?page=1
http://openacs.org/philosophy/why-not-mysql.html

hope this helps,

Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

On Tue, 2003-08-19 at 15:45, Shridhar Daithankar wrote:

Well, if you have some time and hardware to play around, I am sure we can
easily test them side by side.

Interresting project, is this allowed :-)

Interested? This could take couple of weeks taking things to real world
workloads but could provide some insight to community.

Yeps, but this is not the propper time, and I am not sure if I have the
knowledge what it takes.

If you have mysql 4.x and postgresql 7.4beta installed, you can easily setup
these things..

Yeps, but how to test ? And how do one test stability :-)

/BL

On Tue, 2003-08-19 at 15:47, Shridhar Daithankar wrote:

Or have bugzilla setup somewhere. That way the tracking will be hell lot
visible to outside world..

I agree on this, as it seems messy from outside not to be able to get an
overview of both solved and not solved bugs.

I know that as developer, this may not seem like a big problem, but it
will help non hackers to get an overview.

/BL

Bo Lorentsen <bl@netgroup.dk> writes:

On Tue, 2003-08-19 at 14:37, Roderick A. Anderson wrote:

My take on others research was that MySQL transaction
model is a bubble gum and bailing wire add on not an integral part of
MySQL. It _was_ tacked onto the top of the database so if either it or
MySQL failed you were likely to loose data.

But this goes for 3.x have you tried 4.x and there InnoDB tables ?

It's still bolted on. The entire concept that "transactional integrity
is optional" is ludicrous, IMHO. "Integrity" and "optional" are
contradictory.

One thing you should ask about MySQL is where they keep the system's
metadata (catalog data). In Postgres it's under transactional control
just like everything else, which means it's (a) crash-safe and (b)
rollback-able. This is why all DDL changes are rollback-able in PG.
I honestly don't know what the corresponding arrangements are in MySQL
... but I suspect that even in an all-InnoDB database, there is critical
system data that is outside the InnoDB table handler and thus not
transaction-safe.

regards, tom lane

At 03:56 PM 8/19/2003 +0200, Bo Lorentsen wrote:

On Tue, 2003-08-19 at 15:45, Shridhar Daithankar wrote:

Well, if you have some time and hardware to play around, I am sure we can
easily test them side by side.

Interresting project, is this allowed :-)

Interested? This could take couple of weeks taking things to real world
workloads but could provide some insight to community.

Yeps, but this is not the propper time, and I am not sure if I have the
knowledge what it takes.

Install an application that can use both DBs. Muck around with it. If you
can't tell the difference, then I'd say go with postgresql - transactions
isn't bolted on, quite a number of other design wins too. If you can tell
the difference and MySQL is better, many of us here would be interested to
know.

If you have mysql 4.x and postgresql 7.4beta installed, you can easily

setup

these things..

Yeps, but how to test ? And how do one test stability :-)

Do lots of concurrent updates and inserts and selects for a long time?

While you are testing and have no critical data you can do stuff like
pressing the reset button midway during a transaction, or have someone trip
over the power cord. Someone on this list was doing stuff like that to
Postgresql and he said it did pretty well.

I'm not saying postgresql will save you from that, but that's one way to
learn how fault tolerant a product is before the uncontrollable faults
appear. So far there have been quite a number of people with flaky RAM or
hardware and a large percentage of them don't seem to have lost much data
(well it's hard to be 100% sure ;) ).

Have fun!
Link.

At 03:59 PM 8/19/2003 +0200, Bo Lorentsen wrote:

On Tue, 2003-08-19 at 15:47, Shridhar Daithankar wrote:

Or have bugzilla setup somewhere. That way the tracking will be hell lot
visible to outside world..

I agree on this, as it seems messy from outside not to be able to get an
overview of both solved and not solved bugs.

I know that as developer, this may not seem like a big problem, but it
will help non hackers to get an overview.

AFAIK bugzilla requires mysql (for now).

I've recently installed it and if it can be easily made to work with
postgresql I'd like to know.

Link.

Hi,

On Tue, 19 Aug 2003, Lincoln Yeoh wrote:

AFAIK bugzilla requires mysql (for now).

I've recently installed it and if it can be easily made to work with
postgresql I'd like to know.

https://bugzilla.redhat.com/bugzilla/index.cgi
Bugzilla News
===
January 1st, 2003
Current Red Hat version of Bugzilla using PostgreSQL code available for
download.
====

AFAIK RH runs bugzilla on PostgreSQL (or RHDB, whatever). The code is
available from there.

Regards,

--
Devrim GUNDUZ
devrim@gunduz.org devrim.gunduz@linux.org.tr
http://www.tdmsoft.com
http://www.gunduz.org

On Tue, 2003-08-19 at 16:03, Tom Lane wrote:

It's still bolted on. The entire concept that "transactional integrity
is optional" is ludicrous, IMHO. "Integrity" and "optional" are
contradictory.

Good point. Also the problem of MyISAM and InnoDB RI :-)

One thing you should ask about MySQL is where they keep the system's
metadata (catalog data). In Postgres it's under transactional control
just like everything else, which means it's (a) crash-safe and (b)
rollback-able. This is why all DDL changes are rollback-able in PG.
I honestly don't know what the corresponding arrangements are in MySQL
... but I suspect that even in an all-InnoDB database, there is critical
system data that is outside the InnoDB table handler and thus not
transaction-safe.

Thats a really nice thing for temporary tables, but "point in time"
backup is a much stonger argument :-)

/BL

On Tue, 2003-08-19 at 16:20, Lincoln Yeoh wrote:

Install an application that can use both DBs. Muck around with it. If you
can't tell the difference, then I'd say go with postgresql - transactions
isn't bolted on, quite a number of other design wins too. If you can tell
the difference and MySQL is better, many of us here would be interested to
know.

Ok, thanks, we may need to make a test utility, that is open and fair,
but thats a little hard, as PG have some featurs that MySQL does not.

Do lots of concurrent updates and inserts and selects for a long time?

I do think I know why you say this :-)

Have fun!

I like to do this, but I'm not sure that I have the time needed. If I
have the time, and I get some results, I let you now.

/BL

"BL" == Bo Lorentsen <bl@netgroup.dk> writes:

BL> Hi ...
BL> I'm trying to convince my boss to use posgresql (I need RI, transactions
BL> and views), but he keeps comparing the project to mysql. Until now, I
BL> found the answers to he's questions on the www.postgresql.org page, but
BL> now I'm lost :-)

My big reason to choose postgres was concurrency. My application has
transactions and updates all over the place, and even as a single
developer in the early stages, I could already see problems with
table-level locking that mysql was giving me. Who knows what would
have happened in production with hundreds of people hitting the db
simultaneously! The row-level locking in Postgres has made it
possible for an incredible number of simultaneous actions to be
carried out without any waiting for the users.

Try making a table grow beyond your file size limit in mysql. You
can't. Even if you use an OS with 64-bit file pointers (such as
FreeBSD) you can't grow your file beyond 4Gb in mysql (at least with
mysam tables -- dunno about innodb tables). In Postgres, it is
automagically handled for you.

The *only* drawbacks I find with postgres is the need to dump/restore
on major version updates and the need to vacuum the tables
regularly...

Tops on my wish list is that postgres automatically notice when a row
is no longer needed (all transactional references to it are gone) and
'free' it at that time, rather then needing a special scan to
determine the row is no longer needed and freeing it.

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vivek Khera, Ph.D. Khera Communications, Inc.
Internet: khera@kciLink.com Rockville, MD +1-240-453-8497
AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/

On Tuesday 19 August 2003 21:03, Vivek Khera wrote:

Tops on my wish list is that postgres automatically notice when a row
is no longer needed (all transactional references to it are gone) and
'free' it at that time, rather then needing a special scan to
determine the row is no longer needed and freeing it.

Heh.. we have autovacuum right. Well it does not work the way you want but it
works automatically at least.

Couple of releases down the line it will be good enough and vacuum problems
will be history if people take care to setup autovacuum and FSM parameters
correctly..

Shridhar