Re: [BUGS] BUG #5364: citext behavior when type not in public schema
Bruce Momjian writes: > I have documented this citext limitation with the attached, applied > patch. Are you planning to insert similar verbiage into every other contrib module's docs? 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 #5364: citext behavior when type not in public schema
Robert Haas wrote: > On Fri, Mar 5, 2010 at 5:24 AM, Markus Wichitill wrote: > > > > The following bug has been logged online: > > > > Bug reference: ? ? ?5364 > > Logged by: ? ? ? ? ?Markus Wichitill > > Email address: ? ? ?ma...@gmx.de > > PostgreSQL version: 8.4.2 > > Operating system: ? Linux, Win7 > > Description: ? ? ? ?citext behavior when type not in public schema > > Details: > > > > Comparisons with columns of type citext silently work case-sensitively > > without any error message, unless the search_path contains "public", even if > > the type is not located in "public", but in the same schema as the table > > using it. > > Interestingly we recently got another report of this same problem. > Tom did some analysis of it here: > > http://archives.postgresql.org/pgsql-bugs/2010-03/msg00017.php I have documented this citext limitation with the attached, applied patch. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. + Index: doc/src/sgml/citext.sgml === RCS file: /cvsroot/pgsql/doc/src/sgml/citext.sgml,v retrieving revision 1.2 diff -c -c -r1.2 citext.sgml *** doc/src/sgml/citext.sgml 12 Sep 2008 18:29:49 - 1.2 --- doc/src/sgml/citext.sgml 3 Jun 2010 03:02:48 - *** *** 205,210 --- 205,219 will need two indexes if you want both types of searches to be fast. + + + + The schema containing the citext operators must be + in the current search_path (typically public); + if it is not, a normal case-sensitive text comparison + is performed. + + -- 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] Support on Postgres Database Corruption
On Wed, Jun 2, 2010 at 8:38 AM, botak wrote: > Dear sirs, > > Referring to the matter above. > > For your information, we are a government agency and been hosting a > management system since 2006. The system was developed with Postgres Sql and > PHP in Centos Platform. Recently, after a power failure, all the latest data > from system were missing and the system starts to redirect to older data. > However we manage to find the location of the missing data but failed to > rejoin to system as it seems to be corrupted. > > I hope you can solve the problem. > > PostgreSQL 7.4.8 on i686-redhat-linux-gnu, compiled by GCC gcc (GCC) 3.4.3 > 20050227 (Red Hat 3.4.3-22) > Hi, Can you please give some more info so someone can help you? 1) where do you "find the location of the missing data"? and how were you trying to rejoint it? 2) how do you determine it is corrupted? 3) it gives you some error messages? which one? 4) How old is the data that you loss? 5) are you aware that you have to have write-cache disabled on your disks in other to assure the data get it to the disk? 6) how frequent are you executing VACUUM? -- Jaime Casanova www.2ndQuadrant.com Soporte y capacitación de PostgreSQL -- 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] canceling statement due to user request
"Spangler, Todd" wrote: > canceling statement due to user request > I cannot seem to fix. Your application is canceling queries, probably because they're not completing as quickly as it wants them to; that's not a PostgreSQL bug. You should probably gather a bit more information and post to the pgsql-performance list, to see what you can do to improve the query speed. > I have read that this may have something to do with the Autovacuum > feature. Probably not -- at least not directly. It's possible that you aren't vacuuming aggressively enough, and therefore suffer poor performance from bloat, but at this point, that's just conjecture. > It seems the errors do not happen every time. What pattern is there? Do they come in clusters? Is it particular queries? Is it particular search arguments for a query? > If this is the Autovacuum feature, is there a way that I can > disable this feature and then re-enable it when I am done with the > creation of my report? That would probably be counter-productive, although setting autovacuum cost limits to pace the vacuums might possibly be useful. > Also, when we receive these errors, it does not save any > information to the text file like it normally would without the > error message, so we do not get the report we need when these > errors occur. What text file is that? With our configuration, we *do* see statement text for these in the PostgreSQL log files. > Another thought would be for us to allow the Autovacuum to be > turned on only at certain times. That would be pretty risky, and probably counter-productive. > I have read that these messages are by design I'm curious what you read. Can you share a URL? > I need an easy to use workaround that will allow the reports to > work. These reports are very important to the company. Please read these pages and post again to a different list with more detail: http://wiki.postgresql.org/wiki/Guide_to_reporting_problems http://wiki.postgresql.org/wiki/SlowQueryQuestions In particular, since this could be related to checkpoints, it is important to have a good description of your hardware, especially your disk storage system, and all settings in your postgresql.conf file (excluding all comments). -Kevin -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] canceling statement due to user request
Dear PostgreSQL, I have been working with a web application that allows saving of reports to a text file using PostgreSQL. The application has worked fine for about 6 months and now we are getting the following 2 error messages: canceling statement due to statement timeout canceling statement due to user request In development, I seem to have been able to keep the timeout messagebox from showing up by adding a timeout to the connectionstring, but the other error I cannot seem to fix. I have read that this may have something to do with the Autovacuum feature. We are using PostgreSQL version 8.3. I'm testing with 8.4 on another server and still am getting the messages above. It seems the errors do not happen every time. If this is the Autovacuum feature, is there a way that I can disable this feature and then re-enable it when I am done with the creation of my report? Also, when we receive these errors, it does not save any information to the text file like it normally would without the error message, so we do not get the report we need when these errors occur. Another thought would be for us to allow the Autovacuum to be turned on only at certain times. That would be fine for our situation. I have read that these messages are by design and I am fine with that, but I need an easy to use workaround that will allow the reports to work. These reports are very important to the company. We are using Windows Servers and Windows XP, C#.Net 2008 - ASP.Net, and PostgreSQL 8.3. Thank you for your time, Todd Spangler COMSYS - A Manpower Company 804-521-5288
[BUGS] Support on Postgres Database Corruption
Dear sirs, Referring to the matter above. For your information, we are a government agency and been hosting a management system since 2006. The system was developed with Postgres Sql and PHP in Centos Platform. Recently, after a power failure, all the latest data from system were missing and the system starts to redirect to older data. However we manage to find the location of the missing data but failed to rejoin to system as it seems to be corrupted. I hope you can solve the problem. PostgreSQL 7.4.8 on i686-redhat-linux-gnu, compiled by GCC gcc (GCC) 3.4.3 20050227 (Red Hat 3.4.3-22)
Re: [BUGS] BUG #5484: sum() bug
Many thanks for the help! numeric is my choice :) 01.06.10, 19:19, "Kevin Grittner" : > Robert Haas wrote: > > On Tue, Jun 1, 2010 at 9:24 AM, viras wrote: > > >> What type of the data is better for using? Numbers up to 10 > >> and accuracy of 2 fractional signs. > > > > numeric is a good choice to avoid loss of precision, but can be a > > bit slower. > > > > You could also try float8. > > Yeah, as long as you remember that this is an *approximate* data > type. If you really mean that you're satisfied with an *accuracy* > of two fractional digits for a number up to 10, you are OK. But > realize that means that 1.01 would actually be > 1.0100088817841970012523233890533447265625 and that > 10.01 would actually be > 10.0094761310517787933349609375 -- accurate to far more > than two decimal digits, but not *exact*. > > If you want exact values based on decimal fractions, you should use > numeric. > > -Kevin > > -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
