On Fri, Jan 29, 2010 at 11:49 PM, Mason Hale ma...@onespot.com wrote:
While I did not remove the trigger file, I did rename recovery.conf to
recovery.conf.old.
That file contained the recovery_command configuration that identified the
trigger file. So that rename should have eliminated the
The following bug has been logged online:
Bug reference: 5301
Logged by: Jehan-Guillaume (ioguix) de Rorthais
Email address: iog...@free.fr
PostgreSQL version: 8.3
Operating system: Linux
Description:difference of behaviour between 8.3 and 8.4 on IS NULL
with sub
Sun Duozhong(孙多忠) wrote:
So how can emedded SQL in C to get the record type which returning from
plpgsql function?
You seem to have missed the fact that this isn't a web forum for help
questions. It's a bug report form. You are not reporting a bug. You are
not likely to get help by repeatedly
The following bug has been logged online:
Bug reference: 5299
Logged by: Savita
Email address: savita.ha...@gmail.com
PostgreSQL version: 8.3.5
Operating system: HP 11.31
Description:unable to start postgres service
Details:
Hi
I have installed postgres. When I
The following bug has been logged online:
Bug reference: 5300
Logged by: aurelien
Email address: alti...@carrafix.com
PostgreSQL version: 8.4.1
Operating system: Mac OS X 10.6
Description:Bug on Mac OS X 10.6 and Postgres 8.4
Details:
Look what's here :
On Fri, Jan 29, 2010 at 12:03 AM, Mason Hale ma...@onespot.com wrote:
Of course the best solution is to avoid this issue entirely. Something as
easy to miss as file permissions should not cause data corruption,
especially in the process meant to fail over from a crashing primary
database.
Hello Fujii --
Thanks for the clarification. It's clear my understanding of the recovery
process is lacking.
My naive assumption was that Postgres would recover using whatever files
were available
and if it had run out of files it would stop there and come up. And that if
recovery.conf were
On Fri, Jan 29, 2010 at 11:02 AM, Fujii Masao masao.fu...@gmail.com wrote:
You seem to focus on the above trouble. I think that this happened because
recovery.conf was deleted and restore_command was not given. In fact, the
WAL file (e.g., pg_xlog/00023C8200A3) required for recovery
Robert Haas wrote:
On Fri, Jan 29, 2010 at 11:02 AM, Fujii Masao masao.fu...@gmail.com wrote:
You seem to focus on the above trouble. I think that this happened because
recovery.conf was deleted and restore_command was not given. In fact, the
WAL file (e.g., pg_xlog/00023C8200A3)
Savita savita.ha...@gmail.com wrote:
I have installed postgres. When I check the status of postgres
service I get it is not running. But when I start pg_ctl start it
says server starting. But server is actually not started. How do
we get debug information for pg_ctl start?
This doesn't
Jehan-Guillaume (ioguix) de Rorthais iog...@free.fr wrote:
and here is another test case where 8.3 is inconsistent with
*himself* this time:
Sounds like an argument that the behavior *should* have changed in
8.4. We don't like to introduce behavioral changes which might
break something in a
top is not the be-all and end-all of analysis tools. I'm sure you
know that, but it bears repeating.
More importantly, in a virtualised environment the tools on the inside
of the guest don't have a full picture of what's really going on.
Indeed, you have hit the nail on the head.
does
John R Pierce wrote:
top is not the be-all and end-all of analysis tools. I'm sure you
know that, but it bears repeating.
More importantly, in a virtualised environment the tools on the
inside of the guest don't have a full picture of what's really going on.
Indeed, you have hit the
The following bug has been logged online:
Bug reference: 5302
Logged by: Florian Nigsch
Email address: cont...@flo.nigsch.com
PostgreSQL version: 8.4.2
Operating system: x86_64 GNU/Linux 2.6.18-92.el5
Description:WIN1252 encoding causes server memory leak
Details:
If the sysadmin had left the recovery.conf and removed the trigger file,
pg_standby in restore_command would have restored all WAL files required
for recovery, and recovery would advance well.
That may be true, but it's certainly seems unfortunate that we don't
handle this case a bit
Florian Nigsch cont...@flo.nigsch.com writes:
Description:WIN1252 encoding causes server memory leak
Hmm, what server-side encoding and locale are you using?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to
Actually, I think there's a tiny harmless bug in the server too. When it
prints the error message:
2010-01-18 21:08:31 UTC ()FATAL: could not restore file
00023C8200D8 from archive: return code 65280
That return code is not the return code that came from the
restore_command. Ie if
On Fri, Jan 29, 2010 at 3:32 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Actually, I think there's a tiny harmless bug in the server too. When it
prints the error message:
2010-01-18 21:08:31 UTC ()FATAL: could not restore file
00023C8200D8 from archive:
Robert Haas robertmh...@gmail.com writes:
On Fri, Jan 29, 2010 at 3:32 PM, Heikki Linnakangas
That only affects the error message and is harmless otherwise, but I
thought I'd mention it. I'll fix it, unless someone wants to argue that
its more useful to print the raw return value of system(),
The following bug has been logged online:
Bug reference: 5303
Logged by: D Black
Email address: softc...@inbox.com
PostgreSQL version: 8.3
Operating system: Ubuntu 8.04
Description:Upgrade failure due to sever.key permissions
Details:
PostgreSQL 8.3 upgrade failed
Output of 'psql -l':
The 8.4.0 server:
List of databases
Name| Owner | Encoding | Collation |Ctype|
Access privileges
---+--+--+-+-+---
| | UTF8
D Black wrote:
The following bug has been logged online:
Bug reference: 5303
Logged by: D Black
Email address: softc...@inbox.com
PostgreSQL version: 8.3
Operating system: Ubuntu 8.04
Description:Upgrade failure due to sever.key permissions
Details:
22 matches
Mail list logo
