When showing the setting on the slave or master all tcp_keepalive settings
(idle, interval and count) are showing 0;
The config file shows interval and count commented out, but idle in the
config file is set to 2100.
Possible that "show tcp_keepalive_idle;" isn't reporting accurately ? (or a
val
"Ondrej Pachner" writes:
> all counters on zero and warning about wait timeout..
Is the stats collector process running at all? If not, is there
anything in the postmaster log to suggest why not?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgre
The following bug has been logged online:
Bug reference: 5855
Logged by: Ondrej Pachner
Email address: ondrej.pach...@4internet.cz
PostgreSQL version: 9.0.1
Operating system: Debian GNU Linux - stable
Description:pgstat wait timeout
Details:
all counters on zero and
Chris R. wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5854
> Logged by: Chris R.
> Email address: chri...@gmx.net
> PostgreSQL version: 9.02
> Operating system: CentOS 5.5
> Description:base64 decode returns bytea and no text
> Details:
>
"Chris R." writes:
> There is a break in how pg9.0 handles decoding base64 encoded data.
This has nothing to do with decode(), it's a change in the default
output format for bytea data. Set bytea_output to "escape" to get
the old format.
regards, tom lane
--
Sent via p
The following bug has been logged online:
Bug reference: 5854
Logged by: Chris R.
Email address: chri...@gmx.net
PostgreSQL version: 9.02
Operating system: CentOS 5.5
Description:base64 decode returns bytea and no text
Details:
There is a break in how pg9.0 handles
On Tue, Jan 25, 2011 at 1:31 AM, SETU SAXENA wrote:
> To,
> the respective authority
> pgadmin
>
> Sub: to report a bug in posgresql version 1.10.2 (Aug 24 2010, rev 8217)
>
> This to inform you that we are using posgre sql (pgadmin) version mentioned
> above. We are using pgadmin to log on to a
On Wed, Jan 26, 2011 at 8:24 PM, Mark wrote:
> getting a break down in streaming rep. my current work around is to restart
> the PG instance on the ROHS. doesn't seem to affect the master any. doesn't
> require a re-rsync of the base to get replication going again. has happened
> with 9.0.2 twice
(I repeat: please keep the mailing list cc'd so that other can help)
On 28.01.2011 08:49, zoulx1982 wrote:
when the slave computer is reset , there are two situation:
1. the primary don't produce WAL, so walsender won't send any XLOG
I use "netstat -anp | grep postgres" to find the connection st
