Re: [HACKERS] Alignment padding bytes in arrays vs the planner
On Tue, Apr 26, 2011 at 11:51:35PM -0400, Noah Misch wrote: > On Tue, Apr 26, 2011 at 07:23:12PM -0400, Tom Lane wrote: > [input functions aren't the only problematic source of uninitialized datum > bytes] > > > We've run into other manifestations of this issue before. Awhile ago > > I made a push to ensure that datatype input functions didn't leave any > > ill-defined padding bytes in their results, as a result of similar > > misbehavior for simple constants. But this example shows that we'd > > really have to enforce the rule of "no ill-defined bytes" for just about > > every user-callable function's results, which is a pretty ugly prospect. > > FWIW, when I was running the test suite under valgrind, these were the > functions > that left uninitialized bytes in datums: array_recv, array_set, > array_set_slice, > array_map, construct_md_array, path_recv. If the test suite covers this well, > we're not far off. (Actually, I only had the check in PageAddItem ... > probably > needed to be in one or two other places to catch as much as possible.) Adding a memory definedness check to printtup() turned up one more culprit: tsquery_and. *** a/src/backend/utils/adt/tsquery_util.c --- b/src/backend/utils/adt/tsquery_util.c *** *** 336,342 QTN2QT(QTNode *in) cntsize(in, &sumlen, &nnode); len = COMPUTESIZE(nnode, sumlen); ! out = (TSQuery) palloc(len); SET_VARSIZE(out, len); out->size = nnode; --- 336,342 cntsize(in, &sumlen, &nnode); len = COMPUTESIZE(nnode, sumlen); ! out = (TSQuery) palloc0(len); SET_VARSIZE(out, len); out->size = nnode; -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Fw: Help required regarding patch development
--- On Mon, 5/23/11, nil nil wrote: Sir i have read all that material from that link it gives me overall detail but i am still not clear how to develop it. what softwares i need to use, how to integrate with postgresql, i want to know the basic steps for patch development. if you have any casestudy or video tutorial kindly provide me. Regards Emman
Re: [HACKERS] Logfile
sorry, actually becuase of one printf statement(i have added) because of that, these has been occured. My mistake On Mon, May 23, 2011 at 9:06 AM, Robert Haas wrote: > On Sun, May 22, 2011 at 6:42 AM, Nick Raj wrote: > > I am using contrib/cube code. I am building GIST index on cube data type > > then it leads to a very large size of log file (nearly 220 MB for only > 12k > > records). > > While creating index on geometry field with gist gives 1KB size of log > file > > for 17 lakh records. > > > > Can someone please tell me how to stop postgres to logged so much data in > > case of cube? > > Well, I don't have a clue why it would be writing that many log > messages. Maybe you should look in the log file and see what those > messages are specifically... with a few more details, someone might be > able to help you out. > > Also, this question would be better directed to pgsql-general or > pgsql-admin. > > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company >
Re: [HACKERS] 9.1 support for hashing arrays
Robert Haas writes: > I believe, however, that applying this will invalidate the contents of > any hash indexes on array types that anyone has built using 9.1beta1. > Do we need to do something about that? Like bumping catversion? I would probably complain about that, except you already did it post-beta1: http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=9bb6d9795253bb521f81c626fea49a704a369ca9 Possibly Bruce will feel like adding a check to pg_upgrade for the case. I wouldn't bother myself though. It seems quite unlikely that anyone's depending on the feature yet. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Logfile
On Sun, May 22, 2011 at 6:42 AM, Nick Raj wrote: > I am using contrib/cube code. I am building GIST index on cube data type > then it leads to a very large size of log file (nearly 220 MB for only 12k > records). > While creating index on geometry field with gist gives 1KB size of log file > for 17 lakh records. > > Can someone please tell me how to stop postgres to logged so much data in > case of cube? Well, I don't have a clue why it would be writing that many log messages. Maybe you should look in the log file and see what those messages are specifically... with a few more details, someone might be able to help you out. Also, this question would be better directed to pgsql-general or pgsql-admin. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] patch: Allow \dd to show constraint comments
On Thu, May 19, 2011 at 10:36 PM, Josh Kupershmidt wrote: > Precisely, and I think there's a solid argument for putting > constraints into bucket 1 above, as this patch does, since there's no > good room to display constraint comments inside \d+, and there's no > backslash command specifically for constraints. > > I was kind of hoping to avoid dealing with this can of worms with this > simple patch, which by itself seems uncontroversial. If there's > consensus that \dd and the other backslash commands need further > reworking, I can probably devote a little more time to this. But let's > not have the perfect be the enemy of the good. Frankly, I think \dd is a horrid kludge which has about as much chance of being useful as a fireproof candle. I don't really object to the patch at hand: it'll probably solve your problem, or you wouldn't have bothered writing the patch. At the same time, I can't shake the feeling that it solves your problem mostly by accident. Clearly, you have more than no comments on constraints (or you wouldn't care) and you must also have few enough constraints on the types of objects which \dd has randomly decided to care to make it feasible to look at one big list and pick out the information you're interested in. It's hard to work up a lot of enthusiasm for that being a common situation, even though, as you say, this certainly isn't making anything any worse. I continue to think that the right fix for this problem is the one I proposed here: http://archives.postgresql.org/pgsql-hackers/2010-09/msg01080.php -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 9.1 support for hashing arrays
On Fri, May 20, 2011 at 1:43 AM, Dean Rasheed wrote: > Doh! I forgot one important piece of this algorithm - it is necessary > to initialise the result to something non-zero at the start so that > adding leading nulls to an array changes the final result. Looks reasonable. I believe, however, that applying this will invalidate the contents of any hash indexes on array types that anyone has built using 9.1beta1. Do we need to do something about that? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] timezone GUC
On Sun, May 22, 2011 at 10:24 PM, Tom Lane wrote: > Robert Haas writes: >> On Sun, May 22, 2011 at 9:54 PM, Tom Lane wrote: >>> But also, 99.999% of the time >>> it would be completely wasted effort because the DBA wouldn't remove the >>> postgresql.conf setting at all, ever. > >> Well, by that argument, we ought not to worry about masterminding what >> happens if the DBA does do such a thing -- just run the whole process >> and damn the torpedoes. If it causes a brief database stall, at least >> they'll get the correct behavior. > > Yeah, maybe. But I don't especially want to document "If you remove a > pre-existing setting of TimeZone from postgresql.conf, expect your > database to lock up hard for multiple seconds" ... and I think we > couldn't responsibly avoid mentioning it. At the moment that disclaimer > reads more like "If you remove a pre-existing setting of TimeZone from > postgresql.conf, the database will fall back to a default that might not > be what you were expecting". Is A really better than B? Well, I'm not entirely sure, but I lean toward yes. Anyone else have an opinion? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SSI predicate locking on heap -- tuple or row?
Robert Haas wrote: > I think the implementation is what matters here. I understand that > there are certain situations in which the user might choose to > UPDATE a row and other situations in which they might choose to > DELETE and then INSERT: but the user's intent is basically > irrelevant. We don't consider it irrelevant when we decide which triggers to fire. We do have update triggers distinct from the insert and delete triggers. We also consider it relevant when dealing with a write conflict in READ COMMITTED mode. Those facts make me very reluctant to move based on a simple assertion that it doesn't matter. > If the system treats those operations in basically the same way, > then it shouldn't be necessary to follow the CTID chain in one case > given that there is no CTID chain in the other case. Or to put that > another way, if it is necessary to follow the CTID chain, then we > should be able to articulate a reason for that necessity -- > something that is materially different in the UPDATE case. There is a wealth of research on which SSI is based. I've read many (although by no means *all*) of the papers on the topic, and all of the ones I've read have been based around the concept of a row which can be updated and retain its identity. I trust the research, but I think it is incumbent on us to prove, rather than just assert, that it can be applied just as well to a row-version tuple. I sure hope it can, because we can have faster, leaner, less fragile code that way. I've attempted to write out a proof; although I won't trust that without further review -- by me and by others. > Otherwise, we're just following the chain "because it's there". Why would you say it *is* there? > It seems to me that we can actually state with some degree of > precision what that "material difference" would need to be. The > goal of SSI is to prevent serialization anomalies that would not be > prevented by snapshot isolation. Let's suppose that it successfully > does that in the DELETE/INSERT case. Suppose further that we change > SSI so that it handles the UPDATE case in the same way that it > handles the DELETE/INSERT case. This change will be incorrect only > if there is a serialization anomaly that snapshot isolation *would > have prevented* in the DELETE/INSERT case that *it does not > prevent* in the update case. I don't see that -- it could be correct because of the conceptual difference between an UPDATE and a DELETE/INSERT pair. > In other words, if SSI needs to be more rigorous in the UPDATE > case, it can only be because snapshot isolation is less rigorous in > that case, and the additional rigor that SSI must apply there must > be exactly equal to whatever snapshot isolation isn't picking up > (as compared with the DELETE/INSERT case). > > Does that make any sense? It seems logical to me, but IJWH. I've always loved logic, but one of the most intriguing aspects is identifying the unproven assumptions in an argument. You have a built-in premise that there is no significant difference between an UPDATE and a DELETE/INSERT pair, in which case the logic is flawless which is leading you to the conclusion that a lock on the visible tuple is enough. I'm not confident in that premise, so the simple argument doesn't persuade me. > Your argument seems reasonable to me; Thanks much for fighting through it. It is heartening that you couldn't punch any holes in it. > but it would be nice if we could find a simpler one, because > simpler arguments are less likely to be incorrect. :-) All generalizations are false. :-) -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] timezone GUC
Robert Haas writes: > On Sun, May 22, 2011 at 9:54 PM, Tom Lane wrote: >> But also, 99.999% of the time >> it would be completely wasted effort because the DBA wouldn't remove the >> postgresql.conf setting at all, ever. > Well, by that argument, we ought not to worry about masterminding what > happens if the DBA does do such a thing -- just run the whole process > and damn the torpedoes. If it causes a brief database stall, at least > they'll get the correct behavior. Yeah, maybe. But I don't especially want to document "If you remove a pre-existing setting of TimeZone from postgresql.conf, expect your database to lock up hard for multiple seconds" ... and I think we couldn't responsibly avoid mentioning it. At the moment that disclaimer reads more like "If you remove a pre-existing setting of TimeZone from postgresql.conf, the database will fall back to a default that might not be what you were expecting". Is A really better than B? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [BUGS] BUG #6034: pg_upgrade fails when it should not.
On Sun, May 22, 2011 at 9:39 PM, Bruce Momjian wrote: > Tim Uckun wrote: >> pg_upgrade from 8.4 to 9.0 fails with the following error message. >> >> old and new cluster lc_collate values do not match >> >> >> on 8.4 show lc_collate outputs >> >> en_NZ.utf8 >> (1 row) >> >> >> on 9.0 it outputs >> >> en_NZ.UTF8 >> (1 row) >> >> >> So the difference seems to be in capitalization. Presumably they are the >> same collation with "different" names so it strikes me as odd that >> pg_upgrade would balk and refuse to upgrade the database. >> >> pg_upgrade should be able to tell that these are the same collations and go >> ahead with the upgrade. >> >> It also should give some indication of how to overcome the problem. > > [ Moved to hackers list.] > > Interesting. It can be easily fixed in the C code. Does anyone know of > an example where the case of the locale name is significant in > controlling the behavior? Uh, are we talking about locale, or collation? Because if it's collation, that seems certain to affect index contents. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] timezone GUC
On Sun, May 22, 2011 at 9:54 PM, Tom Lane wrote: >> If not, then how about jiggering things somehow so that only one >> server process needs to run the hack? Perhaps it can drop the result >> in a file or shared memory or something from which the remaining >> backends can read it out without having to redo all that work? >> Admittedly there is a synchronization problem there I'm not quite sure >> how to solve. > > Well, the main point in my mind is that the process is so damn expensive > that we don't want to run it at all, ever, if we can avoid it. > > We could imagine launching a postmaster child to compute the result, > as you suggest. And it would work 99.9% of the time, because probably > nobody would remove the setting from postgresql.conf within a few > seconds of having started the postmaster. But also, 99.999% of the time > it would be completely wasted effort because the DBA wouldn't remove the > postgresql.conf setting at all, ever. Well, by that argument, we ought not to worry about masterminding what happens if the DBA does do such a thing -- just run the whole process and damn the torpedoes. If it causes a brief database stall, at least they'll get the correct behavior. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] timezone GUC
Robert Haas writes: > On Thu, May 19, 2011 at 12:19 PM, Tom Lane wrote: >> What would make everybody happy is to find a way of identifying the >> system timezone that isn't such a massive, expensive kluge. Any ideas? > ...reads the code... > Good grief. What an incredibly ugly hack. Is there seriously no > portable way of doing this? AFAIK, not. The info is certainly not available in the POSIX/SUS spec, probably because they don't think there's a standardized idea of what timezone names are to begin with. (There was some discussion just a week or two ago in the Fedora lists about this, but I fear Lennart Poettering suffers from a seriously inflated view of his ability to establish standards without bothering with any actual, um, standards process.) > If not, then how about jiggering things somehow so that only one > server process needs to run the hack? Perhaps it can drop the result > in a file or shared memory or something from which the remaining > backends can read it out without having to redo all that work? > Admittedly there is a synchronization problem there I'm not quite sure > how to solve. Well, the main point in my mind is that the process is so damn expensive that we don't want to run it at all, ever, if we can avoid it. We could imagine launching a postmaster child to compute the result, as you suggest. And it would work 99.9% of the time, because probably nobody would remove the setting from postgresql.conf within a few seconds of having started the postmaster. But also, 99.999% of the time it would be completely wasted effort because the DBA wouldn't remove the postgresql.conf setting at all, ever. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [BUGS] BUG #6034: pg_upgrade fails when it should not.
Tim Uckun wrote: > pg_upgrade from 8.4 to 9.0 fails with the following error message. > > old and new cluster lc_collate values do not match > > > on 8.4 show lc_collate outputs > > en_NZ.utf8 > (1 row) > > > on 9.0 it outputs > > en_NZ.UTF8 > (1 row) > > > So the difference seems to be in capitalization. Presumably they are the > same collation with "different" names so it strikes me as odd that > pg_upgrade would balk and refuse to upgrade the database. > > pg_upgrade should be able to tell that these are the same collations and go > ahead with the upgrade. > > It also should give some indication of how to overcome the problem. [ Moved to hackers list.] Interesting. It can be easily fixed in the C code. Does anyone know of an example where the case of the locale name is significant in controlling the behavior? -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] timezone GUC
On Thu, May 19, 2011 at 12:19 PM, Tom Lane wrote: > Robert Haas writes: >> On Thu, May 19, 2011 at 12:12 PM, Tom Lane wrote: >>> We could do that, but the issue that this code is trying to avoid is >>> that identify_system_timezone can easily add several seconds to the >>> postmaster startup time. So one of the reasons why someone would be >>> putting a timezone setting into postgresql.conf in the first place is >>> to not pay that startup overhead. I'm not thrilled with the idea >>> of defeating that in order to cover the corner case where they remove >>> the setting later. > >> Yeah, I'm not thrilled with that either. However, I'm also not >> thrilled with the existing behavior. Consistency is the hobgoblin of >> small minds, and also mine. > > What would make everybody happy is to find a way of identifying the > system timezone that isn't such a massive, expensive kluge. Any ideas? ...reads the code... Good grief. What an incredibly ugly hack. Is there seriously no portable way of doing this? If not, then how about jiggering things somehow so that only one server process needs to run the hack? Perhaps it can drop the result in a file or shared memory or something from which the remaining backends can read it out without having to redo all that work? Admittedly there is a synchronization problem there I'm not quite sure how to solve. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] eviscerating the parser
On Sun, May 22, 2011 at 1:38 PM, Joshua Berkus wrote: >> Another point is that parsing overhead is quite obviously not the >> reason for the massive performance gap between one core running simple >> selects on PostgreSQL and one core running simple selects on MySQL. >> Even if I had (further) eviscerated the parser to cover only the >> syntax those queries actually use, it wasn't going to buy more than a >> couple points. > > I don't know if you say Jignesh's presentation, but there seems to be a lot > of reason to believe that we are lock-bound on large numbers of concurrent > read-only queries. I didn't see Jignesh's presentation, but I'd come to the same conclusion (with some help from Jeff Janes and others): http://archives.postgresql.org/pgsql-hackers/2010-11/msg01643.php http://archives.postgresql.org/pgsql-hackers/2010-11/msg01665.php We did also recently discuss how we might improve the behavior in this case: http://archives.postgresql.org/pgsql-hackers/2011-05/msg00787.php ...and ensuing discussion. However, in this case, there was only one client, so that's not the problem. I don't really see how to get a big win here. If we want to be 4x faster, we'd need to cut time per query by 75%. That might require 75 different optimizations averaging 1% a piece, most likely none of them trivial. I do confess I'm a bit confused as to why prepared statements help so much. That is increasing the throughput by 80%, which is equivalent to decreasing time per query by 45%. That is a surprisingly big number, and I'd like to better understand where all that time is going. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Some PGCon quotes
On Sun, May 22, 2011 at 3:23 PM, Jim Nasby wrote: > These all stemmed from beers Friday night... > > David Wheeler: "I'm trying to picture Tom Lane as a kid... Was he constantly > rewriting the other kid's homework?" > > Greg Smith: "When bullies said they were going to take Tom's lunch money, > he'd ask if they had proof." > > Jeremy Lawler remarked that the lucnhmoney datatype has been depricated since > 8.2. Awesome... -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do you recommend 8.4 or 9.0 for basic usage?
Josh, From: "Joshua Berkus" Could you give me your frank opinions about which of 8.4 or 9.0 you recommend to ISVs who embed PostgreSQL? So, first of all, you posted this question to the wrong list. pgsql-general or pgsql-admin would have been more appropriate for this question. However, at this time there have already been four update releases for 9.0, so you can be fairly assured that any major bugs have been fixed. 9.0 was definitely a higher patch release (and longer beta) than 8.4 specifically because of streaming replication & hot standby. Those are major, complex features which offer the opportunity for issues which only occur in multi-server configurations and are thus hard to test for. Our company has multiple ISV clients who are deploying products built on 9.0.X, and to date have had no special issues. As an ISV, though, you need to devise a plan whereby you can apply update releases to your client's machines if they are connected to the internet. One of the primary reasons for update releases is closing security holes, which means that you need to have a way to upgrade your customers. Some of the biggest issues we've seen in our clients is that an inability to apply in-the-field updates causing customers to experience bugs which have long been fixed in PostgreSQL releases. Thank you very much for offering your experience and advice, I'd like to share your voice with my boss. And I'm sorry for posting to the wrong list. Yes, I was torn between pgsql-hackers and pgsql-general. I didn't want to unintentionally give misconception about 9.0 quality to general users, so I kept the mail here in the end. Regards, MauMau -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] inconvenient compression options in pg_basebackup
On Fri, May 20, 2011 at 17:45, Peter Eisentraut wrote: > On fre, 2011-05-20 at 14:19 -0400, Magnus Hagander wrote: >> > I suggest we add an argument-less option -z that means "compress", >> and >> > then -Z can be relegated to choosing the compression level. >> >> We can't just use -Z without a parameter for that? > > You can't portably have a command-line option with an optional argument. Ugh. In that case, I'm fine with your suggestion. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Some PGCon quotes
These all stemmed from beers Friday night... David Wheeler: "I'm trying to picture Tom Lane as a kid... Was he constantly rewriting the other kid's homework?" Greg Smith: "When bullies said they were going to take Tom's lunch money, he'd ask if they had proof." Jeremy Lawler remarked that the lucnhmoney datatype has been depricated since 8.2. -- Jim C. Nasby, Database Architect j...@nasby.net 512.569.9461 (cell) http://jim.nasby.net -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] proposal: enhanced get diagnostics statement
2011/5/22 Tom Lane : > Alvaro Herrera writes: >> Excerpts from Pavel Stehule's message of sáb may 21 16:05:01 -0400 2011: >>> A implementation of ERROR_CONTEXT is not without impact on >>> performance, because context should be collected when exception is >>> caught. One solution is removing a ERROR_CONTEXT from proposal. Second >>> solution can be a design of enhanced syntax for exception trap like >>> (it means - collect CONTEXT when exception is handled) > >> I don't understand why we should worry about this. I mean, if you don't >> catch the error, you have to form errcontext anyway. Why is it a >> problem to generate it when the exception is caught? > > The argument is nonsense anyway, because it's based on an incorrect > implementation. exec_stmt_block has no business calling the error > context stack --- that was already done in errfinish. Worse, by the time > you get control back from the longjmp, you probably have popped off some > of the stack variables that those links would need to use. If that code > didn't dump core in testing, it's likely only because it wasn't tested > very much. > It works with copy of ErrorData, that is available in estate - when estate->cur_err is NOT NULL. I am not sure about "context" - the my implementation is strange, but access to detail and hint is without any known problems. Please, can you specify a situation, when access to ErrorData fields can be broken? > > A bigger issue is that it seems like this is an abuse of GET > DIAGNOSTICS. The existing options of that statement report on the > results of the immediately preceding command. If we add options that > report on the last error, then we will have a situation where some of > the options have different "lifespan" than others. That seems pretty > klugy and confusing to me. > It doesn't mean a "last error", it means a error in current handler block - because life of cur_err is limited per block. But you has true. ANSI SQL defines "stacked diagnostics" statement for access to error info about outer exceptions. The expected information is available only when GET STATEMENT is first statement of exception handler. If isn't first statement, you should to use a stacked GET DIAGNOSTICS statement. > I'm not real sure what to do instead. If we were actually trying to > follow precedent here, what we'd be looking to do is add more > auto-initialized variables like SQLERRM inside recovery blocks. > That would again have the issue of wasting cycles in code that never > actually looked at the variables. (But I wonder if we couldn't tweak > plpgsql so that we could determine at compile time which variables have > references and which don't, so that we'd not bother filling in variables > that weren't used. Or somehow arrange to only do the work when the > variable's value is accessed.) Any new magic values are not good - hard to enhance it. The correct way is implementation GET DIAGNOSTICS statement based on ANSI/SQL. But should be implemented different, it has to return exception info, only when GD is first statement of handler block. Is it less confusing for you? Some optimization for SQLERRM can be done still - I am doing some similar in PL/PSM and it is possible. Regards Pavel Stehule > > regards, tom lane > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] proposal: enhanced get diagnostics statement
Alvaro Herrera writes: > Excerpts from Pavel Stehule's message of sáb may 21 16:05:01 -0400 2011: >> A implementation of ERROR_CONTEXT is not without impact on >> performance, because context should be collected when exception is >> caught. One solution is removing a ERROR_CONTEXT from proposal. Second >> solution can be a design of enhanced syntax for exception trap like >> (it means - collect CONTEXT when exception is handled) > I don't understand why we should worry about this. I mean, if you don't > catch the error, you have to form errcontext anyway. Why is it a > problem to generate it when the exception is caught? The argument is nonsense anyway, because it's based on an incorrect implementation. exec_stmt_block has no business calling the error context stack --- that was already done in errfinish. Worse, by the time you get control back from the longjmp, you probably have popped off some of the stack variables that those links would need to use. If that code didn't dump core in testing, it's likely only because it wasn't tested very much. A bigger issue is that it seems like this is an abuse of GET DIAGNOSTICS. The existing options of that statement report on the results of the immediately preceding command. If we add options that report on the last error, then we will have a situation where some of the options have different "lifespan" than others. That seems pretty klugy and confusing to me. I'm not real sure what to do instead. If we were actually trying to follow precedent here, what we'd be looking to do is add more auto-initialized variables like SQLERRM inside recovery blocks. That would again have the issue of wasting cycles in code that never actually looked at the variables. (But I wonder if we couldn't tweak plpgsql so that we could determine at compile time which variables have references and which don't, so that we'd not bother filling in variables that weren't used. Or somehow arrange to only do the work when the variable's value is accessed.) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] eviscerating the parser
Robert, > Another point is that parsing overhead is quite obviously not the > reason for the massive performance gap between one core running simple > selects on PostgreSQL and one core running simple selects on MySQL. > Even if I had (further) eviscerated the parser to cover only the > syntax those queries actually use, it wasn't going to buy more than a > couple points. I don't know if you say Jignesh's presentation, but there seems to be a lot of reason to believe that we are lock-bound on large numbers of concurrent read-only queries. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com San Francisco -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do you recommend 8.4 or 9.0 for basic usage?
MauMau, > Could you give me your frank opinions about which of 8.4 or 9.0 you > recommend to ISVs who embed PostgreSQL? So, first of all, you posted this question to the wrong list. pgsql-general or pgsql-admin would have been more appropriate for this question. That being said, I find your statistics on bug fixes interesting, so thank you for collecting them. However, at this time there have already been four update releases for 9.0, so you can be fairly assured that any major bugs have been fixed. 9.0 was definitely a higher patch release (and longer beta) than 8.4 specifically because of streaming replication & hot standby. Those are major, complex features which offer the opportunity for issues which only occur in multi-server configurations and are thus hard to test for. Our company has multiple ISV clients who are deploying products built on 9.0.X, and to date have had no special issues. As an ISV, though, you need to devise a plan whereby you can apply update releases to your client's machines if they are connected to the internet. One of the primary reasons for update releases is closing security holes, which means that you need to have a way to upgrade your customers. Some of the biggest issues we've seen in our clients is that an inability to apply in-the-field updates causing customers to experience bugs which have long been fixed in PostgreSQL releases. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com San Francisco -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Logfile
Hi, I am using contrib/cube code. I am building GIST index on cube data type then it leads to a very large size of log file (nearly 220 MB for only 12k records). While creating index on geometry field with gist gives 1KB size of log file for 17 lakh records. Can someone please tell me how to stop postgres to logged so much data in case of cube? Thanks Nick
[HACKERS] sepgsql: fix relkind handling on foreign tables
The attached patch fixes up case handling in foreign tables. Now it didn't assign security label on foreign table on its creation time, and didn't check access rights on the dml hook. This patch fixes these problems; It allows foreign tables default labeling and access checks as db_table object class. Thanks, -- KaiGai Kohei sepgsql-fix-foreign-table.1.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Compile plPython for Python 3.2
I am trying to build plPython for Python 3.2 64bit under Windows 7 with Microsoft Windows SDK v7.0 (all tools are 64bit). I downloaded Python from python.org I get this error: "C:\Users\user\Desktop\postgresql-9.0.4\pgsql.sln" (default target) (1) -> (PLs\plpython target) -> .\src\pl\plpython\plpython.c(3210): error C2201: 'PyInit_plpy' : must have ex ternal linkage in order to be exported/imported "C:\Users\user\Desktop\postgresql-9.0.4\pgsql.sln" (default target) (1) -> (interfaces\ecpg target) -> Project : error PRJ0019: A tool returned an error code from "Running bison on src\interfaces\ecpg\preproc\preproc.y" How can I fix this?
