Обсуждение: Stalled post to pgsql-bugs
Dear Sir I have got the following error message when connecting postgres from postgres admin connecting form the localhost (only special thing in machine configuration is attached the 2 network cards to the installation machine) could not connect to server: Connection refused (0x0000274D/10061) Is the server running on host "127.0.0.1" and accepting TCP/IP connections on port 5432? If you encounter this message, please check if the server you're trying to contact is actually running PostgreSQL on the given port. Test if you have network connectivity from your client to the server host using ping or equivalent tools. Is your network / VPN / SSH tunnel / firewall configured correctly? You probably have some low level network connectivity problems (e.g. firewall please let me how to resolve this problem permanently we have got this error message time by time but not always run the postgresSQL service using the .\postgres account when start up the machine Thanks
On Fri, Aug 14, 2009 at 1:35 AM, Saneera Gunasekara<saneera@apturion.com> wrote: > > Dear Sir > > I have got the following error message when connecting postgres from > postgres admin connecting form the localhost > (only special thing in machine configuration is attached the 2 network cards > to the installation machine) > > could not connect to server: Connection refused (0x0000274D/10061) > Is the server running on host "127.0.0.1" and > > accepting TCP/IP connections on port 5432? > > If you encounter this message, please check if the server you're trying to > contact is > > actually running PostgreSQL on the given port. > > Test if you have network connectivity from your client to the server host > using ping or > > equivalent tools. Is your network / VPN / SSH tunnel / firewall configured > correctly? > > You probably have some low level network connectivity problems (e.g. > firewall > > please let me how to resolve this problem permanently we have got this error > message time by time but not always run the postgresSQL service using the > .\postgres account when start up the > machine Maybe you should follow the directions given in the error message. They are fairly detailed. If you can't figure it out, you could ask for help on pgsql-general or pgsql-novice, but you're going to need to provide a lot more information about what you tried and what happened. In any event, this is neither a bug nor a security issue, so I don't think you should be sending it to these lists. ...Robert
Hi: I met a problem about postgres, please check the info belows, thanks in advance. > > PostgreSQL version: 8.3.8-1 > Operating system: windows 2000 > Description: postgresql crash always > > Details: > > My program will use postgresal database, after start my program ,I find it > hangs always, so I check the db log,and find these exception: > > 2010-07-27 14:08:22 EDT LOG: loaded library > "$libdir/plugins/plugin_debugger.dll" > 2010-07-27 14:08:22 EDT LOG: loaded library > "$libdir/plugins/plugin_debugger.dll" > 2010-07-27 14:08:22 EDT LOG: CreateProcess call failed: A blocking > operation was interrupted by a call to WSACancelBlockingCall. > > (error code 5) > 2010-07-27 14:08:22 EDT LOG: could not fork new process for connection: A > blocking operation was interrupted by a call to WSACancelBlockingCall. > > > 2010-07-27 14:08:23 EDT LOG: CreateProcess call failed: A blocking > operation was interrupted by a call to WSACancelBlockingCall. > > (error code 5) > 2010-07-27 14:08:23 EDT LOG: could not fork new process for connection: A > blocking operation was interrupted by a call to WSACancelBlockingCall. > > ...(fill of this exception) > > -- Best Regard
After further testing, this test case should be refined to throw NO_DATA_FOUND errors from the INTO STRICT clause to produce the memory leak.
In pl_exec.c, exec_stmt_execsql does not free the SPI_tuptable by calling SPI_freetuptable before the ereport. Attached is a patch to 9.2-STABLE that seems to resolve it.
Вложения
Ok. There is a problem with the patches that went in between Postgres 9.4.3->9.4.4 I downgraded to Postgres 9.4.3 and everythig is normal. "Actual disk writes" in iostat is pretty much as "Total disk writes" (between 50-100 Kbps and not in Mbps). "vmstat 1" also shows no excessive disk writes. I am using postgres 9.4.3 on Gentoo linux along with uwsgi, python 2.7 and nginx. -Sushant. On Thu, Jul 23, 2015 at 10:27 AM, <pgsql-bugs-owner@postgresql.org> wrote: > Your message to pgsql-bugs has been delayed, and requires the approval > of the moderators, for the following reason(s): > > The author (sushant@indiankanoon.com) > is not a member of any of the restrict_post groups. > > If you do not wish the message to be posted, or have other concerns, > please send a message to the list owners at the following address: > pgsql-bugs-owner@postgresql.org > > > ---------- Forwarded message ---------- > From: sushant@indiankanoon.com > To: pgsql-bugs@postgresql.org > Cc: > Date: Thu, 23 Jul 2015 04:56:17 +0000 > Subject: BUG #13515: Much higher disk writes after postgres upgrade > 9.4.3->9.4.4 > The following bug has been logged on the website: > > Bug reference: 13515 > Logged by: Sushant Sinha > Email address: sushant@indiankanoon.com > PostgreSQL version: 9.4.4 > Operating system: Linux > Description: > > After upgrade from postgres 9.4.3 to 9.4.4 I am seeing constant disk writes > of 4-8MB/s in the background in production. I verified it using iotop and > vmstat. iotop shows "Total Disk Write" to be minuscule (like 10-100Kbps). > It > is affecting runtime performance. I never noticed this issue with postgres > 9.4.3. > > I increased the shared buffers from 128MB to 1GB and still didn't see any > benefit. > > The website (http://indiankanoon.org) mostly uses text search with gin > index > and some logging of click through data. The main database is replicated > using "streaming asynchronous replication". > > I am going to downgrade it to 9.4.3 to see if the upgrade was the real > problem. But just wanted to check if anyone else noticed it. > > >
Sushant Sinha <sushant@indiankanoon.com> wrote: > On Thu, Jul 23, 2015 at 10:27 AM, <pgsql-bugs-owner@postgresql.org> wrote: >> After upgrade from postgres 9.4.3 to 9.4.4 I am seeing constant disk writes >> of 4-8MB/s in the background in production. I verified it using iotop and >> vmstat. iotop shows "Total Disk Write" to be minuscule (like 10-100Kbps). It >> is affecting runtime performance. I never noticed this issue with postgres >> 9.4.3. >> >> I increased the shared buffers from 128MB to 1GB and still didn't see any >> benefit. >> >> The website (http://indiankanoon.org) mostly uses text search with gin index >> and some logging of click through data. The main database is replicated >> using "streaming asynchronous replication". >> >> I am going to downgrade it to 9.4.3 to see if the upgrade was the real >> problem. But just wanted to check if anyone else noticed it. > Ok. There is a problem with the patches that went in between > Postgres 9.4.3->9.4.4 > > I downgraded to Postgres 9.4.3 and everythig is normal. "Actual > disk writes" in iostat is pretty much as "Total disk writes" > (between 50-100 Kbps and not in Mbps). "vmstat 1" also shows no > excessive disk writes. Did you notice whether it was an autovacuum process causing the additional I/O in 9.4.4? There were some bugs in 9.4.3 that failed to vacuum away old multi-transaction tracking structures in a timely fashion, causing data loss and database corruption. Once you upgraded a background task was probably trying to make up for the lack of timely maintenance, so that you would not experience those problems. Downgrading may be a little faster for a little while, but you're almost certain to regret doing it very soon.... -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company