Thread: pgpool ABORT + no transaction warning
A while back, I posted about seeing a number of warnings from pgpool: http://archives.postgresql.org/pgsql-admin/2005-03/msg00305.php A typical pair of statements in my postgres logs looks like this: WARNING: there is no transaction in progress STATEMENT: ABORT Tatsuo Ishii declared that these were harmless, and I took (and still take) his word for it. At some point in the past with my old configuration (postgres 8.1.3 / pgpool 2.5.1) I did something that prevented the warnings from showing up. On a system running postgres 8.1.3, I recently upgraded pgpool from 2.5.1 to 3.0.1. When I upgraded pgpool, I began seeing the warnings again after a long window of not having seen them. My configuration files for pgpool and postgres didn't change during the upgrade, so I'm wondering what I might've been doing to avoid polluting my logs with them previously and why they are showing up again. pgpool itself seems to be working fine after the upgrade, so as long as the warnings are harmless, it's not a big deal, but I'd like a clean method of preventing log noise if one exists. -- Thomas F. O'Connell Database Architecture and Programming Co-Founder Sitening, LLC http://www.sitening.com/ 3004 B Poston Avenue Nashville, TN 37203-1314 615-260-0005 (cell) 615-469-5150 (office) 615-469-5151 (fax)
> A while back, I posted about seeing a number of warnings from pgpool: > > http://archives.postgresql.org/pgsql-admin/2005-03/msg00305.php > > A typical pair of statements in my postgres logs looks like this: > > WARNING: there is no transaction in progress > STATEMENT: ABORT > > Tatsuo Ishii declared that these were harmless, and I took (and still > take) his word for it. > > At some point in the past with my old configuration (postgres 8.1.3 / > pgpool 2.5.1) I did something that prevented the warnings from > showing up. On a system running postgres 8.1.3, I recently upgraded > pgpool from 2.5.1 to 3.0.1. When I upgraded pgpool, I began seeing > the warnings again after a long window of not having seen them. My > configuration files for pgpool and postgres didn't change during the > upgrade, so I'm wondering what I might've been doing to avoid > polluting my logs with them previously and why they are showing up > again. > > pgpool itself seems to be working fine after the upgrade, so as long > as the warnings are harmless, it's not a big deal, but I'd like a > clean method of preventing log noise if one exists. Could you tell me how to reproduce the problem? -- Tatsuo Ishii SRA OSS, Inc. Japan
The problem is not reproduced here. Do you have any idea how to reproduce it? -- Tatsuo Ishii SRA OSS, Inc. Japan > On Apr 1, 2006, at 8:01 AM, Tatsuo Ishii wrote: > > >> A while back, I posted about seeing a number of warnings from pgpool: > >> > >> http://archives.postgresql.org/pgsql-admin/2005-03/msg00305.php > >> > >> A typical pair of statements in my postgres logs looks like this: > >> > >> WARNING: there is no transaction in progress > >> STATEMENT: ABORT > >> > >> Tatsuo Ishii declared that these were harmless, and I took (and still > >> take) his word for it. > >> > >> At some point in the past with my old configuration (postgres 8.1.3 / > >> pgpool 2.5.1) I did something that prevented the warnings from > >> showing up. On a system running postgres 8.1.3, I recently upgraded > >> pgpool from 2.5.1 to 3.0.1. When I upgraded pgpool, I began seeing > >> the warnings again after a long window of not having seen them. My > >> configuration files for pgpool and postgres didn't change during the > >> upgrade, so I'm wondering what I might've been doing to avoid > >> polluting my logs with them previously and why they are showing up > >> again. > > > > Could you tell me how to reproduce the problem? > > Here's what happened: I performed an on-line backup and recovery to > move postgres from one server to another. On the new server, I > installed pgpool 3.0.1 and copied over my old configuration files. > > I have two instances of pgpool running on the server and am only > using pgpool for connection pooling, not load balancing or > replication. The only three settings that are different between the > two configurations are port, logdir, and num_init_children. > > Below is one pgpool.conf (with a few paths changed back to the > defaults just for obfuscation), which doesn't include > child_max_connections, insert_lock, or ignore_leading_white_space > because I just used my 2.5.1 configuration file. I assume it would > just use defaults for these values if they weren't specified in the > file? > > listen_addresses = '*' > port = 9999 > socket_dir = '/tmp' > backend_host_name = '' > backend_port = 5432 > backend_socket_dir = '/tmp' > secondary_backend_host_name = '' > secondary_backend_port = 0 > num_init_children = 64 > max_pool = 4 > child_life_time = 300 > connection_life_time = 10 > logdir = '/tmp/pgpool1' > replication_mode = false > replication_strict = true > replication_timeout = 5000 > load_balance_mode = false > weight_master = 0.5 > weight_secondary = 0.5 > replication_stop_on_mismatch = false > reset_query_list = 'ABORT; RESET ALL; SET SESSION AUTHORIZATION DEFAULT' > print_timestamp = true > master_slave_mode = false > connection_cache = true > health_check_timeout = 20 > health_check_period = 0 > health_check_user = 'nobody' > > -- > Thomas F. O'Connell > Database Architecture and Programming > Co-Founder > Sitening, LLC > > http://www.sitening.com/ > 3004 B Poston Avenue > Nashville, TN 37203-1314 > 615-260-0005 (cell) > 615-469-5150 (office) > 615-469-5151 (fax) >
On Apr 3, 2006, at 3:05 AM, Tatsuo Ishii wrote: > The problem is not reproduced here. Do you have any idea how to > reproduce it? If I did, I'd resolve it. :P I suppose I can try restarting the connection pools on this server just to see what happens. If I am able to do that, I will post the results. -- Thomas F. O'Connell Database Architecture and Programming Co-Founder Sitening, LLC http://www.sitening.com/ 3004 B Poston Avenue Nashville, TN 37203-1314 615-260-0005 (cell) 615-469-5150 (office) 615-469-5151 (fax) >> On Apr 1, 2006, at 8:01 AM, Tatsuo Ishii wrote: >> >>>> A while back, I posted about seeing a number of warnings from >>>> pgpool: >>>> >>>> http://archives.postgresql.org/pgsql-admin/2005-03/msg00305.php >>>> >>>> A typical pair of statements in my postgres logs looks like this: >>>> >>>> WARNING: there is no transaction in progress >>>> STATEMENT: ABORT >>>> >>>> Tatsuo Ishii declared that these were harmless, and I took (and >>>> still >>>> take) his word for it. >>>> >>>> At some point in the past with my old configuration (postgres >>>> 8.1.3 / >>>> pgpool 2.5.1) I did something that prevented the warnings from >>>> showing up. On a system running postgres 8.1.3, I recently upgraded >>>> pgpool from 2.5.1 to 3.0.1. When I upgraded pgpool, I began seeing >>>> the warnings again after a long window of not having seen them. My >>>> configuration files for pgpool and postgres didn't change during >>>> the >>>> upgrade, so I'm wondering what I might've been doing to avoid >>>> polluting my logs with them previously and why they are showing up >>>> again. >>> >>> Could you tell me how to reproduce the problem? >> >> Here's what happened: I performed an on-line backup and recovery to >> move postgres from one server to another. On the new server, I >> installed pgpool 3.0.1 and copied over my old configuration files. >> >> I have two instances of pgpool running on the server and am only >> using pgpool for connection pooling, not load balancing or >> replication. The only three settings that are different between the >> two configurations are port, logdir, and num_init_children. >> >> Below is one pgpool.conf (with a few paths changed back to the >> defaults just for obfuscation), which doesn't include >> child_max_connections, insert_lock, or ignore_leading_white_space >> because I just used my 2.5.1 configuration file. I assume it would >> just use defaults for these values if they weren't specified in the >> file? >> >> listen_addresses = '*' >> port = 9999 >> socket_dir = '/tmp' >> backend_host_name = '' >> backend_port = 5432 >> backend_socket_dir = '/tmp' >> secondary_backend_host_name = '' >> secondary_backend_port = 0 >> num_init_children = 64 >> max_pool = 4 >> child_life_time = 300 >> connection_life_time = 10 >> logdir = '/tmp/pgpool1' >> replication_mode = false >> replication_strict = true >> replication_timeout = 5000 >> load_balance_mode = false >> weight_master = 0.5 >> weight_secondary = 0.5 >> replication_stop_on_mismatch = false >> reset_query_list = 'ABORT; RESET ALL; SET SESSION AUTHORIZATION >> DEFAULT' >> print_timestamp = true >> master_slave_mode = false >> connection_cache = true >> health_check_timeout = 20 >> health_check_period = 0 >> health_check_user = 'nobody'