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 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
Re: [BUGS] BUG #5855: pgstat wait timeout
"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@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 #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 http://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
Re: [BUGS] BUG #5854: base64 decode returns bytea and no text
"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 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] A bug to report
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 lnux server with the client > applicaions on our lab systems. > It has been repeatedly observed that whenever a connection to the sever is > released/cut off the client app automatically gets closed( may be the > procress gets dead/hang and the app gets closed) > > kindly see to the problem , we really love working on pgadmin but this bug > removes all our status and all the query gets lost. > > Hope you will see to the matter. I seem to remember something like this being reported before, but I don't remember the details. You might try here: http://archives.postgresql.org/pgadmin-support/ -- 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
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 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] 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