Re: PostgreSQL on 64-bit Windows

On Fri, 11 Jan 2008, Joshua D. Drake wrote:

> Pedro Briones Garca wrote:
>> Hello.
>>
>>
>> According to PostgreSQL FAQ
>>
>> *Q: Does PostgreSQL Support 64-bit Computing?*
>> A: Yes. In fact, we've supported 64-bit systems for at least 10 years, just
>> like a lot of other Unix and POSIX software. *We do not yet support 64-bit
>> Windows, however*.
>>
>> Does it mean that PostgreSQL can not run on a 64-bit Windows computer, or
>> does it mean that it is possible, but the database does not make the most
>> of the capacity, but it works as if the computer would be of 32 bits?
>>
>
>
> My understanding is that it will run on 64-bit windows but in 32bit mode.
>
I know from first hand experience that it runs as a 32-bit app on XP 64.

LER

> Joshua D. Drake
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 512-248-2683 E-Mail: ler(at)lerctr(dot)org
US Mail: 430 Valona Loop, Round Rock, TX 78681-3893
>From pgsql-admin-owner(at)postgresql(dot)org Fri Jan 11 15:46:57 2008
Received: from localhost (unknown [200.46.204.187])
by postgresql.org (Postfix) with ESMTP id E6C962E444F
for <pgsql-admin-postgresql(dot)org(at)postgresql(dot)org>; Fri, 11 Jan 2008 15:46:54 -0400 (AST)
Received: from postgresql.org ([200.46.204.71])
by localhost (mx1.hub.org [200.46.204.187]) (amavisd-maia, port 10024)
with ESMTP id 92574-08 for <pgsql-admin-postgresql(dot)org(at)postgresql(dot)org>;
Fri, 11 Jan 2008 15:46:45 -0400 (AST)
Received: from mail2.yozons.com (mail2.yozons.com [63.251.168.97])
by postgresql.org (Postfix) with ESMTP id 2CCD32E444E
for <pgsql-admin(at)postgresql(dot)org>; Fri, 11 Jan 2008 15:46:47 -0400 (AST)
Received: from [192.168.1.2] (pool-71-164-18-27.sttlwa.fios.verizon.net [71.164.18.27])
(authenticated bits=0)
by mail2.yozons.com (8.12.10/8.12.10) with ESMTP id m0BJkjlG026593
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT)
for <pgsql-admin(at)postgresql(dot)org>; Fri, 11 Jan 2008 11:46:45 -0800
Message-ID: <4787C7A7(dot)3000503(at)computer(dot)org>
Date: Fri, 11 Jan 2008 11:46:47 -0800
From: David Wall <d(dot)wall(at)computer(dot)org>
Reply-To: d(dot)wall(at)computer(dot)org
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: pgsql-admin(at)postgresql(dot)org
Subject: WAL recovery, stop and resume recovery?
Content-Type: multipart/alternative;
boundary="------------070207050707000702030905"
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200801/123
X-Sequence-Number: 27897

This is a multi-part message in MIME format.
--------------070207050707000702030905
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Using PG 8.2, I have a database in recovery mode using pg_standby to
handle the WAL restores.

Is it allowable to have a backup database in recovery mode, then stop
recovery (in this case, by putting the trigger file in place to stop
pg_standby), check out that the backup db appears up to date, stop the
now active backup db, and then restart it in recover mode again to have
it resume its backup role?

I have had some success doing this, with the restart in recovery showing:

LOG: starting archive recovery
LOG: restore_command = "~/postgresql/bin/pg_standby -l -d -s 2 -k 20 -t
~/postgresql/restoreWALs/STOP_RESTORE ~/postgresql/restoreWALs %f %p 2>>
~/pg_standby.log"
LOG: restored log file "000000010000000500000018" from archive
*LOG: invalid xl_info in primary checkpoint record*
LOG: using previous checkpoint record at 5/18000020
LOG: redo record is at 5/18000020; undo record is at 0/0; shutdown FALSE
LOG: next transaction ID: 0/1535389; next OID: 53990
LOG: next MultiXactId: 1; next MultiXactOffset: 0
*LOG: automatic recovery in progress*
LOG: redo starts at 5/18000068

But there are times when I do this that it cannot. Is this because the
steps are an issue (after all, I did stop recovery and go active
briefly, though I didn't update the db during that time, just did \d and
select queries to see that DDL and row data were updated on the backup),
or is it related to not keeping enough WAL files around (pg_standby -k
20 was chosen, but it's not clear how to select this value, and it
sounds like 8.3 gets rid of that issue entirely) to find the 'secondary
checkpoint record'.

Here's the sort of error I get when it doesn't allow me to restart:

LOG: database system was shut down at 2008-01-11 11:40:05 PST
LOG: starting archive recovery
LOG: restore_command = "~/postgresql/bin/pg_standby -l -d -s 2 -k 20 -t
~/postgresql/restoreWALs/STOP_RESTORE ~/postgresql/restoreWALs %f %p 2>>
~/pg_standby.log"
*LOG: restored log file "00000001000000050000001D" from archive
LOG: invalid record length at 5/1D000068
LOG: invalid primary checkpoint record
LOG: restored log file "00000001000000050000001D" from archive
LOG: invalid resource manager ID in secondary checkpoint record
PANIC: could not locate a valid checkpoint record*
LOG: startup process (PID 9219) was terminated by signal 6
LOG: aborting startup due to startup process failure
LOG: logger shutting down

Thanks,
David

--------------070207050707000702030905
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
Using PG 8.2, I have a database in recovery mode using pg_standby to
handle the WAL restores.<br>
<br>
Is it allowable to have a backup database in recovery mode, then stop
recovery (in this case, by putting the trigger file in place to stop
pg_standby), check out that the backup db appears up to date, stop the
now active backup db, and then restart it in recover mode again to have
it resume its backup role?<br>
<br>
I have had some success doing this, with the restart in recovery
showing:<br>
<br>
<tt>LOG:&nbsp; starting archive recovery<br>
LOG:&nbsp; restore_command = "~/postgresql/bin/pg_standby -l -d -s 2 -k 20
-t ~/postgresql/restoreWALs/STOP_RESTORE ~/postgresql/restoreWALs %f %p
2&gt;&gt; ~/pg_standby.log"<br>
LOG:&nbsp; restored log file "000000010000000500000018" from archive<br>
<b>LOG:&nbsp; invalid xl_info in primary checkpoint record</b><br>
LOG:&nbsp; using previous checkpoint record at 5/18000020<br>
LOG:&nbsp; redo record is at 5/18000020; undo record is at 0/0; shutdown
FALSE<br>
LOG:&nbsp; next transaction ID: 0/1535389; next OID: 53990<br>
LOG:&nbsp; next MultiXactId: 1; next MultiXactOffset: 0<br>
<b>LOG:&nbsp; automatic recovery in progress</b><br>
LOG:&nbsp; redo starts at 5/18000068</tt><br>
<br>
But there are times when I do this that it cannot.&nbsp; Is this because the
steps are an issue (after all, I did stop recovery and go active
briefly, though I didn't update the db during that time, just did \d
and select queries to see that DDL and row data were updated on the
backup), or is it related to not keeping enough WAL files around
(pg_standby -k 20 was chosen, but it's not clear how to select this
value, and it sounds like 8.3 gets rid of that issue entirely) to find
the 'secondary checkpoint record'.<br>
<br>
Here's the sort of error I get when it doesn't allow me to restart:<br>
<br>
<tt>LOG:&nbsp; database system was shut down at 2008-01-11 11:40:05 PST<br>
LOG:&nbsp; starting archive recovery<br>
LOG:&nbsp; restore_command = "~/postgresql/bin/pg_standby -l -d -s 2 -k 20
-t ~/postgresql/restoreWALs/STOP_RESTORE ~/postgresql/restoreWALs %f %p
2&gt;&gt; ~/pg_standby.log"<br>
<b>LOG:&nbsp; restored log file "00000001000000050000001D" from archive<br>
LOG:&nbsp; invalid record length at 5/1D000068<br>
LOG:&nbsp; invalid primary checkpoint record<br>
LOG:&nbsp; restored log file "00000001000000050000001D" from archive<br>
LOG:&nbsp; invalid resource manager ID in secondary checkpoint record<br>
PANIC:&nbsp; could not locate a valid checkpoint record</b><br>
LOG:&nbsp; startup process (PID 9219) was terminated by signal 6<br>
LOG:&nbsp; aborting startup due to startup process failure<br>
LOG:&nbsp; logger shutting down</tt><br>
<br>
<br>
Thanks,<br>
David<br>
</body>
</html>

--------------070207050707000702030905--