On Wed, 18 Jun 2008, Sam Mason wrote:
What I'd try doing is this: find a 8.1 version of PG (8.1.4 or later) and
run this against the data you saved off, once this is running you can then
run 8.3's version of pg_dump against it, then you can restore this dump
into the new version of PG.
Sam,
On Wed, Jun 18, 2008 at 08:48:41AM -0700, Rich Shepard wrote:
> while I'm glad to learn more than I knew before how to go about
> making backups and upgrading the PostgreSQL installation, having folks
> telling me all I did incorrectly is not as helpful to me as guidance on
> getting the cluster
On Wed, 18 Jun 2008, Alan Hodgson wrote:
If the database was in use when _that_ backup was taken, it may also not
be usable.
You can't just backup a live database from the filesystem level and expect
it to work ...
Alan,
The only database in the cluster that has seen any use recently is th
Alan Hodgson wrote:
On Wednesday 18 June 2008, Craig Ringer <[EMAIL PROTECTED]> wrote:
Every file from /var/lib/pgsql/ before I started this is on the
weekly backup tape from last Friday night. If need be I can restore
from that and start over.
Well, no worries then. I'm sure you can understa
On Wednesday 18 June 2008, Craig Ringer <[EMAIL PROTECTED]> wrote:
> > Every file from /var/lib/pgsql/ before I started this is on the
> > weekly backup tape from last Friday night. If need be I can restore
> > from that and start over.
>
> Well, no worries then. I'm sure you can understand that
Rich Shepard wrote:
> According to the cp man page here, 'cp -a' is equivalent to 'cp -dpR'.
You're quite right. I was thinking "aah, a BSD-ism" but no, it's true
for Linux too. Sorry.
>>select pg_start_backup('migrate');
>>
>> or similar before starting the copy then you're going to have
On Tue, 17 Jun 2008, Adrian Klaver wrote:
Define nothing. When you ran initdb there where no messages? Also when in
doubt I use the full path /var/lib/pgsql/bin/initdb as you have an old
version of initdb present in the old version directory you copied. When
you have two versions present at the
On Wed, 18 Jun 2008, Klint Gore wrote:
Make sure that initdb is the version you want
initdb --version
Klint,
Yes, it is: 8.3.
then
initdb -E UTF8 -D /var/lib/pgsql/data
then post the output of that.
Very interesting. While en_US is not accepted, UTF8 is.
[EMAIL PROTECTED]:/var/lib/
On Wed, 18 Jun 2008, Craig Ringer wrote:
I hope you mean cp -aR , because you need those subdirectories if you're
ever going to try to use the _old copy. Even if you actually did a
recursive copy, if you really copied the data directories with the DB
server running and without executing:
Craig
Klint Gore wrote:
> Rich Shepard wrote:
>>Despite trying to be careful, I managed to mess up the upgrade from
>> -8.1.4
>> to -8.3.3 on my Slackware-11.0 server/workstation. I expect that someone
>> here will see my error and point me in the right direction to recover a
>> working dbms.
>>
>>
Rich Shepard wrote:
On Wed, 18 Jun 2008, Klint Gore wrote:
>>5.) Built postgresql-8.3.3 using the SlackBuild script, then ran
>> 'upgradepkg postgresql-8.3.3*tgz'; other than reporting not finding an
>> expected pid file, that went smoothly.
>>
> Is there an initdb in here somewhere? Or is
On Tuesday 17 June 2008 7:18 pm, Rich Shepard wrote:
> On Wed, 18 Jun 2008, Klint Gore wrote:
> >>5.) Built postgresql-8.3.3 using the SlackBuild script, then ran
> >> 'upgradepkg postgresql-8.3.3*tgz'; other than reporting not finding an
> >> expected pid file, that went smoothly.
> >
> > Is t
On Wed, 18 Jun 2008, Klint Gore wrote:
5.) Built postgresql-8.3.3 using the SlackBuild script, then ran
'upgradepkg postgresql-8.3.3*tgz'; other than reporting not finding an
expected pid file, that went smoothly.
Is there an initdb in here somewhere? Or is the 8.3 server trying to start
w
On Wed, 18 Jun 2008, Klint Gore wrote:
You copied the files without stopping the database? move 4 to 2.
Klint,
Yes, actually. There was no activity on any of the databases.
Is there an initdb in here somewhere? Or is the 8.3 server trying to start
with an 8.1 file structure?
Ah, yes
Rich Shepard wrote:
Despite trying to be careful, I managed to mess up the upgrade from -8.1.4
to -8.3.3 on my Slackware-11.0 server/workstation. I expect that someone
here will see my error and point me in the right direction to recover a
working dbms.
Here's what I did:
1.) As a user
Despite trying to be careful, I managed to mess up the upgrade from -8.1.4
to -8.3.3 on my Slackware-11.0 server/workstation. I expect that someone
here will see my error and point me in the right direction to recover a
working dbms.
Here's what I did:
1.) As a user, I ran pg_dumpall on ve
On Wed, Jan 19, 2005 at 07:39:29AM -0700, Michael Garriss wrote:
> We had a significant production outage with a box running 8.0 Beta 4,
> 140GB data, 190GB index. We think it was a bad RAID controller card.
> Our transaction logs are gone but we have raw data.
>
> How can we recover this data
We had a significant production outage with a box running 8.0 Beta 4,
140GB data, 190GB index. We think it was a bad RAID controller card.
Our transaction logs are gone but we have raw data.
How can we recover this data? Can the transaction logs be reset? Can
we safely set this zero_damaged
18 matches
Mail list logo
