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:
Output of 'psql -l':
The 8.4.0 server:
List of databases
Name| Owner | Encoding | Collation |Ctype|
Access privileges
---+--+--+-+-+---
| | UTF8
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 d
Robert Haas 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(), because it
>> m
On Fri, Jan 29, 2010 at 3:32 PM, Heikki Linnakangas
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: return code 65280
>
> That retur
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
"Florian Nigsch" 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 your subscription:
htt
>
>
> >> 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
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:
T
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 nail
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 an
"Jehan-Guillaume (ioguix) de Rorthais" 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 minor rele
"Savita" 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 sound like a bug; i
Robert Haas wrote:
> On Fri, Jan 29, 2010 at 11:02 AM, Fujii Masao 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 rec
On Fri, Jan 29, 2010 at 11:02 AM, Fujii Masao 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
> was unable to be
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 renam
> On Fri, Jan 29, 2010 at 12:03 AM, Mason Hale 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.
>
> I be
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 : http://trac.
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 che
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: 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 rows
On Fri, Jan 29, 2010 at 11:49 PM, Mason Hale 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 problem. But it
>
22 matches
Mail list logo
