Re: [BUGS] BUG #4267: initdb fails
Dave Page wrote: Yeah - unfortunately though recent experience with similar hard-to-find bugs have not normally shown up in PM. They've been much more subtle, usually requiring much poking around in Process Explorer which is difficult to do via email. Alas, Process Explorer doesn't seem to work on Vista. MS think that Process monitor is a replacement, but it lacks all the handy detailed process introspection, thread control, etc that Process Explorer has. Frustrating. -- Craig Ringer -- 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 #4267: initdb fails
Dave Page wrote: On Fri, Jun 27, 2008 at 6:26 PM, Craig Ringer <[EMAIL PROTECTED]> wrote: Alas, Process Explorer doesn't seem to work on Vista. MS think that Process monitor is a replacement, but it lacks all the handy detailed process introspection, thread control, etc that Process Explorer has. Frustrating. Eh? Process Monitor certainly works on Vista (although I haven't used it on SP1 yet). I used it extensively when trying to figure out a rather nasty bug issue in our privilege-shedding code a while back. Interesting. I've always had system stability problems after launching either it or filemon. I'm about to configure a clean Vista install (post hard disk failure) so I'll have to re-test. Perhaps there was a hook DLL or similar nastyness interfering. -- Craig Ringer -- 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 #4267: initdb fails
Craig Ringer wrote: Dave Page wrote: On Fri, Jun 27, 2008 at 6:26 PM, Craig Ringer <[EMAIL PROTECTED]> wrote: Alas, Process Explorer doesn't seem to work on Vista. MS think that Process monitor is a replacement, but it lacks all the handy detailed process introspection, thread control, etc that Process Explorer has. Frustrating. Eh? Process Monitor certainly works on Vista (although I haven't used it on SP1 yet). I used it extensively when trying to figure out a rather nasty bug issue in our privilege-shedding code a while back. Interesting. I've always had system stability problems after launching either it or filemon. I'm about to configure a clean Vista install (post hard disk failure) so I'll have to re-test. Perhaps there was a hook DLL or similar nastyness interfering. Sorry, I just re-read your mail and noticed you said process monitor, not explorer. I've had issues with process *Explorer* on Vista. Process monitor works perfectly, but seems to lack some of the features of process explorer. This could have been system configuration specific, but I've seen enough reports to think it's probably not. Anyway, this is way off topic. -- Craig Ringer -- 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 #4317: problem with comparision of datatype date
Sanjay Rajdev wrote: If I execute "select * from myTable where somedate between '2008-07-18' and '2008-07-18'" I get all 277 rows. I'm not able to help you out directly (just another user) but answering the following questions might help others: - What was the previous database version? - Can you provide DDL for the table? - What is the exact data type of the field `somedate' ? -- Craig Ringer -- 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] winsock error 10004
Cédric Villemain wrote: Hi, I get the following error with postgresql 8.2.7 on a "Microsoft windows server 2003 R2 Standard Edition Service pack 1" : « LOG: could not rename temporary statistics file "global/pgstat.tmp" to "global/pgstat.stat": Unknown winsock error 10004 » It happens frequently, without using SSL (I have seen some post relative to SSL with windows). Any idea ? The usual question with weird Windows errors: Do you have a virus scanner? If so, have you tried completely disabling it or uninstalling it (NOT just excluding PostgreSQL) and re-tested? -- Craig Ringer -- 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 #4322: Problems with field not updatable
Alexandre Caneo wrote: When I select the datas with this instruction "select a.x from a,b where a.z = b.z order by 1" the program run very well and I can insert, update and delete rows. But, when I select any column from table b an error occurs when I try to modify the column value from textbox for an example. "Binding Collection Error. field not updatable". Maybe you should try your query from psql, and see if it works fine there. If it does, then you know the problem is in your data access driver or application. At a guess, I'd say you'll be having issues with data type support in the data access driver. You are using a prehistoric programming language, which won't be helping. You should post your query (if it's generated by your app at runtime, get it by enabling query logging in the database and fishing it out of the PostgreSQL log) and the schema definition of the problem table as obtained with psql's \d command. -- Craig Ringer -- 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] Error while loading shared libraries
[EMAIL PROTECTED] wrote: > Hello, > I have installed postgresql, version 8.3.3. Some information you left out would be useful, such as: - Operating system - Version of operating system - How you obtained and installed PostgreSQL (from where, how you built it if you built it yourself, etc) - ... and anything else that seems relevant. > and when I run: su -l postgres > -c "/usr/local/pgsql/bin/createuser -d -a nobody", I get this error: > > sh-2.05b# su -l postgres -c "/usr/local/pgsql/bin/createuser -d -a nobody" > /usr/local/pgsql/bin/createuser: error while loading shared libraries: > libz.so.1: cannot open shared object file: No such file or directory > > However, this library is there..: > sh-2.05b# su -l postgres -c "echo $LD_LIBRARY_PATH" > /lib:/usr/lib:/opt/IBM-ME-2.2.2/jre/bin:/usr/local/pgsql/lib Hmm... if you're on Linux (at least, any faintly sensible Linux flavour) you shouldn't need /lib or /usr/lib in LD_LIBRARY_PATH, as they're configured to be searched by default in /etc/ld.so.conf . > So I was wondering if you guys could help me! I do not know what is wrong > :-( > Is createuser not looking at LD_LIBRARY_PATH for its libraries? In this case it shouldn't have to. The error you're encountering does indeed seem rather odd, though. What's the output of: su -l postgres -c "ldd /usr/local/pgsql/bin/createuser" ? If you're on a glibc system (essentially all Linux, at least) try using LD_DEBUG to trace the linker's operation, too, and see if that tells you anything useful: LD_DEBUG="libs,files" su -l postgres "" See this page for a simple summary: http://www.wlug.org.nz/LD_DEBUG It looks like it's similar on Solaris, too: http://docsun.cites.uiuc.edu/sun_docs/C/solaris_9/SUNWdev/LLM/p18.html -- Craig Ringer -- 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 #4335: Error w/ PostgreSQL & EnterpriseDB Stack Builder
Mary Kealey wrote: > The following bug has been logged online: > > Bug reference: 4335 > Logged by: Mary Kealey > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.3 > Operating system: Windows XP > Description:Error w/ PostgreSQL & EnterpriseDB Stack Builder > Details: > > I launched PostgreSQL & EnterpriseDB Stack Builder and get the error "Failed > to open the application list: http://www.postgresql.org/applications.xml > Error: The URL specified could not be opened. Do you have a software firewall? If so, is it configured to permit the stack builder to access the Internet? Are you behind a proxy server that might limit access to some files? Did you do a tcpdump or use wireshark to record the network communication between client and server? If not, consider doing so. -- Craig Ringer -- 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 #4368: problem with jdbc postgresql
devi wrote: > its really much confusing in connectivity..please help me giving answers to > this question > > 1. where to save postgresql-8.2-508.jdbc3 > (all have giving different ideas) > > 2.how to set the class path?is i have to download tomcate > > 3.can you please give me a clear picture to set class > path with postgresql-8.2-508.jdbc3 > > 4. how to run my java application files Your question does not describe a bug or problem with PostgreSQL or its JDBC drivers. Your questions are all covered in the documentation for the JDBC driver and as a part of very basic Java use. You should read: http://doc.postgresintl.com/jdbc/index.html http://java.sun.com/docs/books/tutorial/ http://java.sun.com/docs/books/tutorial/jdbc/index.html Then, if you are still having problems, use Google to search for information about your problem. If you STILL cannot find the answer and the question is about PostgreSQL and Java/JDBC, consider posting a question on the PostgreSQL JDBC mailing list. -- Craig Ringer -- 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 #4374: pg_restore does not restore public schema comment
Tom Lane wrote: > "Daniel Migowski" <[EMAIL PROTECTED]> writes: >> Currently a schema dump (custom format, containing the public schema >> comment) can be restored, but the public schema version is not restored. > >> I assume you check if a schema already exists and the skip the schema part. > > That assumption is false, so it's not entirely clear to me exactly what > you are complaining about. Please provide a specific test case --- what > did you do, what happened, what would you like to happen instead? The issue actually appears to be that the comment on default schema like `public' isn't dumped in the first place. Setup: CREATE DATABASE re; \c re COMMENT ON SCHEMA public IS 'public comment'; CREATE SCHEMA testschema; COMMENT ON SCHEMA testschema IS 'testschema comment'; \q \dn+ shows the comments as set on schema `public' and `testschema'. The output of: pg_dump re includes the statement: COMMENT ON SCHEMA testschema IS 'testschema comment'; but lacks any COMMENT statement for the `public' schema. So: the user's report is incorrect in blaming pg_restore, but correct in that comments on the public schema (and presumably other default schema) aren't preserved by pg_dump | pg_restore. The real reason appears to be that they're not dumped in the first place. I haven't checked to see if a custom dump behaves differently. -- Craig Ringer -- 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 #4384: jdbc driver not working
lakshmidevi wrote: > The following bug has been logged online: > > Bug reference: 4384 > Logged by: lakshmidevi > Email address: [EMAIL PROTECTED] > PostgreSQL version: postgresql 8.2 > Operating system: windows Xp > Description:jdbc driver not working > Details: > > am uing postgresql-8.2-508.jdbc3.jar > > WHEN I RUN THE JDBC3 JAR FILE IN XP IT SHOWS ERROR LIKE THIS > > C:\Program Files\Java\jdk1.5.0_14\jre\lib\ext>set > CLASSPATH=%CLASSPATH%;C:\Progr > am Files\Java\jdk1.5.0_14\lib\ext\postgresql-8.2-508.jdbc3.jar > > C:\Program Files\Java\jdk1.5.0_14\jre\lib\ext>java -jar > postgresql-8.2-508.jdbc3 > .jar > Failed to load Main-Class manifest attribute from > postgresql-8.2-508.jdbc3.jar You can't "run" the JDBC jar. It's not a standalone Java executable. Read the PostgreSQL JDBC documentation to find out how to use it. If you still need help, consider posting on the JDBC list, but do make sure to read the manual first. -- Craig Ringer -- 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 #4409: postmaster service is stopped
prasana venkatesh wrote: The following bug has been logged online: Bug reference: 4409 Logged by: prasana venkatesh Email address: [EMAIL PROTECTED] PostgreSQL version: pg3 Operating system: linux Description:postmaster service is stopped Details: how to start postgrey post master service manually This appears to be a question, not a bug report. You've also provided far too little information - "linux" is not an operating system, it is a kernel. Please post to the pgsql-general mailing list with a detailed question that explains what you're trying to do, what you've tried, and what went wrong. Specify your operating system (eg "Ubuntu 8.04") and PostgreSQL version (eg "8.3.1") as well as how you installed postgresql, and anything else that you can see might be relevant. -- Craig Ringer -- 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 #4433: entries like "host all all 10.0.50.31/0 ..." should not be allowed or trigger a warning
security improvement proposal: pg_hba.conf and CIDR mask wrote: > The following bug has been logged online: > > Bug reference: 4433 > Logged by: security improvement proposal: pg_hba.conf and CIDR > mask > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.2.4 > Operating system: Linux > Description:entries like "hostall all 10.0.50.31/0 ..." > should not be allowed or trigger a warning > Details: > > Hello, > > not really a bug, but a possible security issue for wrongly configured > installations. > > A CIDR mask length of 0 will allow to connect from any location. I did this > mistake as I didn't read the documentation carefully enough. > > Checking the mask against the IP address would prevent such errors: > > /0 : disallow ? 0.0.0.0/0 should continue to be accepted. > /24 : IP must ends with .0 > /16 : IP must ends with .0.0 If you're going to do that, you might as well enforce it for any CIDR subnet and say that the address given must be the network address, not a host address within the network. That way it works for non-multiple-of-8 CIDR subnets too. -- Craig Ringer -- 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 #4465: GROUP BY is not to SQL standard
[Note: I'm *not* an expert in the SQL standard, but I might be able to help clarify a misunderstanding or two in the discussion so far]. Tony Marston wrote: Support for functional dependencies is not a feature that can be turned off in any database engine. Dependencies, whether they are functional, transitive, multi-valued or join dependencies, are inherent in the database design. Well, my understanding is that they're a core part of relational theory, anyway. This doesn't necessarily make them "inherent in the database design" - in that AFAIK no computer database implementation fully implements the correct and complete relational calculus. In a sense, all relational database implementations can be considered "incorrect" - they can all produce results that wouldn't be permitted by a strict relational implementation. On the upside, they actually produce the results this century, and correctness can still be assured by manual locking in critical situations. If there really is a strict and pure relational implementation, I'd be curious to know about it. Does it work? Does it work in the real world? It is therefore nonsense to say that support for functional dependencies is optional. Again, that's true for the theory, but practical implementations may not achieve theoretical perfection. SQL is a standard describing requirements and optional features fo a practial implementation of a relational database engine, not a description of relational theory. Saying that the SQL standard and Relational Theory are unconnected is complete misdirection. The SQL standard is surely there to define how Relational Theory can/should be implemented. You have used the word "surely" - in this case, as conjecture. People here have already told you that the SQL standard does NOT describe a strict implementation of relational theory, and that an SQL-confirming implementation may lack features like predicate locking, identification of functional dependencies in result sets, etc. A database cannot be classed as "relational" if it does not support standard SQL, therefore the two must go hand in hand. Er, no. Support for standard SQL does not imply a strict implementation of relational theory (ie being "classed as relational"), as the SQL standard does not actually describe a strict implementation of relational theory. I don't know enough about the standard to be sure, but I wouldn't be too surprised if a fully conformant SQL implementation could *not* strictly implement relational theory. The simple fact is that it is only in the 1992 standard that it states that ALL columns in the SELECT clause must be identified in the GROUP BY clause. In all subsequent standards it has been permissible to omit any column from the GROUP BY clause if it is functionally dependent on any other column in the GROUP BY clause. All you can do is point to paragraphs which are NOT contained in the definition of the GROUP BY clause and say "this is our get out". Now you wonder why I refer to your arguments as "weasel words". What's been said in response to your initial post all looks pretty reasonable to me, and I see attempts to explain the situation rather than "weasel". Standards aren't generally the perfect ideals we might want them to be, and the SQL standard is full of optional features, practical compromises, and so on. As Peter Eisentraut explained in reply to your initial post, PostgreSQL does not support one of the optional features in the SQL-99/SQL-2003 standard, namely T301, and retains SQL-92 behaviour in this area. That's perfectly acceptable according to the standard. The definition of functional dependencies in T301 that you are arguing about is a definition in the SQL standard that PostgreSQL attempts to follow, not a definition made up by the PostgreSQL developers. If you don't like the definition, you'll need to take that up with the SQL standards body. If it contradicts relational theory, then that's either a practical compromise or an error made by the SQL standards body. It would be nice if PostgreSQL did support that feature. However, it can be compliant with the SQL standard without it, as it's an optional feature. (In fact I don't know if PostgreSQL *is* fully compliant with any of the SQL standards, but that's another issue). Arguably no SQL database should be described as "relational" - but in practice, SQL describes a good and workable approximation of relational theory that works in the real world and is useful to describe as "relational" to distinguish it from other, completely different, database designs. -- Craig Ringer -- 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 #4496: Memory leak in pg_dump.c?
Tomáš Szépe wrote: A pg_dump run is comparatively short-lived, so if Zdenek is right then there's no important leak here -- we're counting on program exit to release the memory. There's probably little point in releasing things earlier than that. Well, I'd tend to consider any logical part of a program that fails to release the memory it uses to be bad coding practice. You never know when you're going to need to shuffle things around, change the context of the code in a way that makes it long-lived, in turn causing the leak to become a real problem. I find that documenting where alloations are not correspondingly free()'d is usually sufficient for this. Personally I usually don't bother freeing some allocations in short-lived programs, but I make sure I know what they are and I'll usually have code in there to free them if the binary is built for debugging mostly to stop people reporting bogus memory leaks. There are good reasons not to free memory if a program will shortly be terminating and thus all its resources will be freed by the operating system. Sometimes explicitly freeing large piles of memory, especially if there's any sort of automatic cleanup associated, can take real time that you don't really want to waste when you're about to terminate anyway. Additionally, sometimes it's hard to know when it's safe to free a structure, but you always know it's safe for the OS to release the program's memory mappings after it terminates. This is a particular issue in libraries that use various caching and reuse mechanisms, have long-lived service providers, or do other things that may not be visible to the program using the library. It's a good idea to provide a libraryname_cleanup() call or similar, but it's probably only going to be useful if the app is being run under a memory leak checker or the like, and even then it's only useful to reduce noise. Memory leaks that actually matter are where memory is allocated and not freed as part of a process that is repeated many times in a program, or that consumes a huge amount of memory. Also, don't you like seeing the free()s paired to their mallocs()s in a way that makes the allocations intuitively correct? :) No - I like to use lexically scoped instances of useful classes to hide the minutae of memory management behind a nice RAII interface. Think std::vector. When forced, I like to use std::auto_ptr<> or std::tr1::shared_ptr<> (or boost::shared_ptr<> if TR1 is not available) as appropriate to manage the block. I in fact loathe seeing malloc() and free() [ or operator new() and operator delete() ] pairs, because every one is a potential leak or double free bug. Then again, I use C++ by preference, where you have those more sophisticated resource management options available to you. In the case of PostgreSQL code, of course, you just use palloc() and let it's management of memory contexts take care of everything for you. That sort of domain-specific smart memory management seems to be the best way to go whenever you can use it - see also, for example, Samba's talloc() and GhostScript's reference counting allocator. So ... in short, I see malloc() and free() as rather low level, and not something I want to see at all in the significant parts of any nontrivial program. -- Craig Ringer -- 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] Upgrade from 7.4.5 to 8.3.3
Harvey, Allan AC wrote: >> Do you use system libc or glibc? You can try create own >> locale by localedef and >> test what happen. > > I think it would have to be glibc as I used the gcc loaded with the > "skunkware" tools that SCO provide. gcc may be, and often is, used with the system libc. It'd be much less useful otherwise, since you generally can't link to more than one libc without a great deal of trouble, and thus you couldn't use libraries that were linked to the system libc with gcc if it could only use gcc. If I recall correctly the gcc shipped in skunkware generates binaries linked to the system libc. It should be trivial to find out by compiling a "hello world" program and using /bin/ldd to show what it's linked to. It might be possible to build PostgreSQL against glibc instead, but it seems like way more work than would be worthwhile when you can just run Pg on a modern machine and talk to it over the network. -- Craig Ringer -- 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] Behavior change of FK info query
Zahid Khan wrote: > > Hi, > > I am getting one failures in odbc application with 8.3 server which is > related to foreign key information. Which ODBC driver version are you using? Remember that newer drivers work with older database servers, but older drivers may not work with newer database servers. -- Craig Ringer -- 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] Behavior change of FK info query
Zahid Khan wrote: > > > I am using 8.3.1 driver ,Is this changed in any new version ? Not as far as I know. There might be problems if you were using, say, an 8.2.x driver with an 8.3 server, though. -- Craig Ringer -- 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 #4510: memory leak with libpg.dll
MWendt wrote: The following bug has been logged online: Bug reference: 4510 Logged by: MWendt Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.x, 8.2.x Operating system: windows xp (client), linux (postgres server) Description:memory leak with libpg.dll Details: 1) DB server is down. 2) the client will connect to these DB server and is running correctly in a timeout. the problem is: for each connection attempt that will fail the memory usage is growing. that will result in massive memory allocation, if the client try to reconnect in high frequency. and furthermore the memory is not freed when the next connection can be established. 3) I guess in libpg.dll are some connection structures that are not freed correctly if the connection coult not established well. Is there any chance you can supply the source code of a self-contained, compileable test case (example program) that can demonstrate this? Your description doesn't exclude the possibility of leaks occurring as a consequence of failure to free resources in the program using libpq. -- Craig Ringer -- 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] could not read block 77 of relation 1663/16385/388818775
Alexandra Nitzschke wrote: Hi, we encountered the following error while inserting a record into a table: org.postgresql.util.PSQLException: ERROR: could not read block 77 of relation 1663/16385/388818775: read only 0 of 8192 bytes This is probably a problem with your disk or filesystem. Have you checked your disks and file system, checked your system logs for disk errors, made sure your RAID array is in good condition, etc? You should be able to fix it by REINDEXing the problem index. You can find out which index it is from pg_catalog, though if you just REINDEX the table(s) being operated on by the query that should work too. Consider making a copy of your database and your log files before you REINDEX in case one of the developers thinks it might actually be caused by a PostgreSQL bug and wants to have a look. -- Craig Ringer -- 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] could not read block 77 of relation 1663/16385/388818775
Alexandra Nitzschke wrote: > Hi, > > we have had similar postgres problems in the past. > Please have a look at Bug 3484. > > We didn't resolve the problems metioned in bug 3484. The other postgres > developers also thought, that there are hardware > problems. > So our customer bought a new server with diffrent hardware configuration > ( ... and NEW hardware drives ... ). > The error today encountered on the new machine. Just running under heavy > load since two days. Yes, that does seem somewhat unlikely, especially if in both cases you've only seen issues with PostgreSQL. However, I'm a bit confused about the fact that you're seeing apparent corruption all over the place - your earlier report mentions damaged blocks across a number of relations, and this one is a bad index. You'd expect this sort of thing to come up a lot on the list, so it must be assumed that there's something a bit unusual or different about your configuration that's either triggering a hard-to-hit bug in PostgreSQL, or that's damaging PostgreSQL's data somehow. Is there any chance you have EVER hard-killed the postmaster manually (eg with "kill -9" or "kill -KILL")? If you do that and don't also kill the backends, it's my understanding that BAD things may happen especially if you then attempt to relaunch the postmaster. Do you use _any_ 3rd party C extensions? Contrib modules? It doesn't have to be in the same database, another database on the same machine could be bad too. Do you have any unusual workload? What is your workload like? What procedural languages, if any, do you use? Pl/PgSQL? Pl/Perl? Pl/Java? Pl/Python? etc. Again, in any database, not just your problem one. If you use any other than Pl/PgSQL please also note the version of the language interpreter/tools and in the case of Java the JVM vendor & install method. Does your site possibly have dodgy power? Are the servers on a UPS? Have the servers had any crashes, kernel panics, unexpected reboots, or hard poweroffs? (Not that it should matter, but): Have you hard killed any backends (kill -9 / SIGKILL)? If you run a RAID verify using tw_cli or through the 3dm web interface, does it report any block mismatches in the array? -- Craig Ringer -- 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] PQescapeStringConn in C:\Program Files\PostgreSQL\8.3\lib not found"
劉大維 wrote: > Dear Sir, > > I try to make gammu-svn2643. You're having issues with `cmake' configuration of a project other than PostgreSQL. This is unlikely to be a PostgreSQL bug. > "Cmake error: invalid escape sequence \p" > "Syntax error in cmake code at > D:/gammu-svn2643/cmake/FindPostgres.cmake:73: syntax error, > unexpected cal_ERRO, expecting $end (38), when parsing string Looking > for PQescapeStringConn in C:\Program Files\PostgreSQL\8.3\lib not found" FindPostgres.cmake is part of the gammu project. You need to contact them and inform them that their CMake code to detect PostgreSQL is broken. Make sure to tell them your cmake version, because that is the first thing they will ask, and also send them your CMakeCache.txt . This is not a problem with PostgreSQL. > Then I type make on cmd That won't work, because CMake configuration didn't work properly. CMake shouldn't have even generated a Makefile; the fact that it did suggests that the error handling in the gammu cmake code is far from ideal. -- Craig Ringer -- 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 #4559: performance issue
M. Alaa ElGohary wrote: > The following bug has been logged online: > > Bug reference: 4559 > Logged by: M. Alaa ElGohary > Email address: alaa.elgoh...@backandfront.ws > PostgreSQL version: 7.4.19 > Operating system: FreeBSD 6.3 > Description:performance issue > Details: > > I have a POS application that performs end of day process in which data is > transfered from a set of tables to another this process stops completely > with no reason when i make a dump of the database and drop then create and > restore the dump the end of day process performs extremely fast with no > stopage > i need to know whats the reason that stops this process and why is it > overcome when i drop and restore the database and how can i solve this > without needing to drop and restore the database > thanks This is not a bug report. You haven't explained what, exactly, PostgreSQL is doing wrong, nor have you provided any examples or any way for anybody else to understand the problem. I suggest posting a more detailed question to the pgsql-general mailing list. Include examples and a step-by-step explanation of what happens. Mention your Pg version and other things people need to know. It's also likely to help if you punctuate your question so that people can follow what you are saying; I found your writing very difficult to understand. -- Craig Ringer -- 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 #4661: Installation
Thomas Waelde wrote: > checking test program... failed > configure: error: > Could not execute a simple test program. This may be a problem > related to locating shared libraries. Check the file 'config.log' > for the exact reason. This is unlikely to be a bug in Pg - it's known to compile and work perfectly well on Ubuntu 8.10 . Perhaps you should do what the error message says and look at "config.log" ? If you still have trouble, post a request for assistance to -general and MAKE SURE TO INCLUDE A LINK TO YOUR config.log FILE. DO NOT ATTACH IT. A good place to upload such files is http://rafb.net/ . Alternately, if you're not comfortable building from source just install PostgreSQL from the Ubuntu repositories (using backports if needed). -- Craig Ringer -- 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] could not write block
Kopljan Michael wrote: recently appears to me the following error : could not write block 86 of relation 1663/121027/151994: Invalid argument What is that error and how to fix this? It's much more likely to be a problem with your disks or filesystem than with PostgreSQL. "Invalid argument" is a standard system call error code translation for the code -EINVAL . You should check your kernel logs for error messages about your disks and file systems. You should also run a file system check (fsck) on your filesystems. If you have a RAID array, get it to do a verification/scrubbing run too. -- Craig Ringer -- 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 #4663: I am unable to download the manuals from site
Please DO NOT just reply to me. Reply to the list. dattathreya Bonakurthi wrote: I m using acrobat reader 8.0 version the browser is Mozilla version 3.0 ... Firefox 3.0, perhaps? ** PLEASE POST THE FULL, EXACT TEXT OF THE ERROR MESSAGE YOU GET WHEN YOU ATTEMPT TO OPEN THE FILE. ** I am jst trying to download the pdf from the link of manuals in postgres.. That's not a URL. Perhaps you meant: http://www.postgresql.org/files/documentation/pdf/8.3/postgresql-8.3-A4.pdf which is accessed by visiting http://www.postgresql.org/docs/manuals/ and clicking on the link "Comprehensive Manual: A4 PDF (16.5 MB)" in the 8.3 version row. If that's not the file you were trying to download, please say which one you WERE attempting to download. There is nothing wrong with that file. Most likely there's something wrong with your Adobe Reader install, your browser plugin, or your browser install. Adobe Reader's netscape/firefox plugin has always been flakey. Try saving the file to your desktop (right click, "Save Link As...") and opening the downloaded PDF directly from Adobe Reader, rather than via your web browser. -- Craig Ringer -- 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 #4663: I am unable to download the manuals from site
Dattathreya wrote: The following bug has been logged online: Bug reference: 4663 Logged by: Dattathreya Email address: dattu.bonakur...@gmail.com PostgreSQL version: 8.2 Operating system: Windows Xp Description:I am unable to download the manuals from site Details: when ever i am trying to download the pdf file it is giving an error, as the file is corrupted. Perhaps you might provide the readers of your report with a little information, since most people here aren't actually psychic. Consider mentioning: - What the URL of the PDF file you are attempting to download is - WHAT THE FULL, EXACT TEXT OF THE ERROR MESSAGE YOU GET IS - What PDF reader you have installed - Whether that has a browser plugin active or not - Whether you're trying to download the PDF (right click -> save as) or read it embedded in the browser -- Craig Ringer -- 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 #4661: Installation
Devrim GÜNDÜZ wrote: On Mon, 2009-02-16 at 12:11 +, Thomas Waelde wrote: i got the following error: checking test program... failed configure: error: Could not execute a simple test program. This may be a problem related to locating shared libraries. Check the file 'config.log' for the exact reason. Is libc6-dev (or such) installed on your Ubuntu box? What you really want to get a basic build environment is: sudo apt-get install build-essential To obtain all required libraries etc for building a particular app, if Ubuntu happens to package that app, you can just run: sudo apt-get build-dep postgresql In most cases Ubuntu builds the most complete and generic configuration of the app so that'll get you what you need. -- Craig Ringer -- 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 #4716: Error initialiting postgresql
Serbe wrote: The following bug has been logged online: Bug reference: 4716 Logged by: Serbe Email address: se...@rocketmail.com PostgreSQL version: 8.1.11 Operating system: Linux RedHat Description:Error initialiting postgresql Details: #service postgresql restart Parando el servicio postgresql: [FALLÓ] Iniciando la base de datos: mkdir: no se puede crear el directorio «/var/lib/pgsql/data/pg_log»: El fichero ya existe [FALLÓ] Iniciando servicios postgresql:[FALLÓ] That's not a bug. PostgreSQL is failing to start because the pg_log directory is missing. Are you sure your database is configured correctly, you have the right data directory set up in postgresql.conf, and you haven't recently rearranged anything in /var ? Are your file systems OK ? -- Craig Ringer -- 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 #4724: Array index out of bounds
Ett Martin wrote:
> I have checked the sources with a static code analysis tool cppcheck:
>
> cppcheck -q -a -j2 postgresql-8.3.7
> [postgresql-8.3.7/contrib/cube/cube.c:1418]: (all) Array index out of
> bounds
> [postgresql-8.3.7/contrib/cube/cube.c:1437]: (all) Array index out of
> bounds
Have you then verified that the complaint is actually valid? Static
analysis tools only point out places where you might want to look.
It's common in C to do things like:
struct block {
block *next;
size_t blockdata_size;
uint8_t blockdata[0];
}
where you allocate a `block' structure using something like:
block* alloc_block(size_t numbytes)
{
return (block*)(malloc(sizeof(block)+numbytes));
}
Because C permits indexing past the end of an array, you can then safely
and legally access your allocated memory past the block header with
things like:
someblock->blockdata[11];
Static analysis tools won't realise what's going on, and will complain.
I'd say after a quick glance that that's what's happening here, though
I'm far from certain.
--
Craig Ringer
--
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 #4732: Help me
Petrus wrote: > The following bug has been logged online: > > Bug reference: 4732 > Logged by: Petrus > Email address: peetupa...@hotmail.com > PostgreSQL version: 8.2 > Operating system: dunno > Description:Help me > Details: > > Please Help me i forgot my old postgres password how i get it back?? That's not a bug. Search Google for "lost postgresql password" or "reset postgresql password". If you still don't know what to do, please post to pgsql-general with a COMPLETE request for help, including things like your operating system and the version of your operating system. -- Craig Ringer -- 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] Help me to solve this problem!
sam rab wrote:
> Great day to you!
> I tried to install postgresql 8.3.7 on Linux RedHat 7.2 platform.
Maybe this is a stupid question, but ... why?
Red Hat 7.2 is *ANCIENT*. There haven't been security updates since
nigh-unto-forever. It's using C libraries with a completely different
threading model to modern Linuxes, it has an ancient kernel, and it's
generally scary.
Since the database server doesn't even need to live on the same hardware
as the rest of the application, why not just provide a modern machine
for the DB server?
If you're just trying to build the client libraries that makes more
sense - maybe you're stuck with an ancient server thanks to some
braindead binary-only library that chokes on a newer system, for example.
> Process of "configure" ends normally,
> process of "gmake" ends with this output of errors:
> {
> gmake[3]: Entering directory
> `/usr/home/install/postgresql-8.3.7/src/interfaces/
> libpq'
> gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline
> -fno-strict-aliasing
> -fpic -shared -Wl,-soname,libpq.so.5 -Wl,--version-script=exports.list
> fe-aut
> h.o fe-connect.o fe-exec.o fe-misc.o fe-print.o fe-lobj.o fe-protocol2.o
> fe-prot
> ocol3.o pqexpbuffer.o pqsignal.o fe-secure.o md5.o ip.o wchar.o encnames.o
> noblo
> ck.o pgstrcasecmp.o thread.o strlcpy.o -L../../../src/port -lcrypt
> -Wl,-rpath,'
> /usr/home/pgsql/lib' -o libpq.so.5.1
> /usr/bin/ld:exports.list:1: parse error in VERSION script
Your toolchain is just TOO OLD. You probably need a newer gcc and
binutils. Maybe it's possible to make it all go, but I wouldn't bother
unless really forced.
Maybe rather than upgrading gcc and binutils you might be able to modify
the configure script and/or makefile to work around it. I wouldn't be
too sure how; I'd need to dig into what was happening and probably have
an old box on hand.
--
Craig Ringer
--
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] Unable to make DBD-Pg-2.13.1
Mark wrote: > I'm new to PostgreSQL. Just installed the latest version, 8.3.7, on my > FreeBSD system (client + server). All went well... > > Until I tried to install DBD-Pg-2.13.1 (for Perl) thereafter. And I'm > getting the weirdest errors that just won't go away (see below). Does > anyone know what the cause might be? Or better still, how to fix it? :) What is "cc" in this context? cc -v > cc -c -I/usr/local/PostgreSQL/include -I/usr/local/include Is it possible that you have old or conflicting PostgreSQL headers in /usr/local/include ? Or even in /usr/include ? -- Craig Ringer -- 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] sorting problem
CK Leung wrote: > I create a new database use UTF-8 and SQL_ASCII, same result found, how > can i fix this problem ? If I recall correctly, the collation order is set at initdb time, and isn't bound to the database encoding. If that's right, you'd need to dump all your databases, re-initdb with the new collation settings, and re-load your databases. -- Craig Ringer -- 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 #4825: Before installation the server not running
Herbert Bonaffini wrote: > The following bug has been logged online: > > Bug reference: 4825 > Logged by: Herbert Bonaffini > Email address: hgsystem.m...@gmail.com > PostgreSQL version: 8.3.7-1 > Operating system: Windows > Description:Before installation the server not running > Details: > > Dear PostgreSQL support, > > i installed PostgreSQL on Windows XP (just formatted), > but after the installation the Server PostgreSQL > not running. > > The error message is: > > could not connect to server: Connection refused (0x274D/10061) Is the > server running on host "127.0.0.1" and accepting TCP/IP connections on port > 5432? > > If i use the version 8.3.3 everything works well. That's not necessarily a bug. Did you install under the same user account? Have you checked the Event Viewer to see if there are any errors starting PostgreSQL? (Control Panel -> Administrative Tools -> Event Viewer on WinXP). Have you looked at the PostgreSQL log files to see what, if anything, went wrong starting up? -- Craig Ringer -- 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 #4826: Cannot install Postgresql
Tobias Storm wrote: > The following bug has been logged online: > > Bug reference: 4826 > Logged by: Tobias Storm > Email address: tobias_st...@ofir.dk > PostgreSQL version: postgresql-8.3 > Operating system: Windows XP Home Edition > Description:Cannot install Postgresql > Details: > > When I am trying to install PostgreSQL I get an error message which say: > (Due to this I am not able to install PostgreSQL) > > Failed to run initdb: 1! > Please see the logfile in: C/Programmer/... > > When I go to the logfile it says: > > The files belonging to this database system will be owned by user SYSTEM. > This user must also own the server process. > > The database cluster will be initialized with locale Danish_Denmark.1252. > The default text search configuration will be set to danish. > > creating directory CProgrammerPostgreSQL8.3data ... initdb could not create > directory CProgrammerPostgreSQL File exists > > > Can you tell me how I can solve this problem? It sounds like you set the data directory to the same directory as the PostgreSQL install directory. That won't work. Specify a subdirectory of the install directory if you must have it in there. -- Craig Ringer -- 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 #4836: Losing data
Haitham Isac wrote: > Thanks a lot Tom, I'll start with upgrading to 8.3.7 and see how is t going > to be. Just to re-iterate an important point, too: Antivirus software is KNOWN to cause problems for PostgreSQL. See the archives. It is VERY strongly recommended that antivirus software be uninstalled, not just disabled or told to ignore PostgreSQL. Well-designed, bug-free antivirus software shouldn't affect PostgreSQL, but there doesn't seem to be much of that around. In any case, you shouldn't really need antivirus software on a database server. -- Craig Ringer -- 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] psql: FATAL: the database system is in recovery mode
Bhushan Verma wrote: > server closed the connection unexpectedly > This probably means the server terminated abnormally > before or while processing the request. > connection to server was lost Look in the PostgreSQL server logs for more information. It's probably in /var/log/postgresql or something like that - it depends on exactly how the distro packaged PostgreSQL. -- Craig Ringer -- 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] psql: FATAL: the database system is in recovery mode
Bhushan Verma wrote: >>> Is it a particular one, or does it crash at random? > > its crash at random. Random segfaults easily by application bugs ( memory corruption, accessing uninitialized memory and dereferencing pointers there, etc ) or hardware issues like bad CPU/CPU cache/memory, overheating, etc. Are you having issues with any other applications? If you can afford the load, consider running something quite CPU/memory intensive for a while - say, a big compile job - and make sure it all goes smoothly. It'd also be interesting to know whether a separate PostgreSQL instance with a fresh database had issues, but that's probably not practical for you to test. Most likely it's some kind of corrupt database triggering a subtle bug somewhere in Pg, anyway... -- Craig Ringer -- 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 #4890: Allow insert character has no equivalent in "LATIN2"
On Sat, 2009-06-27 at 19:20 +, saint wrote:
> set client_encoding to 'WIN1250';
> insert into public.test(col) values('‰');
You're lying to the server about the client encoding in one or both
cases. I can't know which without knowing what program you're talking to
the server with and how it's set up.
'SET client_encoding' tells the server what encoding to expect incoming
data in. It doesn't change what encoding the client sends that data in.
If your client has a different default encoding to that of the server,
you can inform the server that the client will be sending differently
encoded data.
In other words, you can't use 'SET client_encoding' to change what
encoding the client uses, only how the server interprets the bytes it
gets from the client.
--
Craig Ringer
--
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 #4875: /etc/init.d/postgresql status shows postmaster is stopped when executed as user
On Sun, 2009-06-28 at 00:32 -0400, Tom Lane wrote: > "Armin Jenewein" writes: > > When i run "/etc/init.d/postgresql status" as a non-root user, it shows > > "postmaster is stopped" while it actually is running. If i run it as root it > > reports correctly. > > AFAICS this just depends on "pidof postmaster". Perhaps you should be > filing a bug against pidof. First, though, make sure that SELinux isn't hiding the `postmaster' process from your normal users. Make sure you can actually see it with `ps aux' or `ps -ef' . -- Craig Ringer -- 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 #4892: postmaster died and didn't restart
On Sun, 2009-06-28 at 22:54 +, Rikard Pavelic wrote: > log of death [i hate automatic translation feature :(] On UNIX, it's so easy to change what language PostgreSQL uses that it's generally considered very helpful - the only time you really want to disable it is when posting to mailing lists. On Windows, it might be nice to be able to set a language for Pg. -- Craig Ringer -- 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 #4890: Allow insert character has no equivalent in "LATIN2"
(Please reply to the list, not just to me)
I'm not sure about this so far. Re the specific issue you mention of
conversion between cp1250 and latin-2 (ISO-8859-2) the Unicode tables
at:
http://unicode.org/Public/MAPPINGS/ISO8859/8859-2.TXT
appear to agree - there's no PER MILLE in ISO-8859-2.
With a UTF-8 database, Pg correctly doesn't accept PER MILLE as a valid
ISO-8859-2 char:
-- Connecting with unicode (utf-8) client
CREATE TABLE test (x);
INSERT INTO test(x) VALUES ('‰');
SET client_encoding='iso-8859-2';
SELECT * from test;
ERROR: character 0xe280b0 of encoding "UTF8" has no equivalent in
"LATIN2"
If the encoding is set to WIN1250 Pg outputs the appropriate byte. So
it's doing the right thing in each individual case where a UTF-8 DB is
concerned.
Your problem, though, is that if you connect to a LATIN2 database with a
WIN1250 client and INSERT a string containing the per-mille glyph, Pg
accepts it and it should not. If it does, indeed, accept it, then I
agree that's a bug.
I haven't tested with a LATIN2 database as I'd have to re-initdb and the
machine I'm working on has semi-useful databases on it. What you're
saying makes sense, though, presuming your client really is sending
win1250 per-mille (byte 0x89).
I'd still like to know how you're setting your client encoding. You
can't just run "SET client_encoding='win1250'" - you must tell the
client program, or the terminal it runs in, to use the appropriate
encoding as well. Otherwise when you paste the per-mille character
you'll see the right glyph, but the CLIENT will interpret that as the
character in the encoding you specified.
So, if you're using a utf-8 terminal, that means that the terminal will
send 0xe2 0x80 0xb0 for per-mille, which when interpreted as win1250
becomes ‰ , so that's what the server thinks you sent it.
In that case, though, you'd find that the euro symbol, which isn't
defined in latin-2, will cause an error:
ERROR: character 0xe282ac of encoding "UTF8" has no equivalent in
"LATIN2"
--
Craig Ringer
--
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 #4945: Parallel update(s) gone wild
On Mon, 2009-07-27 at 21:56 +, dan boeriu wrote: > What I noticed is that the second will not finish if the READ table has many > rows to be read (1 million let's say) but it finishes when the read table > has only a few 1000s of rows. > Any idea why? It could be that it _does_ finish ... eventually. It might be doing something that scales very poorly with number of input rows, like a nested loop within a nested loop. Can you provide EXPLAIN ANALYZE output for the problem query? -- Craig Ringer -- 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 #4945: Parallel update(s) gone wild
Please reply to the list, not directly to me. > I don't think is that simple. The VERY SAME statement runs twice - one > finishes in about 20 secs the other doesn't finish in 24 hours. Yep, OK, so it's not just a planning or scaling issue. Have you checked pg_locks ? SELECT * FROM pg_locks; What does pg_stat_activity indicate about the query? SELECT * FROM pg_stat_activity; > The plan might change from one execution to the other - is there a way > to get the executed plan at runtime? I think there is in 8.4, but I haven't moved up to it and tested yet. Not in previous versions. -- Craig Ringer -- 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 #4945: Parallel update(s) gone wild
Dan Boeriu wrote: The second will not finish in 24h but the CPU stays at 100% and iostat shows no IO other than the checkpoints. > IF I cancel the second UPDATE (pg_cancel_backend) and restart it (new > pgsql invocation) ASAP it goes through in 20 secs. OK, that's interesting when combined with the information provided. (Though, in general, it's preferable that you quote command output as well as your interpretation; I think we all miss things sometimes.) You might want to connect to the problem process (the one pegged at 100% CPU) with gdb and see if you can get a backtrace showing what's going on. Where the pid of the problem process is shown as here: gdb -p (gdb) bt (gdb) cont ^C (gdb) bt (gdb) cont ^C (gdb) bt (gdb) cont ^C (gdb) bt (gdb) q y In other words: connect to the process with gdb. Issue the "bt" command (backtrace) to get a backtrace at the point you interrupted it at by connecting with gdb, then tell it to continue execution normally. After a little while (a few seconds/minutes/whatever, just tell us vaguely how long) hit control-C, request another backtrace, and tell the program to continue. Repeat a few times, then quit gdb and tell it to detach from the process. Then send the ENTIRE, EXACT output to the mailing list. If the output mostly looks like this: #0 0xb7f6a410 in ?? () #1 0xbfe75578 in ?? () #2 0x in ?? () then your Linux distro has stripped debug info out of the Pg binaries. You may need to install debuginfo RPMs for PostgreSQL and glibc at the very least, then repeat the process of collecting backtrace information. -- Craig Ringer -- 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 #4951: installation dir wrong for libpq compilation
On Tue, 2009-07-28 at 22:57 +, Jim Michaels wrote: > The following bug has been logged online: > > Bug reference: 4951 > Logged by: Jim Michaels > Email address: jmich...@yahoo.com > PostgreSQL version: 8.4.0 > Operating system: Win XP Pro Sp3 > Description:installation dir wrong for libpq compilation > Details: > > it is impossible to compile in libpq headers unless the installation > directory for postgres has no spaces. compilers such as gcc/mingw don't > like that. I use mingw32 with include paths that contain spaces all the time. Not for PostgreSQL admittedly, but for other projects. Use the -I directive with "double quotes" on the path, or use a Windows PATH-style semicolon-separated directory list in the CPATH environment variable, eg set CPATH=%CPATH%;C:\PROGRAM FILES\PostgreSQL\8.3\include Really, gcc doesn't care, either in its various native forms nor as mingw32. Nor does GNU make. However, build scripts and sloppily written makefiles may fail to properly quote variable substitutions, which will lead to problems. The answer is to fix the build scripts, not move the header files. If you're really stuck with build scripts or tools you can't change, you can always create an NTFS junction point (like a symbolic link) to remap the include dir somewhere else. -- Craig Ringer -- 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 #4966: wrong password.....
On Thu, 2009-08-06 at 11:22 +0200, Dimitri Fontaine wrote: > Would we consider providing a documentation section explaining how to > change pg_hba.conf to trust, reload, change password, get back to saner > HBA if needed? > > This question is a such a FAQ that it deserves a place in the docs, I > think. Sounds like a _REALLY_ good idea to me. I almost wonder if Pg on Windows needs a "safe mode" where it's launched with an alternate pg_hba.conf that trusts postmaster on 127.0.0.1, rejects *all* other logins, and doesn't listen on any external interfaces. People seem to lose passwords a _lot_ . Some info in the docs on changing/deleting the Pg service account might also not be a bad idea. -- Craig Ringer -- 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] Fatal Error
On 17/08/2009 9:23 AM, Travis Kirtley wrote: Further searching by the windows event viewer shows a postgreSQL error which leads me to writing this email. The error says "FATAL: syntax error in file "C/Program Files/PostgreSQL/8.3/data/postgresql.conf" line 1, near token "," ". I have no idea what this means or how to go about addressing this. You or your software has modified your postgresql configuration file - incorrectly. You can edit C:/Program Files/PostgreSQL/8.3/data/postgresql.conf to fix the issue. There's a comma on the first line somewhere it doesn't make sense. You might want to contact the technical support for the company whose software includes PostgreSQL for more in-depth assistance. One thought was to delete my old database (against this preferably) and see if that is the source of the issue. No, it's not. It's your PostgreSQL configuration file, which is shared across all databases. So far I've reinstated previous windows states, removed any newish updates by windows and reinstalled postgreSQL, none of which has worked. Any Ideas? Fix the config file. You haven't posted its contents so nobody can see what might be wrong with it. The config file is the file whose location is given in the error message you saw. -- Craig Ringer -- 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 #4989: Fatal Error
On 17/08/2009 9:34 AM, Travis K wrote: The following bug has been logged online: Bug reference: 4989 Logged by: Travis K Email address: travisjkirt...@yahoo.com PostgreSQL version: 8.3 Operating system: Windows XP Description:Fatal Error Details: Hello, I was using holdem manager with support from postgresql for several months and recently it all came crashing down. There's no indication this is a PostgreSQL bug. Maybe you should've asked on the "-general" or beginners lists? Contact the tech support for your poker card counting software for in-depth assistance. -- Craig Ringer -- 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 #4996: postgres.exe memory consumption keeps going up
On 19/08/2009 11:50 PM, Shivesh Wangrungvichaisri wrote: Logged by: Shivesh Wangrungvichaisri Email address: s...@appsig.com PostgreSQL version: 8.3.7 Operating system: Windows XP x64 / Windows 7 x64 Description:postgres.exe memory consumption keeps going up - Example code that should demonstrate the problem: http://stackoverflow.com/questions/1280513/posgressql-memory-leaque (note we use Intel TBB to launch threads..you can use whatever thread library you want.) I went to build your example for testing, but found that the threading library you use isn't freely available. Any chance you can post a version using the standard win32 threading calls and test that version to make sure it still exhibits the problem? (I do a little bit of programming on Windows, but all of it is cross-platform code that sticks to POSIX APIs or uses the Qt library, so I never have to touch the actual win32 bits and know very little about things like win32's threading. As such, if I try converting it myself I won't be confident I'm really accurately testing the same thing you are). -- Craig Ringer -- 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 #4996: postgres.exe memory consumption keeps going up
On 23/08/2009 10:37 AM, Craig Ringer wrote: On 19/08/2009 11:50 PM, Shivesh Wangrungvichaisri wrote: Logged by: Shivesh Wangrungvichaisri Email address: s...@appsig.com PostgreSQL version: 8.3.7 Operating system: Windows XP x64 / Windows 7 x64 Description: postgres.exe memory consumption keeps going up - Example code that should demonstrate the problem: http://stackoverflow.com/questions/1280513/posgressql-memory-leaque (note we use Intel TBB to launch threads..you can use whatever thread library you want.) I went to build your example for testing, but found that the threading library you use isn't freely available. ... so of course, as soon as I post this I find out I located the commercial licensing page for a dual proprietary-and-GPL library. Sigh. Building the test with VC++EE '08 now. -- Craig Ringer -- 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 #4996: postgres.exe memory consumption keeps going up
On 19/08/2009 11:50 PM, Shivesh Wangrungvichaisri wrote: The following bug has been logged online: Bug reference: 4996 Logged by: Shivesh Wangrungvichaisri Email address: s...@appsig.com PostgreSQL version: 8.3.7 I ran your test program on 8.4.0 (not 8.3.7 as you used), and didn't find any sign of a leak in the backends (postgres.exe). Interestingly, though, the test program does appear to be leaking - at least, the peak working set slowly climbs. It's all private working set. Not sure why yet since the memory use looks like it _should_ be constant. Re the backends, the shared working set on each postgres.exe backend goes up until each backend has touched all the shm it'll ever touch, at which point the backends' usage stabilizes. I see no sign of a leak. Have you perhaps tried to configure WAY too much shared memory? How much RAM does your test machine have? Can you post all uncommented lines from your postgresql.conf ? For the next thing you need to check you'll need Process Explorer. Install it and the rest of the sysinternals suite if you don't have it yet, it's a VITAL windows admin tool: http://technet.microsoft.com/en-gb/sysinternals/bb842062.aspx Please launch Process Explorer and then your test program. Double-click on the postgres.exe backends to open info windows for them and do the same for the test program. Take a screenshot (windows-prtscrn) and save it. Let the test run a while and do the same thing occasionally to keep a record. If/when a backend crashes save the windows event log and the postgresql log. Upload the lot as a zip file somewhere accessible and post a report on what happened. I'll try to figure out why your test program appears to be leaking (or just using more memory with time). libpq and friends were built with MSVC7 and I'm using MSVC9 for the test program so there are two different runtimes linked to the program, but there aren't any FILE pointers being passed around, no memory is allocated in one module and freed in another, etc, so I'm not sure where it's going yet. Valgrind doesn't support Windows and all the Windows leak-checking tools cost $LOTS so I can't just hook it up to a heap analyzer / leak checker. Sigh. -- Craig Ringer -- 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 #4996: postgres.exe memory consumption keeps going up
Please launch Process Explorer and then your test program. Double-click on the postgres.exe backends to open info windows for them and do the same for the test program. Take a screenshot (windows-prtscrn) and save it. Let the test run a while and do the same thing occasionally to keep a record. Auto Screen Recorder from: http://wisdom-soft.com/products/screenhunter_free.htm might be handy for that, by the way. -- Craig Ringer -- 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 #4996: postgres.exe memory consumption keeps going up
On 23/08/2009 12:42 PM, Greg Stark wrote: On Sun, Aug 23, 2009 at 4:48 AM, Craig Ringer wrote: Interestingly, though, the test program does appear to be leaking - at least, the peak working set slowly climbs. It's all private working set. Not sure why yet since the memory use looks like it _should_ be constant. How does the return value of str() get cleaned up here? PGresult* res=PQexec(conn,insert.str().c_str()); str() returns a std::string instance by value. It's not returning a pointer to a heap allocated object. The returned std::string is cleaned up when it leaves scope - in this case, at end-of-statement. c_str() is called on the temporary std::string . This returns a const char * to a block of memory owned by the std::string . It must *NOT* be freed by the caller or modified by the caller. It's usually just the internal buffer maintained by the std::string. See: http://www.cplusplus.com/reference/string/string/c_str/ So, no, there's no leak there. -- Craig Ringer -- 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 #5007: could not reattach to shared memory
On Tue, 2009-08-25 at 05:44 +, Regina wrote: > The following bug has been logged online: > > Bug reference: 5007 > Logged by: Regina > Email address: l...@pcorp.us > PostgreSQL version: 8.3.6 > Operating system: Windows 2008 Server Standard > Description:could not reattach to shared memory > Details: > > One of our clients is getting the following error in their PostgreSQL 8.3.6 > logs in their ASP.NET application. This only happens if their application > runs a long query (which they dump out to disk and disk size (ESRI > shapefiles) is generally above 70 mb or more) when this fails. > > The error is below: > FATAL: could not reattach to shared memory (key=232, addr=01DF): 487 > %t WARNING: worker took too long to start; cancelled Search the -general mailing list archives for "reattach to shared memory". The issue has been around for a while but until recently nobody could reproduce it well enough to isolate it and test possible fixed. You'll see some recent discussion and a proposed patch. Try upgrading to the latest version in the 8.3 series. If you still see the problem please follow up here, or try the patch for the issuye proposed on the pgsql-general list. > In these cases their .NET app returns this error > Exception of type 'System.OutOfMemoryException' was thrown That's probably a bug in their application caused by failure to properly handle a connection problem. -- Craig Ringer -- 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 #5009: Loss of information
On 25/08/2009 8:07 PM, Fernando Velloso Tanure wrote: The following bug has been logged online: Bug reference: 5009 Logged by: Fernando Velloso Tanure Email address: f_tan...@terra.com.br PostgreSQL version: 8.1.11 Operating system: CentOS5.3 Red Hat Enterprise Linux RHEL Description:Loss of information Details: Good afternoon I'm having problem in postgres where some rows inserted or changed during the day was lost as a rollback was executed. I am using a system developed in Delphi with Zeos components for access to the database. The sequences used in the inserts are not lost. That sounds like "database working exactly as designed" to me. If you issue a sequence of statements like: -- Given the table structure: CREATE TABLE x ( id SERIAL PRIMARY KEY, n INTEGER NOT NULL); -- Program issues: BEGIN; INSERT INTO x(n) VALUES (1); INSERT INTO x(n) VALUES (3); INSERT INTO x(n) VALUES (9); INSERT INTO x(n) VALUES (42); ... then either you disconnect, the DB server is restarted, or your client issues a ROLLBACK, then you'll end up with an empty table `x' and the sequence x_id_seq will be 4. Why? Because sequences are, by design, not transactional. For good reasons. See the manual for the SERIAL pseudo-type and for SEQUENCEs. http://www.postgresql.org/docs/8.4/static/datatype-numeric.html#DATATYPE-SERIAL http://www.postgresql.org/docs/8.4/static/functions-sequence.html http://www.postgresql.org/docs/8.4/static/sql-createsequence.html Note that with some database driver interfaces the BEGIN may be implicit, especially if it defaults to "non-autocommit" or "autocommit off" ... so just because you didn't open a transaction doesn't mean one wasn't open. If your application really needs gapless sequences where a rollback also rolls back the sequence counter, there are options available - but they have HORRIBLE effects on performance, especially with concurrent inserts. They can be kind of OK if all you do in the transaction is: BEGIN; INSERT blah COMMIT; (or just use an implicit autocommit transaction) but if you do anything more complex in your transactions you risk deadlocks between concurrent transactions, awful performance, huge commit delays, and more. Search the pgsql-general mailing list archives for "gapless sequence" for more information. -- Craig Ringer -- 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 #4996: postgres.exe memory consumption keeps going up
On 26/08/2009 9:25 AM, WANGRUNGVICHAISRI, SHIVESH wrote: Hi, I have uploaded everything that you should need here: http://www.filefactory.com/file/ah334c6/n/Pgsql_Leak_zip I notice that you used the Windows Task Manager to monitor memory usage, rather than Process Explorer. There's a reason I suggested that you monitor with Process Explorer: it provides more detail about the process's memory usage. In particular, it lets you tell how much of the memory usage is shared memory and how much is private. The Task Manager does not. Because PostgreSQL makes heavy use of shared memory this information is important. That said, the "VM size" looks like the private size, making the rest shared. The growth you're observing is in shared memory, suggesting it's not in fact a leak at all, but the backend touching more and more of shared_buffers . I don't see any sign of a leak in postgres.exe . Given your configuration, I'd expect to see postgres.exe's memory use grow up to between 256 and say 290-ish MB (given that you have shared_buffers = 256MB) and none of your screenshots show it exceeding that. It all looks quite normal to me from what you've posted. You need to understand that PostgreSQL uses shared memory. The postmaster allocates this memory *once*. All postgres.exe backends attach to this shared memory block, which is already allocated. The way Windows accounts for memory use means that they don't immediately show up as using that memory, but it does get added to their reported memory usage as they read from and write to the shared memory block. Despite it being shown as part of each backend's memory use, the memory is actually ONLY USED ONCE - by the postmaster. You haven't let the test run long enough for the crash you've reported to take place or even for postgres.exe to grow beyond normal size (if it does). You also haven't provided the contents of postgresql's log file after the crash you described. As a result so I can't tell what happens when growth hits the ~2GB limit you mentioned in your initial post. I can't reproduce the crash myself since shared usage on my postgres.exe process(es) stabilizes and ceases growing after a while, as it should. I'm running your test program on my sandbox machine now to see if I can reproduce the issue, but so far everything looks quite normal. Both active backends have stabilized at 37,965K of shared memory - one has a total working set of 41,697K and the other 41,620K (so each is using about 3.6MB of real system RAM). I'll come back tomorrow and see if there are any signs of anything odd going on, but right now it looks sensible. SandBox.exe is growing in the same way my locally built test program is. Weird. I think I'm going to have to recompile PostgreSQL's libpq using VC++8 in memory debugging mode. Sigh. -- Craig Ringer -- 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 #4996: postgres.exe memory consumption keeps going up
On Wed, 2009-08-26 at 07:09 -0700, WANGRUNGVICHAISRI, SHIVESH wrote: > I also did use the Process Explorer as you suggested; I'm sorry I > didnt mention that in the post. As I mentioned before in the zip file, > the working set kept growing. Yes, but does the *private* working set? The screen shots of the Task Manager you supplied suggest it does not. Please provide screen recordings, screenshots, or other details from Process Explorer that show the growing private working set. You're just not providing the details needed to understand this, which are AT LEAST timed snapshots of: * For both active postgres.exe backends and SandboxTest.exe: ** Total working set size ** Private working set size ** Shared memory size ** Sharable memory size Process Explorer can tell you all these. If it is in fact postgres.exe that crashes at some point, it'd also *REALLY* help to have a backtrace of the crash. Please see this wiki article on how to collect a backtrace of a crashing process: http://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Windows This is REALLY important to help identify where the memory being allocated is. Note that you will need to set up your debug environment as per the instructions and make sure the stack trace is a useful one. > I will keep the program running today until it crashes. I've now been able to get your test program to crash (but not postgres.exe - only SandboxTest.exe). The postgres.exe backends are fine and do not have any problems. I'm running your test program again with a debugger attached. > Which one is the postgresql log file that you would be interested in > looking at? The most recent log in the pg_log directory inside the postgresql data directory. Please confirm the crash USING SANDBOXTEST.EXE not the real application. You need to be using the same test program as I am for it to be much use. If you cannot cause the postgres.exe crash with sandboxtest.exe but you can with your real application, then the test case isn't actually demonstrating the problem and we'll need different debugging tactics instead. -- Craig Ringer -- 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 #4996: postgres.exe memory consumption keeps going up
On Wed, 2009-08-26 at 16:51 -0700, WANGRUNGVICHAISRI, SHIVESH wrote: > > So my claim that PostgreSQL was leaking memory was not true, and I do > apologize. > No problem. That's why it's important to look into these things - so we find out. > However, I still insist that potentially the PostgreSQL community might > want to look into why making use of libpq causes the client program's > memory consumption to keep growing. This can be easily observed using > the earlier test program uploaded to here: I agree. I can reproduce the growth with your test program when I built it from sources against 8.4.0's libpq and run it against an 8.4.0 server. The source of the growth (leak?) isn't clear at the moment. It doesn't seem to be the test code its self, nor is it clear how it could be. To learn more I'm going to have to build PostgreSQL (or at least libpq) from sources using VC++8 in debug mode with memory tracing enabled. I'll also try building it on a Linux machine to see if it's a Windows-specific issue. Thanks for your persistence on this. I'll follow up in a bit when I've learned more about what's going on with libpq. -- Craig Ringer -- 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 #5015: MySQL migration wizard does not start
On Wed, 2009-08-26 at 12:52 -0700, John R Pierce wrote: > Sam Mason wrote: > > On Wed, Aug 26, 2009 at 02:55:37PM +, Ken Smith wrote: > > > >> I also noted > >> that if I try to run from the commandline that you use '/' in some of the > >> program paths causing the OS to say it cannot find the file - "C:/Program > >> Files/Java/jdk1.5.0_16/jre/bin/java.exe". > >> > > > > I'm pretty sure that Windows has known about forward slashes being path > > delimiters since Windows 95 and the start of Win32. I know I normally > > use forward slashes in XP when I'm at work! > > > > > they work in the APIs but not in the CMD command line shell, as it > expects / to be the command option seperrator (much as - is used in > Unix-like systems) That's very program specific - it's part of the program's command line parsing and argument processing, not cmd.exe / CreateProcess(...)'s handling of the command line arguments. Most Windows utilities, including command-line tools, handle forward-slash paths quite fine. It's just a few nasty old DOS-like ones that're a problem ... but that does include many of the basic cmd.exe built-in commands :-( -- Craig Ringer -- 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 #4996: postgres.exe memory consumption keeps going up
On Wed, 2009-08-26 at 16:51 -0700, WANGRUNGVICHAISRI, SHIVESH wrote:
> However, I still insist that potentially the PostgreSQL community might
> want to look into why making use of libpq causes the client program's
> memory consumption to keep growing. This can be easily observed using
> the earlier test program uploaded to here:
I've looked into it ... and concluded I'm an idiot.
Your query is:
SELECT * FROM tmp WHERE id>615;
(where "615" could be any value < 1000)
For some reason I'd been thinking all along that the query was grabbing
*no* *more* *than* *1000* *rows* ... but of course it's not, it's
grabbing all but some lower fraction of the rows. So the result set gets
bigger and bigger over time until the program doesn't have enough RAM to
hold the result set and it crashes.
The attached (adjusted) test program no longer has any issues with
growth or runtime. There's no libpq issue here, only a
my-brain-is-only-semifunctional issue.
So, it seems we've eliminated any issue with leakage in the PostgreSQL
server backend, you've isolated your problem to PostGIS, and we've found
that the growth of the test program was libpq working as designed.
It looks like we're done here.
--
Craig Ringer
// Standard C++ headers
#include
#include
#include
// PostgreSQL libpq headers
#include "libpq-fe.h"
#include "libpq/libpq-fs.h"
// Intel TBB header for threading
#include
#include
#include
#if defined(_WIN32)
# include
# define sleep Sleep
#else
# include
#endif
class TestException: public std::exception
{
std::string m_what;
public:
TestException(const std::string& what) : m_what(what) { }
~TestException() throw() { }
virtual const char* what() const throw()
{
return "My exception happened";
}
};
// Flag used to control thread exit
static bool terminate = false;
// This class does an insert into the test table
struct Inserter
{
void operator()()
{
// Establish a connection
PGconn* conn = PQconnectdb("user=postgres password=1234");
// Insert data into table indefinitely
int i=0;
while(!terminate)
{
// SQL Statement
std::stringstream insert;
insert << "INSERT INTO tmp (value) VALUES (" << i%250 << ");";
std::string insertStr = insert.str();
const char* c_str = insertStr.c_str();
// Execute query
PGresult* res=PQexec(conn,c_str);
if (PQresultStatus(res) == PGRES_FATAL_ERROR)
{
std::cerr << "Error in inserting data:\nError code: " << PQresStatus(PQresultStatus(res)) << "Error Message: " << PQerrorMessage(conn);
PQclear(res);
PQfinish(conn);
throw TestException( "Inserter::PQexec() failed." );
}
PQclear(res);
// Increment index
i++;
}
PQfinish(conn);
}
};
struct Queryer
{
void operator()()
{
// Establish a connection
PGconn* conn = PQconnectdb("user=postgres password=1234");
// Retrieve data from the test table indefinitely
int i=1;
while (!terminate)
{
// SQL statement - read the top 1000 values off `tmp'
std::stringstream query;
query << "SELECT * FROM tmp WHERE id > (SELECT last_value - 1000 FROM tmp_id_seq);";
std::string queryStr = query.str();
const char* c_str= queryStr.c_str();
// Execute query
PGresult* res=PQexec(conn, c_str);
if (PQresultStatus(res) == PGRES_FATAL_ERROR)
{
std::cerr << "Error in searching data:\nError code: " << PQresStatus(PQresultStatus(res)) << "Error Message: " << PQerrorMessage(conn);
PQclear(res);
PQfinish(conn);
throw TestException( "Queryer::PQexec() failed." );
}
PQclear(res);
// Increment index
i++;
}
PQfinish(conn);
}
};
int main(int argc, char * argv[])
{
int sleep_time = 0;
if (argc > 1) {
sleep_time = atoi(argv[1]);
}
std::cerr << std::string("Libpq is ") + (PQisthreadsafe() ? "" : "not ") + "threadsafe" << std::endl;
// Establish a connection
PGconn* conn = PQconnectdb("user=postgres password=1234");
// Create the test table
std::cout << "Creating table...\n";
PGresult* res=PQexec(conn,"DROP TABLE IF EXISTS tmp; CREATE TABLE tmp (id SERIAL8 PRIMARY KEY,value INT);");
if (PQresultStatus(res) == PGRES_FATAL_ERROR)
{
std::cerr << "Error in Creating table:\nError code: " << PQresStatus(PQresultStatus(res)) << "Error Message: " << PQerrorMessage(conn);
PQclear(res);
PQfinish(conn);
return 1;
}
// Clear and close the current connectio
Re: [BUGS] BUG #5055: Invalid page header error
On Mon, 2009-09-14 at 23:17 +, john martin wrote: > All of a sudden we started seeing page header errors in certain queries. Was there any particular event that marked the onset of these issues? Anything in the system logs (dmesg / syslog etc) around that time? [for SATA disks]: does smartctl from the smartmontools package indicate anything interesting about the disk(s)? (Ignore the "health status", it's a foul lie, and rely on the error log plus the vendor attributes: reallocated sector count, pending sector, uncorrectable sector count, etc). Was Pg forcibly killed and restarted, or the machine hard-reset? (This _shouldn't_ cause data corruption, but might give some starting point for looking for a bug). > I am urging the community to investigate the possibility that it may not be > hardware related, especially since it was first reported at least 5 years > back. If anything, the fact that it was first reported 5 years back makes it _more_ likely to be hardware related. Bad hardware eats/scrambles some of your data; Pg goes "oh crap, that page is garbage". People aren't constantly getting their data eaten, though, despite the age of the initial reports. It's not turning up lots. It's not turning up in cases where hardware issues can be ruled out. There doesn't seem to be a strong pattern associating issues to a particular CPU / disk controller / drive etc to suggest it could be Pg triggering a hardware bug or a bug in Pg triggered by a hardware quirk. It doesn't seem to be reproducible and people generally don't seem to be able to trigger the issue repeatedly. Either it's a *really* rare and quirky bug that's really hard to trigger, or it's a variety of hardware / disk issues. If it's a really rare and quirky hard to trigger bug, where do you even start looking without *some* idea what happened to trigger the issue? Do you have any idea what might've started it in your case? *** DID YOU TAKE COPIES OF YOUR DATA FILES BEFORE "FIXING" THEM *** ? -- Craig Ringer -- 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 #5055: Invalid page header error
On Mon, 2009-09-14 at 22:58 -0700, John R Pierce wrote: > and, if you're doing RAID with desktop grade disks, its quite possible > for the drive to spontaneously decide a sector error requires a data > relocation but not have the 'good' data to relocate, and not return an > error code in time for the RAID controller or host md-raid to do > anything about it. this results in a very sneaky sort of data > corruption which goes undetected until some time later. > > > this is the primary reason to use the premium "ES" grade SATA drives > rather than the cheaper desktop stuff in a raid, they return sector > errors in a timely fashion rather than retrying for many minutes in the > background. Ugh, really? What do the desktop drives return in the mean time, when they haven't been able to read a sector properly? Make something up and hope it gets written to soon? That seems too hacky even for desktop HDD firmware, which is saying something. I've generally seen fairly prompt failure responses from desktop-grade drives (and I see a lot of them fail!). While there are usually many layers of OS-driven retries above the drive that delay reporting of errors, the RAID volume the drive is a member of will generally block until a retry succeeds or the OS layers between the software RAID implementation and the disk give up and pass on the disk's error report. That said, I've mostly used Linux's `md' software RAID, which while imperfect seems to be pretty sane in terms of data preservation. -- Craig Ringer -- 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 #5055: Invalid page header error
postgres bee wrote: > Correct me if I am wrong, but I thought one of the, if not the most, primary > tasks for relational databases is to ensure that no data loss ever occurs. > Which is why I was initially surprised that the issue did not get enough > importnace. But now it seems more like the community not knowing what > triggered the issue i.e. not knowing which component to fix. ... or if there is anything to fix. PostgreSQL has to trust the hardware and the OS to do their jobs. If the OS is, unbeknownst to PostgreSQL, flipping the high bit in any byte written at exactly Midnight on a tuesday, there's nothing PostgreSQL can do to prevent it. If Pg checksummed blocks and read each block back after writing it could possibly detect *immediate* write problems - but then, OS caching would probably hide the issue unless Pg bypassed the OS's caching and forced direct disk reads. To say this would perform poorly is a spectacular understatement. Even with such a scheme, there's no guarantee that data isn't being mangled after it hits disk. The RAID controller might be "helpfully" "fixing" parity errors in a RAID 5 volume using garbage being returned by a failing disk during periodic RAID scrubbing. An SSD might have a buggy wear leveling algorithm that results in blocks being misplaced. And so on. Now, in those cases you might see some benefit from an OS-level checksumming file system, but that won't save you from OS bugs. It's the OS and the hardware's job to get the data Pg writes to disk onto disk successfully and accurately, keep it there, and return it unchanged on request. If they can't do that, there's nothing Pg can do about it. > But I do have one overriding question - since postgres is still running on > the same hardware, wouldn't it rule out hardware as the primary suspect? Absolutely not. As Tom Lane noted, such faults are generally intermittent. For example: I had lots of "fun" years ago tracking down an issue caused by RAID scrubbing on a defective 3Ware 8500-8 card. The card ran fine in all my tests, and the system would remain in good condition for a week or two, but then random file system corruption would start arising. Files would be filled with garbage or with the contents of other files, the file system structure would get damaged and need fsck, files would vanish or turn up in lost+found, etc etc. It turned out that by default the controller ran a weekly parity check - which was always failing due to an defect with the controller, triggering a rebuild. The rebuild, due to the same issue with the controller, would proceed to merrily mangle the data on the array in the name of restoring parity. 3Ware replaced the controller and all was well. Now, what's PostgreSQL going to do when it's run on hardware like that? How can it protect its self? It can't. Common causes of intermittent corruption include: - OS / file system bugs - Buggy RAID drivers and cards, especially "fake raid" cards - Physically defective or failing hardware RAID cards - Defective or overheating memory / CPU, resulting in intermittent memory corruption that can affect data written to or read from disk. Doesn't always show up as crashing processes etc as well; such things can be REALLY quirky. - Some desktop hard disks, which are so desperate to ensure you don't return them as defective that they'll do scary things to remap blocks. "Meh, it was unreadable anyway, I'll just re-allocate it and return zeroes instead of reporting an error" Sometimes bugs will only arise in certain circumstances. A RAID controller bug might only be triggered by a Western Digital "Green" hard disk with a 1.0 firmware*. An issue with a 2.5" laptop SSD might only arise when a write is committed to it immediately before it's powered off as a laptop goes into sleep. A buggy disk might perform an incomplete write of a block if power from the PSU momentarily drops below optimal levels because someone turned on the microwave on the same phase as the server. The list is endless. What it comes down to, though, is that this issue manifests its self first as some corrupt blocks in one of the database segments. There's absolutely no information available about when they got corrupted or by what part of the system. It could've even been anti-virus software on the system "disinfecting" them from a suspected virus, ie something totally outside the normal parts of the system Pg is concerned with. So, unless an event is noticed that is associated with the corruption, or some way to reproduce it is found, there's no way to tell whether any given incident could be a rarely triggered Pg bug (ie: Pg writes wrong data, writes garbage to files, etc) or whether it's something external like hardware or interfering 3rd party software. Make se
Re: [BUGS] BUG #5058: [jdbc] Silent failure with executeUpdate()
On Tue, 2009-09-15 at 19:26 +, Joseph Shraibman wrote: > The following bug has been logged online: > > Bug reference: 5058 > Logged by: Joseph Shraibman > Email address: j...@selectacast.net > PostgreSQL version: 8.2.14 > Operating system: Linux > Description:[jdbc] Silent failure with executeUpdate() > Details: > > I was trying to figure out why I was getting different results with sql I > was running through jdbc and running through psql. I was able to fix the > bug by changing an executeUpdate() to an execute(). See attached code. > While the test case is appreciated, it's not really that clear what's expected to happen vs what happens, at what point things go wrong and under what circumstances, etc. Looking at your code and your post, I can't tell: - If the code you've attached is before or after the change described - Where the change is/was made - Why - What it actually does There are also a couple of randomly commented-out bits of code that seem odd, some code seems like unnecessary wrapper code in such a simple example ( eg getStatement(...) ) and some of the code is downright hairy. In particular: private static StringBuilder toString(Object o, StringBuilder sb) cries out "use parameterized queries!". You're making life unnecessarily hard for yourself, increasing SQL injection risk dramatically, and giving yourself more to debug than you need by building queries as strings including all parameters. Perhaps you could pare down the code to that required to demonstrate the issue and document the issue a little? Cut out unnecessary or duplicate code (why are there two doQuery() implementations with mostly the same code), drop any result-printing code etc if it doesn't help demonstrate the bug you're reporting, remove commented out code and empty blocks, and generally tidy things up so that the reader can read it to follow your problem report, not puzzle out why your code does things how it does. Above all else, make sure to provide an explanation of where the problem you are reporting arises, what actually happens, what you expect to happen instead, and what exactly you change to "fix" it. It might help to turn detailed error logging on in the server and capture the server error log for your "silent" query failure, too. -- Craig Ringer -- 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 #5060: 8.2 bin install
Attila Somogyi wrote: > I have a special problem, I use a java based software that use postgresql, > but as I know the sql queries cahnged in 8.3 and the manufacturer of my > software support only 8.2 or earlier version. I look for a long time a > binary install package on the Internet but didn't found. Build and install PostgreSQL 8.2 from source. This is not a bug. -- Craig Ringer -- 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 report
황수진 wrote: > > postgres=# \encoding > EUC_KR > postgres=# CREATE DATABASE 수진이_친구; > WARNING: could not determine encoding for locale "Korean_Korea.949": codeset > is > "CP949" > 상세정보: Please report this to http://www.postgresql.org/mailpref/pgsql-bugs
Re: 답장: [BUGS] bug report
On Thu, 2009-09-17 at 12:06 +0900, 황수진 wrote: > Pg version is 8.4.1. > I am using Windows XP. > Please reply to the list, not just to me. I've cc'd the bugs list. I don't have much idea what could be causing your issue personally, as I have practically zero knowledge about locale handling on Windows. -- Craig Ringer
Re: [BUGS] BUG #5069: Segfault
Tom Lane wrote: > "Kenaniah Cerny" writes: >> Segfault party > > I couldn't reproduce a crash given this information. Which probably means 'it's time to hook up `gdb' and get a backtrace of the crash'. -- Craig Ringer -- 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]
On Mon, 2009-10-19 at 23:04 +0200, steffen nielsen wrote: > Hello.. I just purchased for holdem manager pro. And i need PostgreSQL > 8.3.msi file to continue my installation. Everytime I try to install > this message pops up: That i can't open the install file and to > contact you guys. If i have the right software to my windows. I use > Windows Vista and i have deactivated user thing in control panel. You might want to contact the tech support team for your poker software. There's no indication that you're reporting a PostgreSQL bug, and you've provided nowhere near enough information to understand what might be going on. If you don't have any luck and you're convinced there's really something wrong with the PostgreSQL MSI installer, please ask on the pgsql-general list and provide details such as where you got the installer from (exact URL please), the file size of the installer, the MD5SUM of the installer (search the Internet for how to do this), the EXACT error message, any Windows error log entries that appear in the Event Viewer when you run the installer, etc. -- Craig Ringer
Re: [BUGS] BUG #5130: Failed to run initdb:1
Robert Haas wrote: > Well, I'm sort of hoping one of the Windows folks will chime in > here... but I would start by checking that PostgreSQL is in your path > exactly once and that the permissions are set right. It could also be a character coding issue or an issue caused by the localization of Windows paths. Robert: does your system actually have a directory called "C:\Program Files" ? If you open the Run dialog in the Start menu, paste in: "C:\Program Files" including the quotes, and press enter, does any folder open? (Note that even if no "program files" folder is visible in C:\ in Windows Explorer it might still open; Windows virtualises some paths). -- Craig Ringer -- 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] Postmaster hangs
Karen Pease wrote: > kill -9 does kill postmaster (or at least seems to). But I can't figure > out a way to get it restarted without a reboot -- I don't know what I'm > missing. The Fedora postgres restart scripts don't do the trick, and I > couldn't get it to work with pg_ctl either. It'd help to know where the postmaster was stuck, and if possible where the backend you were using is stuck. A backtrace from gdb can be handy for this. http://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Linux/BSD > kill -9 doesn't work on the locked up httpd processes. So that has to > have the system restarted. If `kill -9' isn't working they're probably in uninterruptable sleep in the kernel. You can find out what they're sleeping in with `ps': ps ax -o pid,ppid,stat,wchan:50,cmd (Filter for just the postmaster and postgres processes if you want) > Both filesystems are EXT-4. That's interesting given the issues you're having... -- Craig Ringer -- 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] Postmaster hangs
On 26/10/2009 5:28 PM, Karen Pease wrote: > I did my best to follow the gdb instructions. I ran: > > gdb -p 2852 > > Then connected entered the logging statements, then ran "cont", then > ctrl-c'ed it a couple times. I got: OK, so there's nothing shrieklingly obviously wrong with what the postmaster is up to. But what about the backend that's stopped responding? Try connecting gdb to that "postgres" process once it's stopped responding and get a backtrace from that. > [r...@chmmr dbscripts]# ps ax -o pid,ppid,stat,wchan:50,cmd | grep -i > http > 3376 1 D > start_this_handle /usr/sbin/httpd start_this_handle appears in common ext4 call paths, and several lkml issue reports over time: http://lkml.org/lkml/2009/3/11/253 http://www.google.com.au/search?q=%22start_this_handle%22+ext4 Smells like kernel bug. When looking at two extremely stable pieces of software (Pg and apache) both having issues on a well tested kernel (Linux) with a new and fairly immature file system in use (ext4) it's probably not an unreasonable assumption. You can find out a bit more about what the kernel is doing using the "magic" keyboard sequence "ALT-SysRQ-T" from a vconsole (not under X). If the results scroll past too fast you can page through them with "less" on /var/log/kern.log (or /var/log/dmesg depending on your distro) or using the "dmesg" command. I won't be too surprised if you see a kernel stack trace for your httpd process(es) starting something like this: schedule+0x18/0x40 start_this_handle+0x374/0x508 jbd2_journal_start+0xbc/0x11c ext4_journal_start_sb+0x5c/0x84 ext4_dirty_inode+0xd4/0xf0 -- Craig Ringer -- 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] Postmaster hangs
On Tue, 2009-10-27 at 00:50 -0500, Karen Pease wrote: > > OK, so there's nothing shrieklingly obviously wrong with what the > > postmaster is up to. But what about the backend that's stopped > > responding? Try connecting gdb to that "postgres" process once it's > > stopped responding and get a backtrace from that. > > > > Okay -- I started up a psql instance, which immediately locks up. I > then attached gdb to it and got this: > > (gdb) cont > Continuing. > ^C > Program received signal SIGINT, Interrupt. > 0x00fe2416 in __kernel_vsyscall () You didn't actually request a backtrace (bt), so all it shows is the top stack frame. That doesn't tell us anything except that it's busy in a system call in the kernel. > > You can find out a bit more about what the kernel is doing using the > > "magic" keyboard sequence "ALT-SysRQ-T" from a vconsole (not under X). > > Nothing happened. Nothing useful in dmesg -- certainly no stacktraces. Your kernel might not have the "magic sysrq key" enabled. Run: sudo sysctl -w kernel.sysrq=1 and try again. Note that on some systems with weird keyboards you might have to hold the "Fn" key (if you have one) or disable "F-Lock" (if you have it) to get SysRq to be recognised. The print screen / PrtScn key is usually shared with SysRq even if it's not marked as such. Hmm, it looks like the SysRq magic key sequences even work under X. I didn't think they did, but on my system here hitting alt-sysrq-t under X11 dumps a bunch of task trace data in to /var/log/kern.log (Ubuntu system), including task info and some general info on the CPU states. Oct 27 14:20:19 wallace kernel: [13668207.501781] postgres S 28e389e2 0 3152 31105 Oct 27 14:20:19 wallace kernel: [13668207.501781] f352bcac 00200086 c3634358 28e389e2 00029346 c069a340 c07d2180 Oct 27 14:20:19 wallace kernel: [13668207.501781] c51fe480 c51fe6f8 c3634300 c3634300 c3634300 c51fe6f8 Oct 27 14:20:19 wallace kernel: [13668207.501781] f352bca8 c01398c8 c90e 7fff c90e01a8 f352bcf8 c050ec7d f352bcc8 Oct 27 14:20:19 wallace kernel: [13668207.501781] Call Trace: Oct 27 14:20:19 wallace kernel: [13668207.501781] [] ? enqueue_task_fair+0x68/0x70 Oct 27 14:20:19 wallace kernel: [13668207.501781] [] schedule_timeout+0xad/0xe0 Oct 27 14:20:19 wallace kernel: [13668207.501781] [] ? prepare_to_wait+0x3a/0x70 Oct 27 14:20:19 wallace kernel: [13668207.501781] [] unix_stream_data_wait+0x88/0xe0 Oct 27 14:20:19 wallace kernel: [13668207.501781] [] ? autoremove_wake_function+0x0/0x50 Oct 27 14:20:19 wallace kernel: [13668207.501781] [] unix_stream_recvmsg+0x311/0x490 Oct 27 14:20:19 wallace kernel: [13668207.501781] [] ? apparmor_socket_recvmsg+0x10/0x20 Oct 27 14:20:19 wallace kernel: [13668207.501781] [] sock_recvmsg+0xf4/0x120 Oct 27 14:20:19 wallace kernel: [13668207.501781] [] ? autoremove_wake_function+0x0/0x50 Oct 27 14:20:19 wallace kernel: [13668207.501781] [] ? __mem_cgroup_uncharge_common+0x137/0x170 Oct 27 14:20:19 wallace kernel: [13668207.501781] [] ? __dec_zone_page_state+0x18/0x20 Oct 27 14:20:19 wallace kernel: [13668207.501781] [] ? page_remove_rmap+0x61/0x130 Oct 27 14:20:19 wallace kernel: [13668207.501781] [] ? kunmap_atomic+0x50/0x60 Oct 27 14:20:19 wallace kernel: [13668207.501781] [] sys_recvfrom+0x7c/0xd0 Oct 27 14:20:19 wallace kernel: [13668207.501781] [] ? __pagevec_free+0x25/0x30 Oct 27 14:20:19 wallace kernel: [13668207.501781] [] ? release_pages+0x160/0x1a0 Oct 27 14:20:19 wallace kernel: [13668207.501781] [] ? rb_erase+0xcd/0x150 Oct 27 14:20:19 wallace kernel: [13668207.501781] [] sys_recv+0x36/0x40 Oct 27 14:20:19 wallace kernel: [13668207.501781] [] sys_socketcall+0x1b7/0x2b0 Oct 27 14:20:19 wallace kernel: [13668207.501781] [] ? sys_gettimeofday+0x2b/0x70 Oct 27 14:20:19 wallace kernel: [13668207.501781] [] sysenter_do_call+0x12/0x2f BTW, if you do get kernel task trace information and you decide to redact it, it'd be good to include at least all your `postgres' instances, all `httpd' instances, and the summary information at the end. -- Craig Ringer -- 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 #5149: Can't untar the src code file
Robert Haas wrote: >> tar -x post*.tar >> ^C >> c-76-123-226-197:Downloads donfox1$ tar -xvf postgresql-8.4.1.tar >> tar: Unrecognized archive format: Inappropriate file type or format >> tar: Error exit delayed from previous errors. I've seen some browsers on Mac OS X "helpfully" strip the .gz extension. I have no idea why. Try using the "file" utility to see what sort of file it is. If "file" says: postgresql-8.4.1.tar: gzip compressed data, from Unix, then use "tar xvzf" instead. (I've never understood why tar doesn't detect the gzip and bzip2 file headers and automatically shell out to the appropriate helper. Or just link to zlib, for that matter. "purist" issues I expect.) Anyway, if "file" says something else, post the result here along with the result of: od -x postgresql-8.4.1.tar | head -- Craig Ringer -- 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] Postmaster hangs
nimal kernel knowledge. Second: From this one snapshot in time it's not possible to tell what (if anything) is going wrong with the postgresql backends. Everything looks pretty sane. The kernel stack trace doesn't tell us if PostgreSQL is somehow stuck doing this atime update or whether it's just busy touching a lot of files. There's nothing inconsistent with a big, busy query. This is when I start wanting to be able to play with the machine. It's hard to do interactive debugging remotely, and that's what I really want to do to get a handle on this. I don't think I'm smart enough to figure this one out otherwise, though others here on this list probably are. As for Apache: about half of your httpd instances appear to be waiting on a lock. The other half of them are updating atime metadata on files after performing reads. And this one I'm not sure what it's doing: > httpd S c06aaab2 0 18474 3285 >ef333d94 0082 ef333d2c c06aaab2 ef333d38 c087c67c c087fc00 > c087fc00 >c087fc00 ec6319a0 ec631c14 c1ff7c00 0002 c1ff7c00 c087c8e8 > ef333dc4 >ef333d80 c041f4f5 ef333d6c ec631c14 05f8a33e c04ec457 ef333dc8 > ee32dea8 > Call Trace: > [] ? _cond_resched+0x8/0x32 > [] ? kmap_atomic_prot+0x1b0/0x1da > [] ? ipc_lock+0x2b/0x45 > [] sys_semtimedop+0x4ca/0x579 > [] ? handle_mm_fault+0x2e8/0x6ec > [] ? kunmap_atomic+0x87/0xa7 > [] ? do_page_fault+0x3ac/0x710 > [] ? resched_task+0x3a/0x6e > [] ? _spin_unlock_irqrestore+0x22/0x38 > [] ? __dequeue_entity+0x73/0x7b > [] ? __slab_alloc+0x56/0x45b > [] ? __switch_to+0xb9/0x139 > [] ? _spin_lock+0x8/0xb > [] ? add_wait_queue+0x2b/0x30 > [] ? ep_ptable_queue_proc+0x58/0x69 > [] sys_ipc+0x48/0x149 > [] ? syscall_trace_enter+0xb5/0xc9 > [] syscall_call+0x7/0xb -- Craig Ringer -- 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] Postmaster hangs
On 31/10/2009 4:32 PM, Karen Pease wrote: > Sorry for the delay in responding, and thanks for your help. By the way, you may also be able to learn some more using the 'blktrace' tool. This gathers low-level data about what processes are performing I/O on your system. # mount -t debugfs none /sys/kernel/debug # btrace /dev/YOUR_DISK eg on my workstation, Pg is busy on /dev/md1 so: # btrace /dev/md1 > 9,1013496 2.514811417 31109 A W 114959520 + 8 <- (252,3) > 31073056 > 9,1013497 2.514811732 31109 Q W 114959520 + 8 [postgres] > 9,1013498 2.514816413 31109 A W 114959528 + 8 <- (252,3) > 31073064 > 9,1013499 2.514816732 31109 Q W 114959528 + 8 [postgres] > 9,1013500 2.514819960 31109 A W 114959536 + 8 <- (252,3) > 31073072 > 9,1013501 2.514820280 31109 Q W 114959536 + 8 [postgres] > 9,1013502 2.514823399 31109 A W 114959544 + 8 <- (252,3) > 31073080 > 9,1013503 2.514823737 31109 Q W 114959544 + 8 [postgres] > 9,1013504 2.514826792 31109 A W 114959552 + 8 <- (252,3) > 31073088 > 9,1013505 2.514827112 31109 Q W 114959552 + 8 [postgres] > 9,1013506 2.514830715 31109 A W 114959560 + 8 <- (252,3) > 31073096 > 9,1013507 2.514831034 31109 Q W 114959560 + 8 [postgres] > 9,1013508 2.514834278 31109 A W 114959568 + 8 <- (252,3) > 31073104 > 9,1013509 2.514834593 31109 Q W 114959568 + 8 [postgres] > 9,1013510 2.514838977 31109 U N [postgres] 0 > 9,1013511 2.515773952 31109 U N [postgres] 0 > 9,1013512 2.51577888916 U N [kblockd/0] 0 > 9,1013513 2.519146885 31109 U N [postgres] 0 > 9,1013514 2.520511306 31109 U N [postgres] 0 > CPU0 (9,1): > Reads Queued: 1,4KiB Writes Queued:6718, > 26872KiB > Read Dispatches:0,0KiB Write Dispatches:0, > 0KiB > Reads Requeued: 0 Writes Requeued: 0 > Reads Completed:0,0KiB Writes Completed:0, > 0KiB > Read Merges:0,0KiB Write Merges:0, > 0KiB > Read depth: 0 Write depth: 0 > IO unplugs:53 Timer unplugs: 6 (ignore quotes; working around a stuipid Thunderbird limitation) -- Craig Ringer -- 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 #5163: Admin can't connect and won't use port 5432
Charles wrote: > The following bug has been logged online: > > Bug reference: 5163 > Logged by: Charles > Email address: cni...@mediasensorcorp.com > PostgreSQL version: 8.4.1 > Operating system: Vista Home Premium > Description:Admin can't connect and won't use port 5432 > Details: > > The installer forced me to use port 5433. If you had an older copy of PostgreSQL still installed and it was using port 5432 already, the installer would pick the next available port. > So how can I make it work with the correct port and start it? Uninstall or disable whatever's using port 5432. Then edit postgresql.conf and change the port setting from 5433 to 5432 and restart the PostgreSQL service. > Not sure why it created a new User account on my login screen called > postgress either. Was that necessary? Security. PostgreSQL is a "sealed server" where the user is absolutely never meant to mess with the data directory at all. The user has no reason to access the data directory or be able to access it. So postgresql creates a separate user account for the postgresql server and restricts access to the data directory to that account. This also means that if a security hole is discovered in the postgresql server and someone is able to exploit postgresql to run code on your machine, they can only do the things that the restricted-priveleges postgresql account lets them do. They shouldn't be able to install a rootkit, drop a virus on the machine, etc. Running services under specific user accounts is absolutely standard on all operating systems, including Windows. Many Microsoft services run under different user accounts too, such as the IIS web server, Exchange mail server, and in fact many standard built-in services on a normal Windows system. What's odd is that you noticed the new user account. Is it showing up on your login screen? Or did you only notice because you were asked for a password? A service account shouldn't make any difference to your use of the machine, and it already has lots of them when it's installed. > Baffled. I am blaming MS and VISTA at this point. Incorrectly so in this case, I'm afraid. -- Craig Ringer -- 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 #5163: Admin can't connect and won't use port 5432
[Please reply to the list, not just to me - use the "reply all" button] cni...@mediasensorcorp.com wrote: > Tried a few time to uninstall and install. Is there additional > unsinstall steps beyond the remove program control panel thing? Assuming you installed using the installer, rather than using the non-installer .zip and creating the service etc yourself, then removing PostgreSQL using the add/remove programs should be all that is required. > I port > scanned and nothing was using port 5432. A port scan is the wrong tool for the job. Use the operating system's built in "netstat" command to show listening ports. You can use it via cmd.exe. Search the Internet and read the built-in help (start with "netstat /?") for more information if you have trouble. > I turned the firewall off in > order to even install it. That is not necessary. > Unfortunately the client app needs 5432 port to be used and I can't > change it to 5433. So edit postgresql.conf and change the port the server uses to port 5432, then restart the service. Not hard. postgresql.conf lives in a subdirectory of the directory you installed PostgreSQL in. If you use PgAdmin III you can open postgresql.conf via its menus - it's under "Tools" -> "Server Configuration". -- Craig Ringer -- 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 #5163: Admin can't connect and won't use port 5432
cni...@mediasensorcorp.com wrote: > Netstat -a shows 0.0.0.0:5432 Listening First: please reply to the list, not to me. I will not respond to further mail directly to me. Use the "reply all" button in your mail client. As for the port: Yes, it's listening, but what process is listening on it? Get netstat to show the process IDs, then use Task Manager to match those up with process names. See: http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/netstat.mspx?mfr=true > But I don't see my IP 192.168.0.199 having that port open. So maybe it's only listening on 127.0.0.1 (the loopback address) ? Did you check? Netstat tells you that. You might need to tell PostgreSQL to listen on all addresses as I think it may default to listening only on the loopback address for security. > I noticed when I restart the Postgre server it gives me a message in a > CMD window that says: > Server not started > See nethelp MSG 3521 > And system error 5 has occured And what happens if you use the "net help" command to display the text for that error message? (Who knows why Microsoft did it this way rather than just displaying the error in-place). Also check the Windows event log to see what might be going on. You can find the Event Viewer in the Administrative Tools section of the Control Panel. > When I run pgAdmin III > In object browser 1 server is indicated. Did you check to make sure it's connecting to the right port, after you restarted the service? > When I double click it asks for PW then I get an error message as Follows > "2009-11-04 03:19:09 ESTLOG: invalid IP mask "md5": Unknown host > 2009-11-04 03:19:09 ESTCONTEXT: line 73 of configuration file > "C:/Program Files/PostgreSQL/8.4/data/pg_hba.conf" > 2009-11-04 03:19:09 ESTFATAL: could not load pg_hba.conf" You've mucked up your pg_hba.conf - it looks like you've deleted the host specification on a line. if you wanted to say "any host", use 0.0.0.0/0 instead of deleting the entry. That text appears to be read out of the server error log. It looks like PgAdmin is helping you out by trying to start the service and when it fails, looking at the server error log to see why. > Can you help me get this going? Not unless you start using the resources you already have, no. USE THE POSTGRESQL SERVER ERROR LOG - remember where I said it was? It is your main tool in any troubleshooting process. PgAdmin II has already done this for you for the immediate problem and shown you that you've messed up your pg_hba.conf. The error even tells you the line number and what's wrong with it. I can't actually fix it for you, and you already have enough information to fix it yourself. -- Craig Ringer -- 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] Crazy query plan.
On 13/11/2009 7:25 PM, Oleg Serov wrote: > EXPLAIN ANALYZE SELECT ((SELECT tmp::test FROM (SELECT * FROM test > LIMIT 1) tmp)::test).*; This may be simplified to the comparison between these two queries: SELECT ((SELECT test FROM test LIMIT 1)::test); SELECT ((SELECT test FROM test LIMIT 1)::test).*; The former results in a single seq scan in a single subquery: Result (cost=0.02..0.03 rows=1 width=0) InitPlan -> Limit (cost=0.00..0.02 rows=1 width=32) -> Seq Scan on test (cost=0.00..27.70 rows=1770 width=32) The latter does this four times: Result (cost=0.06..0.07 rows=1 width=0) InitPlan -> Limit (cost=0.00..0.02 rows=1 width=32) -> Seq Scan on test (cost=0.00..27.70 rows=1770 width=32) -> Limit (cost=0.00..0.02 rows=1 width=32) -> Seq Scan on test (cost=0.00..27.70 rows=1770 width=32) -> Limit (cost=0.00..0.02 rows=1 width=32) -> Seq Scan on test (cost=0.00..27.70 rows=1770 width=32) -> Limit (cost=0.00..0.02 rows=1 width=32) -> Seq Scan on test (cost=0.00..27.70 rows=1770 width=32) The change is triggered by expansion of the single-ROW result of the subquery into a regular 4-tuple. Is the co0nversion of the ROW into individual fields in the SELECT clause done by some kind of macro-expansion in parsing/planning? -- Craig Ringer -- 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] Crazy query plan.
> This may be simplified to the comparison between these two queries:
... or even further into:
CREATE TYPE test AS ( a integer, b integer, c integer, d integer );
EXPLAIN SELECT ((SELECT ROW(1,1,1,1)::test)::test);
EXPLAIN SELECT ((SELECT ROW(1,1,1,1)::test)::test).*;
craig=# EXPLAIN SELECT ((SELECT ROW(1,1,1,1)::test)::test);
QUERY PLAN
--
Result (cost=0.01..0.02 rows=1 width=0)
InitPlan
-> Result (cost=0.00..0.01 rows=1 width=0)
(3 rows)
craig=# EXPLAIN SELECT ((SELECT ROW(1,1,1,1)::test)::test).*;
QUERY PLAN
--
Result (cost=0.04..0.05 rows=1 width=0)
InitPlan
-> Result (cost=0.00..0.01 rows=1 width=0)
-> Result (cost=0.00..0.01 rows=1 width=0)
-> Result (cost=0.00..0.01 rows=1 width=0)
-> Result (cost=0.00..0.01 rows=1 width=0)
(6 rows)
Something odd I stumbled upon while testing for this:
craig=# SELECT tmp FROM (SELECT ((SELECT ROW(1,1,1,1)::test)::test)) AS tmp;
tmp
---
("(1,1,1,1)")
(1 row)
... is fine,
craig=# SELECT tmp.* FROM (SELECT ((SELECT ROW(1,1,1,1)::test)::test))
AS tmp;
test
---
(1,1,1,1)
(1 row)
... is fine,
craig=# SELECT (tmp.*).* FROM (SELECT ((SELECT
ROW(1,1,1,1)::test)::test)) AS tmp;
test
---
(1,1,1,1)
(1 row)
... is ... WTF? How is "(tmp.*).*" the same as "tmp.*" ?
--
Craig Ringer
--
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] Crazy query plan.
Sorry for the multiple replies-to-self, but this seemed worth specifically noting: the expansion also results in multiple calls to tuple-returning functions, even functions marked VOLATILE. For example: CREATE OR REPLACE FUNCTION expandtest(INTEGER) RETURNS test AS $$ DECLARE rec test; BEGIN RAISE NOTICE 'expandtest(%)',$1; rec.a := $1; rec.b := $1; rec.c := $1; rec.d := $1; RETURN rec; END; $$ LANGUAGE 'plpgsql' STRICT VOLATILE; craig=# SELECT (expandtest(1)).*; NOTICE: expandtest(1) NOTICE: expandtest(1) NOTICE: expandtest(1) NOTICE: expandtest(1) a | b | c | d ---+---+---+--- 1 | 1 | 1 | 1 (1 row) I don't know if that's intended behaviour or not, but I certainly find it very _surprising_ behaviour, especially given the otherwise equivalent translation: craig=# SELECT t.* FROM expandtest(1) t; NOTICE: expandtest(1) a | b | c | d ---+---+---+--- 1 | 1 | 1 | 1 (1 row) -- 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 #5221: errors converting string to utf8
On 1/12/2009 7:36 PM, DM wrote:
select convert('Vall\xe9e','LATIN1','UTF8');
You expect the result 'Vallée', right? As in the utf-8 bytes
Vall\xc3\xa9e
?
ERROR: invalid byte sequence for encoding "UTF8": 0xe965
HINT: This error can also happen if the byte sequence does not match the
encoding expected by the server, which is controlled by "client_encoding".
The HINT tells you what's going on here.
The error isn't being raised by convert(...). You'll get the same error
if you just:
select 'Vall\xe9e';
... because the problem is that the server is trying to treat that
literal as a string in your client_encoding, which is UTF-8, and convert
it to the server encoding.
You will note that the convert(...) function takes a 'bytea' argument
rather than 'text'. That's because PostgreSQL string literals are
expected to be valid text in the current encoding. Entering a string
literal with a byte sequence invalid in the current encoding will be
problematic. You need to supply a valid bytea value, which involves
juggling some interesting double-escaping and using octal escapes for
characters.
The octal escape for the byte 0xe9 is \351, so to correctly submit your
query to PostgreSQL you'd need to send:
select convert(E'Vall\\351e','LATIN1','UTF8');
or if you really just want to convert to the server encoding:
select convert_from(E'Vall\\351e','LATIN-1');
Here, E'' is used for the string to tell PostgreSQL to interpret
escapes, and \\351 is used as the octal escape for 0xe9. We double the
backslashes because the first backslash gets used up parsing the
literal, and we want the bytea value to actually be 'Val\351e' after
string literal parsing.
Instead, if standard_conforming_strings is on, you can omit the E'' and
use single backslashes.
Note that in 8.5 and above you could use E'Val\\xe9e' instead of the
octal form, as 8.5 understands hex escapes in bytea values.
I guess bytea is kind of ugly to use in a text-based protocol :-(
because the query string has to be valid text in the client_encoding, so
bytea values containing data not valid in the client encoding must be
escaped in the parsed query string. There's nothing much to be done
about it, though.
--
Craig Ringer
--
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 #5222: failed to run initdb: 1!
On 2/12/2009 2:25 AM, Nicolas urtizberea wrote: The following bug has been logged online: Bug reference: 5222 Logged by: Nicolas urtizberea Email address: nurtizbe...@gmail.com PostgreSQL version: 8.3.1-1 Operating system: Windows XP Fundamentals for Legacy Pc`s SP3 Wow, really? I'm not at all sure PostgreSQL has been tested on that. It's hard to get hold of copies, for one thing. I don't know what Microsoft cut out for XP Fundamentals, but I wouldn't be too surprised if it broke PostgreSQL since Pg relies on proper, working service accounts and the like. Another person reported the same issue with a version of Windows Embedded: http://archives.postgresql.org/pgsql-bugs/2009-03/msg00028.php ... which further suggests that it might be problems caused by a limited Windows version. Try digging through these search results to see if you find anything useful: http://www.google.com.au/search?q=%22The+system+cannot+find+the+file+specified%22+site%3Apostgresql.org It'd be nice to know why this happens, since it might be easy to work around and get Pg working on these versions of Windows. It's hard to know what's going on, though. It'd be helpful if you could provide a process monitor log (in native process monitor format) of the installation process, since that might shed some light. -- Craig Ringer -- 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 #5224: After upgrading from vista to windows 7, postgres services are missing
On 2/12/2009 12:57 PM, Sriram Gopalan wrote: The following bug has been logged online: Bug reference: 5224 Logged by: Sriram Gopalan Email address: sriramgopa...@gmail.com PostgreSQL version: 8.4.1 Operating system: Windows 7 Description:After upgrading from vista to windows 7, postgres services are missing Details: I recently upgraded my machine from windows vista to window 7. I had installed postgresql 8.4.1 on that machine and it was working great. However, after upgrade, I cannot even see the services related to postgres. When I try to connect, I get the message that postgres is not running and listening to its port. In the services control panel (start -> run ->services.msc , or via Control Panel -> Administrative Tools) can you see the postgresql service listed? What state is it in? Is there anything in the Windows Error Log about PostgreSQL? Is there anything of interest at the end of the most recent log file in the "pg_log" subdirectory of the PostgreSQL data directory? -- Craig Ringer -- 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 #5224: After upgrading from vista to windows 7, postgres services are missing
On 2/12/2009 11:51 PM, Sriram Gopalan wrote: 1. After I reinstalled the latest version of postgresql, I do see a service called postgresql-8.4. 2. It is started automatically. Yes, but is it *running* ? The service manager shows the current status (running or stopped) separately to the startup settings. Check if it's running. Also: If you look in Task Manager, are there any "postgres.exe" processes shown? (You'll need to show all users' tasks, since they run under a different user account to yours). psql: could not connect to server: Cannot assign requested address (0x2741/1 0049) Is the server running on host "localhost" and accepting TCP/IP connections on port test? er ... what? "port test" ? Did you mean to specify a port number and just put the wrong thing in the wrong field, or did you really intend to tell psql to connect to the port "test" (via servicename->port translation presumably)? What port is PostgreSQL listening on? Check postgresql.conf. The default is 5432. Try connecting to PostgreSQL by port number. As for the error message: 0x2741 appears to be a name service error, which makes sense if the system is trying to look up the service name to get a port number and failing. Say, if it's deeply confused by being fed a non-numeric string for a port number. Specifically, it's: Windows Error 0x2741 - 10049 The requested address is not valid in its context. WSAEADDRNOTAVAIL 4. I believe ever since I upgraded, the pg_log logs have been empty. There is nothing much interesting in the prior few logs (just info messages about starting up and shutting down etc.) Not even server startup messages? When is the most recent log entry? -- Craig Ringer -- 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 #5224: After upgrading from vista to windows 7, postgres services are missing
On 2/12/2009 11:57 PM, Sriram Gopalan wrote: Please consider this issue as resolved. Reinstallation seems to have fixed it. The service is running, as noted before and I am able to connect and use the database. My syntax was wrong in the previous email. Ah, OK. Please disregard my previous mail then. Thanks for letting us know rather than just going quiet when the problem was fixed. It's nice to know when things work out, and it helps others who search for answers later. -- Craig Ringer -- 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 #5226: Limit operator slows down
On 2/12/2009 10:35 PM, aftab wrote: The following bug has been logged online: Bug reference: 5226 Logged by: aftab Email address: akha...@hotmail.co.uk PostgreSQL version: 8.3.8 Operating system: Centos 5 Description:Limit operator slows down Details: S1="SELECT * FROM position WHERE position.POSITION_STATE_ID=2 AND position.TARGET_ID=18 ORDER BY position.ID DESC "; S2="SELECT * FROM position WHERE position.POSITION_STATE_ID=2 AND position.TARGET_ID=18 ORDER BY position.ID DESC LIMIT 1 "; S1 takes 0.16ms compared to S2 which takes 5 secs. Both S1 and S2 are same except "LIMIT 1 " is added to S2. Please read this: http://wiki.postgresql.org/wiki/Guide_to_reporting_problems then re-post your question to the pgsql-general mailing list, including appropriate EXPLAIN ANALYZE output for both queries, etc. -- Craig Ringer -- 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 #5225: create table: cast necessary for constant??
On 3/12/2009 12:35 AM, Tom Lane wrote: "Kurt wagner" writes: During migration from Informix to Postgres I came across following issue: create temp table temp1 as SELECT firmnr, werknr, 'I' as invper, invnum from ; You really ought to cast the 'I' to some specific type. It's usually neatest to do this by just explicitly identifying the intended type in the first place, eg: SELECT firmnr, werknr, TEXT 'I' as invper, invnum from ; ... which, IIRC, is the standard way to do it. I don't have a copy to check against to be sure. Personally, I like the fact that Pg errs on the side of caution here rather than guessing what you want. -- Craig Ringer -- 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 #5235: Segmentation fault under high load through JDBC
On 8/12/2009 8:09 AM, Tom Lane wrote: "Oleg Yurchenko" writes: Program terminated with signal 11, Segmentation fault. #0 0x0839380b in MemoryContextAllocZeroAligned (context=0x2d9eaf70, size=16) at mcxt.c:559 559 mcxt.c: No such file or directory. in mcxt.c [New Thread 28b01140 (LWP 100115)] #(gdb)bt #14185 0x081c1024 in ExecTargetList (targetlist=0x2b61a158, econtext=0x2b619330, values=0x2b61a0c8, isnull=0x2b61a0d8 "", itemIsDone=0x2b61a170, isDone=0xbfbfe4f0) at execQual.c:5007 #14186 0x081c14cd in ExecProject (projInfo=0x2b61a0e8, isDone=0xbfbfe4f0) at execQual.c:5222 So where are the 14184 intermediate call levels? To generate a full backtrace, disable paging and enable logging with: (gdb) set pagination off (gdb) set logging file debuglog.txt (gdb) set logging on (gdb) bt Gzip the resulting 'debuglog.txt' and put it somewhere accessible, then post a link to this mailing list. (If your PostgreSQL was built with full debugging support, rather than just having debuginfo packages installed for a distro version, run 'gdb full' instead of 'gdb' to get stack frame details). Alternately, it might be helpful enough to just go back toward the bottom of the stack and dump the first few hundred frames: (gdb) set pagination off (gdb) set logging file debuglog.txt (gdb) set logging on (gdb) bt -200 ... then paste the result directly into this. -- Craig Ringer -- 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 #5235: Segmentation fault under high load through JDBC
quot;, > isDone=0xbfbfe120) at execQual.c:1685 > #14181 0x081bb631 in ExecEvalFunc (fcache=0x2b6197c0, econtext=0x2b619330, > isNull=0xbfbfe344 "8*(9*\027", isDone=0xbfbfe120) at > execQual.c:2116 > #14182 0x081ba291 in ExecEvalFuncArgs (fcinfo=0xbfbfe1a4, argList=0x2b619c40, > econtext=0x2b619330) at execQual.c:1216 > #14183 0x081ba834 in ExecMakeFunctionResult (fcache=0x2b6193b8, > econtext=0x2b619330, isNull=0x2b61a0d8 "", isDone=0x2b61a170) at > execQual.c:1463 > #14184 0x081bb631 in ExecEvalFunc (fcache=0x2b6193b8, econtext=0x2b619330, > isNull=0x2b61a0d8 "", isDone=0x2b61a170) at execQual.c:2116 > #14185 0x081c1024 in ExecTargetList (targetlist=0x2b61a158, > econtext=0x2b619330, values=0x2b61a0c8, isnull=0x2b61a0d8 "", > itemIsDone=0x2b61a170, isDone=0xbfbfe4f0) at execQual.c:5007 > #14186 0x081c14cd in ExecProject (projInfo=0x2b61a0e8, isDone=0xbfbfe4f0) at > execQual.c:5222 > #14187 0x081c1623 in ExecScan (node=0x2b6192a8, accessMtd=0x81d5120 > ) at execScan.c:143 > #14188 0x081d516a in ExecSubqueryScan (node=0x2b6192a8) at > nodeSubqueryscan.c:85 > #14189 0x081b7f9e in ExecProcNode (node=0x2b6192a8) at execProcnode.c:381 > #14190 0x081b598e in ExecutePlan (estate=0x2b619018, planstate=0x2b6192a8, > operation=CMD_SELECT, numberTuples=0, direction=ForwardScanDirection, > dest=0x28bc4420) at execMain.c:1504 > #14191 0x081b3d53 in standard_ExecutorRun (queryDesc=0x2b789e40, > direction=ForwardScanDirection, count=0) at execMain.c:309 > #14192 0x081b3c66 in ExecutorRun (queryDesc=0x2b789e40, > direction=ForwardScanDirection, count=0) at execMain.c:258 > #14193 0x082958a7 in PortalRunSelect (portal=0x2ab68018, forward=1 '\001', > count=0, dest=0x28bc4420) at pquery.c:953 > #14194 0x082955c0 in PortalRun (portal=0x2ab68018, count=2147483647, > isTopLevel=1 '\001', dest=0x28bc4420, altdest=0x28bc4420, > completionTag=0xbfbfe7d4 "") at pquery.c:779 > #14195 0x0829155f in exec_execute_message (portal_name=0x28bc4018 "", > max_rows=2147483647) at postgres.c:1928 > #14196 0x08293e23 in PostgresMain (argc=4, argv=0x28b3b890, > username=0x28b3b7c0 "tad") at postgres.c:3671 > #14197 0x0825e2d0 in BackendRun (port=0x28b2f600) at postmaster.c:3447 > #14198 0x0825d7b3 in BackendStartup (port=0x28b2f600) at postmaster.c:3061 > #14199 0x0825ad4a in ServerLoop () at postmaster.c:1387 > #14200 0x0825a466 in PostmasterMain (argc=3, argv=0xbfbfec2c) at > postmaster.c:1040 > #14201 0x081ea4e5 in main (argc=3, argv=0xbfbfec2c) at main.c:188 Recursion within PL/PgSQL? -- Craig Ringer -- 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 #5235: Segmentation fault under high load through JDBC
> Recursion within PL/PgSQL? er ... sorry for stating the belated and obvious. I was dropped from the CC on the other branch of this thread so it wasn't hitting my INBOX and didn't realise it'd carried on until I saw it in my Pg list folder. -- Craig Ringer -- 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 #5238: frequent signal 11 segfaults
On 10/12/2009 5:12 AM, Daniel Nagy wrote: The following bug has been logged online: Bug reference: 5238 Logged by: Daniel Nagy Email address: nagy.dan...@telekom.hu PostgreSQL version: 8.4.1 Operating system: Debian Lenny 5.0.3 x86_64. Kernel: 2.6.31.6-grsec Description:frequent signal 11 segfaults Details: I got postgres segfaults several times a day. http://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Linux/BSD -- Craig Ringer -- 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] statement_timeout is not cancelling query
On 15/12/2009 12:35 PM, Mark Williamson wrote: So what happened is, the above update never completed and the Postgresql service consumed all available memory. We had to forcefully reboot the machine That means your server is misconfigured. PostgreSQL should never consume all available memory. If it does, you have work_mem and/or maintenance_work_mem set way too high, and you have VM overcommit enabled in the kernel. You also have too much swap. http://www.postgresql.org/docs/current/interactive/kernel-resources.html http://www.network-theory.co.uk/docs/postgresql/vol3/LinuxMemoryOvercommit.html I wouldn't be surprised if you had shared_buffers set too high as well, and you have no ulimit set on postgresql's memory usage. All those things add up to "fatal". A properly configured machine should be able to survive memory exhaustion caused by a user process fine. Disable VM overcommit, set a ulimit on postgresql so it can't consume all memory, use a sane amount of swap, and set sane values for work_mem and maintenance_work_mem. Why does Postgresql NOT have a maximum memory allowed setting? We want to allocate resources efficiently and cannot allow one customer to impact others. It does. "man ulimit". The operating system can enforce it much better than PostgreSQL can. If a Pg bug was to cause Pg to go runaway or try to allocate insane amounts of RAM, the ulimit would catch it. I *do* think it'd be nice to have ulimit values settable via postgresql.conf so that you didn't have to faff about editing init scripts, though. ( TODO item? ) -- Craig Ringer -- 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] Optimal platform for pg?
On 16/12/2009 10:31 AM, Mark Williamson wrote: What is the most ideal/optimal platform for postgresql? Linux (distro?), freebsd, windows, etc. Pg has been around on UNIX-like platforms for longer than Windows, and is better tested on those platforms. Its design is also more friendly toward UNIX-like systems, being based on a connection-per-process rather than connection-per-thread model - though that matters less with the NT kernel used in all modern Windows flavours. Of the UNIX-like systems, the vast majority of people on the list seem to use a Linux flavour or FreeBSD. I mostly see Red Hat Enterprise, FreeBSD, Ubuntu, Debian, and CentOS users when OS is mentioned. I'd stick to whatever Linux/BSD you're most familiar with, personally. Rather than worry about OS, though, your real issues are with hardware selection. Getting a good quality RAID controller with battery backup, plus plenty of disks in RAID 10 and plenty of RAM will make more difference than about anything else. -- Craig Ringer -- 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] pgstat wait timeout (by Robert Schnabel)
On 16/12/2009 11:55 PM, Robert Haas wrote: On Wed, Dec 16, 2009 at 10:45 AM, Magnus Hagander wrote: On Wed, Dec 16, 2009 at 16:12, Tom Lane wrote: Alvaro Herrera writes: Alexey Luchko wrote: postgres.exe!mdpostckpt+0x181b38 postgres.exe!mdpostckpt+0x18bbdb This stack trace seems bogus. The stats collector should not be calling mdpostckpt at all. Given the size of the offsets, it's pretty clear that it's not actually in mdpostckpt at all. Probably this is a stripped executable and mdpostckpt is just the nearest global symbol. If that is so, the OP should follow: http://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Windows specifically the part about symbols. Which it certainly looks like :) We should really take some of the vast quantity of really useful information that is in the wiki and try to index it somehow or incorporate it into the docs. I'm always learning about new pages that have good stuff on them, but I never seem to stumble across them organically. MediaWiki offers features to make this a lot easier. The categories feature in particular is great: go to the page: Category:Blah and you'll see a listing of all pages containing a link to [[Category:Blah]]. The existing list of all categories can be found via the "special pages" link in the sidebar: http://wiki.postgresql.org/wiki/Special:Categories A "favourite" or "highlight" category would be one way to do what you're talking about. -- Craig Ringer -- 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 #5248: Cannot find SSLEAY32.dll problem.
On 17/12/2009 6:10 PM, Vincent Pinto wrote: The following bug has been logged online: Bug reference: 5248 Logged by: Vincent Pinto Email address: vincent_pi...@mentor.com PostgreSQL version: 8.3.1.876 Operating system: Windows XP SP3 Description:Cannot find SSLEAY32.dll problem. Details: We have an application that installs postgres. How? Using the OneClick installer's silent/scripted install? From the zip files? If the latter, how and where? But during the install, while it tries to start the database, and error "This application failed to start because SSLEAY32.dll was not found. Re-installing the application may fix this problem." pops up. SSLEAY32.DLL should be part of the PostgreSQL install and in the same directory as the PostgreSQL binaries. Is it not? I tried reinstalling but that does not help. I also noticed on my earlier laptop that ssleay32.dll is not in the windows/system32 dir (many folks on various forums suggest to do so, but I did not do it because the db starts on the earlier machine, so why should it not start on the newer on?) No, do *not* mess with WINDOWS\SYSTEM32 . People who tell you to install random libraries there are almost certainly wrong, and are parroting advice that used to apply back in the Windows 95/98 days before Windows preferentially loaded libraries from the same directory as the application. -- Craig Ringer -- 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 #5248: Cannot find SSLEAY32.dll problem.
On 18/12/2009 11:34 AM, Pinto, Vincent wrote: Our application installation starts by the user double-clicking install.exe (It is simply a 320MB install.exe, which contains all the stuff; the db, the application files, the help files, etc). Yes, but is the copy of PostgreSQL included as an embedded copy of the one-click installer run via silent install, or is it just the PostgreSQL program (etc) files that get installed directly by your own installer? Look inside your installer package. Do you see a postgresql installer exe? Or do you see "postgres.exe", "psql.exe", etc? If the latter, where did they come from? I'm beginning to wonder if somebody installed PostgreSQL from the one-click installer, then just took a copy of C:\Program Files\PostgreSQL and bundled it up in the installer. It then installs various application files, and somewhere in this flow, I suspect a scripted install happens of the postgres db. You *suspect*? Have a look at the sources for your installer, and find out. If you can't, you need to get in touch with somebody who actually has control over your installer package and get their help tracking down this issue - you cannot usefully do it yourself if you do not know exactly how your installer works. Yes it is. That is what is very confusing. Are you _sure_ it's there at the time you first try to run PostgreSQL, though? Is it possible ssleay32.dll is copied in there _after_ the attempt to start PostgreSQL is made? -- Craig Ringer -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
