The following bug has been logged online:
Bug reference: 2459
Logged by: Silvio Macedo
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.4
Operating system: Windows XP SP2
Description:psql 8.1.4 vs 8.0.x behaves differently with tty / con
/ stdin recent fixes
Silvio Macedo wrote:
I've been using stdin/stdout of psql on Windows to run a script, without
messing with expect.
Before v8.1.4, one could include the password in the string fed to psql via
stdin to authenticate the connection.
With 8.1.4, it doesn't work.
You can use PGPASSWORD or a
Silvio Macedo [EMAIL PROTECTED] writes:
I've been using stdin/stdout of psql on Windows to run a script, without
messing with expect.
Before v8.1.4, one could include the password in the string fed to psql via
stdin to authenticate the connection.
With 8.1.4, it doesn't work.
That's how it's
Unix always prompted from /dev/tty, but on Win32 we didn't have that
working until 8.1.4. It should be that way.
---
Silvio Macedo wrote:
The following bug has been logged online:
Bug reference: 2459
Logged by:
Silvio Macedo wrote:
In this case, I think users upgrading from 8.0.x to 8.1. should be
warned.(think interfacing with old software, no source available,
upgraded to PGSql via messy console stub scripts)
Users uncomfortable with writing down the password on a PGPASSWORD
environment var or
I have a problem restoring our large database. This has only stared
happening since we moved to 8.1.x
We are currently on 8.1.3.
We perform an over night dump of the database as follows;
pg_dump -Ft $db | bzip2 $db.dump.tbz
This happens fine, without any errors.
On our backup machine also
Hi,
I'm using Postgresql 8.1.3.
Recently I facing one problem, when the connection for postgresql grow up
to 45 or more, when I trigger a statement from WebApp
this statement will stuck forever.
I try to kill this transaction and then trigger the same statement again
but it still the same.
Michael Andreasen [EMAIL PROTECTED] writes:
pg_dump -Ft $db | bzip2 $db.dump.tbz
...
pg_restore: [tar archiver] could not find header for file 3765.dat in
tar archive
Does it work better if you use -Fc format? There was a similar report
recently, which makes me think the tar-format code
