Re: [BUGS] pg_stat_statements produces multiple entries for a single query with track = 'top'
On Sat, Aug 10, 2013 at 5:45 PM, Tom Lane wrote: > Isn't this just the behavior we decided we wanted for SQL-language > functions? At least, if we change pg_stat_statements so it doesn't > break out SQL-language functions, I'm sure somebody's gonna complain. Perhaps there was some discussion of this with Takahiro Itagaki, but I have no recollection of having been involved in or having followed a discussion about pg_stat_statements behavior with regards to SQL-language functions in particular. Actually, if Itagaki-san had discussed this, there is a reasonably good chance that I'd have read it before now. I can tell you that at the very least, this behavior does not seem consistent with the documentation: "pg_stat_statements.track controls which statements are counted by the module. Specify top to track top-level statements (those issued directly by clients), all to also track nested statements (such as statements invoked within functions), or none to disable statement statistics collection. The default value is top. Only superusers can change this setting." Clearly the statement "SELECT '6378168'::float8" was not directly issued by the client here. If this is the behavior we want for SQL functions, that is something that ought to be highlighted as a special case. -- Peter Geoghegan -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] pg_stat_statements produces multiple entries for a single query with track = 'top'
006ffca9 in BackendStartup (port=0x239e2b0) at postmaster.c:3304 #68 0x006fcacb in ServerLoop () at postmaster.c:1367 #69 0x006fc3c2 in PostmasterMain (argc=2, argv=0x23792a0) at postmaster.c:1127 #70 0x006676ba in main (argc=2, argv=0x23792a0) at main.c:199 These pg_stat_statements entries are appear to be wrong, because all of the associated executor instrumentation costs (like total_time) aren't accumulating in the "top-level" entry. Also, while I realize that this is rather hazy, it is arguably the case that the subquery_planner preprocessing work shown here shouldn't be instrumented by pg_stat_statements, at least for as long as pg_stat_statements is supposed to instrument executor costs only. -- Peter Geoghegan -- 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 #8161: Several instances of Postgres service
On Tue, May 14, 2013 at 2:47 PM, John R Pierce wrote: > on a typical unix system, with one user connection active, I see 8 processes > active at present... To be fair, you need to use process explorer or something to see equivalent information on Windows. Most people never will. -- Peter Geoghegan -- 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 #8013: Memory leak
On 30 March 2013 14:01, wrote: > env CFLAGS='-O3 -march=native' ./configure --with-segsize=128 Why did you build with a segment size of 128GB? Postgres binaries built with a non-standard segment size are not widely used. -- Regards, Peter Geoghegan -- 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] Questions about PostgreSQL Setup License
On 14 March 2013 16:42, DUBILLOT Aurelien wrote: > Are we also allowed to do that ? Why are you posting this to the -bugs mailing list? The answer is yes, though IANAL, and that does not constitute legal advice. However, there are a number of fairly prominent full commercial forks, so I think you're safe. -- Regards, Peter Geoghegan -- 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 #7903: EAN13s are shown ISBN values
On 26 February 2013 21:45, Peter Eisentraut wrote: > Have each user create their custom domain? That's likely to be the most effective solution, yes. I'd take the fact that people haven't been complaining about contrib/isn more as suggestive of people figuring this out for themselves than suggestive of contrib/isn being of acceptable quality. > Is there a stable subset that we could maintain with minimal effort? Well, at the very least I'd rip out the over-zealous sanitisation (everything but the check digit). I guess that enforcing the GS1 country codes within EAN-*s isn't completely crazy, if only because new countries don't come along that often, and when they do that doesn't tend to have anything to do with the dissolution of a GS1 member state. Note that ISBN13 is just an EAN-13 from the fictional country of bookland (that's a GS1 code). So for that reason, there arguably doesn't need to be and shouldn't be a separate ISBN type. I guess having a separate ISBN type was motivated solely by that enabling the ill-advised additional sanitisation of ISBNs, though there is no reason why you can't do something special with the bookland GS1 code instead (nothing other than the fact that, as I've said, sanitising what the module calls "ISBN_range" is generally quite a bad idea). > Would it be better if the module were removed from PostgreSQL core but > maintained externally where it can iterate faster and keep the database > up to date? I don't think so. To my mind, the whole idea of sanitising ISBN_range stinks. GS1 country code sanitisation works out a lot better in practice, but feels just as wrong to me. Check digit enforcement is fine, even if that approach is a little bit limiting compared to a custom domain. Enforcing that a check digit must be correct gives you 99% of the value that you're likely to get here, because it protects against transposition errors, which are by far the most likely type of error made by data entry clerks. > Is there a third-party library that does maintain such a database so > that this module could be based upon that instead of having to maintain > the database itself? No, there is not. The textual representation of the types - the dashes - are fairly odd, but it's too late to fix that. -- Regards, Peter Geoghegan -- 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 #7903: EAN13s are shown ISBN values
On 23 February 2013 14:09, wrote: > My problem now is that I it's always displayed with the dashes in between, > even when I want to show the EAN13. As far as I know EANs are never shown > with the dashes. Right, they're not. But then, contrib/isn also sanitises both ISBN ranges and EAN country codes using its own internal database, which ought to be kept in lockstep with an external database whose maintenance is highly decentralised - regional authorities make certain decisions that can create a need to update the database. I'm pretty sure that that database doesn't actually exist, at least all in one place, in the case of ISBN. So contrib/isn is fundamentally wrong-headed, and I would be quite happy to see its removal from contrib. In my experience of supply chain type applications, there is generally a need to support fairly complex custom rules for sanitising EANs, which generally makes a custom bigint domain a compelling choice. For example, sometimes (typically in situations where products are sold by weight), a price will be baked into the barcode that is affixed to the product after it is weighed on a digital scales. The last 5 digits of a barcode before the check digit is often a price (a number of cents, usually) that a scales assigns based on a known price per kilogram, plus the item's weight. This may present you with a need to store the "normalised, base barcode" (basically, just the pseudo "custom" country code and SKU) without any price, and without a check digit (the check digit is of course a function of the dynamically assigned price). There are examples for Postgres on the internet that you can generalise from for this sort of thing. These show how to enforce that a check digit is correct using SQL, using this simple method: https://en.wikipedia.org/wiki/EAN-13#Calculation_of_checksum_digit We actually discussed changing the formatting of isn along the lines you've discussed, and it was shot down. I'd just like to see it go. -- Regards, Peter Geoghegan -- 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] Arbitrary whitespace restrictions on range types
On 18 December 2012 23:31, Josh Berkus wrote: > Jeff, Hackers: > > Is there a strong reason why this has to error? Having taken a look at the range I/O routines, I surmise that it was just easier to write range_parse() such that whitespace is included within tokens: * Whitespace before or after is ignored. Whitespace within a * is taken literally and becomes part of the input string for that bound. I think that escaping the underlying literal values for parsing is a surprisingly difficult task, so I can see why the implementation would shrug in this case. This behaviour may be astonishing, but that doesn't make it a POLA violation. I don't have time to check now, but I'm pretty sure that doing something else would break a whole bunch of other common cases. -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services -- 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 #7670: BUG #7545: Unresponsive server with error log reporting: "poll() failed: Invalid argument"
On 18 November 2012 18:42, Marc Balmer wrote: > Have you cross-checked this on a 64bit platform vs. a 32 bit platform? > e.g. on Linux i386 vs. Linux amd64? Well, strictly speaking sizeof(int) is dictated by both the compiler and CPU architecture in question. I believe that all current Unix-like systems follow LLP64 (or LLP32) in practice. sizeof(int) is 4 on Windows (though, in contrast to LLP64, sizeof(long) is 4 too on 64-bit windows). -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services -- 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 #7670: BUG #7545: Unresponsive server with error log reporting: "poll() failed: Invalid argument"
On 18 November 2012 18:18, Tom Lane wrote: > Well, we have two reports of people trying such values (assuming that > #7545 actually is the same thing), and it didn't work for either of > them. I don't think it's a problem to restrict the value to something > that will work rather than fail. Right. sizeof(int) is very probably 4 on all platforms that we support. I see no problem with the proposal. -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services -- 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 #7670: BUG #7545: Unresponsive server with error log reporting: "poll() failed: Invalid argument"
On 18 November 2012 17:12, Andres Freund wrote: > Ok, this is already helpful. Do you have anything the log that shows > what process pid 95528 is? Could you grep for it? I haven't looked at this in detail, but are you sure that this isn't the bug that was fixed by commit e81e8f9342b037246b284bad15e42e21b1929301 ? The "invalid argument" poll() error is too generic to be sure what is really at fault, but this doesn't need to be a FATAL error, it seems. Is this a 32-bit platform? It's probably just that there is a large number of sockets, which Google seems to think can cause this error with poll(), so this seems like a slight variant of the problem reported by Sean Chittenden (kernel resource exhaustion causes pipe creation to fail, with unnecessarily bad consequences for Postgres). -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services -- 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 #7648: Momentary index corruption while in hot standby
On 10 November 2012 00:29, Daniel Farina wrote: > Me too. Database clients finding these unambiguously platform-level > problems and being relied upon to report them to receive treatment is > a long-standing embarrassment to me. However, I've been way too > swamped to even start thinking of how one would disentangle error > reporting suitable for physical issues from logical issues. I complained about this a few months ago (and a few months before that), and the upshot was that we kicked around a few ideas and were able to outline a useful API [1]. The idea here was to derive what I called magnitude from SQLSTATE. In other words, we'd represent how routine or non-routine a particular error message was (the "wake me up in the middle of the night" factor). Severity levels don't and cannot capture this, since for example a FATAL error occurs in the event of failed authentication, whereas ERRORs (technically a lesser severity) may occur in far more serious situations that a Postgres DBA can reasonably hope to never see, with problems that indicate data corruption, for example. [1] http://archives.postgresql.org/message-id/caeylb_xdtyje6wtuy4tgdjuq6eutjjp0ctfladp9qwp8got...@mail.gmail.com -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services -- 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] Segmentation Fault V 9.1.5
On 30 August 2012 22:42, Jeff Lake wrote: > Lack even basic manners?? > I have been at installing this for 3 days > manners/patience is gone!! That's not my problem. Projecting your frustration on this mailing list isn't cool, and, along with your poor description of the problem, is a sure way to get your bug report ignored. > lets see MySql works , Oracle works... > install PostgreSQL > nope it don't work, either using Command line, php, for the hell of I tried > perl > nope all fail, all segmentation fault so what would that say to you??? > PostgreSQL is the failing point !! No, as I've already pointed out, the failing point is php/pgsql.so's questionable assumption, an assumption that was made elsewhere within php, since this same issue is known to affect MySQL installations. Just because your MySQL installation isn't affected doesn't mean all other MySQL installations are not. For example, it might just be that your MySQL client library wasn't built with OpenSSL support. > 9.1.5 > 8.1.23 > 8.4 > > all give the same EXACT Error ... > > oh yes .. libpq.so.5 is in the ldd for pgsql.so That doesn't mean anything on its own. What is the path to libpq.so.*? Can't you paste the output? Does pg_config output confirm that the server version associated with this libpq shared object is in fact the version that you believe it to be? If all of that is consistent with having a libpq version that actually has commit 4e816286533dd34c10b368487d4079595a3e1418, can you produce a GDB back trace of the php process, by doing the same thing as the complainant that posted to the php bug tracker? The process is documented here: https://bugs.php.net/bugs-generating-backtrace.php -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services -- 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] Segmentation Fault V 9.1.5
On 30 August 2012 20:29, Jeff Lake wrote: > I have looked at darn near every listing for this bug .. > "..because curl is loaded before postgresql" << nope didn't work > here is my system specs This must be the worst bug report I've ever seen. I'd give the usual link to "How to Report Bugs Effectively", but it would probably be lost on someone who seems to lack even basic manners. > so whats the fix ??? > or do I need to just delete, forget and reuse MySQL ??? Well, from a little googling I gather that MySQL is also affected by this PHP bug (I am not 100% sure that this is what you're referring to): http://www.logikdev.com/tag/postgresql/ What you don't seem to realise is that this is a mailing list for bugs in the PostgreSQL server. "pgsql" in this context refers to a third-party client library for php, and there's no reason to believe that any of its maintainers are active on this mailing list. That said, why are you trying to use the "ordering" kludge recommended here? https://bugs.php.net/bug.php?id=40926&edit=3 It sounds extremely fragile. Since we apparently now defensively unregister the callbacks associated with this problem, as of this commit from back in 2008: http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=4e816286533dd34c10b368487d4079595a3e1418 It seems likely that pgsql.so is still linking to some ancient, unsupported libpq, even though you don't think that it is. Are you sure that you're using the libpq distributed with 9.1.5? I don't know much about php, but for Python, you'd do something like: [peter@peterlaptop psycopg2]$ ldd _psycopg.so linux-vdso.so.1 => (0x7fffbd5ff000) libpython2.7.so.1.0 => /lib64/libpython2.7.so.1.0 (0x7f8753aa4000) libpq.so.5 => /home/peter/pgsql/lib/libpq.so.5 (0x7f875387c000) libpthread.so.0 => /lib64/libpthread.so.0 (0x7f875366) libc.so.6 => /lib64/libc.so.6 (0x7f87532a9000) libdl.so.2 => /lib64/libdl.so.2 (0x7f87530a4000) libutil.so.1 => /lib64/libutil.so.1 (0x7f8752ea1000) libm.so.6 => /lib64/libm.so.6 (0x7f8752ba6000) /lib64/ld-linux-x86-64.so.2 (0x003cdc40) Is the libpq shared object you see here (but for pgsql.so) the one that you expect? -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services -- 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 #6672: Memory leaks in dumputils.c
On 1 June 2012 06:06, Tom Lane wrote: > There were no html reports attached, and I'd prefer plain text > anyway please ... I saw a number of false positives when I ran the Clang static analyser a few months ago. As I recall, I could see why the tool concluded that certain lines of code may have contained errors, even though it was evident to me that they actually did not. That said, it probably wouldn't hurt to give it another try sometime soon. -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services -- 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] wCTE cannot be used to update parent inheritance table
On 29 January 2012 23:47, Josh Berkus wrote: > This is *so* not a discussion to have on the pgsql-bugs list. Please > take it to -hackers. I suppose you're right, since the first discussion occurred there and didn't really go anywhere. -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Silly typo in proc.h
In proc.h, it says: "Prior to PostgreSQL 9.2, the fieds below " This is obviously a typo, and should read "the fields below". I recently started to take the precaution of running an American English spell checker over my code before submitting patches - the vim one works rather well here, though I'm sure that equivalent tools are available for emacs and other popular editors. I use American English spelling for code, and British English for everything else, but it can be hard to avoid switching back. It's difficult to know where I should be drawing the line with this stuff. Should I continue to report trivialities like these as bugs? I would think that in the case of documentation the answer is "yes", but I can't help but feel slightly silly about reporting cases like this. -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services -- 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] wCTE cannot be used to update parent inheritance table
On 29 January 2012 21:19, Peter Geoghegan wrote: > Is it really that much of a problem to create a new severity level for > this stuff? I should probably have quoted this refinement, which was part of the discussion that I originally quoted Robert from: On 24 November 2011 16:55, Alvaro Herrera wrote: > > Excerpts from Robert Haas's message of jue nov 24 13:14:38 -0300 2011: > >> What I think we want to distinguish between is things that are >> PEBKAC/GIGO, and everything else. In other words, if a particular >> error message can be caused by typing something stupid, unexpected, >> erroneous, or whatever into psql, it's just an error. But if no >> input, however misguided, should ever cause that symptom, then it's, I >> don't know what the terminology should be, say, a "severe error". > > +1 I'm strongly in favour of this. -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services -- 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] wCTE cannot be used to update parent inheritance table
On 29 January 2012 20:52, Tom Lane wrote: > Seems like a lot of make-work. The fact that it's got an XX000 SQLSTATE > is already sufficient confirmation that the problem is an internal one, > if the DBA isn't sure about that already. I'm not worried about the DBA not being able to figure that out - it seems like they'd stand a pretty good chance of figuring it out quickly once they were aware of the problem. Rather, I share Robert's concern: On 23 November 2011 02:49, Robert Haas wrote: > There is no sort of systematic labeling of error messages in the log > to enable the DBA to figure out that the first error message is likely > nothing more serious than an integrity constraint doing its bit to > preserve data integrity, while the second is likely a sign of > impending disaster. Is it really that much of a problem to create a new severity level for this stuff? -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services -- 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] wCTE cannot be used to update parent inheritance table
On 29 January 2012 20:39, Josh Berkus wrote: > >> This is the kind of thing that could go unnoticed for a long time, >> simply because it is not highlighted any more prominently than a >> routine error message like an integrity constraint violation. I >> continue to maintain that we should have a new severity level for this >> sort of thing. > > Huh? I don't follow you at all Peter. I mean that we should change code like this: elog(ERROR, "could not find plan for CTE \"%s\"", rte->ctename) to this: elog(INTERNAL_ERROR, "could not find plan for CTE \"%s\"", rte->ctename) (which would necessitate creating a new severity level, INTERNAL_ERROR). So that DBAs could find these kinds of problems systematically. This is an error message that we expect no one to see. -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services -- 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] wCTE cannot be used to update parent inheritance table
On 29 January 2012 20:06, Josh Berkus wrote: > On 1/28/12 5:27 PM, Tom Lane wrote: >> Josh Berkus writes: >>> SUMMARY: if you attempt to UPDATE or DELETE FROM a parent table in an >>> inheritance relationship using a wCTE, you get the following error message: >>> ERROR: could not find plan for CTE >> >> Fixed, thanks for the report. > > Should we add a regression test for this? This is the kind of thing that could go unnoticed for a long time, simply because it is not highlighted any more prominently than a routine error message like an integrity constraint violation. I continue to maintain that we should have a new severity level for this sort of thing. -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services -- 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 #6200: standby bad memory allocations on SELECT
On 28 January 2012 21:34, Michael Brauwerman wrote: > We have the (5GB) core file, and are happy to do any more forensics anyone > can advise. Ideally, you'd be able to install debug information packages, which should give a more detailed and useful stack trace, as described here: http://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Linux/BSD -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Doc-bug; minor typo in auto_explain documentation
I noticed the following in the auto_explain documentation: "This can have extremely negative impact on performance." Surely it should say: "This can have an extremely negative impact on performance." -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services -- 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] Documentation bug: reference to checkpoint activity in bgwriter
On 20 January 2012 02:53, Robert Haas wrote: > OK, done. Thanks -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services -- 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] Incorrect comment in heapam.c
On 17 January 2012 01:37, Robert Haas wrote: >> It's a fairly inconsequential bug, but it is worth fixing... > > Fixed. Thanks. -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services -- 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] Documentation bug: reference to checkpoint activity in bgwriter
On 9 January 2012 18:47, Robert Haas wrote: > On Sat, Dec 31, 2011 at 8:54 PM, Peter Geoghegan > wrote: >> ISTM that the following reference, at config.sgml line 1345, ought to >> be adjusted due to the introduction of the new checkpointer process: >> >> Setting this to zero disables >> background writing (except for checkpoint activity). > > Hmm, so what should we adjust it *to*? How about "Setting this to zero disables background writing. Note that checkpoints, which are managed by a separate, dedicated auxiliary process, are unaffected." If this was the first release of Postgres, I'd suggest that we remove any references to checkpoints, which are sort of orthogonal to the stated main function of the bgwriter in past releases, which is to clean dirty buffers so that backends don't have to. However, people may still expect the bgwriter to manage checkpointing, particularly if they're working off old sources of information, so it's useful to set them straight. -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Documentation bug: reference to checkpoint activity in bgwriter
ISTM that the following reference, at config.sgml line 1345, ought to be adjusted due to the introduction of the new checkpointer process: Setting this to zero disables background writing (except for checkpoint activity). -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services -- 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] Incorrect comment in heapam.c
On 20 December 2011 18:11, Tom Lane wrote: > Simon Riggs writes: >> On Tue, Dec 20, 2011 at 5:50 PM, Peter Geoghegan >> wrote: >>> In fact, that macro is defined in access/htup.h...should it be? > >> IMHO comment is wrong, code is in the right place. > > It used to be in heapam.h ... evidently, whoever moved it missed this > comment. I imagined that that was the case. It's a fairly inconsequential bug, but it is worth fixing... -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Incorrect comment in heapam.c
Line 834 of heapam.c has the following comment: /* * This is formatted so oddly so that the correspondence to the macro * definition in access/heapam.h is maintained. */ In fact, that macro is defined in access/htup.h...should it be? -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services -- 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] About Wince App
On 11 December 2011 17:53, Cihan ŞENGÜL wrote: > Hi > Libpqwce are published. Gösterilemiyor.Bana reference to VB NET 2003. NET > 2003, I can reference the DLL required for VB I don't understand. -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services -- 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] About Wince App
On 10 December 2011 15:13, Hiroshi Saito wrote: > First, official support does not have Postgrs about WinCE. > > Next, I had tried libpq by WinCE (mobile) in the past. > But, My telephone is Android now...therefore, I forgotten > about WinCE.,sorry... Yes, I used Hiroshi's WinCE libpq port very successfully. I built it from source too, as there were binary compatibility problems with some of the ARM devices that had custom WinCE kernels (not uncommon - WinCE is available under a "shared source" agreement), but not others that didn't. What's the problem? :-) -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services -- 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 #6300: duplicate key value violates unique constraint
On 24 November 2011 16:55, Alvaro Herrera wrote: > > Excerpts from Robert Haas's message of jue nov 24 13:14:38 -0300 2011: > >> What I think we want to distinguish between is things that are >> PEBKAC/GIGO, and everything else. In other words, if a particular >> error message can be caused by typing something stupid, unexpected, >> erroneous, or whatever into psql, it's just an error. But if no >> input, however misguided, should ever cause that symptom, then it's, I >> don't know what the terminology should be, say, a "severe error". > > +1 +1 On reflection, that's better than what I proposed. -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services -- 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 #6300: duplicate key value violates unique constraint
On 23 November 2011 02:49, Robert Haas wrote:
> There is no sort of systematic labeling of error messages in the log
> to enable the DBA to figure out that the first error message is likely
> nothing more serious than an integrity constraint doing its bit to
> preserve data integrity, while the second is likely a sign of
> impending disaster.
+1
I suggested that there be an INTERNAL_ERROR severity level before on
this list, in response to an opaque internal error that was raised in
the planner due to a bug in master (it was a simple elog() call that
raised the error), and the idea was not well received. Tom said that
"Well, the SQLSTATE for this sort of thing is already
ERRCODE_INTERNAL_ERROR". A quick search of that shows that it only
appears in the following places:
src/pl/plpgsql/src/plerrcodes.h
876:"internal_error", ERRCODE_INTERNAL_ERROR
src/backend/access/gist/gistsplit.c
374:(errcode(ERRCODE_INTERNAL_ERROR),
src/backend/access/nbtree/nbtinsert.c
455:(errcode(ERRCODE_INTERNAL_ERROR),
src/backend/utils/misc/guc.c
6369: (errcode(ERRCODE_INTERNAL_ERROR),
src/backend/utils/adt/xml.c
259:xml_ereport_by_code(WARNING, ERRCODE_INTERNAL_ERROR,
3787: xml_ereport(xmlerrcxt, ERROR, ERRCODE_INTERNAL_ERROR,
3816: xml_ereport(xmlerrcxt, ERROR, ERRCODE_INTERNAL_ERROR,
3828: xml_ereport(xmlerrcxt, ERROR, ERRCODE_INTERNAL_ERROR,
src/backend/utils/adt/ri_triggers.c
3501: (errcode(ERRCODE_INTERNAL_ERROR),
src/backend/utils/mb/conversion_procs/utf8_and_win/utf8_and_win.c
125:(errcode(ERRCODE_INTERNAL_ERROR),
152:(errcode(ERRCODE_INTERNAL_ERROR),
src/backend/utils/mb/conversion_procs/utf8_and_iso8859/utf8_and_iso8859.c
135:(errcode(ERRCODE_INTERNAL_ERROR),
162:(errcode(ERRCODE_INTERNAL_ERROR),
src/backend/utils/error/elog.c
353:edata->sqlerrcode = ERRCODE_INTERNAL_ERROR;
612:edata->sqlerrcode = ERRCODE_INTERNAL_ERROR;
648:edata->sqlerrcode = ERRCODE_INTERNAL_ERROR;
src/backend/utils/errcodes.h
322:#define ERRCODE_INTERNAL_ERROR MAKE_SQLSTATE('X','X','0','0','0')
src/backend/postmaster/pgstat.c
493:(errcode(ERRCODE_INTERNAL_ERROR),
src/include/utils/elog.h
93: * ERRCODE_INTERNAL_ERROR if elevel is ERROR or more, ERRCODE_WARNING
contrib/sepgsql/uavc.c
184:(errcode(ERRCODE_INTERNAL_ERROR),
521:(errcode(ERRCODE_INTERNAL_ERROR),
contrib/sepgsql/hooks.c
94: (errcode(ERRCODE_INTERNAL_ERROR),
426:(errcode(ERRCODE_INTERNAL_ERROR),
contrib/sepgsql/selinux.c
768:(errcode(ERRCODE_INTERNAL_ERROR),
854:(errcode(ERRCODE_INTERNAL_ERROR),
contrib/sepgsql/label.c
84: (errcode(ERRCODE_INTERNAL_ERROR),
194:(errcode(ERRCODE_INTERNAL_ERROR),
234:(errcode(ERRCODE_INTERNAL_ERROR),
464:(errcode(ERRCODE_INTERNAL_ERROR),
526:(errcode(ERRCODE_INTERNAL_ERROR),
A new severity level is called for. In addition, if we had a new
severity level, the footprint wouldn't be too bad on all those legacy
elog() calls as compared to using errcode(ERRCODE_INTERNAL_ERROR).
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Typo in nbtsort.c
I noticed this typo in a comment in the file nbtsort.c: /* * We need to log index creation in WAL iff WAL archiving/streaming is * enabled UNLESS the index isn't WAL-logged anyway. */ I suggest an s/iff/if/ -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services -- 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] "no relation entry for relid 1"
On 29 September 2011 23:15, Tom Lane wrote: > Peter Geoghegan writes: >> I've built Postgres from master, and found that the following fairly >> simple query breaks: > >> select count(*) >> from >> ( >> select >> schemaname >> from pg_stat_user_tables >> order by 1 >> ) sub >> group by schemaname > >> This produces the internal error message "no relation entry for relid >> 1". Why is that? > > Looks like I broke it here: > > http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=1cb108efb0e60d87e4adec38e7636b6e8efbeb57 Hmm. Although it was obvious to me that this was an internal error, I have to wonder what a novice would have made of it. Specifically, I wonder if there should be an INTERNAL_ERROR severity level, to explicitly advertise that you're not supposed to see this, and to help log analysis tools (including grep) bring these sorts of things to the DBA's attention, as they are surely much more severe than most errors seen in practice. -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services -- 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] "no relation entry for relid 1"
On 29 September 2011 21:59, Merlin Moncure wrote: > hm -- works for me (9.1.0) It works for me on REL9_1_STABLE too, unsurprisingly, as I would think it highly unlikely that such a glaring bug would slip into a stable release. -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] "no relation entry for relid 1"
I've built Postgres from master, and found that the following fairly simple query breaks: select count(*) from ( select schemaname frompg_stat_user_tables order by1 ) sub group by schemaname This produces the internal error message "no relation entry for relid 1". Why is that? -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
