Wierd error message

I have situation where I have one box with linux native 64 bit distribution
(Gentoo on AMD) running pg 8.x and other box running a 32 bit distro
running version of pg 8.x

Is it posssible to take a "filesystem level backup" (copyiing all in
$PGDATA directory) from 64 bit system and use it as $PGDATA in the native 32
bit system with the same version of postgresql ?

Ie to have one big 64 bit server and eventually a small but cheap 32 bit box
as an emergency backup ?

On Tue, Mar 15, 2005 at 02:29:51PM +0100, NTPT wrote:

I have situation where I have one box with linux native 64 bit
distribution (Gentoo on AMD) running pg 8.x and other box running a 32 bit
distro running version of pg 8.x

Is it posssible to take a "filesystem level backup" (copyiing all in
$PGDATA directory) from 64 bit system and use it as $PGDATA in the native
32 bit system with the same version of postgresql ?

Doubt it, it's not explicitly supported. It might work, but padding
changes, certain width changes, may screw you up.

Ie to have one big 64 bit server and eventually a small but cheap 32 bit
box as an emergency backup ?

Use something like Slony, it's specifically supports this kind of
usage...

Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/

Martijn van Oosterhout <kleptog@svana.org> writes:

On Tue, Mar 15, 2005 at 02:29:51PM +0100, NTPT wrote:

Is it posssible to take a "filesystem level backup" (copyiing all in=20
$PGDATA directory) from 64 bit system and use it as $PGDATA in the native=
32 bit system with the same version of postgresql ?

Doubt it, it's not explicitly supported. It might work, but padding
changes, certain width changes, may screw you up.

It might work if the main server were compiled as a 32-bit application
... but AFAIK the Intel-ish 64bit architectures mostly suck in 32-bit
emulation mode, so you'd not want to do that. It will almost certainly
*not* work to just cram 64-bit files onto a 32-bit machine, because the
file layout is dependent on MAXALIGN which will likely be different.

Use something like Slony, it's specifically supports this kind of
usage...

Agreed.

regards, tom lane

On Tue, 2005-03-15 at 07:29, NTPT wrote:

I have situation where I have one box with linux native 64 bit distribution
(Gentoo on AMD) running pg 8.x and other box running a 32 bit distro
running version of pg 8.x

Is it posssible to take a "filesystem level backup" (copyiing all in
$PGDATA directory) from 64 bit system and use it as $PGDATA in the native 32
bit system with the same version of postgresql ?

Ie to have one big 64 bit server and eventually a small but cheap 32 bit box
as an emergency backup ?

Following up on what Tom wrote, I'd suggest using Slony-I to keep the
two machines in sync.

On Tue, Mar 15, 2005 at 07:32:43AM -0500, Alex Turner wrote:

I'm working with mod_python and pygresql (although I get virtualy the
same error with psycopg too)

What's the exact error you get with psycopg?

Anyone know what the following error actualy means:

Exception pg.InternalError: 'Connection already closed' in > ignored

Does it mean the obvious: Some code tries to access a connection
object that was already closed?

That would be my guess. What are you doing that results in the
error? Is it easily repeatable? Does anything else show up in the
web server or database logs?

but why the "in > ignored" then?

Can you tell us more about the setup? What are all the pieces
involved and their versions?

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/

I'm running apache 2.0.52 on pentium III 866 using RedHat EL3 - kernel
2.4.21-27.0.2.EL I'm using mod_python 3.1.3 and the
postgresql-python-8.0.1-1PGDG RPM.

Unfortunately the error is not readibly reproducable. Sometimes it
happens, and sometimes it doesn't. Normaly if I reload the page it
goes away. There are cron jobs that make HTTP calls to the system
every 5 minutes also written in python. When httpd is isdle "lsof |
grep httpd | grep 5432" shows nothing.

We have only been experiencing this error recently. It may just be
conincidence, but it has been noticed since upgrading to 8.0.

much to my amazement, error_log contains:
[Wed Mar 16 00:38:41 2005] [error] [client 66.216.147.134]
PythonHandler ContentGenerator: STDERR Contained data: Exception
pg.InternalError: 'Connection already closed' in <bound method
PostgresqlDBConnection.__del__ of <PGDBC.PostgresqlDBConnection
instance at 0x8b3428c>> ignored\n, referer:
http://www.totalleads.com/client_administration/display_employee_postal_code_list.nece?eid=13071&amp;section=users

The STDERR part I can explain: my web page evals and calls some python code.

I think I know the problem. The current release is printing an error
to stderr if a database connection that is aready closed is tried to
be closed again. I am catching anything on stderr and raising it as
an exception.

So I think the problem is solved.

Alex Turner
netEconomist