Buglist

[Bo Lorentsen]

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 ?

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

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

/BL


---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

[Roderick A. Anderson]

Re: Buglist

On 19 Aug 2003, Bo Lorentsen wrote:
[color=blue]
> Also have anyone tryed to compare the new transaction model in MySQL 4.x
> to PostgreSQL ?[/color]

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.
[color=blue]
> I'm looking forward to recive even more constructive arguements :-)[/color]

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..."


---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

[Shridhar Daithankar]

Re: Buglist

On 19 Aug 2003 at 13:32, Bo Lorentsen wrote:
[color=blue]
> 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 ?[/color]

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..

[color=blue]
> Also have anyone tryed to compare the new transaction model in MySQL 4.x
> to PostgreSQL ?[/color]

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


---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postg resql.org

[Bo Lorentsen]

Re: Buglist

On Tue, 2003-08-19 at 14:31, Shridhar Daithankar wrote:[color=blue]
> 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..[/color]
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
[color=blue]
> Check this.. http://www.mysql.com/doc/en/ANSI_diff_Transactions.html[/color]
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.
[color=blue]
> 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.[/color]
This sounds like there MyISAM tables, or ???
[color=blue]
> Few major differences I can see right here. Correct me on mysql side.
>
> - WAL log
> - Transactabl DDLs[/color]
Yes and lets add :
- Views
- subselects
- plperl, plsql, plpython, plXXX
[color=blue]
> - Nested transactions coming soon to PG
> - PITR coming soon to PG[/color]
Not good for argumenting with my boss about future :-)
[color=blue]
> I would love to see entire checklist but don't have any time to devote to
> mysql.[/color]
I do understand, and its no pleasure either :-)

/BL


---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

[Tom Lane]

Re: Buglist

"Shridhar Daithankar" <shridhar_daith ankar@persisten t.co.in> writes:[color=blue]
> On 19 Aug 2003 at 13:32, Bo Lorentsen wrote:[color=green]
>> 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 ?[/color][/color]
[color=blue]
> 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..[/color]

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

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

[Shridhar Daithankar]

Re: Buglist

On Tuesday 19 August 2003 18:59, Bo Lorentsen wrote:[color=blue][color=green]
> > 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.[/color]
>
> But this goes for 3.x have you tried 4.x and there InnoDB tables ?[/color]

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


---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postg resql.org so that your
message can get through to the mailing list cleanly

[Shridhar Daithankar]

Re: Buglist

On Tuesday 19 August 2003 19:12, Tom Lane wrote:[color=blue]
> 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.[/color]

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


---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

[Bo Lorentsen]

Re: Buglist

On Tue, 2003-08-19 at 15:45, Shridhar Daithankar wrote:
[color=blue]
> Well, if you have some time and hardware to play around, I am sure we can
> easily test them side by side.[/color]
Interresting project, is this allowed :-)
[color=blue]
> Interested? This could take couple of weeks taking things to real world
> workloads but could provide some insight to community.[/color]
Yeps, but this is not the propper time, and I am not sure if I have the
knowledge what it takes.
[color=blue]
> If you have mysql 4.x and postgresql 7.4beta installed, you can easily setup
> these things..[/color]
Yeps, but how to test ? And how do one test stability :-)

/BL


---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postg resql.org

[Bo Lorentsen]

Re: Buglist

On Tue, 2003-08-19 at 15:47, Shridhar Daithankar wrote:
[color=blue]
> Or have bugzilla setup somewhere. That way the tracking will be hell lot
> visible to outside world..[/color]
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


---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

[Tom Lane]

Re: Buglist

Bo Lorentsen <bl@netgroup.dk > writes:[color=blue]
> On Tue, 2003-08-19 at 14:37, Roderick A. Anderson wrote:[color=green]
>> 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.[/color][/color]
[color=blue]
> But this goes for 3.x have you tried 4.x and there InnoDB tables ?[/color]

It's still bolted on. The entire concept that "transactio nal 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

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

[Lincoln Yeoh]

Re: Buglist

At 03:56 PM 8/19/2003 +0200, Bo Lorentsen wrote:
[color=blue]
>On Tue, 2003-08-19 at 15:45, Shridhar Daithankar wrote:
>[color=green]
> > Well, if you have some time and hardware to play around, I am sure we can
> > easily test them side by side.[/color]
>Interresting project, is this allowed :-)
>[color=green]
> > Interested? This could take couple of weeks taking things to real world
> > workloads but could provide some insight to community.[/color]
>Yeps, but this is not the propper time, and I am not sure if I have the
>knowledge what it takes.[/color]

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.

[color=blue][color=green]
> > If you have mysql 4.x and postgresql 7.4beta installed, you can easily[/color]
> setup[color=green]
> > these things..[/color]
>Yeps, but how to test ? And how do one test stability :-)[/color]

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.




---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

[Lincoln Yeoh]

Re: Buglist

At 03:59 PM 8/19/2003 +0200, Bo Lorentsen wrote:
[color=blue]
>On Tue, 2003-08-19 at 15:47, Shridhar Daithankar wrote:
>[color=green]
> > Or have bugzilla setup somewhere. That way the tracking will be hell lot
> > visible to outside world..[/color]
>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.[/color]

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.

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

[Devrim GUNDUZ]

Re: Buglist


Hi,

On Tue, 19 Aug 2003, Lincoln Yeoh wrote:
[color=blue]
> 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.[/color]

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.o rg devrim.gunduz@l inux.org.tr

http://www.tdmsoft.com

http://www.gunduz.org

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

[Bo Lorentsen]

Re: Buglist

On Tue, 2003-08-19 at 16:03, Tom Lane wrote:
[color=blue]
> It's still bolted on. The entire concept that "transactio nal integrity
> is optional" is ludicrous, IMHO. "Integrity" and "optional" are
> contradictory.[/color]
Good point. Also the problem of MyISAM and InnoDB RI :-)
[color=blue]
> 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.[/color]
Thats a really nice thing for temporary tables, but "point in time"
backup is a much stonger argument :-)

/BL


---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postg resql.org so that your
message can get through to the mailing list cleanly

[Bo Lorentsen]

Re: Buglist

On Tue, 2003-08-19 at 16:20, Lincoln Yeoh wrote:
[color=blue]
> 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.[/color]
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.
[color=blue]
> Do lots of concurrent updates and inserts and selects for a long time?[/color]
I do think I know why you say this :-)
[color=blue]
> Have fun![/color]
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


---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match