[BUGS] Re: ????:Re: ????:Re: [BUGS] BUG #5853: when the walsender cannot exit when reboot slave computer
(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 state is ESTABLISHED 2. the primary produce WAL and need to send to walreceiver, but there need a long time to wait timeout(about 15 minutes) in this situation, the connection state is also ESTABLISHED Yeah, 15 minutes is the timeout in TCP. I don't remember if that's just a default that can be changed in the OS, or a requirement of the protocol. whether we should set a reasonable timeout to avoid waiting long time? You can use tcp_keep_alive_* settings to somewhat alleviate that (see manual http://www.postgresql.org/docs/9.0/interactive/warm-standby.html#STREAMING-REPLICATION), but other than that there's currently no application-level timeout. A lingering walsender shouldn't normally cause any problems, though, it will timeout eventually. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5851: ROHS (read only hot standby) needs to be restarted manually in somecases.
On Wed, Jan 26, 2011 at 8:24 PM, Mark dvlh...@gmail.com 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 now in a month. 2011-01-26 08:35:42 MST :: (postgres@10.80.2.89) LOG: could not receive data from client: Connection reset by peer 2011-01-26 08:35:42 MST :: (postgres@10.80.2.89) LOG: unexpected EOF on standby connection this was all I have in the master's log with the level set to debug 1, I have reset it to debug 5 and will just wait till it dies again and hopefully get a better idea of what is going on. nothing is being logged to the standby. Maybe a break in network connectivity is leading the master to think that the slave is dead, while the slave still thinks it's connected. You might need to adjust the TCP keepalive parameters the slave uses to connect to the master. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5854: base64 decode returns bytea and no text
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 decoding base64 encoded data.
With PostgreSQL 8.4:
select decode(encode('abc', 'base64'), 'base64');
decode
--
\x616263
With PostgreSQL 9.0:
select decode(encode('abc', 'base64'), 'base64');
decode
--
\x616263
To get the old result, convert_from helps out:
select convert_from(decode(encode('abc', 'base64'), 'base64'), 'UTF8');
Still, shouldn't this be consistent with 8.x and 9.x?
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5854: base64 decode returns bytea and no text
Chris R. chri...@gmx.net 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 pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5854: base64 decode returns bytea and no text
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:
There is a break in how pg9.0 handles decoding base64 encoded data.
With PostgreSQL 8.4:
select decode(encode('abc', 'base64'), 'base64');
decode
--
\x616263
With PostgreSQL 9.0:
select decode(encode('abc', 'base64'), 'base64');
decode
--
\x616263
To get the old result, convert_from helps out:
select convert_from(decode(encode('abc', 'base64'), 'base64'), 'UTF8');
Still, shouldn't this be consistent with 8.x and 9.x?
Uh, they look the same to me. cut/paste error?
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5855: pgstat wait timeout
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 warning about wait timeout.. postgres= SELECT * FROM pg_stat_database; WARNING: pgstat wait timeout datid | datname | numbackends | xact_commit | xact_rollback | blks_read | blks_hit | tup_returned | tup_fetched | tup_inserted | tup_updated | tup_deleted ---+---+-+-+---+ ---+--+--+-+--+- +- 11866 | template0 | 0 | 0 | 0 | 0 |0 |0 | 0 |0 | 0 | 0 11874 | postgres | 1 | 0 | 0 | 0 |0 |0 | 0 |0 | 0 | 0 214340298 | eims_ejb_total_50 | 3 | 0 | 0 | 0 |0 |0 | 0 |0 | 0 | 0 1 | template1 | 0 | 0 | 0 | 0 |0 |0 | 0 |0 | 0 | 0 (4 rows) --- configuration: listen_addresses = '*' port = 5432 max_connections = 100 shared_buffers = 512MB work_mem = 128MB maintenance_work_mem = 256MB effective_cache_size = 12288MB default_statistics_target = 1 log_destination = 'stderr' logging_collector = on log_directory = 'pg_log' log_truncate_on_rotation = on log_rotation_age = 1d log_rotation_size = 0 log_min_messages = warning log_min_duration_statement = 300 log_connections = off log_disconnections = off log_duration = off log_line_prefix = '%t [%p]: [%l-1] ' log_lock_waits = on track_counts = on log_planner_stats = on autovacuum = on log_autovacuum_min_duration = 300 autovacuum_max_workers = 3 autovacuum_naptime = 1min autovacuum_vacuum_threshold = 50 autovacuum_analyze_threshold = 50 autovacuum_vacuum_scale_factor = 0.2 autovacuum_analyze_scale_factor = 0.1 autovacuum_freeze_max_age = 2 autovacuum_vacuum_cost_delay = 20ms autovacuum_vacuum_cost_limit = -1 datestyle = 'iso, dmy' lc_messages = 'cs_CZ.utf8' lc_monetary = 'cs_CZ.utf8' lc_numeric = 'cs_CZ.utf8' lc_time = 'cs_CZ.utf8' default_text_search_config = 'pg_catalog.simple' custom_variable_classes = 'pljava' dynamic_library_path ='$libdir:/usr/local/postgresql-9.0.1/lib/postgresql' pljava.classpath='/usr/local/postgresql-9.0.1/lib/postgresql/pljava.jar:/usr /local/postgresql-9.0.1/lib/postgresql/jbossall-client.jar' - 8CPUs, 16G of RAM, uname -a gives: Linux tbdb-901 2.6.26-2-xen-amd64 #1 SMP Thu Sep 16 16:32:15 UTC 2010 x86_64 GNU/Linux -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5855: pgstat wait timeout
Ondrej Pachner ondrej.pach...@4internet.cz 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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5851: ROHS (read only hot standby) needs to be restarted manually in somecases.
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 value that high isn't be accepted?) I have reloaded configs and still seeing 0's I assume you would suggest I turn that number down... a lot. ..: Mark -Original Message- From: Robert Haas [mailto:robertmh...@gmail.com] Sent: Friday, January 28, 2011 6:48 AM To: Mark Cc: pgsql-bugs@postgresql.org Subject: Re: [BUGS] BUG #5851: ROHS (read only hot standby) needs to be restarted manually in somecases. On Wed, Jan 26, 2011 at 8:24 PM, Mark dvlh...@gmail.com 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 now in a month. 2011-01-26 08:35:42 MST :: (postgres@10.80.2.89) LOG: could not receive data from client: Connection reset by peer 2011-01-26 08:35:42 MST :: (postgres@10.80.2.89) LOG: unexpected EOF on standby connection this was all I have in the master's log with the level set to debug 1, I have reset it to debug 5 and will just wait till it dies again and hopefully get a better idea of what is going on. nothing is being logged to the standby. Maybe a break in network connectivity is leading the master to think that the slave is dead, while the slave still thinks it's connected. You might need to adjust the TCP keepalive parameters the slave uses to connect to the master. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
