"umashankar narayanan" wrote:
> Version : 8.3
>
>
> Below is the log from the server.
>
>
> -
> --
The above is everything that showed up on your post. Make sure
you're not
"umashankar narayanan" wrote:
> Version : 8.3
Please give the full version and a bit more information about the
environment it's running in:
http://wiki.postgresql.org/wiki/Guide_to_reporting_problems
> 2012-03-07 11:57:20 EST LOG: server process (PID 5944) exited
> with exit code 128
W
Version : 8.3
Below is the log from the server.
---
2012-03-07 11:57:20 EST LOG: server process (PID 5944) exited with exit code
128
2012-03-07 11:57:20 EST LOG: terminating
Kevin,
The full version of Postgres is 8.3.1. It is running on Microsoft Windows 2003
Standard 32-bit on VMWare.
On the system logs around this time, the only message that we receive is that
the PID crashed.
All that I see on the postgres log before the crash is the below message:
2012-03
On Thu, Mar 8, 2012 at 12:23 PM, umashankar narayanan
wrote:
> Kevin,
>
> The full version of Postgres is 8.3.1. It is running on Microsoft Windows
> 2003 Standard 32-bit on VMWare.
> On the system logs around this time, the only message that we receive is
> that the PID crashed.
>
> All that I se
[Please don't top-post. http://idallen.com/topposting.html ]
"umashankar narayanan" wrote:
> "Kevin Grittner" wrote:
>> "umashankar narayanan" wrote:
>> Please give the full version
> The full version of Postgres is 8.3.1.
You are missing four years of bug fixes for 8.3.
http://www.pos
Scott Marlowe writes:
> On Thu, Mar 8, 2012 at 12:23 PM, umashankar narayanan
> wrote:
>> The full version of Postgres is 8.3.1. It is running on Microsoft Windows
>> 2003 Standard 32-bit on VMWare.
> If I remember correctly this bug was fixed in later windows versions.
see release notes for 8.
Anyone have any thoughts on why this may be happening?
thanks,
- Brian F
On 03/01/2012 04:38 PM, Brian Fehrle wrote:
I just now ran the following query a few times after each other on the
hot standby:
select now(), * from pg_stat_bgwriter;
Here are the results:
now
Hi!
I have a few questions regarding vacuum behavior. But first, some background:
We're running Postgres version 9.1.2 on FreeBSD 8.2 stable.
We did a large data-only single table dump (table was 12TB when we dumped it)
and restored it on a new machine while our database was live in the new
l
Natalie Wenz writes:
> [ waiting for autovacuum to deal with an impending XID wraparound ]
> My first question is: Is it even possible for this vacuum to finish? It began
> before the database stopped accepting connections, but now that it's in this
> state, will the database allow the vacuum t
10 matches
Mail list logo
