When I start the postmaster it seems ok. But there is no process
running.
Then it didn't really start successfully. (Unless you use the -w
option, "pg_ctl start" just launches the postmaster --- it doesn't
wait around to see what happens.) You need to look into the log
file to see what the pro
On Thu, Jan 24, 2008 at 05:41:20PM +0100, Stefan Schwarzer wrote:
> What would you recommend now in order to get the data back? I have
> postgis data in the databases too, although this is not too important
> for me...
pg_dump, pg_dumpall...
Have a nice day,
--
Martijn van Oosterhout <[EMA
On Jan 24, 2008 10:41 AM, Stefan Schwarzer
<[EMAIL PROTECTED]> wrote:
> >> When I start the postmaster it seems ok. But there is no process
> >> running.
> >
> > Then it didn't really start successfully. (Unless you use the -w
> > option, "pg_ctl start" just launches the postmaster --- it doesn't
On Thu, Jan 24, 2008 at 05:10:51PM +0100, Stefan Schwarzer wrote:
> Oh, stupid me! Gush, I'll never learn it...
>
> But nevertheless:
>
> When I start the postmaster it seems ok. But there is no process
> running. When I try to stop it it says:
>
> pg_ctl: PID file "/usr/local/pgsql/data/postm
When I start the postmaster it seems ok. But there is no process
running.
Then it didn't really start successfully. (Unless you use the -w
option, "pg_ctl start" just launches the postmaster --- it doesn't
wait around to see what happens.) You need to look into the log
file to see what the pro
Stefan Schwarzer <[EMAIL PROTECTED]> writes:
> When I start the postmaster it seems ok. But there is no process
> running.
Then it didn't really start successfully. (Unless you use the -w
option, "pg_ctl start" just launches the postmaster --- it doesn't
wait around to see what happens.) You n
On Jan 24, 2008, at 4:41 PM, Tom Lane wrote:
Stefan Schwarzer <[EMAIL PROTECTED]> writes:
After running initdb the postmaster started smoothly. I stopped it,
copied my database files into the same location, started the
postmaster again, and then got this error message:
schwarzers-mac-mini:/
Stefan Schwarzer <[EMAIL PROTECTED]> writes:
> After running initdb the postmaster started smoothly. I stopped it,
> copied my database files into the same location, started the
> postmaster again, and then got this error message:
> schwarzers-mac-mini:/usr/local/pgsql schwarzer$ /usr/lo
As for the real problem (on the same hardware), when you rebuilt
Postgres on your new machine did you change any of the configure
options that MacPorts would have used from what would have been used
previously (I assume they can be overridden)?
There's not that much that can be overridden that w
On Fri, 18 Jan 2008, Tom Lane wrote:
pg_controldata already provides this information, no? At least barring
the case of wrong-time_t-size, which we already know we want to fix.
It provides some of it, and I think you could make a case that the text
file format Dave suggested could be prototy
On 18/01/2008, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Dave Page" <[EMAIL PROTECTED]> writes:
> > On 18/01/2008, Tom Lane <[EMAIL PROTECTED]> wrote:
> Ah. That would work better than what I thought you were suggesting, but
> I still don't trust it a whole lot --- there's the problem of "universal
>
Greg Smith <[EMAIL PROTECTED]> writes:
> The usual advice, telling them to replicate the binaries used to create it
> in the first place, isn't always the easiest to follow. It seems to me
> that including a "environment at cluster creation" note in $PGDATA like
> Dave suggests would be helpful
On Fri, 18 Jan 2008, Dave Page wrote:
For just about zero cost we could drop something like:
Architecture: Darwin snake 8.11.1 Darwin Kernel Version 8.11.1: Wed
Oct 10 18:23:28 PDT 2007; root:xnu-792.25.20~1/RELEASE_I386 i386 i386
Configuration: '--prefix=/usr/local/pgsql83/'
'--enable
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Dave Page wrote:
>> That said, is zlib used by toast or do we have some other code for
>> that? If it is used for that, do we record it's presence or absence in
>> pg_control?
> Nope, toast uses its own compression code.
pg_dump/pg_restore use zlib, bu
"Dave Page" <[EMAIL PROTECTED]> writes:
> On 18/01/2008, Tom Lane <[EMAIL PROTECTED]> wrote:
>> uname is a separate executable. If you do system("uname") you'll get
>> results that reflect how uname was built, not how Postgres was built.
> My suggestion was that we take the output of uname at con
On 18/01/2008, Tom Lane <[EMAIL PROTECTED]> wrote:
> uname is a separate executable. If you do system("uname") you'll get
> results that reflect how uname was built, not how Postgres was built.
Right, I realise it's a seperate executable, but doesn't configure
rely on it anyway? Meaning if someon
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> What might be better is if we had an explicit endianness mark in pg_control
> rather than relying on users discovering endianness problems by seemingly
> corrupted version numbers.
Chicken-and-egg problem there: you won't know if there's an endianne
"Dave Page" <[EMAIL PROTECTED]> writes:
> On 18/01/2008, Tom Lane <[EMAIL PROTECTED]> wrote:
>> Zero cost and also zero benefit. The missing piece of information here
>> was that the executable being used was running under PPC emulation, and
>> I'll bet money that there would have been nothing in
Dave Page wrote:
> That said, is zlib used by toast or do we have some other code for
> that? If it is used for that, do we record it's presence or absence in
> pg_control?
Nope, toast uses its own compression code.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
On 18/01/2008, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
> Am Freitag, 18. Januar 2008 schrieb Dave Page:
> > It got figured out when someone who knew what they were looking for
> > peeked at the byte ordering in a file which for all we knew at the
> > time might have been damaged anyway
>
> What
Am Freitag, 18. Januar 2008 schrieb Dave Page:
> It got figured out when someone who knew what they were looking for
> peeked at the byte ordering in a file which for all we knew at the
> time might have been damaged anyway
What might be better is if we had an explicit endianness mark in pg_contro
On 18/01/2008, Tom Lane <[EMAIL PROTECTED]> wrote:
> Hm? integer_datetimes is encoded separately and there's a very specific
> error message if it's wrong. The case I think you are remembering was
> caused by a width-of-time_t discrepancy, which should be fixed but it's
> got nothing to do with a
"Dave Page" <[EMAIL PROTECTED]> writes:
> On 18/01/2008, Tom Lane <[EMAIL PROTECTED]> wrote:
>> That's what pg_control is for. We figured out easily enough that this
>> was an endianness problem; having had "big endian" somewhere in
>> cleartext wouldn't have improved matters.
> It got figured ou
On 18/01/2008, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Dave Page" <[EMAIL PROTECTED]> writes:
> > Note to the other hackers - is it worth having initdb dump the
> > architecture details and configure options used into the cluster in a
> > human readble form so we can pickup on this sort of thing mor
"Dave Page" <[EMAIL PROTECTED]> writes:
> Note to the other hackers - is it worth having initdb dump the
> architecture details and configure options used into the cluster in a
> human readble form so we can pickup on this sort of thing more easily
> in the future?
That's what pg_control is for.
"Dave Page" <[EMAIL PROTECTED]> writes:
> As for the real problem (on the same hardware), when you rebuilt
> Postgres on your new machine did you change any of the configure
> options that MacPorts would have used from what would have been used
> previously (I assume they can be overridden)?
There
On 18/01/2008, Stefan Schwarzer <[EMAIL PROTECTED]> wrote:
> I don't understand it either, which is why I was wondering if it was
> running under some PPC emulation (can you run standard mac software or
> do you have to get special Intel versions).]
Yes, Apple have an emulation layer called Rosett
Ok, it seems to be related to a Intel/PPC issue, as Martijn and Tom
suggested.
So, I copied all files to a PPC, but which runs Linux - don't know if
this is important. Now, it tells me:
"Fatal error: Incorrect checksum on control file"
Any way out of this? Thanks for any advice.
That's the ki
On 18/01/2008, Stefan Schwarzer <[EMAIL PROTECTED]> wrote:
> Ok, it seems to be related to a Intel/PPC issue, as Martijn and Tom
> suggested.
>
> So, I copied all files to a PPC, but which runs Linux - don't know if
> this is important. Now, it tells me:
>
> "Fatal error: Incorrect checksum on cont
On Jan 18, 2008 7:25 AM, Stefan Schwarzer <[EMAIL PROTECTED]> wrote:
> >
> >>> Did you just move from a PPC-based Mac to an Intel-based one?
> >>> If so, you're out of luck --- you need to go back to the PPC
> >>> to make a dump of those files.
> >>>
> >>
> >> No, I just re-installed my Intel M
Did you just move from a PPC-based Mac to an Intel-based one?
If so, you're out of luck --- you need to go back to the PPC
to make a dump of those files.
No, I just re-installed my Intel Mac. First I just upgraded from
Tiger to Leopard (without getting my database to run; but I didn't
put
This looks like an endianess mismatch; did you already mention on
what
architecture you are on?
MacPro, Leopard
Did you just move from a PPC-based Mac to an Intel-based one?
If so, you're out of luck --- you need to go back to the PPC
to make a dump of those files.
No, I just re-installe
This looks like an endianess mismatch; did you already mention on
what
architecture you are on?
MacPro, Leopard
Did you just move from a PPC-based Mac to an Intel-based one?
If so, you're out of luck --- you need to go back to the PPC
to make a dump of those files.
No, I just re-installe
Stefan Schwarzer <[EMAIL PROTECTED]> writes:
>> This looks like an endianess mismatch; did you already mention on what
>> architecture you are on?
> MacPro, Leopard
Did you just move from a PPC-based Mac to an Intel-based one?
If so, you're out of luck --- you need to go back to the PPC
to make a
| The logfile is telling me this when I try to start the server with
my
| "old" data folder:
|
| FATAL: database files are incompatible with server
| DETAIL: The database cluster was initialized with
PG_CONTROL_VERSION
| 738394112, but the server was compiled with PG_CONTROL_VERSION 812.
|
On Mittwoch, 16. Januar 2008, Stefan Schwarzer wrote:
| The logfile is telling me this when I try to start the server with my
| "old" data folder:
|
| FATAL: database files are incompatible with server
| DETAIL: The database cluster was initialized with PG_CONTROL_VERSION
| 738394112, but the
Ok, did what you said: stopping server, deleting "newly" created
"data" directory, re-running initdb, starting the server, stopping
the
server.
Renamed "empty" data directory.
Restarting server: NOT COMPLAINING "you need to run initdb" or
something else Although it's saying that it
Ok, did what you said: stopping server, deleting "newly" created
"data" directory, re-running initdb, starting the server, stopping
the
server.
Renamed "empty" data directory.
Restarting server: NOT COMPLAINING "you need to run initdb" or
something else Although it's saying that it st
Stefan Schwarzer <[EMAIL PROTECTED]> writes:
> Ok, did what you said: stopping server, deleting "newly" created
> "data" directory, re-running initdb, starting the server, stopping the
> server.
> Renamed "empty" data directory.
> Restarting server: NOT COMPLAINING "you need to run initdb" or
I re-installed my machine and "forgot" to dump my database(s). I
naturally still have the whole database folders. For the moment I
installed the "old" postgres version (8.1) to be able to read my
data.
But how can I read them? It seems that it doesn't work that I just
overwrite the new database
On Tue, Jan 15, 2008 at 02:42:05PM +0100, Stefan Schwarzer wrote:
> Thanks a lot for this. Still trying. But although the postmaster did
> run at one time, now, after copying back and forth, it doesn't want to
> do anything anymore... Gush, getting really frustrated...
If it really doesn't wor
Stefan Schwarzer wrote:
I re-installed my machine and "forgot" to dump my database(s). I
naturally still have the whole database folders. For the moment I
installed the "old" postgres version (8.1) to be able to read my data.
But how can I read them? It seems that it doesn't work that I just
over
I re-installed my machine and "forgot" to dump my database(s). I
naturally still have the whole database folders. For the moment I
installed the "old" postgres version (8.1) to be able to read my
data.
But how can I read them? It seems that it doesn't work that I just
overwrite the new database
And also remember to use the same version of Postgres as the previous
installation...
It might be helpful to post the tail of your server's log ahen it fails.
Best Regards,
On Jan 14, 2008 7:58 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Stefan Schwarzer <[EMAIL PROTECTED]> writes:
> > I re-insta
Stefan Schwarzer <[EMAIL PROTECTED]> writes:
> I re-installed my machine and "forgot" to dump my database(s). I
> naturally still have the whole database folders. For the moment I
> installed the "old" postgres version (8.1) to be able to read my data.
> But how can I read them? It seems that
Hi there,
I re-installed my machine and "forgot" to dump my database(s). I
naturally still have the whole database folders. For the moment I
installed the "old" postgres version (8.1) to be able to read my data.
But how can I read them? It seems that it doesn't work that I just
overwrite
46 matches
Mail list logo
