Hi,

Does anyone have an idea how risky it is to start using 8.3b1 in
production, with the intention of upgrading to release (or newer beta)
as soon as it becomes available? Risky compared to running a release,
that is. Beta -> release upgrades might be less tricky than 8.2 -> 8.3.

Thank you.

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

rihad <rihad@mail.ru> writes:
> Does anyone have an idea how risky it is to start using 8.3b1 in
> production, with the intention of upgrading to release (or newer beta)
> as soon as it becomes available? Risky compared to running a release,
> that is. Beta -> release upgrades might be less tricky than 8.2 -> 8.3.

At this point you're guaranteed to need a dump/reload between beta1 and
beta2 ...

regards, tom lane

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

http://archives.postgresql.org/

On Wednesday 24 October 2007 09:59:20 rihad wrote:
> Hi,
>
> Does anyone have an idea how risky it is to start using 8.3b1 in
> production, with the intention of upgrading to release (or newer beta)
> as soon as it becomes available? Risky compared to running a release,
> that is. Beta -> release upgrades might be less tricky than 8.2 -> 8.3.
>

I'm pretty sure b2 is going to require a fresh initdb (due to bugs found). So
I'd advice against that.

> Thank you.

jan

>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings



--
--------------------------------------------------------------
Jan de Visser * * * * * * * * * * jdevisser@digitalfairway.com

* * * * * * * * Baruk Khazad! Khazad ai-menu!
--------------------------------------------------------------

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

"rihad" <rihad@mail.ru> writes:

> Hi,
>
> Does anyone have an idea how risky it is to start using 8.3b1 in production,
> with the intention of upgrading to release (or newer beta) as soon as it
> becomes available? Risky compared to running a release, that is. Beta ->
> release upgrades might be less tricky than 8.2 -> 8.3.

Well nobody's going to be able to guess at what problems haven't been found
yet. All we can say decisively is what bugs have already been found:

.. On Windows UTF8 encoding isn't allowed

.. VACUUM does an unnecessarily large amount of I/O

.. Toaster could cause failures on machines with strict alignment

.. Resources limits in Windows limit the number of clients

.. pg_tablespace_size() on pg_global fails even for superuser

.. ABI break with old libpq for applications which depend on encoding IDs
(such as initdb -- you can't run initdb with an 8.2 libpq against an 8.3 server)

.. invalid tsvector input could cause crashes

.. ALTER COLUMN TYPE would reset the index's options, possibly moving it to the
default tablespace or worse

Also:

.. A new data type, txid, was added

.. Several new contrib modules were added to aid tsearch migration

.. Some tsearch functions were removed or modified

.. tsearch word categories were redefined and renamed

.. Make plan invalidation work for dropped sequences (etc)

.. Be careful to get share lock on each page before computing its free space.

.. This avoids useless checkpoint activity if XLogWrite is executed when we
have a very stale local copy of RedoRecPtr.

.. Teach planagg.c that partial indexes specifying WHERE foo IS NOT NULL can be
used to perform MIN(foo) or MAX(foo)

.. Remove an Assert that's been obsoleted by recent changes in the parsetree
representation of DECLARE CURSOR. Report and fix by Heikki.

.. Ensure that the result of evaluating a function during constant-expression
simplification gets detoasted before it is incorporated into a Const node.

.. Make dumpcolors() have tolerable performance when using 32-bit chr, as we do

.. Make "role is not permitted to log in" errors not be hidden

.. Remove quotes around locale names in some places for consistency.

.. Add missing entry for PG_WIN1250 encoding, per gripe from Pavel Stehule.
Also enable translation of PG_WIN874

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

On 24/10/2007, Gregory Stark <stark@enterprisedb.com> wrote:
>
> "rihad" <rihad@mail.ru> writes:
>
> > Hi,
> >
> > Does anyone have an idea how risky it is to start using 8.3b1 in
> production,
> > with the intention of upgrading to release (or newer beta) as soon as it
> > becomes available? Risky compared to running a release, that is. Beta ->
> > release upgrades might be less tricky than 8.2 -> 8.3.
>
> Well nobody's going to be able to guess at what problems haven't been
> found
> yet. All we can say decisively is what bugs have already been found:
>
> . On Windows UTF8 encoding isn't allowed
>
> . VACUUM does an unnecessarily large amount of I/O
>
> . Toaster could cause failures on machines with strict alignment
>
> . Resources limits in Windows limit the number of clients
>
> . pg_tablespace_size() on pg_global fails even for superuser
>
> . ABI break with old libpq for applications which depend on encoding IDs
> (such as initdb -- you can't run initdb with an 8.2 libpq against an 8.3server)
>
> . invalid tsvector input could cause crashes
>
> . ALTER COLUMN TYPE would reset the index's options, possibly moving it to
> the
> default tablespace or worse
>
> Also:
>
> . A new data type, txid, was added
>
> . Several new contrib modules were added to aid tsearch migration
>
> . Some tsearch functions were removed or modified
>
> . tsearch word categories were redefined and renamed
>
> . Make plan invalidation work for dropped sequences (etc)
>
> . Be careful to get share lock on each page before computing its free
> space.
>
> . This avoids useless checkpoint activity if XLogWrite is executed when we
> have a very stale local copy of RedoRecPtr.
>
> . Teach planagg.c that partial indexes specifying WHERE foo IS NOT NULL
> can be
> used to perform MIN(foo) or MAX(foo)
>
> . Remove an Assert that's been obsoleted by recent changes in the
> parsetree
> representation of DECLARE CURSOR. Report and fix by Heikki.
>
> . Ensure that the result of evaluating a function during
> constant-expression
> simplification gets detoasted before it is incorporated into a Const
> node.
>
> . Make dumpcolors() have tolerable performance when using 32-bit chr, as
> we do
>
> . Make "role is not permitted to log in" errors not be hidden
>
> . Remove quotes around locale names in some places for consistency.
>
> . Add missing entry for PG_WIN1250 encoding, per gripe from Pavel Stehule.
> Also enable translation of PG_WIN874


Hmm looks like December release might be a dream then....

I was wondering why my PITR base back up was taking 2 hours on my 8.3 test
database where as it takes 50 minutes on 8.1 and the database files are
meant to be smaller on a freshly installed 8.3 server rather than a
8.1.1server that aint been rebuilt since
8.1.1 was newly out.
I was planning to upgrade to 8.3 once its out...

Down time for upgrades is somwhat lacking in a 24x7 business.

Oh my 8.1 server has been up for well over a year with out being down at
all. the database for longer which really show how good postgres really is
377 days uptime on computer and I think that was to move a plug.


Peter Childs

On 10/25/07, Peter Childs <peterachilds@gmail.com> wrote:
> I was wondering why my PITR base back up was taking 2 hours on my 8.3 test
> database where as it takes 50 minutes on 8.1 and the database files are
> meant to be smaller on a freshly installed 8.3 server rather than a 8.1.1
> server that aint been rebuilt since 8.1.1 was newly out.
> I was planning to upgrade to 8.3 once its out...
>
> Down time for upgrades is somwhat lacking in a 24x7 business.
>
> Oh my 8.1 server has been up for well over a year with out being down at
> all. the database for longer which really show how good postgres really is
> 377 days uptime on computer and I think that was to move a plug.

You should really look at scheduling the 5 minute window up update
your 8.1 install. 8.1.1 is quite old and has a few known data eating
bugs, if I remember correctly. Updating to 8.1.10 should only take
literally about 1 or 2 minutes.

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

"Scott Marlowe" <scott.marlowe@gmail.com> writes:

> On 10/25/07, Peter Childs <peterachilds@gmail.com> wrote:
>> I was wondering why my PITR base back up was taking 2 hours on my 8.3 test
>> database where as it takes 50 minutes on 8.1 and the database files are
>> meant to be smaller on a freshly installed 8.3 server rather than a 8.1.1
>> server that aint been rebuilt since 8.1.1 was newly out.
>> I was planning to upgrade to 8.3 once its out...
>>
>> Down time for upgrades is somwhat lacking in a 24x7 business.
>>
>> Oh my 8.1 server has been up for well over a year with out being down at
>> all. the database for longer which really show how good postgres really is
>> 377 days uptime on computer and I think that was to move a plug.
>
> You should really look at scheduling the 5 minute window up update
> your 8.1 install. 8.1.1 is quite old and has a few known data eating
> bugs, if I remember correctly. Updating to 8.1.10 should only take
> literally about 1 or 2 minutes.

Actually 8.1.2 fixed two locale problems which could require reindexing. If
you're using plperl functions which play with the locale or a locale like
hungarian which compares some different strings as equal then you might have
to reindex.

Otherwise it's just a Postgres server restart's worth of downtime. There are
both data eating bug fixes and security fixes in 8.1.10 for you.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

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