On Thu, 17 Apr 2008 11:29:56 -0700
"Joshua D. Drake" <jd@commandprompt.com> wrote:

> Hello,
>
> I am currently chilling at MySQLCon. If any other Elephant riders
> who are doing a little Dolphin hunting are about... I am in
> Ballroom E about to give a talk on what Mysql can learn from
> PostgreSQL.

Is your presentation available online at all?

Hope it goes well,

Josh

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

On Thu, 17 Apr 2008 22:19:23 -0500
Josh Trutwin <josh@trutwins.homeip.net> wrote:

> Is your presentation available online at all?

Blogging the bad boy up right now.... Will be available soon.

Joshua D. Drake



--
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL SPI Liaison | SPI Director | PostgreSQL political pundit


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFICBTBATb/zqfZUUQRAt26AJ4t7WE4X6kjG+VgmIjtXzf8YtwpOgCdHEOL
Al++vSaAGESrt581aEr5sPs=
=TP6d
-----END PGP SIGNATURE-----

jd@commandprompt.com ("Joshua D. Drake") writes:
> On Thu, 17 Apr 2008 22:19:23 -0500
> Josh Trutwin <josh@trutwins.homeip.net> wrote:
>
>> Is your presentation available online at all?
>
> Blogging the bad boy up right now.... Will be available soon.

The presentation seems pretty good...

.... But what is more interesting is what was the reaction?

I note in the blog that the "in place upgrade" issue came up.
(Interesting to observe that it *also* came up pretty prominently in
the intro session at PG East... This is obviously a matter of Not
Inconsiderable Interest...) It would be nice to hear what other
things got a reaction. Of course, some of that may be yet to arrive,
as there are doubtless conversations yet to happen!
--
"cbbrowne","@","cbbrowne.com"
http://www3.sympatico.ca/cbbrowne/spiritual.html
FLORIDA: We've been Gored by the bull of politics and we're Bushed.

On Friday 18 April 2008, Chris Browne <cbbrowne@acm.org> wrote:
> I note in the blog that the "in place upgrade" issue came up.
> (Interesting to observe that it *also* came up pretty prominently in
> the intro session at PG East... This is obviously a matter of Not
> Inconsiderable Interest...)

Upgrades are certainly the biggest PostgreSQL operational issue for me.

Uhh, boss, I need to bring the database down for 3 days to do an upgrade.
Yes, that means clients can't do anything during that time. Boss - !!@#@#$#

Hence why I'm still running 8.1 ....

--
Alan

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Alan Hodgson wrote:
> On Friday 18 April 2008, Chris Browne <cbbrowne@acm.org> wrote:
>> I note in the blog that the "in place upgrade" issue came up.
>> (Interesting to observe that it *also* came up pretty prominently in
>> the intro session at PG East... This is obviously a matter of Not
>> Inconsiderable Interest...)
>
> Upgrades are certainly the biggest PostgreSQL operational issue for me.
>
> Uhh, boss, I need to bring the database down for 3 days to do an upgrade.
> Yes, that means clients can't do anything during that time. Boss - !!@#@#$#
>
> Hence why I'm still running 8.1 ....

What about the:

8.1 -> slony -> 8.3
switch users to 8.3 databases

solution.

--
Until later, Geoffrey

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety.
- Benjamin Franklin

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

On Fri, 18 Apr 2008 13:54:52 -0400
Geoffrey <lists@serioustechnology.com> wrote:

> What about the:
>
> 8.1 -> slony -> 8.3
> switch users to 8.3 databases
>
> solution.

Is it? What is your transactional velocity? How long will the initial
sync transaction have to run? You know vacuum isn't working while
that transaction is open right? Are you going to have to setup up a
dozen different replicated sets in order to get it done?

Slony works in "some" cases it does not work in all nor the most
critical (in terms of large sets with minimal downtime requirement).

Sincerely,

Joshua D. Drake

--
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate



--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Joshua D. Drake wrote:
> On Fri, 18 Apr 2008 13:54:52 -0400
> Geoffrey <lists@serioustechnology.com> wrote:
>
>> What about the:
>>
>> 8.1 -> slony -> 8.3
>> switch users to 8.3 databases
>>
>> solution.
>
> Is it? What is your transactional velocity? How long will the initial
> sync transaction have to run? You know vacuum isn't working while
> that transaction is open right? Are you going to have to setup up a
> dozen different replicated sets in order to get it done?
>
> Slony works in "some" cases it does not work in all nor the most
> critical (in terms of large sets with minimal downtime requirement).

I don't know that slony is the answer. It was more of a question then
an answer. We are hoping to use that solution to migrate from 7.4.19 to
8.3.1. The primary reason is to reduce downtime.

--
Until later, Geoffrey

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety.
- Benjamin Franklin

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

On Fri, 18 Apr 2008 14:30:18 -0400
Geoffrey <lists@serioustechnology.com> wrote:

> I don't know that slony is the answer. It was more of a question
> then an answer. We are hoping to use that solution to migrate from
> 7.4.19 to 8.3.1. The primary reason is to reduce downtime.

Well That is why I asked the questions I did. It very well may be
the answer. It might not. For example, what size is your database? How
many transactions per hour are you doing?

Sincerely,

Joshua D. Drake


--
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate



--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Joshua D. Drake wrote:
> On Fri, 18 Apr 2008 14:59:34 -0400
> Alvaro Herrera <alvherre@commandprompt.com> wrote:
>
> > I find it pretty unlikely that Slony would be unable to help you
> > upgrade here. Obviously you can upgrade one database at a time.
> >
> > Also, mostly it's not the database size what's a concern, but rather
> > the size of the largest table.
>
> As I recall (I could be wrong) Slony syncs the whole set as a single
> transaction. So if he has his entire database as a set he may
> have a problem regardless of the largest or smallest table.

Yes, if he does that then you are right, but it's unlikely to be the
best idea.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Geoffrey wrote:

> I'm really not altogether sure what you mean by transaction velocity.
> I'm pretty sure the electrons are traveling pretty close to the speed of
> light.

Actually, electrons themselves flow rather slowly -- millimeters per
second according to Wikipedia. The signal propagation is a bit faster:
"typically 75% of light speed", Wikipedia again.

Anyway, he means "transaction rate". But the actual useful figure is
further removed from that because we're mostly only interested in write
transactions, not read-only (though those still have an effect in
versions earlier than 8.3.)

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general