473,883 Members | 1,527 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

State of Beta 2


Anyone out there using beta 2 in production situations? Comments on
stability? I am rolling out a project in the next 4 weeks, and really
don't want to go though an upgrade soon after its released on an
Unsuspecting Client, so I would LIKE to start working with 7.4.

--------------------

Andrew Rawnsley
President
The Ravensfield Digital Resource Group, Ltd.
(740) 587-0114
www.ravensfield.com
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddres sHere" to ma*******@postg resql.org)

Nov 11 '05
236 10127
Manfred Koizar <mk*****@aon.at > writes:
I tend to believe that every code change or new feature that gets
implemented is unique by its nature, and if it involves catalog
changes it requires a unique upgrade script/tool. How should a
generic tool guess the contents of a new catalog relation?
*It does not have to*. Perhaps you should go back and study what
pg_upgrade actually did. It needed only minimal assumptions about the
format of either old or new catalogs. The reason is that it mostly
relied on portability work done elsewhere (in pg_dump, for example).
Rod's adddepend is a good example.
adddepend was needed because it was inserting knowledge not formerly
present. I don't think it's representative. Things we do more commonly
involve refactoring information --- for example, changing the division
of labor between pg_aggregate and pg_proc, or adding pg_cast to replace
what had been some hard-wired parser behavior.
... I wouldn't call it perfect (for example, I still don't know how
to insert the new table into template0),


.... in other words, it doesn't work and can't be made to work.

pg_upgrade would be a one-time solution for a fairly wide range of
upgrade problems. I don't want to get into developing custom solutions
for each kind of catalog change we might want to make. That's not a
productive use of time.

regards, tom lane

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

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

Nov 11 '05 #181
Manfred Koizar <mk*****@aon.at > writes:
Elsewhere in this current thread it has been suggested that the
on-disk format will stabilize at some time in the future and should
then be frozen to ensure painless upgrades. IMHO, at the moment when
data structures are declared stable and immutable the project is dead.
This is something that concerns me also.
A working pg_upgrade is *not* the first thing we need.
Yes it is. As you say later,
... But once the infrastructure is in place, things
should get easier.


Until we have a working pg_upgrade, every little catalog change will
break backwards compatibility. And I do not feel that the appropriate
way to handle catalog changes is to insist on one-off solutions for each
one. Any quick look at the CVS logs will show that minor and major
catalog revisions occur *far* more frequently than changes that would
affect on-disk representation of user data. If we had a working
pg_upgrade then I'd be willing to think about committing to "no user
data changes without an upgrade path" as project policy. Without it,
any such policy would simply stop development in its tracks.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddres sHere" to ma*******@postg resql.org)

Nov 11 '05 #182


On Fri, 19 Sep 2003, Tom Lane wrote:
Manfred Koizar <mk*****@aon.at > writes:
Elsewhere in this current thread it has been suggested that the
on-disk format will stabilize at some time in the future and should
then be frozen to ensure painless upgrades. IMHO, at the moment when
data structures are declared stable and immutable the project is dead.


This is something that concerns me also.


But, is there anything wrong with striving for something you mentioned
earlier ... "spooling" data structure changes so that they don't happen
every release, but every other one, maybe?
... But once the infrastructure is in place, things
should get easier.


Until we have a working pg_upgrade, every little catalog change will
break backwards compatibility. And I do not feel that the appropriate
way to handle catalog changes is to insist on one-off solutions for each
one. Any quick look at the CVS logs will show that minor and major
catalog revisions occur *far* more frequently than changes that would
affect on-disk representation of user data. If we had a working
pg_upgrade then I'd be willing to think about committing to "no user
data changes without an upgrade path" as project policy. Without it,
any such policy would simply stop development in its tracks.


hmmm ... k, is it feasible to go a release or two at a time without on
disk changes? if so, pg_upgrade might not be as difficult to maintain,
since, unless someone an figure out a way of doing it, 'on disk change
releases' could still require dump/reloads, with a period of stability in
between?

*Or* ... as we've seen more with this dev cycle then previous ones, how
much could be easily back-patched to the previous version(s) relatively
easily, without requiring on-disk changes?

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

Nov 11 '05 #183
"Joshua D. Drake" <jd@commandprom pt.com> writes:
The reality of pg_dump is not a good one. It is buggy and not very
reliable.
I think everyone acknowledges that we have more work to do on pg_dump.
But we have to do that work anyway. Spreading ourselves thinner by
creating a whole new batch of code for in-place upgrade isn't going to
improve the situation. The thing I like about the pg_upgrade approach
is that it leverages a lot of code we already have and will need to
continue to maintain in any case.

Also, to be blunt: if pg_dump still has problems after all the years
we've put into it, what makes you think that in-place upgrade will
magically work reliably?
This I am hoping
changes in 7.4 as we moved to a pure "c" implementation.


Eh? AFAIR, pg_dump has always been in C.

regards, tom lane

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

http://archives.postgresql.org

Nov 11 '05 #184
On Sat, 2003-09-20 at 11:17, Tom Lane wrote:
"Marc G. Fournier" <sc*****@postgr esql.org> writes:
No, I'm not suggesting no catalog changes ... wait, I might be wording
this wrong ... there are two changes that right now requires a
dump/reload, changes to the catalogs and changes to the data structures,
no? Or are these effectively inter-related?


Oh, what you're saying is no changes in user table format. Yeah, we


Whew, we're finally on the same page!

So, some definitions we can agree on?
"catalog change": CREATE or ALTER a pg_* table.
"on-disk structure", a.k.a. "user table format": the way that the
tables/fields are actually stored on disk.

So, a catalog change should *not* require a dump/restore, but an
ODS/UTF change should.

Agreed?

--
-----------------------------------------------------------------
Ron Johnson, Jr. ro***********@c ox.net
Jefferson, LA USA

"they love our milk and honey, but preach about another way of living"
Merle Haggard, "The Fighting Side Of Me"
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Nov 11 '05 #185


On Sat, 20 Sep 2003, Ron Johnson wrote:
On Sat, 2003-09-20 at 11:17, Tom Lane wrote:
"Marc G. Fournier" <sc*****@postgr esql.org> writes:
No, I'm not suggesting no catalog changes ... wait, I might be wording
this wrong ... there are two changes that right now requires a
dump/reload, changes to the catalogs and changes to the data structures,
no? Or are these effectively inter-related?


Oh, what you're saying is no changes in user table format. Yeah, we


Whew, we're finally on the same page!

So, some definitions we can agree on?
"catalog change": CREATE or ALTER a pg_* table.
"on-disk structure", a.k.a. "user table format": the way that the
tables/fields are actually stored on disk.

So, a catalog change should *not* require a dump/restore, but an
ODS/UTF change should.


As long as pg_update is updated/tested for this, yes, that is what the
thought is ... but, that still requires someone(s) to step up and work
on/maintain pg_upgrade for this to happen ... all we are agreeing to right
now is implement a policy whereby maintaining pg_upgrade is *possible*,
not one where maintaining pg_upgrade is *done* ...
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Nov 11 '05 #186
On Fri, 2003-09-19 at 06:37, Christopher Browne wrote:
ro***********@c ox.net (Ron Johnson) wrote:
On Thu, 2003-09-18 at 16:29, Andrew Sullivan wrote:
On Sat, Sep 13, 2003 at 10:52:45AM -0500, Ron Johnson wrote:

> So instead of 1TB of 15K fiber channel disks (and the requisite
> controllers, shelves, RAID overhead, etc), we'd need *two* TB of
> 15K fiber channel disks (and the requisite controllers, shelves,
> RAID overhead, etc) just for the 1 time per year when we'd upgrade
> PostgreSQL?

Nope. You also need it for the time when your vendor sells
controllers or chips or whatever with known flaws, and you end up
having hardware that falls over 8 or 9 times in a row.
????


This of course never happens in real life; expensive hardware is
_always_ UTTERLY reliable.

And the hardware vendors all have the same high standards as, well,
certain database vendors we might think of.

After all, Oracle and MySQL AB would surely never mislead their
customers about the merits of their database products any more than
HP, Sun, or IBM would about the possibility of their hardware having
tiny flaws.


Well, I use Rdb, so I wouldn't know about that!

(But then, it's an Oracle product, and runs on HPaq h/w...)
And I would /never/ claim to have lost sleep as a result of flakey
hardware. Particularly not when it's a HA fibrechannel array. I'm
/sure/ that has never happened to anyone. [The irony herre should be
causing people to say "ow!"]


Sure, I've seen expensive h/e flake out. It was the "8 or 9 times
in a row" that confused me.

--
-----------------------------------------------------------------
Ron Johnson, Jr. ro***********@c ox.net
Jefferson, LA USA

The difference between drunken sailors and Congressmen is that
drunken sailors spend their own money.
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Nov 11 '05 #187
> No can do, unless your intent is to force people to work on pg_upgrade
and nothing else (a position I for one would ignore ;-)). With such a
policy and no pg_upgrade we'd be unable to apply any catalog changes at
all, which would pretty much mean that 7.5 would look exactly like 7.4.


Not sure about your position here. You claimed that it would be a good idea to
freeze the on disk format for at least a couple of versions. Do you argue
here that this cycle shouldn't start with the next version, or did you
reverse your thought ?

If the former, I think you're right. There are some too big changes close to
being made - if I have read this list correctly. Table spaces and PITR would
certainly change it.

But if the freeze could start after 7.5 and last two-three years, it might
help things.

--
Kaare Rasmussen --Linux, spil,-- Tlf: 3816 2582
Kaki Data tshirts, merchandize Fax: 3816 2501
Howitzvej 75 Åben 12.00-18.00 Email: ka*@kakidata.dk
2000 Frederiksberg Lørdag 12.00-16.00 Web: www.suse.dk

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

Nov 11 '05 #188
Kaare Rasmussen <ka*@kakidata.d k> writes:
Not sure about your position here. You claimed that it would be a good idea to
freeze the on disk format for at least a couple of versions.
I said it would be a good idea to freeze the format of user tables (and
indexes) across multiple releases. That's distinct from the layout and
contents of system catalogs, which are things that we revise constantly.
We could not freeze the system catalogs without blocking development
work, and we should not make every individual catalog change responsible
for devising its own in-place-upgrade scheme either. We need some
comprehensive tool for handling catalog upgrades automatically. I think
pg_upgrade points the way to one fairly good solution, though I'd not
rule out other approaches if someone has a bright idea.

Clear now?
Do you argue here that this cycle shouldn't start with the next
version,


I have not said anything about that in this thread. Now that you
mention it, I do think it'd be easier to start with the freeze cycle
after tablespaces are in place. On the other hand, tablespaces might
not appear in 7.5 (they already missed the boat for 7.4). And
tablespaces are something that we could expect pg_upgrade to handle
without a huge amount more work. pg_upgrade would already need to
contain logic to determine the mapping from old-installation user table
file names to new-installation ones, because the table OIDs would
normally be different. Migrating to tablespaces simply complicates that
mapping somewhat. (I am assuming that tablespaces won't affect the
contents of user table files, only their placement in the Unix directory
tree.)

I think a reasonable development plan is to work on pg_upgrade assuming
the current physical database layout (no tablespaces), and concurrently
work on tablespaces. The eventual merge would require teaching
pg_upgrade about mapping old to new filenames in a tablespace world.
It should only be a small additional amount of work to teach it how to
map no-tablespaces to tablespaces.

In short, if people actually are ready to work on pg_upgrade now,
I don't see any big reason not to let them ...

regards, tom lane

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

Nov 11 '05 #189
Manfred Koizar wrote:
On Thu, 18 Sep 2003 12:11:18 -0400, Lamar Owen <lo***@pari.edu > wrote:
Marc G. Fournier wrote:
[...] upgrading is a key feature [...]
a migration tool
that could read the old format _without_a_runn ing_old_backend _ [...]
the new backend is powerless to recover the old data.
OS upgrades [...], FreeBSD ports upgrades, and RPM
upgrades are absolutely horrid at this point. [...]
[censored] has a better system than we
[...] the pain of upgrading [...]
*I* should complain about a ramble? :-)
Lamar, I *STRONGLY* agree with almost everything you say here and in
other posts, except perhaps ... You et al. seem to think that system catalog changes wouldn't be a
problem if only we could avoid page format changes. This is not
necessarily so. Page format changes can be handled without much
effort, if
No, I'm aware of the difference, and I understand the issues with
catalog changes. Tom and I, among others, have discussed this. We
talked about reorganizing the system catalog to separate the data that
typically changes with a release from the data that describes the user's
tables. It is a hard thing to do, separating this data.
Oh, that's me, I think. I am to blame for the heap tuple header
changes between 7.2 and 7.3;
It has happened at more than one version change, not just 7.2->7.3. I
actually was thinking about a previous flag day. So the plural still
stands.
Later, in your "Upgrading rant" thread, I even posted some code
(http://archives.postgresql.org/pgsql.../msg00294.php).
Unfortunately this went absolutely unnoticed, probably because it
looked so long because I fat-fingered the mail and included the code
twice. :-(
I don't recall that, but I believe you. My antivirus software may have
flagged it if it had more than one . in the file name. But I may go
back and look at it. Again, I wasn't fingering 7.2->7.3 -- it has
happened more than once prior to that.
A working pg_upgrade is *not* the first thing we need. What we need
first is willingness to not break backwards compatibility.


To this I agree. But it must be done in stages, as Tom, Marc, and
others have already said (I read the rest of the thread before replying
to this message). We can't simply declare a catalog freeze (which you
didn't do, I know), nor can we declare an on-disk format change freeze.
We need to think about what is required to make upgrades easy, not
what is required to write a one-off upgrade tool (which each version of
pg_upgrade ends up being). Can the system catalog be made more
friendly? Is upgrading by necessity a one-step process (that is, can we
stepwise migrate tables as they are used/upgraded individually)? Can we
decouple the portions of the system catalogs that change from the
portions that give basic access to the user's data? That is, what would
be required to allow a backend to read old data tables? An upgrade tool
is redundant if the backend is version agnostic and version aware.

Look, my requirements are simple. I should be able to upgrade the
binaries and not lose access to my data. That's the bottom line.
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute

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

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

Nov 11 '05 #190

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

0
2393
by: Eric Raymond | last post by:
When installing the rpms (or the tar file) onto Red Hat Enteprise Linux AS Beta 1 (Taroon), we get the follwing error: Installing all prepared tables /usr/bin/mysql_install_db: line 1: 7690 Segmentation fault /usr/sbin/mysqld --bootstrap --skip-grant-tables --basedir=/ --datadir=/var/lib/mysql --skip-innodb --skip-bdb Installation of grant tables failed The log file simply shows a start and a stop of the server.
1
389
by: Andrew Rawnsley | last post by:
Anyone out there using beta 2 in production situations? Comments on stability? I am rolling out a project in the next 4 weeks, and really don't want to go though an upgrade soon after its released on an Unsuspecting Client, so I would LIKE to start working with 7.4. -------------------- Andrew Rawnsley President The Ravensfield Digital Resource Group, Ltd.
4
2349
by: Chad Crowder | last post by:
I've taken a look at this article http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspnet/html/asp12282000.asp which someone posted a month or so ago regarding setting up SQL server to handle state data. The article references .Net beta, and the file state.sql in the framwork/1.0x directory, but that file doesn't exist for version 1.1.4322. I'm wondering if there's a component that I need to install, or if I need to...
0
1462
by: Kevin Davidson | last post by:
I am trying to get a clean installation of the .NET framework 1.1 on Windows 2000 Professional. I had previously installed a beta of the 2.0 Framework and uninstalled it. I also uninstalled framework 1.1 and 1.0 and reinstalled 1.1 and service pack 1. When I attempt to start the ASP.NET State Service, I get event log: Event Type: Error Event Source: Service Control Manager Event Category: None
1
3001
by: alundi | last post by:
Greetings: I'd like to post this as a new thread to an article in microsoft.public.dotnet.languages.vb originally made by nevin and replied to by Alan Pretre back in December ("ThreadState == not in the enumeration"). Like nevin, I have a VB.NET multi-threaded application, and quite frequently, after my main application class will call Thread.Suspend() on the thread the ThreadState of the Suspended Thread will be a value of 96. From...
0
1004
by: Shell | last post by:
Hi All, We have an application that uses SQL Server 2000 for State Management data. We previously use to build and deploy this application using ASP.NET Beta 2 version. Now we are using ASP.NET RTM version.With that, we are able to build & deploy the application successfully. But it gives us the error "The Session State information is valid or might be corrupted." while retrieving data from SQL Server. We can see the data stored...
8
2263
by: Steve Thompson | last post by:
Hello all, I was wondering the differnced there were betwee Active State's python and the open source version of python. Would I have to unistall my opend souce python? Additonally, how does Active State's Komodo IDE vs. the eric3 IDE unler SuSE Linux v. 10.i? Addionally, is the eric IDE (version 3) an acceptible IDE or are there more easy and more productive IDE's for perl?
3
8719
by: Nathan Sokalski | last post by:
I am recieving the following error on the second postback of a page I have written: The state information is invalid for this page and might be corrupted Stack Trace: System.Convert.FromBase64String(String s) +0
70
4368
by: Anson.Stuggart | last post by:
I'm designing a debounce filter using Finite State Machine. The FSM behavior is it follows the inital input bit and thinks that's real output until it receives 3 consecutive same bits and it changes output to that 3 consecutive bit until next 3 consecutive bits are received. A reset will set the FSM to output 1s until it receives the correct input and ouput. This is the test sequence with input and correct output. 1 0 0 1 0 1 0 0 0 1...
0
9936
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look ! Part I. Meaning of...
0
9791
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
0
11137
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. Here is my compilation command: g++-12 -std=c++20 -Wnarrowing bit_field.cpp Here is the code in...
0
10742
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
0
9571
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
1
7970
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
0
7123
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert into image. Globals.ThisAddIn.Application.ActiveDocument.Select();...
1
4609
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
2
4215
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.