Re: [HACKERS] sepgsql contrib module
On Sun, Jan 23, 2011 at 03:19, Robert Haas robertmh...@gmail.com wrote: 2011/1/21 KaiGai Kohei kai...@ak.jp.nec.com: Do we have any workaround to avoid these indenting/formatting? Or, the reformatted code is better than before? That's pretty horrendous. Tom/Bruce, any ideas? I saw some similar things earlier, and it turned out to be two different reasons in two different cases. In one case, it was because I was using GNU indent, even though I thought I was using the one that's on our ftp. But it does give a warning in that case, you just have to actually *read* the warning. In the other case it was really weird - when my wrapper script (that called pgindent with path specification and such) executing using dash (the default /bin/sh on Ubuntu), it did weird things - but when I explicitly executed the wrapper script with /bin/bash, it worked - even though pgindent itself is still using /bin/sh. -- 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
Re: [HACKERS] Perl 5.12 complains about ecpg parser-hacking scripts
On Sat, Jan 22, 2011 at 08:40:13PM -0500, Andrew Dunstan wrote: I think these really need to be rewritten from scratch. They look like they were written by someone who never heard of Perl 5 (it's only about 16 years old). You might remember that we had this discussion before. The script was written in awk and then translated to perl by a2p. We knew that this code was less than optimal, but at least it works. As I already said when the script was introduced, I would love to have a real perl solution, but I'm not a perl programmer by any means. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at googlemail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- 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] pg_basebackup for streaming base backups
On Thu, Jan 20, 2011 at 17:17, Magnus Hagander mag...@hagander.net wrote: On Thu, Jan 20, 2011 at 16:45, Bruce Momjian br...@momjian.us wrote: Do we envision pg_basebackup as something we will enahance, and if so, should we consider a generic name? Well, it's certainly going to be enhanced. I think there are two main uses for it - backups, and setting up replication slaves. I can't see it expanding beyond those, really. I've committed this with the current name, pg_basebackup, before the bikeshed hits all the colors of the rainbow. If there's too much uproar, we can always rename it - it's a lot easier now that we have git :P Base backups is something we discuss regularly, so it's not a new term. And I don't see why people would be confused that this is a tool that you run on the client (which can be the same machine) - afte rall, we don't do pg_receive_dump, pg_receive_dumpall, pg_send_restore on those tools. -- 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
Re: [HACKERS] Use of O_DIRECT only for open_* sync options
Bruce Momjian wrote: xlogdefs.h says: /* * Because O_DIRECT bypasses the kernel buffers, and because we never * read those buffers except during crash recovery, it is a win to use * it in all cases where we sync on each write(). We could allow O_DIRECT * with fsync(), but because skipping the kernel buffer forces writes out * quickly, it seems best just to use it for O_SYNC. It is hard to imagine * how fsync() could be a win for O_DIRECT compared to O_SYNC and O_DIRECT. * Also, O_DIRECT is never enough to force data to the drives, it merely * tries to bypass the kernel cache, so we still need O_SYNC or fsync(). */ This seems wrong because fsync() can win if there are two writes before the sync call. Can kernels not issue fsync() if the write was O_DIRECT? If that is the cause, we should document it. The comment does look busted, because you did imagine exactly a case where they might be combined. The only incompatibility that I'm aware of is that O_DIRECT requires reads and writes to be aligned properly, so you can't use it in random application code unless it's aware of that. O_DIRECT and fsync are compatible; for example, MySQL allows combining the two: http://dev.mysql.com/doc/refman/5.1/en/innodb-parameters.html (That whole bit of documentation around innodb_flush_method includes some very interesting observations around O_DIRECT actually) I'm starting to consider the idea that much of the performance gains seen on earlier systems with O_DIRECT was because it decreased CPU usage shuffling things into the OS cache, rather than its impact on avoiding pollution of said cache. On Linux for example, its main accomplishment is decribed like this: File I/O is done directly to/from user space buffers. http://www.kernel.org/doc/man-pages/online/pages/man2/open.2.html The earliest paper on the implementation suggests a big decrease in CPU overhead from that: http://www.ukuug.org/events/linux2001/papers/html/AArcangeli-o_direct.html Impossible to guess whether that's more true (CPU cache pollution is a bigger problem now) or less true (drives are much slower relative to CPUs now) today. I'm trying to remain agnostic and let the benchmarks offer an opinion instead. -- Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us PostgreSQL 9.0 High Performance: http://www.2ndQuadrant.com/books -- 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] Perl 5.12 complains about ecpg parser-hacking scripts
On 01/22/2011 09:28 PM, k...@shannon.id.au wrote: On 23 January 2011 13:14, Andrew Dunstanand...@dunslane.net wrote: But there are quite a few perlheads around. ISTR Matt Trout was muttering about these scripts on IRC recently. A quick cleanup of the check_rules.pl... It's a starting point at least. Oh! Perl is my favorite. Kris, if you're not going to, I'd love to work on this. -Andy -- 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] Perl 5.12 complains about ecpg parser-hacking scripts
On 01/23/2011 06:11 AM, Michael Meskes wrote: On Sat, Jan 22, 2011 at 08:40:13PM -0500, Andrew Dunstan wrote: I think these really need to be rewritten from scratch. They look like they were written by someone who never heard of Perl 5 (it's only about 16 years old). You might remember that we had this discussion before. The script was written in awk and then translated to perl by a2p. We knew that this code was less than optimal, but at least it works. Oh, I'm sorry, I'd totally forgotten that. At least it explains why it looks like it's from a time warp. I bet the perl guys haven't touched a2p for many many years. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] 答复: [HACKERS] Is there a way to build PostgreSQL client libraries with MinGW
Hi I am not so familiar with the PostgreSQL development team, but using a MinGW compatible client side is important to us, so I'd like to start doing it myself if any of you experts can help. Cheers Xiaobo Gu -邮件原件- 发件人: Andrew Dunstan [mailto:and...@dunslane.net] 发送时间: 2011年1月21日 23:25 收件人: Magnus Hagander 抄送: Robert Haas; XiaoboGu; pgsql-hackers@postgresql.org 主题: Re: [HACKERS] Is there a way to build PostgreSQL client libraries with MinGW On 01/21/2011 05:24 AM, Magnus Hagander wrote: That advice needs to be taken with a grain or two of salt. First, while you probably should not use Cygwin postgres as a production server, it is still the best way to run psql on Windows that I know of. And second, the stuff Yeah, I agree for psql the client tool (though it used to suck badly if you were in a non-english locale, but they may have fixed that). But not for PostgreSQL the full product. I guess we could add a sentence about the client side, but it needs to be clear that the non-sucky part only applies to the client. It's not so bad it can't be used for development, and I have known people who do that, and indeed I have deployed one very complex app developed in just that way. More importantly from my POV, there is no support in the buildfarm for just building the client side, and I have no intention of providing it. So it's not insignificant for us to be able to continue supporting a complete build on Cygwin, however much you dislike it. about not being able to generate 64-bit binaries with Mingw is no longer true (that's why it's no longer called Mingw32), although it is true that nobody I know has yet tried to do so. It's on my long TODO list, and well worth doing. (Relying on one compiler is the techno equivalent of monolingualism, which my sister's bumper sticker used to tell me is a curable condition.) It's true from the perspective of *postgresql* - you can't use those compiler to generate 64-bit binaries of PostgreSQL. And it's referring to these builds, not the compiler itself. And I'm certainly not going to stand in the way of somebody adding build support for it if they (you or others) want to spend time on it - that patch should just include an update to that documentation paragraph, of course. Personally, I'm going to put what time I can put into windows build system updates into making us work with VS 2010 because I find that more important - but that's just me personally. VS2010 is important, no doubt. But clearly there's some demand for continued Mingw support, hence the OP's question. As I've remarked before, I think we should support as many build platforms/environments as we can. cheers andrew -- 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] SSPI client authentication in non-Windows builds
* Christian Ullrich wrote: Magnus Hagander wrote: On Mon, Jan 3, 2011 at 14:11, Christian Ullrichch...@chrullrich.net wrote: This change has been tested and works correctly on FreeBSD 8.1, using the Kerberos and GSSAPI libraries from Heimdal 1.4. The server is running PostgreSQL 9.0.2 on Windows 2008. Does this require some certain minimum version of the kerberos libraries? Do you know if it works with just Heimdal or both Heimdal and MIT? it works with anything but the configuration I mentioned. I will do some more testing this week, but I'm limited in the number of combinations I can try; some randomly chosen Linux distributions with whatever Kerberos they ship and the Heimdal from the FreeBSD 8 base system instead of the port (if I can get PostgreSQL to build with that) against Windows 2003 and 2008 is probably going to be all I can offer. Expect a report early next week. This is what I tested this week. If there are any additional questions, please let me know. Clients tested -- 1 FreeBSD 8.1 (x86), Heimdal 1.4 (released Sep 2010) 2 Gentoo Linux (x86_64) 20110113, Heimdal 1.3.3 (released May 2010) 3 Gentoo Linux (x86_64) 20110113, MIT 1.9 (released Dec 2010) 4 Gentoo Linux (x86_64) 20110113, MIT 1.8.3 (released Aug 2010) 5 Ubuntu Linux (x86) 10.10, MIT 1.8.1 (released Apr 2010) 6 FreeBSD 7.0 (x86), Heimdal 0.7 (released Jun 2005) 7 Debian Linux (x86) 5.0.7, MIT 1.4 (released Jan 2005) 8 Debian Linux (x86) 5.0.7, Heimdal 0.7.2 (released Feb 2006) Notes: My approach in building PostgreSQL on the clients was to first get it to build without the patch, then add the patch, do a minimal rebuild (make) and test with databases configured for md5 and sspi authentication. I also tried GNU shishi as a third Kerberos implementation, but could not get it to even attempt to get a TGT. 2, 3, 4: These were the only Kerberos implementations available in Portage, obviously very recent ones. 6: Heimdal 0.7 was the oldest release I could get to build on this platform, and getting PostgreSQL to link against it required some work. 7: MIT 1.4 is the first release that will build with gcc 4, while the first release that PostgreSQL might possibly compile with is 1.3. Everything before that does not have a sufficient GSSAPI. For the GCC issue see GCC bug #18799. 8: There was an interesting build issue in this configuration. Linux glibc does not include strlcpy(), which is why both libpgport and Heimdal's libroken have their own versions. What happens is that PostgreSQL's configure, after correctly determining that there is no declaration of strlcpy() in the system headers, nevertheless detects libroken's implementation and excludes it from libpgport. Later, (at least) ecpg and initdb fail to link because it is not there. I could not figure out how to force it to be included in libpgport, so I had to use libroken instead. Servers tested -- A Windows Server 2008 (x86_64), PostgreSQL 9.0.2 (x86_64) B Windows Server 2008R2 (x86_64), PostgreSQL 8.4.4 (x86) C Windows Server 2003R2 (x86), PostgreSQL 9.0.2 (x86) Notes: A:This is the (production) installation I mentioned originally. B, C: These are dedicatedldd testing installations. Server configuration procedure -- - Installed operating system - Joined to domain - Installed PostgreSQL - Stopped service - Created service account in domain, added SPNs using ADSIEdit I used a managed service account for the 2008R2 server, which I then installed on that server. Postgres on the 2003R2 server is using a standard user account. - Changed permissions on data directory - Changed service logon - Started service Combinations tested successfully 1 2 3 4 5 6 7 8 A X B X X X X X X C X X X Combinations tested unsuccessfully -- 1 2 3 4 5 6 7 8 A B C Conclusion -- There is no detectable risk of SSPI-via-GSS authentication failure due to interoperability problems between the client's GSSAPI and the server's SSPI, no matter the versions involved. The only potential exception is with a Windows 2000 server, which I did not have access to and consequently did not test. A number of pitfalls can hamper building PostgreSQL, especially with older Kerberos implementations. These, however, will equally affect builds that are intended to use only traditional GSSAPI authentication. I am not sure what I may have done wrong in the case of client 8, which was a Debian system installed using the minimal CD. Maybe I was missing some package or other. Given that this was on Debian, it would surprise me if it was a genuine bug in configure. -- Christian -- Sent via
Re: [HACKERS] Perl 5.12 complains about ecpg parser-hacking scripts
On 01/23/2011 08:29 AM, Andy Colson wrote: On 01/22/2011 09:28 PM, k...@shannon.id.au wrote: On 23 January 2011 13:14, Andrew Dunstanand...@dunslane.net wrote: But there are quite a few perlheads around. ISTR Matt Trout was muttering about these scripts on IRC recently. Ok, so I've figured out what its purpose is. Are there other problems with this script? Does it not pull out the rule names correct all the time or something? What problem was Matt having with it? I think rewriting from scratch is overkill, unless this script is just failing. The code to pull the rule names out is a bit complex, and it seems to work, so I'd rather not touch it. Are there other things you wished this script did? (reports, counts, etc) -Andy -- 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] Perl 5.12 complains about ecpg parser-hacking scripts
On 01/23/2011 10:16 AM, Andy Colson wrote: On 01/23/2011 08:29 AM, Andy Colson wrote: On 01/22/2011 09:28 PM, k...@shannon.id.au wrote: On 23 January 2011 13:14, Andrew Dunstanand...@dunslane.net wrote: But there are quite a few perlheads around. ISTR Matt Trout was muttering about these scripts on IRC recently. Ok, so I've figured out what its purpose is. Are there other problems with this script? Does it not pull out the rule names correct all the time or something? What problem was Matt having with it? I think rewriting from scratch is overkill, unless this script is just failing. The code to pull the rule names out is a bit complex, and it seems to work, so I'd rather not touch it. Are there other things you wished this script did? (reports, counts, etc) It's doing the right thing. But it's really spaghetti code, generated by a2p. Matt was just (rightly) offended by the $[ setting, IIRC. The point is that it's close to being totally unmaintainable. But if you think you can remedy it without rewriting it, go for it. I think minimum requirements would be: * avoid setting $[ * use strict; * comments saying what it's actually doing We want to be in a situation where of it ever does break because of some external change, we're not left having to wade through the crap to find out how to fix it. cheers andrew -- 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] pg_stat_replication security
On Mon, Jan 17, 2011 at 13:14, Magnus Hagander mag...@hagander.net wrote: On Mon, Jan 17, 2011 at 12:11, Itagaki Takahiro itagaki.takah...@gmail.com wrote: On Mon, Jan 17, 2011 at 19:51, Magnus Hagander mag...@hagander.net wrote: Here's a patch that limits it to superuser only. We can't easily match it to the user of the session given the way the walsender data is returned - it doesn't contain the user information. But limiting it to superuser only seems perfectly reasonable and in line with the encouragement not to use the replication user for login. Objections? It hides all fields in pg_stat_wal_senders(). Instead, can we just revoke usage of the function and view? Or, do we have some plans to add fields which normal users can see? Yes, for consistency with pg_stat_activity. We let all users see which other sessions are there, but not what they're doing - seems reasonable to have the same definitions for replication sessions as other sessions. Committed. -- 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
Re: [HACKERS] Perl 5.12 complains about ecpg parser-hacking scripts
On Sun, Jan 23, 2011 at 09:16:33AM -0600, Andy Colson wrote: Are there other problems with this script? Does it not pull out the rule names correct all the time or something? What problem was Matt having with it? No, afaict it works correctly but throws some warnings. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at googlemail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- 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] Bug in pg_describe_object, patch v2
I wrote: Robert Haas robertmh...@gmail.com writes: We're trying to represent the pg_amproc entry here, and including a bunch of details of the pg_proc entry to which it happens to point seems almost better to be confusing the issue. Yeah, that occurred to me too. However, the CREATE OPERATOR CLASS syntax doesn't really draw a distinction between the referenced function/operator and its reference in the opclass, and I'm not sure users do either. So I don't want to give up the details of the function or operator. But sticking them at the end after a colon might make it clearer that the func/operator is referenced by the amproc or amop entry, but is not the same thing. And yet ... and yet ... if you adopt the position that what we're going to print is amproc item: referenced procedure, then it's not entirely clear why the amproc item description shouldn't be complete. The argument that it's redundant with the procedure description gets a lot weaker as soon as you look at them as two separate items. Ditto amop. And having to add a lot of otherwise-useless code to suppress the redundancy surely isn't very attractive. So I guess I'm coming around to the idea that we want something not too much bigger than Andreas' original patch, but applying to both amop and amproc, and putting the operator/function description at the end. Comments? 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] ALTER TYPE 2: skip already-provable no-work rewrites
Robert Haas robertmh...@gmail.com writes: On Sun, Jan 9, 2011 at 5:01 PM, Noah Misch n...@leadboat.com wrote: As unintended fallout, it's no longer an error to add oids or a column with a default value to a table whose rowtype is used in columns elsewhere. This seems best. Defaults on the origin table do not even apply to new inserts into such a column, and the rowtype does not gain an OID column via its table. I think this should be split into two patches (we can discuss both on this thread, no need to start any new ones), one that implements just the above improvement and another that accomplishes the main purpose of the patch. I haven't been paying much attention to this thread, but I happened to read the above, and quite frankly it scares the cr*p out of me. I don't believe that Noah even begins to be qualified to understand the implications of adding/removing an OID column, and I clearly remember the non-obvious bugs we've had in the past from that. Before this goes in I want to see a convincing explanation (not an unsupported assertion) why this isn't going to re-introduce those old bugs. I'm also pretty unclear on why it's a good idea to let uses of a rowtype be different from the table on which it's allegedly based. To the extent that the current behavior allows that, isn't that a bug rather than a feature we should extend? # The fact that ALTER TYPE requires rewriting the whole table is sometimes an advantage, because the rewriting process # eliminates any dead space in the table. I'm not sure what we can recommend here instead. New-style VACUUM FULL. I don't think that a patch that makes it harder to use ALTER TABLE this way is a problem in itself, now that we've got that. 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] Perl 5.12 complains about ecpg parser-hacking scripts
On 01/23/2011 10:06 AM, Andrew Dunstan wrote: On 01/23/2011 10:16 AM, Andy Colson wrote: On 01/23/2011 08:29 AM, Andy Colson wrote: On 01/22/2011 09:28 PM, k...@shannon.id.au wrote: On 23 January 2011 13:14, Andrew Dunstanand...@dunslane.net wrote: But there are quite a few perlheads around. ISTR Matt Trout was muttering about these scripts on IRC recently. Ok, so I've figured out what its purpose is. Are there other problems with this script? Does it not pull out the rule names correct all the time or something? What problem was Matt having with it? I think rewriting from scratch is overkill, unless this script is just failing. The code to pull the rule names out is a bit complex, and it seems to work, so I'd rather not touch it. Are there other things you wished this script did? (reports, counts, etc) It's doing the right thing. But it's really spaghetti code, generated by a2p. Matt was just (rightly) offended by the $[ setting, IIRC. The point is that it's close to being totally unmaintainable. But if you think you can remedy it without rewriting it, go for it. I think minimum requirements would be: * avoid setting $[ * use strict; * comments saying what it's actually doing We want to be in a situation where of it ever does break because of some external change, we're not left having to wade through the crap to find out how to fix it. cheers andrew ** OOPS, forenote: I only noticed check_rules.pl. That's the only file I looked at. I'll go look at parse.pl right now. Below refers to check_rules.pl only. I can comment the code. $[ can safely be removed (from check_rules.pl) because we are not even using arrays. I disagree (check_rules.pl) is not spaghetti code. There are two loops, one thru gram.y to pick out the rule names, and one through ecpg.addons to make sure they are in use. Unmaintainable is another story. Parsing gram.y for rule names, then combining them to make up the same name in ecpg.addons is a little complex. But then I think it would be a little complex in any language. A little change to the syntax/layout of either file and it could go bad, but you'd have that same problem with any other language too. Is there anyway to make bison/yacc/gcc/etc spit out the rule names? I'm not sure rule name is the proper words. In gram.y we have: stmt : AlterDatabaseStmt | AlterDatabaseSetStmt We pull out and create: stmtAlterDatabaseStmt and stmtAlterDatabaseSetStmt -Andy -- 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] sepgsql contrib module
Magnus Hagander mag...@hagander.net writes: On Sun, Jan 23, 2011 at 03:19, Robert Haas robertmh...@gmail.com wrote: That's pretty horrendous. Tom/Bruce, any ideas? I saw some similar things earlier, and it turned out to be two different reasons in two different cases. In one case, it was because I was using GNU indent, even though I thought I was using the one that's on our ftp. But it does give a warning in that case, you just have to actually *read* the warning. In the other case it was really weird - when my wrapper script (that called pgindent with path specification and such) executing using dash (the default /bin/sh on Ubuntu), it did weird things - but when I explicitly executed the wrapper script with /bin/bash, it worked - even though pgindent itself is still using /bin/sh. Hm, but then the inner /bin/sh is really dash no? Maybe the outer invocation is setting environment variables or something to change the behavior of the inner invocation. That would be pretty broken, but IME most bash substitutes are pretty broken. 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] Perl 5.12 complains about ecpg parser-hacking scripts
Andy Colson a...@squeakycode.net writes: Is there anyway to make bison/yacc/gcc/etc spit out the rule names? bison -v produces a debug output file that includes nicely cleaned-up versions of all the rules. But it includes a lot of other stuff too, and I'm not at all sure that the file format is stable across bison versions, so maybe depending on that isn't a hot idea. I'm not sure rule name is the proper words. In gram.y we have: Production is the standard technical name, but on the other hand the bison documentation seems to consistently use the word rule, so there's probably nothing wrong with doing so here too. 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] Perl 5.12 complains about ecpg parser-hacking scripts
Kris Shannon k...@shannon.id.au writes: What is the minimal perl version that we are requiring these days? 5.8 according to configure. 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] Perl 5.12 complains about ecpg parser-hacking scripts
On 24 January 2011 03:06, Andrew Dunstan and...@dunslane.net wrote:
It's doing the right thing. But it's really spaghetti code, generated by
a2p. Matt was just (rightly) offended by the $[ setting, IIRC.
The point is that it's close to being totally unmaintainable.
But if you think you can remedy it without rewriting it, go for it.
I think minimum requirements would be:
* avoid setting $[
* use strict;
* comments saying what it's actually doing
We want to be in a situation where of it ever does break because of some
external change, we're not left having to wade through the crap to find out
how to fix it.
cheers
andrew
Well here's an absolutely minimal patch to remove the $[ assignments
and fix up the array accesses.
I have tested that parse.pl produces identical output for both HEAD
and the 65 commits which touch ecpg.*
or gram.y since the introduction on check_rules.pl
git log 81a82a13^..HEAD -- src/backend/parser/gram.y
src/interfaces/ecpg/preproc/{ecpg.??*,*.pl}
I've also tested that the new check_rules.pl dies when I add an extra
unused rule to ecpg.addons.
I'll try and make a proper rewrite sometime this week.
What is the minimal perl version that we are requiring these days?
ecpg_preproc_minimal_perl_cleanup.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
Re: [HACKERS] Perl 5.12 complains about ecpg parser-hacking scripts
On 23 January 2011 14:28, Kris Shannon k...@shannon.id.au wrote: On 23 January 2011 13:14, Andrew Dunstan and...@dunslane.net wrote: But there are quite a few perlheads around. ISTR Matt Trout was muttering about these scripts on IRC recently. A quick cleanup of the check_rules.pl... It's a starting point at least. And I should have at least tried to run this before I submitted... :( New minimal tested submission momentarily. -- 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] Bug in pg_describe_object, patch v2
On Sun, Jan 23, 2011 at 11:50 AM, Tom Lane t...@sss.pgh.pa.us wrote: And yet ... and yet ... if you adopt the position that what we're going to print is amproc item: referenced procedure, then it's not entirely clear why the amproc item description shouldn't be complete. The argument that it's redundant with the procedure description gets a lot weaker as soon as you look at them as two separate items. Ditto amop. And having to add a lot of otherwise-useless code to suppress the redundancy surely isn't very attractive. I couldn't agree more. Sorry if I didn't explain that concern clearly enough upthread. So I guess I'm coming around to the idea that we want something not too much bigger than Andreas' original patch, but applying to both amop and amproc, and putting the operator/function description at the end. That's fine with me. I think the principal argument for failing to remove it entirely is that we've traditionally had it there, but IMHO moving in the direction of treating them as separate objects is much more clear and an altogether better approach. -- 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
[HACKERS] REVIEW: ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED
Hi Simon, On 1/14/2011 1:15 PM, Simon Riggs wrote: Patch to implement the proposed feature attached, for CFJan2011. Overall, I think the patch looks good, but I found some problems with it. In tablecmds.c you have: + if (found con-contype == CONSTR_FOREIGN !con-convalidated) which I don't think is correct, and my tests seem to agree; the actual validation doesn't happen at all. Changing that to CONSTRAINT_FOREIGN makes the validation part work, but then I get: ERROR: cache lookup failed for constraint 16419 when trying to drop the table and the regression tests fail because of this. Also having a regression test where the validation fails seems like a good idea. Another problem I found is that psql doesn't indicate in any way that a FOREIGN KEY constraint is not validated yet. I also think that having the function for getting a list of values that violate the constraint would be helpful. Any particular reason why you decided to omit it from this patch? Regards, Marko Tiikkaja -- 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] REVIEW: ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED
On Sun, 2011-01-23 at 19:50 +0200, Marko Tiikkaja wrote: Hi Simon, On 1/14/2011 1:15 PM, Simon Riggs wrote: Patch to implement the proposed feature attached, for CFJan2011. Overall, I think the patch looks good Thanks for the review. , but I found some problems with it. In tablecmds.c you have: + if (found con-contype == CONSTR_FOREIGN !con-convalidated) which I don't think is correct, and my tests seem to agree; the actual validation doesn't happen at all. Changing that to CONSTRAINT_FOREIGN makes the validation part work, but then I get: ERROR: cache lookup failed for constraint 16419 when trying to drop the table and the regression tests fail because of this. Also having a regression test where the validation fails seems like a good idea. Thanks. Will fix. Another problem I found is that psql doesn't indicate in any way that a FOREIGN KEY constraint is not validated yet. Should it? What command do you think needs changing? I also think that having the function for getting a list of values that violate the constraint would be helpful. Any particular reason why you decided to omit it from this patch? Yes, the consensus was that DDL was required, not a function. Function was my preferred approach originally. That now appears to be an additional request from a couple of people. At present, its easy enough to write the SQL statement yourself, so that's non-essential, and maybe/likely won't make this release (not sure, depends upon how other aspects go). There is no option to invoke this yet from pg_restore, which seems likely to top the list of priorities. Would you agree? -- Simon Riggs http://www.2ndQuadrant.com/books/ PostgreSQL Development, 24x7 Support, Training and Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Re: [COMMITTERS] pgsql: Only show pg_stat_replication details to superusers
On Sun, 2011-01-23 at 16:28 +, Magnus Hagander wrote: Only show pg_stat_replication details to superusers What happens to those with REPLICATION privilege? Denied access? -- Simon Riggs http://www.2ndQuadrant.com/books/ PostgreSQL Development, 24x7 Support, Training and Services -- 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] REVIEW: ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED
On 1/23/2011 8:23 PM, Simon Riggs wrote: On Sun, 2011-01-23 at 19:50 +0200, Marko Tiikkaja wrote: Another problem I found is that psql doesn't indicate in any way that a FOREIGN KEY constraint is not validated yet. Should it? What command do you think needs changing? \d table now only shows that there's a FOREIGN KEY, which might lead the user to think that there should not be any values that don't exist in the referenced table. I also think that having the function for getting a list of values that violate the constraint would be helpful. Any particular reason why you decided to omit it from this patch? Yes, the consensus was that DDL was required, not a function. Function was my preferred approach originally. While I do agree that the DDL command should be the preferred way to validate the constraint, I think the function adds a significant value when the validation does not succeed. That now appears to be an additional request from a couple of people. At present, its easy enough to write the SQL statement yourself, so that's non-essential, and maybe/likely won't make this release (not sure, depends upon how other aspects go). I understand. There is no option to invoke this yet from pg_restore, which seems likely to top the list of priorities. Would you agree? I don't understand what you mean with this. Could you be a bit more elaborate? Regards, Marko Tiikkaja -- 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] REVIEW: ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED
On Sun, 2011-01-23 at 20:33 +0200, Marko Tiikkaja wrote: On 1/23/2011 8:23 PM, Simon Riggs wrote: On Sun, 2011-01-23 at 19:50 +0200, Marko Tiikkaja wrote: Another problem I found is that psql doesn't indicate in any way that a FOREIGN KEY constraint is not validated yet. Should it? What command do you think needs changing? \d table now only shows that there's a FOREIGN KEY, which might lead the user to think that there should not be any values that don't exist in the referenced table. Neither \d nor \di shows invalid indexes. Should we add validation for FKs when it is not there for indexes? My feeling was no. Desirable for both? Yes, but not as part of this patch. There is no option to invoke this yet from pg_restore, which seems likely to top the list of priorities. Would you agree? I don't understand what you mean with this. Could you be a bit more elaborate? The purpose of this patch is performance. pg_restore will be faster if it uses this new feature, so I expect to add an option to reload data without validating FKs. -- Simon Riggs http://www.2ndQuadrant.com/books/ PostgreSQL Development, 24x7 Support, Training and Services -- 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] [COMMITTERS] pgsql: Only show pg_stat_replication details to superusers
On Sun, Jan 23, 2011 at 19:27, Simon Riggs si...@2ndquadrant.com wrote: On Sun, 2011-01-23 at 16:28 +, Magnus Hagander wrote: Only show pg_stat_replication details to superusers What happens to those with REPLICATION privilege? Denied access? Correct, same as those without it - only superuser is enough. For rationale, see the original thread discussing the patch :) -- 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
Re: [HACKERS] REVIEW: ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED
On 1/23/2011 8:43 PM, Simon Riggs wrote: On Sun, 2011-01-23 at 20:33 +0200, Marko Tiikkaja wrote: On 1/23/2011 8:23 PM, Simon Riggs wrote: On Sun, 2011-01-23 at 19:50 +0200, Marko Tiikkaja wrote: Another problem I found is that psql doesn't indicate in any way that a FOREIGN KEY constraint is not validated yet. Should it? What command do you think needs changing? \d table now only shows that there's a FOREIGN KEY, which might lead the user to think that there should not be any values that don't exist in the referenced table. Neither \d nor \di shows invalid indexes. What exactly are you referring to? An index with indisvalid=false looks like this in my psql: fooindex btree (a) INVALID And even if it didn't, I don't think we should be adding more deficiencies to psql. Should we add validation for FKs when it is not there for indexes? My feeling was no. Desirable for both? Yes, but not as part of this patch. There is no option to invoke this yet from pg_restore, which seems likely to top the list of priorities. Would you agree? I don't understand what you mean with this. Could you be a bit more elaborate? The purpose of this patch is performance. pg_restore will be faster if it uses this new feature, so I expect to add an option to reload data without validating FKs. Ah. Right, that would make sense. Regards, Marko Tiikkaja -- 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] REVIEW: ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED
On Sun, 2011-01-23 at 20:56 +0200, Marko Tiikkaja wrote: On 1/23/2011 8:43 PM, Simon Riggs wrote: On Sun, 2011-01-23 at 20:33 +0200, Marko Tiikkaja wrote: On 1/23/2011 8:23 PM, Simon Riggs wrote: On Sun, 2011-01-23 at 19:50 +0200, Marko Tiikkaja wrote: Another problem I found is that psql doesn't indicate in any way that a FOREIGN KEY constraint is not validated yet. Should it? What command do you think needs changing? \d table now only shows that there's a FOREIGN KEY, which might lead the user to think that there should not be any values that don't exist in the referenced table. Neither \d nor \di shows invalid indexes. What exactly are you referring to? An index with indisvalid=false looks like this in my psql: fooindex btree (a) INVALID And even if it didn't, I don't think we should be adding more deficiencies to psql. OK, thanks, I wasn't aware of that. I'll add something similar for FKs. -- Simon Riggs http://www.2ndQuadrant.com/books/ PostgreSQL Development, 24x7 Support, Training and Services -- 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] Bug in pg_describe_object, patch v2
Robert Haas robertmh...@gmail.com writes: On Sun, Jan 23, 2011 at 11:50 AM, Tom Lane t...@sss.pgh.pa.us wrote: So I guess I'm coming around to the idea that we want something not too much bigger than Andreas' original patch, but applying to both amop and amproc, and putting the operator/function description at the end. That's fine with me. OK, committed that way. I think the principal argument for failing to remove it entirely is that we've traditionally had it there, but IMHO moving in the direction of treating them as separate objects is much more clear and an altogether better approach. I think there's a usability argument in addition to just plain we always did it that way. But anyway, this patch has now officially been discussed to death. 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] REVIEW: ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED
Simon Riggs si...@2ndquadrant.com writes: On Sun, 2011-01-23 at 20:33 +0200, Marko Tiikkaja wrote: \d table now only shows that there's a FOREIGN KEY, which might lead the user to think that there should not be any values that don't exist in the referenced table. Neither \d nor \di shows invalid indexes. Even if that were true, it's a poor analogy, since a disabled foreign key has visible *semantic* impact, whereas a disabled index doesn't. 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] REVIEW: ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED
On Sun, 2011-01-23 at 14:45 -0500, Tom Lane wrote: Simon Riggs si...@2ndquadrant.com writes: On Sun, 2011-01-23 at 20:33 +0200, Marko Tiikkaja wrote: \d table now only shows that there's a FOREIGN KEY, which might lead the user to think that there should not be any values that don't exist in the referenced table. Neither \d nor \di shows invalid indexes. Even if that were true, it's a poor analogy, since a disabled foreign key has visible *semantic* impact, whereas a disabled index doesn't. Sure. My agreement to add something appears to have crossed with your comments. I'd appreciate you reviewing the parser aspects of the patch. $TITLE no longer reflects the syntax. -- Simon Riggs http://www.2ndQuadrant.com/books/ PostgreSQL Development, 24x7 Support, Training and Services -- 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] Bug in pg_describe_object, patch v2
Tom Lane t...@sss.pgh.pa.us writes: But anyway, this patch has now officially been discussed to death. +1 :) Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- 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] ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED
On Tue, 2010-12-14 at 11:24 -0500, Chris Browne wrote: t...@sss.pgh.pa.us (Tom Lane) writes: Robert Haas robertmh...@gmail.com writes: ... On the other hand, there's clearly also a use case for this behavior. If a bulk load of prevalidated data forces an expensive revalidation of constraints that are already known to hold, there's a real chance the DBA will be backed into a corner where he simply has no choice but to not use foreign keys, even though he might really want to validate the foreign-key relationships on a going-forward basis. There may well be a case to be made for doing this on grounds of practical usefulness. I'm just voicing extreme skepticism that it can be supported by reference to the standard. Personally I'd prefer to see us look into whether we couldn't arrange for low-impact establishment of a verified FK relationship, analogous to CREATE INDEX CONCURRENTLY. We don't let people just arbitrarily claim that a uniqueness condition exists, and ISTM that if we can handle that case we probably ought to be able to handle FK checking similarly. I can point to a use case that has proven useful... Slony-I deactivates indices during the subscription process, because it is enormously more efficient to load the data into the tables sans-indices, and then re-index afterwards. The same would apply for FK constraints. I observe that the deactivation of indices is the sole remaining feature in Slony-I that still requires catalog access in a corruptive sense. (With the caveat that this corruption is now only a temporary one; the indexes are returned into play before the subscription process finishes.) That would be eliminated by adding in: ALTER TABLE ... DISABLE INDEX ... ALTER TABLE ... ENABLE INDEX ... For similar to apply to FK constraints would involve similar logic. I just wanted to point out that the patch submitted here does not allow what is requested here for FKs (nor indexes). You can add an FK without an initial check, but the FK is enforced for all further DML changes. You can then later validate the FK. So that running these commands ALTER TABLE foo ADD FOREIGN KEY ... NOT VALID; ALTER TABLE foo VALIDATE CONSTRAINT ...; is roughly equivalent to the concept of ALTER TABLE foo ADD FOREIGN KEY ... CONCURRENTLY; There is no command that makes the FK NOT ENFORCED, so you can't turn it off then back on again as was requested above. -- Simon Riggs http://www.2ndQuadrant.com/books/ PostgreSQL Development, 24x7 Support, Training and Services -- 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] ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED
Simon Riggs si...@2ndquadrant.com writes: You can add an FK without an initial check, but the FK is enforced for all further DML changes. I seem to recall pointing out upthread that the FK check triggers are designed on the assumption that the constraint does hold currently. Has any analysis been done on exactly how badly they'll fail when it doesn't hold? I remain unconvinced that this behavior is desirable. 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] pg_dump directory archive format / parallel pg_dump
On 21.01.2011 19:11, Euler Taveira de Oliveira wrote: Em 21-01-2011 12:47, Andrew Dunstan escreveu: Maybe we could change the hint to say --file=DESTINATION or --file=FILENAME|DIRNAME ? ... --file=OUTPUT or --file=OUTPUTNAME. Ok, works for me. I've committed this patch now, with a whole bunch of further fixes. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- 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] Bug in pg_describe_object, patch v2
2011/1/23 Dimitri Fontaine dimi...@2ndquadrant.fr: Tom Lane t...@sss.pgh.pa.us writes: But anyway, this patch has now officially been discussed to death. +1 :) +∞ :) In the aftermath, I realized I was almost about to feel a bit ashamed about the fact my original forum post probably gave birth to the most long lived discussion in the history of PostgreSQL. Having realized this, I realized a secondly even more important fact, namely the importance of details, making the whole difference between a sloppy software project and a highly successful project with the ambition of achieving perfection in every little detail. I'm proud we can conclude ProstgreSQL is apparently a project of the second category. -- Best regards, Joel Jacobson Glue Finance -- 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] One Role, Two Passwords
On Thu, Jan 20, 2011 at 6:19 PM, Stephen Frost sfr...@snowman.net wrote: Errr, well, ok, this is curious. gis= alter user sfrost set role gis; ALTER ROLE gis= ^D\q beren:/home/sfrost psql --cluster 8.4/main -d gis psql (8.4.5) Type help for help. gis= show role; role -- gis So far, I think this does exactly what you think it would... This is how I think a mostly-transparent one-role-two-password (ish) system would look like using this property, using a group, as Tom suggested: -- Note: This role does not have LOGIN set CREATE ROLE public_facing_name; -- The first set of credentials CREATE ROLE first_arbitrary_name IN ROLE public_facing_name LOGIN PASSWORD 'first_secret'; ALTER ROLE first_arbitrary_name SET ROLE public_facing_name; -- The second set of credentials CREATE ROLE second_arbitrary_string IN ROLE public_facing_neme LOGIN PASSWORD 'second_secret'; ALTER ROLE second_arbitrary_name SET ROLE public_facing_name; When one logs in as one_arbitrary_name or second_arbitrary_name, all CREATE statements -- and indeed, all privilege checks -- will take place against public_facing_name. No objects should ever get created under the roles first_arbitrary_name or second_arbitrary_name, and no ownership ever assigned to them, unless the client runs SET ROLE to un-do what was done. This would be annoying (when dropping sets of credentials, or when ownership-specific privileges apply to one set of credentials but not the other) but may not occur much at large. Thoughts? -- fdr -- 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] ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED
On Sun, 2011-01-23 at 16:13 -0500, Tom Lane wrote: Simon Riggs si...@2ndquadrant.com writes: You can add an FK without an initial check, but the FK is enforced for all further DML changes. I seem to recall pointing out upthread that the FK check triggers are designed on the assumption that the constraint does hold currently. Has any analysis been done on exactly how badly they'll fail when it doesn't hold? I remain unconvinced that this behavior is desirable. If you mean RESTRICT relationships, then yes. I haven't foreseen other problems myself. What other ideas or risks would you like me to confirm or deny for you? -- Simon Riggs http://www.2ndQuadrant.com/books/ PostgreSQL Development, 24x7 Support, Training and Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] wildcard search support for pg_trgm
Hi, I tested the patch from http://archives.postgresql.org/message-id/aanlktikvxx6_ajzb52ona7mbzijcpdqszomcd-3u1...@mail.gmail.com which adds GIN and GIST index support for wildcard LIKE queries using pg_trgm. The patch is a context diff that applies cleanly. Regression test work after applying it, but they only exercise the similarity() function, so the new functionality is not covered by them. The patch seems to work as advised, I tried a few searches and it does indeed use the gin or gist index to implement '%foo%' searches. I tried to do some tricky queries and it worked for all of them.. I see two issues with this patch. First of them is the resulting index size. I created a table with 5 copies of /usr/share/dict/american-english in it and a gin index on it, using gin_trgm_ops. The results were: * relation size: 18MB * index size: 109 MB while without the patch the GIN index was 43 MB. I'm not really sure *why* this happens, as it's not obvious from reading the patch what exactly is this extra data that gets stored in the index, making it more than double its size. That leads me to the second issue. The pg_trgm code is already woefully uncommented, and after spending quite some time reading it back and forth I have to admit that I don't really understand what the code does in the first place, and so I don't understand what does that patch change. I read all the changes in detail and I could't find any obvious mistakes like reading over array boundaries or dereferencing uninitialized pointers, but I can't tell if the patch is correct semantically. All test cases I threw at it work, though. I'm not sure if the committer with better knowledge of pg_trgm would be able to do a better job than me. After a few days digging in that code I simply give up. This patch changes the names and signatures of some support functions for GIN, and I'm not sure how that affects binary compatibility and pg_upgrade. I tried to create an index with the vanilla source, and then recompile pg_trgm and reindex the table, but it still was not using the index. I think it's because it's missing entries in the catalogs about the index supporting the like strategy. How should this be handled? I'm going to mark the patch as Waiting on Author, because of the index size issue (though it might be OK and expected that the index size will grow so much, I just don't know). As for the comments, or lack of them, I declary myself incompetent to thoroughly verify that the patch works. I think it should have at least the added parts commented enough to match the project's standard. Sorry for taking so long to review this, Cheers, Jan -- 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] Bug in pg_describe_object, patch v2
On Sun, Jan 23, 2011 at 4:24 PM, Joel Jacobson j...@gluefinance.com wrote: In the aftermath, I realized I was almost about to feel a bit ashamed about the fact my original forum post probably gave birth to the most long lived discussion in the history of PostgreSQL. I think you'd need another order of magnitude to achieve that exalted position. :-) -- 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
[HACKERS] Bug? Unexpected argument handling in pl-python variadic argument function
Unexpected argument handling in pl/python variadic argument function
create or replace function variadic_sql
(template text, variadic args text[], out text)
language sql as
$$
select $1 || ' -- ' || $2::text
$$;
create or replace function variadic_python
(template text, variadic args text[], out text)
language plpythonu as
$$
return template + ' -- ' + str(args)
$$;
-- expected
select variadic_sql('html{foo}{bar}/html', '1', '2');
variadic_sql
html{foo}{bar}/html -- {1,2}
-- first scalar arg also in the variadic args
select variadic_python('html{foo}{bar}/html', '1', '2');
variadic_python
--
html{foo}{bar}/html -- ['html{foo}{bar}/html', ['1', '2']]
select version();
PostgreSQL 9.0.1 on i686-pc-linux-gnu, compiled by GCC
i686-pc-linux-gnu-gcc (Gentoo 4.4.2 p1.0) 4.4.2, 32-bit
(1 row)
I could not find very much documentation and only this on the lists:
from Jan Urbański on his planned improvements for pl/python:
http://archives.postgresql.org/pgsql-hackers/2010-12/msg00551.php
* variadic argument handling (is this possible for a non-plpgsql pl?)
Does this mean this is already a recognized flaw or it was unknown at
the time if the feature was implemented? I would definitely would not
expect the argument to duplicated. I know there is big patch for
pl/python being reviewed right now. Perhaps this is being fixed? It
would be wonderful for plpython to support complex arguments
gracefully.
--
Thanks,
Nate Carson
--
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] ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED
Tom Lane wrote: I seem to recall pointing out upthread that the FK check triggers are designed on the assumption that the constraint does hold currently. Has any analysis been done on exactly how badly they'll fail when it doesn't hold? I remain unconvinced that this behavior is desirable. I saw your upstream comment, and it took a quick look at it. On the face of it, I couldn't see where checking that the parent exists on the insert of a child would be broken by the existence of other orphan children, nor could I see where checking for the absence of children on the delete of a parent would be broken by orphan children not related to the parent. With other things on my plate I didn't have time to do a rigorous check, but it was enough to make me wonder what you think depends on existing consistency or what could break. Even a vague hint of what sort of thing you think might go wrong might help people find problem code, if it actually exists. Now, I understand that a broken index, like one based on a function declared immutable which really isn't, could cause problems, but that seems orthogonal. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] add __attribute__((noreturn)) to suppress a waring
I found the following warning with Fedora 14 / gcc 4.5.1. pg_backup_archiver.c: In function ‘_discoverArchiveFormat’: pg_backup_archiver.c:1736:11: warning: ‘fh’ may be used uninitialized in this function To suppress it, I'm thinking to add noreturn to die_horribly(). Any objections? Another solution might be adding a dummy assignment after calls of die_horribly(). -- Itagaki Takahiro noreturn.diff 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] SSI, simplified
Dan is still beating up on the latest patch with DBT-2, but I expect that I'll be posting a patch tomorrow with all known issues fixed, no known bugs, and reasonable performance -- except for the issue of how this work relates to hot standby in the 9.1 release. (We did find and fix a few bugs after V13, although most of our changes have been tweaking comments, and the bug fixes have mostly consisted of moving LW lock statements up or down a few lines.) If I get a solid answer on the SSI/HS issue before I post V14, I might be able to cover that, too, in that patch. I haven't wanted to totally write off the possibility of integrating them as long as discussion was ongoing; but if someone wants to assume the voice of Dr. McCoy and declare It's dead, Jim, I can move on for now and come back to the issue for 9.2. In the mean time, I've been pondering the fact that many of those posting on SSI issues apparently haven't read even the Overview section of the Wiki page. http://wiki.postgresql.org/wiki/Serializable I know how busy people are, so (inspired by the both the Geico commercial which they boast was put together on the xtranormal sight in 15 minutes or less, and the old favorite book Einstein Simplified) I've put together an animated movie which punches a few key points from the overview in less than three minutes. Hopefully, what it lacks in detail it makes up for with brevity and humor. Oddly, the computer generated voice sorta mangled something near the beginning, which was supposed to be I'm psyched, but sorta sounds like I'm sorry. Computers -- you just can't rely on 'em. I hope people find it entertaining and at least slightly informative. :-) http://www.xtranormal.com/watch/8285377/?listid=20642536 I could have just kept on going, but I decided at the start that it had to be less than three minutes. Also, please make allowances for the fact that while I went over 15 minutes putting that movie together, it wasn't by all that much -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] sepgsql contrib module
2011/1/21 KaiGai Kohei kai...@ak.jp.nec.com: The attached patch is a revised version. I've committed this. Cleanup coming... -- 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
[HACKERS] patch: Add PGXS support to hstore's Makefile (trivial)
I discovered today that hstore's Makefile currently does not support PGXS; namely, the ability to install it like so: USE_PGXS=1 make sudo USE_PGXS=1 make install Moreover, hstore is the *only* contrib module whose Makefile does not contain PGXS. The attached patch changes hstore's Makefile so it is like the others. I have tested the above commands on a copy of the hstore directory located outside of the PostgreSQL source tree, and it appears to work just fine. I also tested conventional make and make install, and it still appears to work as well. Joey Adams commit a7384288531ba9a235292836d6ee1e17a65a3997 Author: Joey Adams joeyadams3.14...@gmail.com Date: Sun Jan 23 21:05:03 2011 -0500 Added PGXS support to contrib/hstore/Makefile diff --git a/contrib/hstore/Makefile b/contrib/hstore/Makefile index e466b6f..1d533fd 100644 --- a/contrib/hstore/Makefile +++ b/contrib/hstore/Makefile @@ -1,9 +1,5 @@ # contrib/hstore/Makefile -subdir = contrib/hstore -top_builddir = ../.. -include $(top_builddir)/src/Makefile.global - MODULE_big = hstore OBJS = hstore_io.o hstore_op.o hstore_gist.o hstore_gin.o hstore_compat.o \ crc32.o @@ -12,4 +8,13 @@ DATA_built = hstore.sql DATA = uninstall_hstore.sql REGRESS = hstore +ifdef USE_PGXS +PG_CONFIG = pg_config +PGXS := $(shell $(PG_CONFIG) --pgxs) +include $(PGXS) +else +subdir = contrib/hstore +top_builddir = ../.. +include $(top_builddir)/src/Makefile.global include $(top_srcdir)/contrib/contrib-global.mk +endif -- 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] REVIEW: WIP: plpgsql - foreach in
Pavel,
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
I merge your changes and little enhanced comments.
Thanks. Reviewing this further-
Why are you using 'FOREACH' here instead of just making it another
variation of 'FOR'? What is 'FOUND' set to following this? I realize
that might make the code easier, but it really doesn't seem to make much
sense to me from a usability point of view.
There also appears to be some extra whitespace changes that aren't
necessary and a number of places where you don't follow the indentation
conventions (eg: variable definitions in exec_stmt_foreach_a()).
I'm still not really thrilled with how the checking for scalar vs.
array, etc, is handled. Additionally, what is this? :
else if (stmt-row != NULL)
{
ctrl_var = estate-datums[stmt-row-dno];
}
else
{
ctrl_var = estate-datums[stmt-rec-dno];
}
Other comments- I don't like using 'i' and 'j', you really should use
better variable names, especially in large loops which contain other
loops. I'd also suggest changing the outer loop to be equivilant to the
number of iterations that will be done instead of the number of items
and then to *not* update 'i' inside the inner-loop. That structure is
really just confusing, imv (I certainly didn't entirely follow what was
happening there the first time I read it). Isn't there a function you
could use to pull out the array slice you need on each iteration through
the array?
Thanks,
Stephen
signature.asc
Description: Digital signature
Re: [HACKERS] sepgsql contrib module
On Sun, Jan 23, 2011 at 8:53 PM, Robert Haas robertmh...@gmail.com wrote: 2011/1/21 KaiGai Kohei kai...@ak.jp.nec.com: The attached patch is a revised version. I've committed this. Cleanup coming... Yikes. On further examination, exec_object_restorecon() is pretty bogus. Surely you need some calls to quote_literal_cstr() in there someplace. And how about using getObjectDescriptionOids() for the error message, instead of the entirely bogus construction that's there now? -- 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
[HACKERS] Re: 答复: [HACKERS] Is there a way to build PostgreSQL client libraries with MinGW
Here is my plan, 1. To make the configurate script pass: Currently MinGW does not provide chmod, but on Windows I think this can be ignored now, we all use Admin users to do the work. 2. To make a pg-client Makefile target, can you help wich which c files should be compiled and linked into dlls and lib file. Xiaobo Gu 2011/1/23 XiaoboGu guxiaobo1...@gmail.com: Hi I am not so familiar with the PostgreSQL development team, but using a MinGW compatible client side is important to us, so I'd like to start doing it myself if any of you experts can help. Cheers Xiaobo Gu -邮件原件- 发件人: Andrew Dunstan [mailto:and...@dunslane.net] 发送时间: 2011年1月21日 23:25 收件人: Magnus Hagander 抄送: Robert Haas; XiaoboGu; pgsql-hackers@postgresql.org 主题: Re: [HACKERS] Is there a way to build PostgreSQL client libraries with MinGW On 01/21/2011 05:24 AM, Magnus Hagander wrote: That advice needs to be taken with a grain or two of salt. First, while you probably should not use Cygwin postgres as a production server, it is still the best way to run psql on Windows that I know of. And second, the stuff Yeah, I agree for psql the client tool (though it used to suck badly if you were in a non-english locale, but they may have fixed that). But not for PostgreSQL the full product. I guess we could add a sentence about the client side, but it needs to be clear that the non-sucky part only applies to the client. It's not so bad it can't be used for development, and I have known people who do that, and indeed I have deployed one very complex app developed in just that way. More importantly from my POV, there is no support in the buildfarm for just building the client side, and I have no intention of providing it. So it's not insignificant for us to be able to continue supporting a complete build on Cygwin, however much you dislike it. about not being able to generate 64-bit binaries with Mingw is no longer true (that's why it's no longer called Mingw32), although it is true that nobody I know has yet tried to do so. It's on my long TODO list, and well worth doing. (Relying on one compiler is the techno equivalent of monolingualism, which my sister's bumper sticker used to tell me is a curable condition.) It's true from the perspective of *postgresql* - you can't use those compiler to generate 64-bit binaries of PostgreSQL. And it's referring to these builds, not the compiler itself. And I'm certainly not going to stand in the way of somebody adding build support for it if they (you or others) want to spend time on it - that patch should just include an update to that documentation paragraph, of course. Personally, I'm going to put what time I can put into windows build system updates into making us work with VS 2010 because I find that more important - but that's just me personally. VS2010 is important, no doubt. But clearly there's some demand for continued Mingw support, hence the OP's question. As I've remarked before, I think we should support as many build platforms/environments as we can. cheers andrew -- 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] Is there a way to build PostgreSQL client libraries with MinGW
On 01/23/2011 10:09 PM, Xiaobo Gu wrote: Here is my plan, 1. To make the configurate script pass: Currently MinGW does not provide chmod, but on Windows I think this can be ignored now, we all use Admin users to do the work. 2. To make a pg-client Makefile target, can you help wich which c files should be compiled and linked into dlls and lib file. Why do you need to do this? Postgres can be built as is today on Mingw. Not just the client libraries, the whole server too. It does not need to be an Adminstrative user, and you should by no means assume that the user building Postgres will be an administrator, nor that the user running Postgres will be. My 32 bit Mingw certainly understands chmod. There are machines doing this every day, several times a day. See http://www.pgbuildfarm.org/cgi-bin/show_status.pl - frogmouth and narwhal are examples. We've had working Mingw builds for quite a few years now. The only issue is building 64bit binaries. So get the build working for 32bit, then try switching to the 64bit compiler and see what breaks. If all you need is the client library, build with no zlib or any other third party libraries. cheers andrew -- 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] sepgsql contrib module
On Sun, Jan 23, 2011 at 9:56 PM, Robert Haas robertmh...@gmail.com wrote: On Sun, Jan 23, 2011 at 8:53 PM, Robert Haas robertmh...@gmail.com wrote: 2011/1/21 KaiGai Kohei kai...@ak.jp.nec.com: The attached patch is a revised version. I've committed this. Cleanup coming... Yikes. On further examination, exec_object_restorecon() is pretty bogus. Surely you need some calls to quote_literal_cstr() in there someplace. And how about using getObjectDescriptionOids() for the error message, instead of the entirely bogus construction that's there now? Also, shouldn't a bunch of these messages end in : %m? -- 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] REVIEW: WIP: plpgsql - foreach in
On Sun, Jan 23, 2011 at 9:49 PM, Stephen Frost sfr...@snowman.net wrote: Pavel, * Pavel Stehule (pavel.steh...@gmail.com) wrote: I merge your changes and little enhanced comments. Thanks. Reviewing this further- Why are you using 'FOREACH' here instead of just making it another variation of 'FOR'? Uh oh. You just reopened the can of worms from hell. -- 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] REVIEW: WIP: plpgsql - foreach in
* Robert Haas (robertmh...@gmail.com) wrote: On Sun, Jan 23, 2011 at 9:49 PM, Stephen Frost sfr...@snowman.net wrote: Why are you using 'FOREACH' here instead of just making it another variation of 'FOR'? Uh oh. You just reopened the can of worms from hell. hahahaha. Apparently I missed that discussion; also wasn't linked off the patch. :/ Guess I'll go poke through the archives... Struck me as obviously wrong to invent something completely new for this, but.. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] REVIEW: WIP: plpgsql - foreach in
* Robert Haas (robertmh...@gmail.com) wrote: Uh oh. You just reopened the can of worms from hell. Alright.. I'm missing what happened to this suggestion of using: FOR var in ARRAY array_expression ... I like that a lot more than inventing a new top-level keyword, for the same reasons that Tom mentioned: using a different initial keyword makes it awkward to make generic statements about all types of FOR loop (as I noticed while looking through the documentation changes that should be made for this); and also some of the other comments about how FOREACH doesn't give you any clue that this is some array-specific-FOR-loop-thingy. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] patch: Add PGXS support to hstore's Makefile (trivial)
On Sun, Jan 23, 2011 at 9:20 PM, Joseph Adams joeyadams3.14...@gmail.com wrote: The attached patch changes hstore's Makefile so it is like the others. Thanks, committed. -- 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] Is there a way to build PostgreSQL client libraries with MinGW
Yes, I want it working on 64 bit Windows Server 2003 R2 and 64 bit Windows 7 home basic. Which version of 32bit MinGW do you use, I use the one shipped with Rtools212.exe which is downloaded from http://www.murdoch-sutherland.com/Rtools, and there is no chmod. xiaobo gu 2011/1/24 Andrew Dunstan and...@dunslane.net: On 01/23/2011 10:09 PM, Xiaobo Gu wrote: Here is my plan, 1. To make the configurate script pass: Currently MinGW does not provide chmod, but on Windows I think this can be ignored now, we all use Admin users to do the work. 2. To make a pg-client Makefile target, can you help wich which c files should be compiled and linked into dlls and lib file. Why do you need to do this? Postgres can be built as is today on Mingw. Not just the client libraries, the whole server too. It does not need to be an Adminstrative user, and you should by no means assume that the user building Postgres will be an administrator, nor that the user running Postgres will be. My 32 bit Mingw certainly understands chmod. There are machines doing this every day, several times a day. See http://www.pgbuildfarm.org/cgi-bin/show_status.pl - frogmouth and narwhal are examples. We've had working Mingw builds for quite a few years now. The only issue is building 64bit binaries. So get the build working for 32bit, then try switching to the 64bit compiler and see what breaks. If all you need is the client library, build with no zlib or any other third party libraries. cheers andrew -- 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] ALTER TYPE 2: skip already-provable no-work rewrites
On Sun, Jan 23, 2011 at 12:06 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Sun, Jan 9, 2011 at 5:01 PM, Noah Misch n...@leadboat.com wrote: As unintended fallout, it's no longer an error to add oids or a column with a default value to a table whose rowtype is used in columns elsewhere. This seems best. Defaults on the origin table do not even apply to new inserts into such a column, and the rowtype does not gain an OID column via its table. I think this should be split into two patches (we can discuss both on this thread, no need to start any new ones), one that implements just the above improvement and another that accomplishes the main purpose of the patch. I haven't been paying much attention to this thread, but I happened to read the above, and quite frankly it scares the cr*p out of me. I don't believe that Noah even begins to be qualified to understand the implications of adding/removing an OID column, and I clearly remember the non-obvious bugs we've had in the past from that. Before this goes in I want to see a convincing explanation (not an unsupported assertion) why this isn't going to re-introduce those old bugs. Because all of our old bugs now have regression tests that will break if we reintroduce them? I guess that probably falls into the category of wishful thinking. I'm also pretty unclear on why it's a good idea to let uses of a rowtype be different from the table on which it's allegedly based. To the extent that the current behavior allows that, isn't that a bug rather than a feature we should extend? It's not clear to me what it would mean for OIDs or default values to propagate themselves to the table's row type. Check constraints, foreign keys, unique constraints, etc. don't either. In fact, not even the NOT NULL property flows through. On the surface, preventing these details from interfering with ALTER TABLE commands that can't actually break anything seems like removing an annoying implementation restriction, but I guess one could make the argument that we actually intend to make those flow through some day. But if so, this is the first I'm hearing of it. # The fact that ALTER TYPE requires rewriting the whole table is sometimes an advantage, because the rewriting process # eliminates any dead space in the table. I'm not sure what we can recommend here instead. New-style VACUUM FULL. I don't think that a patch that makes it harder to use ALTER TABLE this way is a problem in itself, now that we've got that. Cool. That'll reclaim space from dropped columns and stuff? -- 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] REVIEW: PL/Python table functions
2011/1/23 Jan Urbański wulc...@wulczer.org:
On 22/01/11 11:15, Hitoshi Harada wrote:
This is a review for
https://commitfest.postgresql.org/action/patch_view?id=460
Thanks,
One issue is typmod of record type.
regression=# create or replace function func1(t text) returns record
as $$ return {'name': t, 'value': 0} $$ language plpythonu;
regression=# select * from func1('jan') as (name text, value bigint);
name | value
--+---
jan | 0
(1 row)
regression=# select * from func1('jan') as (name text, value int);
ERROR: function return row and query-specified return row do not match
DETAIL: Returned type bigint at ordinal position 2, but query expects
integer.
That's a bug, thanks for spotting it.
It seems that typmod of PLyTypeInfo is not updated over statements
within the session. I saw the error doesn't occur when I re-connect to
the backend after the error.
I tracked it down to caching the I/O functions for the return type. Your
example shows that you can't just discover the output record type once,
but you have to recheck whether the returned record's structure has not
changed between calls.
I implemented it by looping over the attributes of the output record and
checking if type for which we have already cached the I/O function is
binary coercible to the type that's actually in the record. This allows
the code to skip recaching the functions in the common case when the
record stays the same, and fixes the bug you found.
Attached is a new patch for table function support and an incremental
patch with the change I did. The new patch for table functions does not
apply to HEAD, it's a refinement of the previous table-functions patch.
After the refactor patches are all applied or rejected, I'll post a
frech patch that applies cleanly to HEAD.
I tested the new incremental patch and the previous example works
fine. I don't know if this can be handled properly but another example
is:
regression=# create function func1(t text) returns record as $$ return
{'name':t, 'value':0}; $$ language plpythonu ;
CREATE FUNCTION
regression=# select * from func1('jan') as (name text, value bigint);
name | value
--+---
jan | 0
(1 row)
regression=# select * from func1('jan') as (value text, name bigint);
value | name
---+--
jan |0
(1 row)
where value and name don't point to the correct data. Your
data-type-check logic might not be enough.
Regards,
--
Hitoshi Harada
--
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] ALTER TYPE 2: skip already-provable no-work rewrites
On Sun, Jan 23, 2011 at 12:06:43PM -0500, Tom Lane wrote: Robert Haas robertmh...@gmail.com writes: On Sun, Jan 9, 2011 at 5:01 PM, Noah Misch n...@leadboat.com wrote: As unintended fallout, it's no longer an error to add oids or a column with a default value to a table whose rowtype is used in columns elsewhere. This seems best. Defaults on the origin table do not even apply to new inserts into such a column, and the rowtype does not gain an OID column via its table. I think this should be split into two patches (we can discuss both on this thread, no need to start any new ones), one that implements just the above improvement and another that accomplishes the main purpose of the patch. I haven't been paying much attention to this thread, but I happened to read the above, and quite frankly it scares the cr*p out of me. I don't believe that Noah even begins to be qualified to understand the implications of adding/removing an OID column, and I clearly remember the non-obvious bugs we've had in the past from that. Before this goes in I want to see a convincing explanation (not an unsupported assertion) why this isn't going to re-introduce those old bugs. Turns out that we do set HEAP_HASOID and allocate space for an OID in the composite-type datums. We don't actually assign an OID, and I can't see any way to read it from the composite. It seems most consistent with the verdict of commit 6d1e361 to continue rejecting these cases. Thanks for the heads-up. I'm also pretty unclear on why it's a good idea to let uses of a rowtype be different from the table on which it's allegedly based. To the extent that the current behavior allows that, isn't that a bug rather than a feature we should extend? From the perspective of defining the behavior afresh, I'd agree. I haven't seen any stirrings of actually implementing this, though. Like Robert, I'm doubting there's a user benefit from rejecting these cases in preparation for the day that they would actually require it. nm -- 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] Is there a way to build PostgreSQL client libraries with MinGW
Hi, I download the lastest 32bit MinGW from sourceforge, and found there are *NIX like tools such as chmod and ls in the MinGW\msys\1.0\bin directory. But the make process does not success, This test is done on my 32bit Windows XP SP3 Here are the messages: D:\devproj\postgresql-9.0.2sh configure --without-zlib .. D:\devproj\postgresql-9.0.2ls 2011-01-24 13:14DIR . 2011-01-24 13:14DIR .. 2010-12-14 10:55 233 .gitignore 2010-12-14 10:55 445 aclocal.m4 2011-01-24 11:12DIR config 2011-01-24 13:14 478,602 config.log 2011-01-24 13:1436,977 config.status 2010-12-14 10:55 844,733 configure 2010-12-14 10:5560,877 configure.in 2011-01-24 12:06 840,095 configure.lineno 2011-01-24 11:12DIR contrib 2010-12-14 10:55 1,192 COPYRIGHT 2011-01-24 11:12DIR doc 2011-01-24 13:14 3,760 GNUmakefile 2010-12-14 10:55 3,760 GNUmakefile.in 2010-12-14 11:21 968,292 HISTORY 2010-12-14 11:2179,024 INSTALL 2010-12-14 10:55 1,477 Makefile 2010-12-14 10:55 1,287 README 2011-01-24 13:14DIR src D:\devproj\postgresql-9.0.2make make -C src all make[1]: Entering directory `/d/devproj/postgresql-9.0.2/src' make -C port all make[2]: Entering directory `/d/devproj/postgresql-9.0.2/src/port' gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -I../../src/port -DFRONTEND -I../.. /src/include -I./src/include/port/win32 -DEXEC_BACKEND -I../../src/include/por t/win32 -c -o fseeko.o fseeko.c gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -I../../src/port -DFRONTEND -I../.. /src/include -I./src/include/port/win32 -DEXEC_BACKEND -I../../src/include/por t/win32 -c -o crypt.o crypt.c In file included from ../../src/include/pg_config_os.h:22, from ../../src/include/c.h:90, from crypt.c:44: /usr/lib/gcc/i686-pc-msys/3.4.4/../../../../include/w32api/winsock2.h:103:2: war ning: #warning fd_set and associated macros have been defined in sys/types. This may cause runtime problems with W32 sockets In file included from ../../src/include/c.h:90, from crypt.c:44: ../../src/include/pg_config_os.h:28:20: direct.h: No such file or directory ../../src/include/pg_config_os.h:90:1: warning: EIDRM redefined In file included from /usr/include/errno.h:1, from ../../src/include/c.h:80, from crypt.c:44: /usr/include/sys/errno.h:64:1: warning: this is the location of the previous def inition In file included from ../../src/include/c.h:90, from crypt.c:44: ../../src/include/pg_config_os.h:165:1: warning: SIGABRT redefined In file included from /usr/include/signal.h:8, from ../../src/include/pg_config_os.h:26, from ../../src/include/c.h:90, from crypt.c:44: /usr/include/sys/signal.h:225:1: warning: this is the location of the previous d efinition In file included from ../../src/include/c.h:90, from crypt.c:44: ../../src/include/pg_config_os.h:222: error: conflicting types for 'uid_t' /usr/include/sys/types.h:133: error: previous declaration of 'uid_t' was here ../../src/include/pg_config_os.h:223: error: conflicting types for 'gid_t' /usr/include/sys/types.h:134: error: previous declaration of 'gid_t' was here In file included from ../../src/include/c.h:90, from crypt.c:44: ../../src/include/pg_config_os.h:251:1: warning: EMSGSIZE redefined In file included from /usr/include/errno.h:1, from ../../src/include/c.h:80, from crypt.c:44: /usr/include/sys/errno.h:132:1: warning: this is the location of the previous de finition In file included from ../../src/include/c.h:90, from crypt.c:44: ../../src/include/pg_config_os.h:252:1: warning: EAFNOSUPPORT redefined In file included from /usr/include/errno.h:1, from ../../src/include/c.h:80, from crypt.c:44: /usr/include/sys/errno.h:116:1: warning: this is the location of the previous de finition In file included from ../../src/include/c.h:90, from crypt.c:44: ../../src/include/pg_config_os.h:253:1: warning: EWOULDBLOCK redefined In file included from /usr/include/errno.h:1, from ../../src/include/c.h:80, from crypt.c:44: /usr/include/sys/errno.h:150:1: warning: this is the location of the previous de finition In file included from ../../src/include/c.h:90, from crypt.c:44: ../../src/include/pg_config_os.h:254:1: warning: ECONNRESET redefined In file included from /usr/include/errno.h:1, from ../../src/include/c.h:80, from crypt.c:44:
Re: [HACKERS] Is there a way to build PostgreSQL client libraries with MinGW
And there are two versions of gcc installed on my WinXP PRO SP3, 3.4.4 is the one used to the above test D:\devproj\postgresql-9.0.2gcc -v Reading specs from /usr/lib/gcc/i686-pc-msys/3.4.4/specs Configured with: /home/cstrauss/build/gcc3/gcc-3.4.4/configure --prefix=/usr --s ysconfdir=/etc --localstatedir=/var --infodir=/share/info --mandir=/share/man -- libexecdir=/lib --enable-languages=c,c++ --disable-nls --enable-threads=posix -- enable-sjlj-exceptions --enable-hash-synchronization --enable-libstdcxx-debug -- with-newlib Thread model: posix gcc version 3.4.4 (msys special) D:\devproj\postgresql-9.0.2 D:\Amber\Program\Rtools211\MinGW\bingcc -v Using built-in specs. COLLECT_GCC=gcc Target: mingw32 Configured with: ../gcc-4.5.0/configure --enable-languages=c,c++,ada,fortran,obj c,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgo mp --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-r untime-libs --disable-werror --build=mingw32 --prefix=/mingw Thread model: win32 gcc version 4.5.0 (GCC) D:\Amber\Program\Rtools211\MinGW\bin On Mon, Jan 24, 2011 at 1:17 PM, Xiaobo Gu guxiaobo1...@gmail.com wrote: Hi, I download the lastest 32bit MinGW from sourceforge, and found there are *NIX like tools such as chmod and ls in the MinGW\msys\1.0\bin directory. But the make process does not success, This test is done on my 32bit Windows XP SP3 Here are the messages: D:\devproj\postgresql-9.0.2sh configure --without-zlib .. D:\devproj\postgresql-9.0.2ls 2011-01-24 13:14 DIR . 2011-01-24 13:14 DIR .. 2010-12-14 10:55 233 .gitignore 2010-12-14 10:55 445 aclocal.m4 2011-01-24 11:12 DIR config 2011-01-24 13:14 478,602 config.log 2011-01-24 13:14 36,977 config.status 2010-12-14 10:55 844,733 configure 2010-12-14 10:55 60,877 configure.in 2011-01-24 12:06 840,095 configure.lineno 2011-01-24 11:12 DIR contrib 2010-12-14 10:55 1,192 COPYRIGHT 2011-01-24 11:12 DIR doc 2011-01-24 13:14 3,760 GNUmakefile 2010-12-14 10:55 3,760 GNUmakefile.in 2010-12-14 11:21 968,292 HISTORY 2010-12-14 11:21 79,024 INSTALL 2010-12-14 10:55 1,477 Makefile 2010-12-14 10:55 1,287 README 2011-01-24 13:14 DIR src D:\devproj\postgresql-9.0.2make make -C src all make[1]: Entering directory `/d/devproj/postgresql-9.0.2/src' make -C port all make[2]: Entering directory `/d/devproj/postgresql-9.0.2/src/port' gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -I../../src/port -DFRONTEND -I../.. /src/include -I./src/include/port/win32 -DEXEC_BACKEND -I../../src/include/por t/win32 -c -o fseeko.o fseeko.c gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -I../../src/port -DFRONTEND -I../.. /src/include -I./src/include/port/win32 -DEXEC_BACKEND -I../../src/include/por t/win32 -c -o crypt.o crypt.c In file included from ../../src/include/pg_config_os.h:22, from ../../src/include/c.h:90, from crypt.c:44: /usr/lib/gcc/i686-pc-msys/3.4.4/../../../../include/w32api/winsock2.h:103:2: war ning: #warning fd_set and associated macros have been defined in sys/types. This may cause runtime problems with W32 sockets In file included from ../../src/include/c.h:90, from crypt.c:44: ../../src/include/pg_config_os.h:28:20: direct.h: No such file or directory ../../src/include/pg_config_os.h:90:1: warning: EIDRM redefined In file included from /usr/include/errno.h:1, from ../../src/include/c.h:80, from crypt.c:44: /usr/include/sys/errno.h:64:1: warning: this is the location of the previous def inition In file included from ../../src/include/c.h:90, from crypt.c:44: ../../src/include/pg_config_os.h:165:1: warning: SIGABRT redefined In file included from /usr/include/signal.h:8, from ../../src/include/pg_config_os.h:26, from ../../src/include/c.h:90, from crypt.c:44: /usr/include/sys/signal.h:225:1: warning: this is the location of the previous d efinition In file included from ../../src/include/c.h:90, from crypt.c:44: ../../src/include/pg_config_os.h:222: error: conflicting types for 'uid_t' /usr/include/sys/types.h:133: error: previous declaration of 'uid_t' was here ../../src/include/pg_config_os.h:223: error: conflicting types for 'gid_t' /usr/include/sys/types.h:134: error: previous declaration of 'gid_t' was here In file included from ../../src/include/c.h:90, from crypt.c:44: ../../src/include/pg_config_os.h:251:1: warning: EMSGSIZE
Re: [HACKERS] pg_basebackup for streaming base backups
On Sun, Jan 23, 2011 at 8:33 PM, Magnus Hagander mag...@hagander.net wrote: I've committed this with the current name, pg_basebackup Great! But, per subsequent commit logs, I should have reviewed more about portability issues :( Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- 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] add __attribute__((noreturn)) to suppress a waring
On 24.01.2011 03:42, Itagaki Takahiro wrote: I found the following warning with Fedora 14 / gcc 4.5.1. pg_backup_archiver.c: In function ‘_discoverArchiveFormat’: pg_backup_archiver.c:1736:11: warning: ‘fh’ may be used uninitialized in this function To suppress it, I'm thinking to add noreturn to die_horribly(). Any objections? Another solution might be adding a dummy assignment after calls of die_horribly(). I added a dummy assignment, that's how we've handled this before in pg_dump. I guess we could use noreturn, we already use it in pg_re_throw function. But we also have a dummy exit(1) call in the PG_RE_THROW macro for non-gcc compilers, so we might need to do that here too. Thanks! -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- 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] Tracking latest timeline in standby mode
On Wed, Jan 5, 2011 at 5:08 AM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: I finally got around to look at this. I wrote a patch to validate that the TLI on xlog page header matches ThisTimeLineID during recovery, and noticed quickly in testing that it doesn't catch all the cases I'd like to catch :-(. The patch added into the CF hasn't solved this problem yet. Are you planning to solve it in 9.1? Or are you planning to just commit the patch for 9.1, and postpone the issue to 9.2 or later? I'm OK either way. Of course, the former is quite better, though. Anyway, you have to add the documentation about this feature. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- 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, simplified
On 24.01.2011 03:48, Kevin Grittner wrote: If I get a solid answer on the SSI/HS issue before I post V14, I might be able to cover that, too, in that patch. I haven't wanted to totally write off the possibility of integrating them as long as discussion was ongoing; but if someone wants to assume the voice of Dr. McCoy and declare It's dead, Jim, I can move on for now and come back to the issue for 9.2. It's dead, Jim. Even if it wasn't, it'd still make sense to leave it out of the first commit, and add as later patch. So in any case, the first commit should just throw an error. Oddly, the computer generated voice sorta mangled something near the beginning, which was supposed to be I'm psyched, but sorta sounds like I'm sorry. Computers -- you just can't rely on 'em. I hope people find it entertaining and at least slightly informative. :-) http://www.xtranormal.com/watch/8285377/?listid=20642536 Wow, that's hilarious! :-) -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- 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] Include WAL in base backup
On Fri, Jan 21, 2011 at 12:28 AM, Tom Lane t...@sss.pgh.pa.us wrote: Magnus Hagander mag...@hagander.net writes: - Why not initialize logid and logseg like so?: int logid = startptr.xlogid; int logseg = startptr.xrecoff / XLogSegSize; Then use those in your elog? Seems cleaner to me. Hmm. Yes. Agreed. Marginal complaint here: int is the wrong type, I'm pretty sure. And, we should use XLByteToPrevSeg here instead of just =, I think. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- 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] Include WAL in base backup
On Mon, Jan 24, 2011 at 08:45, Fujii Masao masao.fu...@gmail.com wrote: On Fri, Jan 21, 2011 at 12:28 AM, Tom Lane t...@sss.pgh.pa.us wrote: Magnus Hagander mag...@hagander.net writes: - Why not initialize logid and logseg like so?: int logid = startptr.xlogid; int logseg = startptr.xrecoff / XLogSegSize; Then use those in your elog? Seems cleaner to me. Hmm. Yes. Agreed. Marginal complaint here: int is the wrong type, I'm pretty sure. And, we should use XLByteToPrevSeg here instead of just =, I think. Not XLByteToSeg? (I admit I missed the existance of both those macros, though) I plan to post a rebased version of this patch today or tomorrow, btw, that should work against all the changes that have been applied to git. -- 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
