[BUGS] BUG #7911: Equal vertices are not identified
The following bug has been logged on the website: Bug reference: 7911 Logged by: ST_Intersection and Equal to operator does not work consistently Email address: dgpli...@yahoo.com PostgreSQL version: 9.2.0 Operating system: Windows XP ,Windows 7 Description: The point below has equal x,y values with 3 Lines. ST_Intersection '=' operator returns only 2 of them POINT(-115.170246909479 36.0755731954767) LINESTRING(-115.16886866056 36.0749632293696,-115.169344063777 36.0751335573678,-115.170006424357 36.0754963465793,-115.170246909479 36.0755731954767) LINESTRING(-115.170246909479 36.0755731954767,-115.169804424035 36.0763443739938) LINESTRING(-115.170246909479 36.0755731954767,-115.170474133874 36.07567333046,-115.170951106408 36.0759910051809,-115.170983532364 36.076342785791) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] 8.4: COPY continues after client disconnects
Using PostgreSQL 8.4.13 on ScientificLinux 6.3 (x86_64), I noticed that a pg_dump ran out of (local) disk space. However, the server was still using CPU and disk resources. An strace clearly showed this pattern: read() = 8192 sendto(...) = -1 EPIPE -- SIGPIPE (Broken pipe) @ The server does detect the broken pipe. It logs the following messages: 637 LOG: 08006: could not send data to client: Connection reset by peer 638 LOCATION: internal_flush, pqcomm.c:1108 639 STATEMENT: COPY ... to stdout; 640 LOG: 08006: could not send data to client: Broken pipe 641 LOCATION: internal_flush, pqcomm.c:1108 642 STATEMENT: COPY ... to stdout; it ran until I killed it. -- Jon -- 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] Excessive space allocations in Postgresql 9.1.6 system files causing the file system to run out of space.
Not sure whymy emails replieswentout in HTML format, I'm re-sending the email trail to date. Thanks Andres for pointing this out. Freddie - Most recent Reply --- We did use pg_upgrade with the hard link option. We are not sure if we ran the cleanup script. Not sure which script you are referring to? Is that script the one that removes the stuff in the source bin directory?We did the pg_largeobject.sql script, as we were instructed by the pg_upgrade process. We also ran vacuum --all --analyzeonly Can we run this script now, even though its month's after we did the upgrade?Our tablespace structure to help sort out the previously sent directories list:CREATE TABLESPACE user_data LOCATION '/opt/PostgreSQL/9.1/data/user_data';CREATE TABLESPACE track_data_year_underflow LOCATION '/opt/PostgreSQL/9.1/data/track_data/year_underflow'; The "year_underflow" tablespace contains all data older than the oldest date.CREATE TABLESPACE track_data_y2010 LOCATION '/opt/PostgreSQL/9.1/data/track_data/year2010';CREATE TABLESPACE track_data-y2011 LOCATION '/opt/PostgreSQL/9.1/data/track_data/year2011';CREATE TABLESPACE track_data-y2012 LOCATION '/opt/PostgreSQL/9.1/data/track_data/year2012'; Original Message Subject: Re: [BUGS] Excessive space allocations in Postgresql 9.1.6system files causing the file system to run out of space.From: Kevin Grittner kgri...@ymail.comDate: Wed, February 27, 2013 1:16 pmTo: "fburg...@radiantblue.com" fburg...@radiantblue.com Please keep the list copied (use "Reply All"). When you do that, please describe how you upgraded. Was it with pg_upgrade? Did you use the hard link option? Did you run the cleanup script afterward? -Kevin From: "fburg...@radiantblue.com" fburg...@radiantblue.comTo: Kevin Grittner kgri...@ymail.com Sent: Wednesday, February 27, 2013 2:08 PMSubject: RE: [BUGS] Excessive space allocations in Postgresql 9.1.6 system files causing the file system to run out of space. I am looking in a variety of directories which include/opt/PostgreSQL/9.1/data/global/opt/PostgreSQL/9.1/data/base/16411/opt/PostgreSQL/9.1/data/user_data/PG_9.1_201105231/16411/opt/PostgreSQL/9.1/data/user_data/PG_9.1_201105231/16416/opt/PostgreSQL/9.1/data/user_data/19177/opt/PostgreSQL/9.1/data/track_data/year2010/19177/opt/PostgreSQL/9.1/data/track_data/year2010/PG_9.1_201105231/16411/opt/PostgreSQL/9.1/data/track_data/year2011/19177/opt/PostgreSQL/9.1/data/track_data/year2011/PG_9.1_201105231/16411/opt/PostgreSQL/9.1/data/track_data/year2012/19177/opt/PostgreSQL/9.1/data/track_data/year2012/PG_9.1_201105231/16411/opt/PostgreSQL/9.1/data/track_data/year2013/PG_9.1_201105231/16411/opt/PostgreSQL/9.1/data/track_data/year_underflow/19177/opt/PostgreSQL/9.1/data/track_data/year_underflow/PG_9.1_201105231/16411Everything in the .../19177 directories represent data files migrated over form postgres 8.4.3. All new files get placed into the .../PG_9.1_201105231/16411 directories.Yes, I exclude all files derived from pg_class that include an underscore or period.The vast majority of the "orphan" files are from the /opt/PostgreSQL/9.1/data/user_data/19177 directory. thanks Original Message Subject: Re: [BUGS] Excessive space allocations in Postgresql 9.1.6system files causing the file system to run out of space.From: Kevin Grittner kgri...@ymail.comDate: Wed, February 27, 2013 8:55 amTo: "fburg...@radiantblue.com" fburg...@radiantblue.com, "pgsql-bugs@postgresql.org" pgsql-bugs@postgresql.org "fburg...@radiantblue.com" fburg...@radiantblue.com wrote: We have a Postgres database that was recently upgraded from 8.4.3 to 9.1.6. We have noticed unusual growth in the data files and generated a script to perform the following actions. 1. Query pg_class for all records 2. Generate a file listing of all postgres data files 3. Compare the two lists and eliminate all files that are contained within pg_class There are 17359 data files. After running the script, there are 5802 data files remaining that are not listed in pg_class. Due to the size of the (5802) data files (~4TB), I am not comfortable about deleting them from the file system. Does postgres 9.1.6 catalog every data file in pg_class? Or does it leave some data files off of this table? If so, how can I determine if I have stale, unnecessary data files on my file system? Yeah, it's good to be cautious -- deleting a needed file can renderyour database cluster unusable. Be sure you have a good backup youcan go back to if you delete the wrong thing. What directories are you looking in? For a database or tablespace directory, are you excluding all fileswhich start with a filename you derived from pg_class and has a dotor underscore followed by more characters? --Kevin GrittnerEnterpriseDB: http://www.enterprisedb.comThe Enterprise PostgreSQL Company Original Message Subject: Re: [BUGS] Excessive space allocations in Postgresql
Re: [BUGS] Excessive space allocations in Postgresql 9.1.6 system files causing the file system to run out of space.
fburg...@radiantblue.com fburg...@radiantblue.com wrote: We did use pg_upgrade with the hard link option. We are not sure if we ran the cleanup script. Can we run this script now, even though its month's after we did the upgrade? Everything in the .../19177 directories represent data files migrated over form postgres 8.4.3. All new files get placed into the .../PG_9.1_201105231/16411 directories. The vast majority of the orphan files are from the /opt/PostgreSQL/9.1/data/user_data/19177 directory. I don't have any reason to expect that you *can't* run the script at this point; but being a cautious person, I would do this at a point where I was confident I could recover from a backup, and I would read through the scripts carefully before applying them. What you want to be really careful that you *don't* do is to modify or truncate any of the hard-linked files, as they are quite likely to still be just another name for the same file that is in use for production under the newer version. You want to simply remove the older directory entry pointing to the file. http://www.linfo.org/hard_link.html -- Kevin Grittner 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] Excessive space allocations in Postgresql 9.1.6 system files causing the file system to run out of space.
Hi Kevin, Do you know the name that was given to the cleanup script? thanks Original Message Subject: Re: [BUGS] Excessive space allocations in Postgresql 9.1.6system files causing the file system to run out of space.From: Kevin Grittner kgri...@ymail.comDate: Fri, March 01, 2013 9:00 amTo: "fburg...@radiantblue.com" fburg...@radiantblue.com, AndresFreund and...@2ndquadrant.comCc: "pgsql-bugs@postgresql.org" pgsql-bugs@postgresql.org"fburg...@radiantblue.com" fburg...@radiantblue.com wrote: We did use pg_upgrade with the hard link option. We are not sure if we ran the cleanup script. Can we run this script now, even though its month's after we did the upgrade? Everything in the .../19177 directories represent data files migrated over form postgres 8.4.3. All new files get placed into the .../PG_9.1_201105231/16411 directories. The vast majority of the "orphan" files are from the /opt/PostgreSQL/9.1/data/user_data/19177 directory.I don't have any reason to expect that you *can't* run the scriptat this point; but being a cautious person, I would do this at apoint where I was confident I could recover from a backup, and Iwould read through the scripts carefully before applying them.What you want to be really careful that you *don't* do is to modifyor truncate any of the hard-linked files, as they are quite likelyto still be just another name for the same file that is in use forproduction under the newer version. You want to simply remove theolder directory entry pointing to the file.http://www.linfo.org/hard_link.html-- Kevin GrittnerEnterpriseDB: http://www.enterprisedb.comThe 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
