Re: [PATCHES] [HACKERS] msvc, build and install with cygwin in the PATH
Andrew Dunstan wrote: > Hannes Eder wrote: >> Magnus Hagander wrote: >> >Hannes Eder wrote: >> >> Is it worth doing this the "Perl-way" and using File::Find? If so, >> I can >> >> work an a patch for that. >> >> >> > It's certainly cleaner that way, but I don't find it a major issue. >> But I'd >> > rather see that fix than the other one. >> >> Here we go. See attached patch. Your comments are welcome. >> >> > > I have committed a fix that is somewhat similar to this. The Install.pm > module needs some love, but that will have to wait till the next cycle. Thanks, Andrew! //Magnus ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] Use latestCompletedXid to slightly optimize TransactionIdIsInProgress
"Florian G. Pflug" <[EMAIL PROTECTED]> writes: > Since we already advance latestCompletedXid on subtransaction and toplevel > transaction aborts, we might as well use the value to rule out surely > in-progress transctions at the top of TransactionIdIsInProgress. This patch bothers me a bit, because TransactionIdIsInProgress has always been defined to return "true" only for XIDs that it can positively confirm are active; not, for instance, transactions that haven't started yet. However, I can't actually see any big downside to changing it as you suggest. The only bad consequence I can think of offhand is that VACUUM could see an already-wrapped-around tuple as INSERT_IN_PROGRESS rather than committed, which would stop it from freezing the tuple, which would break a behavior that people have sometimes used to get out of transaction wraparound situations. But we should now have enough defenses in there to prevent such problems from happening in the first place; and anyway the VACUUM trick would still work, except in the very-improbable case that the tuple's XMIN_COMMITTED bit had never gotten set before it wrapped around. There is one serious bug in the patch as proposed: you can't examine latestCompletedXid without acquiring the ProcArrayLock. In a multiprocessor that requires memory fence instructions, it would be entirely possible to deliver a wrong answer as a consequence of reading a stale value of latestCompletedXid. (We execute fence instructions when acquiring/releasing locks.) However, after the recent rewrite of TransactionIdIsInProgress, we can put the check after taking the lock without added complexity. Hence, applied with revisions. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] Optimizer hook
Julius Stroffek <[EMAIL PROTECTED]> writes: > I rewrote a patch a bit. This hook seems very strangely defined to me. Why did you not put the hook at the point where the current geqo-vs-regular decision is made? I do not see the value of duplicating the joinlist-expansion logic, which is what you're going to have to do if you use a hook that replaces make_rel_from_joinlist. The only things you could do differently than it does would be (1) be smarter about full outer joins, which was not part of the agenda that I heard of, or (2) willfully disregard the user's from_collapse_limit and join_collapse_limit settings, which doesn't seem like an amazingly good idea either. Also, "optimizer_hook" seems nearly content-free as a name for use in this area; I see no reason why the particular sub-section of the planner we're discussing here has more title to that name than other parts. Something like "join_order_search_hook" might be more appropriate. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: XML binary I/O (was Re: [PATCHES] tsearch refactorings)
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes: > Here's a patch that fixes the send/recv functions to work like the > manual says. It fixes the free/pfree typo as well. Applied with a further fix: the patch caused xml_recv to call parse_xml_decl with a non-null-terminated string, which could in the worst case lead to a crash. > Included is a new regression test for the send/recv functions as well I didn't apply this, as it seemed more trouble than it was worth. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[PATCHES] remove convert using
The attached patch removes "convert ... using ..." as recently discussed on -hackers. Most of the patch is regression test changes. If there's no objection I'll apply it in a day or two. cheers andrew convusing.patch.gz Description: GNU Zip compressed data ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] remove convert using
Andrew Dunstan <[EMAIL PROTECTED]> writes: > The attached patch removes "convert ... using ..." as recently discussed > on -hackers. Most of the patch is regression test changes. You should be able to remove CONVERT as a grammar keyword altogether -- the remaining production for CONVERT as a function name seems dead weight now (not to mention that it prevents having user-defined functions named CONVERT). Other than that omission it looks sane to me. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] remove convert using
Tom Lane wrote: Andrew Dunstan <[EMAIL PROTECTED]> writes: The attached patch removes "convert ... using ..." as recently discussed on -hackers. Most of the patch is regression test changes. You should be able to remove CONVERT as a grammar keyword altogether -- the remaining production for CONVERT as a function name seems dead weight now (not to mention that it prevents having user-defined functions named CONVERT). I wonderted a bit about that. I thought it might be better to leave it in case we wanted to put back "convert using" when we have better support for multiple encodings (and maybe when we understand better what it is actually supposed to do). But I have no strong opinions on the subject. cheers anmdrew ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] remove convert using
Andrew Dunstan <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> You should be able to remove CONVERT as a grammar keyword altogether >> -- the remaining production for CONVERT as a function name seems dead >> weight now (not to mention that it prevents having user-defined >> functions named CONVERT). > I wonderted a bit about that. I thought it might be better to leave it > in case we wanted to put back "convert using" when we have better > support for multiple encodings (and maybe when we understand better what > it is actually supposed to do). Well, we could always put it back when we need it --- in the meantime, every extra keyword is some fractional drag on parsing performance. In any case I think the remaining production is probably wrong because it constrains the function to be in pg_catalog schema, when there is no grammatical evidence that it should be special. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] remove convert using
Tom Lane wrote: Andrew Dunstan <[EMAIL PROTECTED]> writes: Tom Lane wrote: You should be able to remove CONVERT as a grammar keyword altogether -- the remaining production for CONVERT as a function name seems dead weight now (not to mention that it prevents having user-defined functions named CONVERT). I wonderted a bit about that. I thought it might be better to leave it in case we wanted to put back "convert using" when we have better support for multiple encodings (and maybe when we understand better what it is actually supposed to do). Well, we could always put it back when we need it --- in the meantime, every extra keyword is some fractional drag on parsing performance. In any case I think the remaining production is probably wrong because it constrains the function to be in pg_catalog schema, when there is no grammatical evidence that it should be special. OK, fix committed doing this. cheers andrew ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[PATCHES] actualised SQL/PSM patch
Hello New version of SQL/PSM patch is available. I am sending only link, because mail with attached patch was lost. Documentation is on available from http://www.pgsql.cz/index.php/SQL/PSM_Manual http://www.pgsql.cz/patches/plpgpsm83.diff.gz Regards Pavel Stehule ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
