[HACKERS] how does one set the plpython python interpreter?
Hello, Hopefully this hasn't been answered already. I attempted to do full due-diligence on it, and could find no answer anywhere. Basically my problem is that my server has both python 2.3 and python 2.4 installed (strange but unavoidable reasons behind this), and it appears that my installation of postgres is using the 2.3 version for my plpython scripts - and I need it to use the python 2.4 version. The 2.4 version is first in all the paths including user postgres on my server, but it seems to keep using python 2.3. Where can I configure which version (or path) that postgres will use? I assume that a python interpreter is not included inside the postgresql-python addon, and that it just uses an already-installed python interpreter. As a corollary, if I can configure the path to the python interpreter then I should be able to install my own python libraries for plpython to use (and since it's untrusted anyways...), correct? Many thanks if anyone can shed some light on this. -Roger ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] Integer datetimes
What is the reasoning behind having two different implementations of the datetime types, with slightly different behavior? Do we intend to keep supporting both FP- and integer-based datetimes indefinitely? Clearly, there are some costs associated with maintaining two different implementations: (1) It means we need to maintain two sets of code, with a corresponding increase in the maintenance burden, the probability of introducing bugs, etc., and making datetime behavior more difficult to test. (2) In general, I think it is a fundamentally *bad* idea to have the semantics of a builtin data type differ subtly depending on the value of a configure parameter. It makes writing portable applications more difficult, and can introduce hard-to-fix bugs. So, are there any corresponding benefits to providing both FP and integer datetimes? AFAIK the following differences in user-visible behavior exist: * integer timestamps have the same precision over their entire range (microsecond precision), whereas FP timestamps do not. This is clearly an advantage for integer timestamps. * integer timestamps have a smaller range than FP timestamps (294276 AD vs. 5874897 AD). Are there actually applications that use timestamps larger than 300,000 AD? Unless there are lots of applications that need timestamps over such a large range, ISTM integer datetimes are the better long-term approach, and I don't see how the FP-based datetime code justifies the maintenance burden. Notably, the FP datetime code doesn't depend on having a functional int64 type, but in 2007, are there really any platforms we care about that don't have such a type? Therefore, I propose that we make integer datetimes the default (perhaps for 8.4), and then eventually remove the floating-point datetime code. Comments? -Neil P.S. One thing to verify is that the performance of integer datetimes is no worse than the perf. of FP datetimes. I'd intuitively expect this to be true, but it would be worth investigating. ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] New idea for patch tracking
--- Original Message --- From: Bruce Momjian [EMAIL PROTECTED] To: PostgreSQL-development pgsql-hackers@postgresql.org Sent: 05/05/07, 03:00:25 Subject: [HACKERS] New idea for patch tracking As for #3, again, I don't want us to take on a burdensome patch tracking process that is more effort than it is worth, and the lack of people jumping to even manage a simple web page for current 8.3 patches has me questioning what kind of support a burdensome tracking system would receive. I don't recall hearing you ask for people to help with a web page. What I think we can do simply is to have our email software automatically number emails submitted to the patches list that already don't have a number. This way, all followups, even if moved to the hackers list, would maintain that patch number, and if an updated version is posted, the user would keep the same number in the email subject. snip tracker outline Barring a few trivial details, that sounds almost identical to what I proposed. Regards, Dave ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] how does one set the plpython python interpreter?
roger wrote: Where can I configure which version (or path) that postgres will use? It uses whatever python program it can find first in the path. If your observation is different, please show the relevant output from configure or config.log. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Integer datetimes
Neil Conway wrote: Notably, the FP datetime code doesn't depend on having a functional int64 type, but in 2007, are there really any platforms we care about that don't have such a type? That is really the only question, AFAIR. The integer datetimes implementation on a 32-bit type would have a range of about 1 hour (or about 1 month, if you reduce it to millisecond precision), which would make it totally useless. If we wanted to move toward requiring a 64-bit type, we should put some big warning into configure now that yells at the user if they don't have that type. And if no one complains, we can make it a requirement in a later release. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] New idea for patch tracking
Dave Page wrote: --- Original Message --- From: Bruce Momjian [EMAIL PROTECTED] To: PostgreSQL-development pgsql-hackers@postgresql.org Sent: 05/05/07, 03:00:25 Subject: [HACKERS] New idea for patch tracking As for #3, again, I don't want us to take on a burdensome patch tracking process that is more effort than it is worth, and the lack of people jumping to even manage a simple web page for current 8.3 patches has me questioning what kind of support a burdensome tracking system would receive. I don't recall hearing you ask for people to help with a web page. I want create and maintain a web page that tracks where we are on each 8.3 patch, but have had not takers. What I think we can do simply is to have our email software automatically number emails submitted to the patches list that already don't have a number. This way, all followups, even if moved to the hackers list, would maintain that patch number, and if an updated version is posted, the user would keep the same number in the email subject. snip tracker outline Barring a few trivial details, that sounds almost identical to what I proposed. Well, Andrew says everyone he talks to doesn't want it. They want a more comprehensive solution that goes from bug to patch. -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] New idea for patch tracking
Bruce Momjian wrote: Dave Page wrote: --- Original Message --- From: Bruce Momjian [EMAIL PROTECTED] To: PostgreSQL-development pgsql-hackers@postgresql.org Sent: 05/05/07, 03:00:25 Subject: [HACKERS] New idea for patch tracking As for #3, again, I don't want us to take on a burdensome patch tracking process that is more effort than it is worth, and the lack of people jumping to even manage a simple web page for current 8.3 patches has me questioning what kind of support a burdensome tracking system would receive. I don't recall hearing you ask for people to help with a web page. I want create and maintain a web page that tracks where we are on each 8.3 patch, but have had not takers. are you thinking about something like http://developer.postgresql.org/index.php/Todo:WishlistFor83 on steriods (ie with more references to actual patches and discussion and explaination of functionality) or something completely different ? I'm a bit unsure on how this webpage would differ from a typical bugtracker ... Maybe you could give a concrete example for a particular patch in the queue so that everybody can follow ? Stefan ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] New idea for patch tracking
Stefan Kaltenbrunner wrote: Bruce Momjian wrote: Dave Page wrote: --- Original Message --- From: Bruce Momjian [EMAIL PROTECTED] To: PostgreSQL-development pgsql-hackers@postgresql.org Sent: 05/05/07, 03:00:25 Subject: [HACKERS] New idea for patch tracking As for #3, again, I don't want us to take on a burdensome patch tracking process that is more effort than it is worth, and the lack of people jumping to even manage a simple web page for current 8.3 patches has me questioning what kind of support a burdensome tracking system would receive. I don't recall hearing you ask for people to help with a web page. I want create and maintain a web page that tracks where we are on each 8.3 patch, but have had not takers. are you thinking about something like http://developer.postgresql.org/index.php/Todo:WishlistFor83 on steriods (ie with more references to actual patches and discussion and explaination of functionality) or something completely different ? I'm a bit unsure on how this webpage would differ from a typical bugtracker ... Maybe you could give a concrete example for a particular patch in the queue so that everybody can follow ? At this point, just one line for each patch, and who is working on it: Patch, Author Committer HOTPavan ? XMLmisc Peter etc. -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] New idea for patch tracking
Bruce Momjian wrote: Stefan Kaltenbrunner wrote: Bruce Momjian wrote: Dave Page wrote: --- Original Message --- From: Bruce Momjian [EMAIL PROTECTED] To: PostgreSQL-development pgsql-hackers@postgresql.org Sent: 05/05/07, 03:00:25 Subject: [HACKERS] New idea for patch tracking As for #3, again, I don't want us to take on a burdensome patch tracking process that is more effort than it is worth, and the lack of people jumping to even manage a simple web page for current 8.3 patches has me questioning what kind of support a burdensome tracking system would receive. I don't recall hearing you ask for people to help with a web page. I want create and maintain a web page that tracks where we are on each 8.3 patch, but have had not takers. are you thinking about something like http://developer.postgresql.org/index.php/Todo:WishlistFor83 on steriods (ie with more references to actual patches and discussion and explaination of functionality) or something completely different ? I'm a bit unsure on how this webpage would differ from a typical bugtracker ... Maybe you could give a concrete example for a particular patch in the queue so that everybody can follow ? At this point, just one line for each patch, and who is working on it: Patch, Author Committer HOTPavan ? XMLmisc Peter etc. that would be easy to do on either the wishlist or a seperate wiki page and I would volunteer to do that if you think it is useful. Stefan ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] New idea for patch tracking
Stefan Kaltenbrunner wrote: Bruce Momjian wrote: Stefan Kaltenbrunner wrote: Bruce Momjian wrote: Dave Page wrote: --- Original Message --- From: Bruce Momjian [EMAIL PROTECTED] To: PostgreSQL-development pgsql-hackers@postgresql.org Sent: 05/05/07, 03:00:25 Subject: [HACKERS] New idea for patch tracking As for #3, again, I don't want us to take on a burdensome patch tracking process that is more effort than it is worth, and the lack of people jumping to even manage a simple web page for current 8.3 patches has me questioning what kind of support a burdensome tracking system would receive. I don't recall hearing you ask for people to help with a web page. I want create and maintain a web page that tracks where we are on each 8.3 patch, but have had not takers. are you thinking about something like http://developer.postgresql.org/index.php/Todo:WishlistFor83 on steriods (ie with more references to actual patches and discussion and explaination of functionality) or something completely different ? I'm a bit unsure on how this webpage would differ from a typical bugtracker ... Maybe you could give a concrete example for a particular patch in the queue so that everybody can follow ? At this point, just one line for each patch, and who is working on it: Patch, Author Committer HOTPavan ? XMLmisc Peter etc. that would be easy to do on either the wishlist or a seperate wiki page and I would volunteer to do that if you think it is useful. OK, you have to go back to Tom's email stating where we are on each patch, then look over the patch application and find out which ones have been applied. Also you have to read the replies to find out who has taken ownership of patches. -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] New idea for patch tracking
Bruce Momjian wrote: Dave Page wrote: Barring a few trivial details, that sounds almost identical to what I proposed. Well, Andrew says everyone he talks to doesn't want it. They want a more comprehensive solution that goes from bug to patch. Dave can speak for his own views, but I think you're misquoting me somewhat. I said that a majority of developers wanted to move to use of a tracking system, not everyone. I did say that this patch tracker would be at best a half measure in almost everyone's eyes. Note the almost. That doesn't mean nobody wants it. Possibly some see significant benefit where I see little or none. Clearly Dave does. But it does mean that it's not what most people really want. I would be prepared to put considerable effort (say, comparable to what I have put into the buildfarm) into establishing and maintaining a feature/bug tracker system, if I thought there was enough buyin. I have not done so in the past because others (principally you) have been against it, and so it seemed doomed to failure. Unlike the buildfarm, which can stand on its own, a tracker requires cooperation from the developers in order to be effective. Our present change management methods strike me as being analogous to keeping track of a banking system in a spreadsheet (don't get me started). It's quite ironic (not to mention sad) given that we are producing a sophisticated database ... cheers andrew ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Integer datetimes
Peter Eisentraut wrote: Neil Conway wrote: Notably, the FP datetime code doesn't depend on having a functional int64 type, but in 2007, are there really any platforms we care about that don't have such a type? That is really the only question, AFAIR. The integer datetimes implementation on a 32-bit type would have a range of about 1 hour (or about 1 month, if you reduce it to millisecond precision), which would make it totally useless. If we wanted to move toward requiring a 64-bit type, we should put some big warning into configure now that yells at the user if they don't have that type. And if no one complains, we can make it a requirement in a later release. Can we discover anything useful from existing configure logs? If so, maybe we can survey the buildfarm database. Incidentally, use of integer datetimes has been in the default config set on the buildfarm from day one, because it seems to me far saner, in principle, to use fixed precision for them, so I cerainly agree with Neil's goal. cheers andrew ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] how does one set the plpython python interpreter?
On May 5, 1:34 am, [EMAIL PROTECTED] (Peter Eisentraut) wrote: roger wrote: Where can I configure which version (or path) that postgres will use? It uses whatever python program it can find first in the path. If your observation is different, please show the relevant output from configure or config.log. -- Peter Eisentrauthttp://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 6: explain analyze is your friend Hi Peter, After doing a little more digging, it appears as if the python version used is hardcoded into the plpython.so (I'm not sure if plpython.so is actually doing the python interpretation itself or not) this is an ldd output on my plpython.so: # ldd plpython.so libpython2.3.so.1.0 = /usr/lib/libpython2.3.so.1.0 (0x00c37000) libpthread.so.0 = /lib/tls/libpthread.so.0 (0x00edd000) libdl.so.2 = /lib/libdl.so.2 (0x00981000) libutil.so.1 = /lib/libutil.so.1 (0x00111000) libm.so.6 = /lib/tls/libm.so.6 (0x00693000) libc.so.6 = /lib/tls/libc.so.6 (0x006bd000) /lib/ld-linux.so.2 (0x0091c000) I installed postgres from RHES 4 RPM. So not sure if that libpython2.3 dependency was done by the RPM builder or was done when I did the install. My pg_config seems to indicate the install configuration used the directories (/usr/lib and /usr/bin) where my Python 2.3 is (Python 2.4 is in /usr/local/bin) So I'm now wondering how I can get the plpython.so to depend on python2.4. Do I have to reinstall, or is there some way of just redoing the plpython.so? The really weird part is that I wrote a plpython script to write out python environment vars: CREATE OR REPLACE FUNCTION blah(varchar) RETURNS integer AS $$ import sys plpy.notice(python exec = '%s' % sys.executable) plpy.notice(python version = '%s' % sys.version) plpy.notice(python path = '%s' % sys.path) return 1 $$ LANGUAGE plpythonu; And I get the following output: NOTICE: (python exec = '/usr/local/bin/python',) NOTICE: (python version = '2.3.4 (#1, Oct 11 2006, 06:18:43) \n[GCC 3.4.6 20060404 (Red Hat 3.4.6-3)]',) NOTICE: (python path = '['/usr/lib/python23.zip', '/usr/lib/ python2.3', '/usr/lib/python2.3/plat-linux2', '/usr/lib/python2.3/lib- tk', '/usr/lib/python2.3/lib-dynload', '/usr/lib/python2.3/site- packages', '/usr/lib/python2.3/site-packages/gtk-2.0']',) The weird part being the first line: plpython thinks it's being run from /usr/local/bin/python (which is 2.4), when the second line clearly indicates version 2.3 Strange... Anyways, for completeness, my pg_config gives: # pg_config BINDIR = /usr/bin DOCDIR = /usr/share/doc/pgsql INCLUDEDIR = /usr/include PKGINCLUDEDIR = /usr/include/pgsql INCLUDEDIR-SERVER = /usr/include/pgsql/server LIBDIR = /usr/lib PKGLIBDIR = /usr/lib/pgsql LOCALEDIR = /usr/share/locale MANDIR = /usr/share/man SHAREDIR = /usr/share/pgsql SYSCONFDIR = /etc/sysconfig/pgsql PGXS = /usr/lib/pgsql/pgxs/src/makefiles/pgxs.mk CONFIGURE = '--build=i686-redhat-linux-gnu' '--host=i686-redhat-linux- gnu' '--target=i686-redhat-linux-gnu' '--program-prefix=' '--prefix=/ usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '-- sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '-- libdir=/usr/lib' '--libexecdir=/usr/libexec' '--localstatedir=/var' '-- sharedstatedir=/usr/com' '--mandir=/usr/share/man' '--infodir=/usr/ share/info' '--disable-rpath' '--with-perl' '--with-tcl' '--with- tclconfig=/usr/lib' '--with-python' '--with-openssl' '--with-pam' '-- with-krb5' '--with-includes=/usr/include' '--with-libraries=/usr/lib' '--enable-nls' '--sysconfdir=/etc/sysconfig/pgsql' '--datadir=//usr/ share/pgsql' '--with-docdir=/usr/share/doc' 'CFLAGS=-O2 -g -pipe -m32 - march=i686 -mtune=pentium4 -I/usr/include/et' 'CPPFLAGS= -I/usr/ include/et' 'build_alias=i686-redhat-linux-gnu' 'host_alias=i686- redhat-linux-gnu' 'target_alias=i686-redhat-linux-gnu' CC = gcc CPPFLAGS = -D_GNU_SOURCE -I/usr/include CFLAGS = -O2 -g -pipe -m32 -march=i686 -mtune=pentium4 -I/usr/include/ et -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration- after-statement -Wendif-labels -fno-strict-aliasing CFLAGS_SL = -fpic LDFLAGS = -L/usr/lib LDFLAGS_SL = LIBS = -lpgport -lpam -lssl -lcrypto -lkrb5 -lz -lreadline -ltermcap - lcrypt -lresolv -lnsl -ldl -lm -lbsd VERSION = PostgreSQL 8.1.5 So, any ideas on how I can get plpython.so to use Python 2.4? Any help is greatly appreciated. thanks, -Roger ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] New idea for patch tracking
Bruce Momjian wrote: Stefan Kaltenbrunner wrote: Bruce Momjian wrote: Stefan Kaltenbrunner wrote: Bruce Momjian wrote: Dave Page wrote: --- Original Message --- From: Bruce Momjian [EMAIL PROTECTED] To: PostgreSQL-development pgsql-hackers@postgresql.org Sent: 05/05/07, 03:00:25 Subject: [HACKERS] New idea for patch tracking As for #3, again, I don't want us to take on a burdensome patch tracking process that is more effort than it is worth, and the lack of people jumping to even manage a simple web page for current 8.3 patches has me questioning what kind of support a burdensome tracking system would receive. I don't recall hearing you ask for people to help with a web page. I want create and maintain a web page that tracks where we are on each 8.3 patch, but have had not takers. are you thinking about something like http://developer.postgresql.org/index.php/Todo:WishlistFor83 on steriods (ie with more references to actual patches and discussion and explaination of functionality) or something completely different ? I'm a bit unsure on how this webpage would differ from a typical bugtracker ... Maybe you could give a concrete example for a particular patch in the queue so that everybody can follow ? At this point, just one line for each patch, and who is working on it: Patch, Author Committer HOTPavan ? XMLmisc Peter etc. that would be easy to do on either the wishlist or a seperate wiki page and I would volunteer to do that if you think it is useful. OK, you have to go back to Tom's email stating where we are on each patch, then look over the patch application and find out which ones have been applied. Also you have to read the replies to find out who has taken ownership of patches. ok I did a rough sketch of how I interpreted your proposal on http://developer.postgresql.org/index.php/Todo:PatchStatus. This table is by far not complete yet(more of a PoC) but I wanted to get some feedback if I'm on the right track before I put more time into this. Stefan ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Feature freeze progress report
People aren't willing to hel pme in even a simple task of maintaining an 8.3 patches status page, so why would they want to help with something larger. I am not going to make my job harder only to find out no one wants to help. I thought about volunteering to do this, but: 1. I am a little warry of inserting myself (as an outsider) into a major controversy as my first contribution to the project. 2. It seems like it would be difficult or impossible for an outsider to do this well. Essentially, I'd have to read every message on -hackers, -patches, and -committers, and try to figure out which of those messages amounted to a change in status for which patches, and then update the status of the patches. Example: Tom says what about XYZ? ISTM this will have to wait for 8.4. The person who wrote the patch replies with I think XYZ is not an issue because of ABC. It's not clear (at least to me) whether the patch is now in play for 8.3 again or whether it's still on hold. In addition, if some discussion is happening via private email (which it sounds like it is), then this wouldn't be complete even if it were done perfectly. I write web-based workflow applications for a living, so in theory I'm more amenable to the idea of helping out in that way. But it seems to me that right now there's no consensus on whether we need this at all, and if so what it should do. I don't really want to get involved in the central argument about what the right way of doing this is, but I think Bruce's proposal to put a patch number in every email that hasn't got one can't possibly be any worse than what we're doing now, and it might be better, so why not? I'm even willing help with this if there is consensus on it. Thanks, ...Robert ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] how does one set the plpython python interpreter?
roger wrote: So, any ideas on how I can get plpython.so to use Python 2.4? You'll have to rebuild the whole thing. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
[HACKERS] Re: [BUGS] Removing pg_auth_members.grantor (was Grantor name gets lost when grantor role dropped)
Stephen Frost wrote: * Tom Lane ([EMAIL PROTECTED]) wrote: Stephen Frost [EMAIL PROTECTED] writes: If you're saying we don't currently warn if a revoke leaves the priviledges in-tact for the right and target, I'm not sure you can currently get in a state where it'd be possible to run into that. I'm thinking of the case that comes up periodically where newbies think that revoking a right from a particular user overrides a grant to PUBLIC of the same right. Technically, the grant to public is a different target from the target of the revoke in such a case. Following the spec would mean that even when the grant and the revoke target is the same (unless you're the original grantor) the right won't be removed. I'm not against adding a warning in the case you describe though, but I don't see it being as necessary for that case. What the spec describes is, at least in my view, much more counter-intuitive than how PG currently works. If we were to follow the spec, I would expect that it would be possible for the object owner to revoke privileges no matter what role granted them. It need not be the default, but as an object owner, I'd expect to be able to say that I want all privileges for a role revoked, no matter who granted them. 8.2 docs state this on the revoke page: -- REVOKE can also be done by a role that is not the owner of the affected object, but is a member of the role that owns the object, or is a member of a role that holds privileges WITH GRANT OPTION on the object. In this case the command is performed as though it were issued by the containing role that actually owns the object or holds the privileges WITH GRANT OPTION. For example, if table t1 is owned by role g1, of which role u1 is a member, then u1 can revoke privileges on t1 that are recorded as being granted by g1. This would include grants made by u1 as well as by other members of role g1. If the role executing REVOKE holds privileges indirectly via more than one role membership path, it is unspecified which containing role will be used to perform the command. In such cases it is best practice to use SET ROLE to become the specific role you want to do the REVOKE as. Failure to do so may lead to revoking privileges other than the ones you intended, or not revoking anything at all. -- Paragraph 1 implies that we are meeting the standard now. I think paragraph two is stating that if you are a member of multiple roles which could have granted privileges, then you don't know which one you are revoking. Makes sense if we are implementing the SQL standard. Does this mean we were intending to be SQL compliant when we wrote the documentation? I also note that 8.1 says the same thing in its documentation. My possible suggestion is; 1. Implement the standard for revoking only your privileges by default. 2. Allow the object owner to revoke privileges assigned by any role, as if you drop and recreate the object you can achieve this anyway. Regards Russell Smith ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] conversion_procs makefiles
Alvaro Herrera wrote: I noticed that conversion_procs is sadly single-tasked to build. I am wondering if it would be acceptable to rework the Makefile.shlib to have an option to allow building multiple libs, by creating a rule to collect libraries to build, and have each conversion_proc Makefile add a target to that. Then the whole lot of libraries would be built by a single non-recursive make pass, instead of the current recursive approach. There is certainly room for improvement there. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] New idea for patch tracking
I would like to add one point: Bruce Momjian wrote: Patch committers check several things before applying a patch: 1) Follows the SQL standard or community agreed-upon behavior 2) Style merges seamlessly into the surrounding code 3) Written as simply and efficiently as possible 4) Uses the available PostgreSQL subsystems properly 5) Contains sufficient comments 6) Contains code that works on all supported operating systems 7) Has proper documentation 8) Passes all regression tests 8.5) Contains regression test(s) which covered performed changes 9) Behaves as expected, even under unusual cirumstances 10) Contains no reliability risks 11) Does not overly complicate the source code 12) If performance-related, it should have a measureable performance benefit 13) Is of sufficient usefulness to the average PostgreSQL user 14) Follows existing PostgreSQL coding standards Zdenek ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] New idea for patch tracking
OK, item modified to: liPasses all regression tests, and if needed, adds new ones/li --- Zdenek Kotala wrote: I would like to add one point: Bruce Momjian wrote: Patch committers check several things before applying a patch: 1) Follows the SQL standard or community agreed-upon behavior 2) Style merges seamlessly into the surrounding code 3) Written as simply and efficiently as possible 4) Uses the available PostgreSQL subsystems properly 5) Contains sufficient comments 6) Contains code that works on all supported operating systems 7) Has proper documentation 8) Passes all regression tests 8.5) Contains regression test(s) which covered performed changes 9) Behaves as expected, even under unusual cirumstances 10) Contains no reliability risks 11) Does not overly complicate the source code 12) If performance-related, it should have a measureable performance benefit 13) Is of sufficient usefulness to the average PostgreSQL user 14) Follows existing PostgreSQL coding standards Zdenek -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Cache plan invalidation
The current TODO list has: Dependency Checking === * Flush cached query plans when the dependent objects change, when the cardinality of parameters changes dramatically, or when new ANALYZE statistics are available A more complex solution would be to save multiple plans for different cardinality and use the appropriate plan based on the EXECUTE values. * Track dependencies in function bodies and recompile/invalidate This is particularly important for references to temporary tables in PL/PgSQL because PL/PgSQL caches query plans. The only workaround in PL/PgSQL is to use EXECUTE. One complexity is that a function might itself drop and recreate dependent tables, causing it to invalidate its own query plan. Which of these are done or not done? -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] storage of sensor data with Fourier transforms
Nathan Buchanan [EMAIL PROTECTED] writes: I had the idea of taking the Fourier transform of the waveform and storing the waveform internally that way to reduce storage requirements. Aside from what Steve said: The Fourier transform in itself doesn't reduce data size --- it's N points in, N points out. If you want to reduce storage requirements you have to resort to lossy compression, ie, deliberately throwing away some data. The transformed data might be more suitable for doing that (eg you can selectively discard high-frequency components) but do you really want to? Usually the point of storing measurements is so you can do unspecified analysis on them later. Applying lossy compression will restrict what you can (meaningfully) do later on. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Cache plan invalidation
Bruce Momjian wrote: The current TODO list has: Dependency Checking === * Flush cached query plans when the dependent objects change, when the cardinality of parameters changes dramatically, or when new ANALYZE statistics are available A more complex solution would be to save multiple plans for different cardinality and use the appropriate plan based on the EXECUTE values. * Track dependencies in function bodies and recompile/invalidate This is particularly important for references to temporary tables in PL/PgSQL because PL/PgSQL caches query plans. The only workaround in PL/PgSQL is to use EXECUTE. One complexity is that a function might itself drop and recreate dependent tables, causing it to invalidate its own query plan. Which of these are done or not done? Also, is this done: * Invalidate prepared queries, like INSERT, when the table definition is altered -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] Patch Status in the wiki
As promised I added a Patch Status site to the wiki: http://developer.postgresql.org/index.php/Todo:PatchStatus It contains all the patches tom mentioned in his recent patch queue triage mail with references to the patches (either on the queue or in the archives) as well as the author and the reviewer (if we have one). items with a ? have no reviewer (or in some cases are awaiting further discussion). Reviewers with a ? following their name have only been proposed for a certain item (like Peter for the XML stuff). If I missed a patch or something else I would like to hear :-) Stefan ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Patch Status in the wiki
There is now a link to it at the top of the patch queue web site. --- Stefan Kaltenbrunner wrote: As promised I added a Patch Status site to the wiki: http://developer.postgresql.org/index.php/Todo:PatchStatus It contains all the patches tom mentioned in his recent patch queue triage mail with references to the patches (either on the queue or in the archives) as well as the author and the reviewer (if we have one). items with a ? have no reviewer (or in some cases are awaiting further discussion). Reviewers with a ? following their name have only been proposed for a certain item (like Peter for the XML stuff). If I missed a patch or something else I would like to hear :-) Stefan ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] array type name mangling
In connection with completing David Fetter's array of composites patch, I am looking at doing some better name mangling for array types as recently discussed. What I'm thinking of is prepending one or more underscores to the type name up to some limit (NAMEDATALEN / 2 ?) and if necessary truncating the result, and then looking to see if there is a name clash. That would, I hope, enable us to get rid of all the places where we require names to be no more than NAMEDATALEN - 2 chars. Does that seem like a reasonable approach? Will it break anything, i.e., is there somewhere that has assumes the array type for foo will be called _foo rather than ___foo ? cheers andrew ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Integer datetimes
Peter Eisentraut [EMAIL PROTECTED] writes: Neil Conway wrote: Notably, the FP datetime code doesn't depend on having a functional int64 type, but in 2007, are there really any platforms we care about that don't have such a type? That is really the only question, AFAIR. We've so far managed to avoid having any hard dependency on a working int64 type, but this would certainly be one. I don't really think the code-size-reduction argument is strong enough to justify that. The datetime code seems relatively stable at this point, so the maintenance overhead of the code as it stands is not high. I'm not necessarily opposed to changing the default configure selection, but I am opposed to removing the FP code entirely. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] array type name mangling
I wrote: In connection with completing David Fetter's array of composites patch, I am looking at doing some better name mangling for array types as recently discussed. What I'm thinking of is prepending one or more underscores to the type name up to some limit (NAMEDATALEN / 2 ?) and if necessary truncating the result, and then looking to see if there is a name clash. That would, I hope, enable us to get rid of all the places where we require names to be no more than NAMEDATALEN - 2 chars. Does that seem like a reasonable approach? Will it break anything, i.e., is there somewhere that has assumes the array type for foo will be called _foo rather than ___foo ? Actually, looking back in the email history I see Tom suggested this, which I'll try instead: prepend _, truncate to less than 64 bytes if necessary, then substitute numbers at the end if needed to get something unique. cheers andrew ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] array type name mangling
Andrew Dunstan [EMAIL PROTECTED] writes: In connection with completing David Fetter's array of composites patch, I am looking at doing some better name mangling for array types as recently discussed. What I'm thinking of is prepending one or more underscores to the type name up to some limit (NAMEDATALEN / 2 ?) and if necessary truncating the result, and then looking to see if there is a name clash. That would, I hope, enable us to get rid of all the places where we require names to be no more than NAMEDATALEN - 2 chars. Does that seem like a reasonable approach? Will it break anything, i.e., is there somewhere that has assumes the array type for foo will be called _foo rather than ___foo ? makeArrayTypeName and users thereof. Or are you going to extend pg_type to have a direct link? regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Patch Status in the wiki
On 5/5/07, Stefan Kaltenbrunner [EMAIL PROTECTED] wrote: As promised I added a Patch Status site to the wiki: http://developer.postgresql.org/index.php/Todo:PatchStatus The original autor of the temp_tablespace GUC patch is Albert Cervera Areny albertca ( at ) hotpop ( dot ) com http://archives.postgresql.org/pgsql-patches/2006-10/msg00141.php -- regards, Jaime Casanova Programming today is a race between software engineers striving to build bigger and better idiot-proof programs and the universe trying to produce bigger and better idiots. So far, the universe is winning. Richard Cook ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Cache plan invalidation
Bruce Momjian [EMAIL PROTECTED] writes: Bruce Momjian wrote: The current TODO list has: Dependency Checking === * Flush cached query plans when the dependent objects change, when the cardinality of parameters changes dramatically, or when new ANALYZE statistics are available A more complex solution would be to save multiple plans for different cardinality and use the appropriate plan based on the EXECUTE values. This is partially done --- you'll have to split it into multiple items if you want to preserve the bit about keeping different plans for different parameter values. Note that in the current code, any VACUUM or ANALYZE on a table will force relcache inval and hence replan; see vac_update_relstats. So the only case not covered as far as non-parameterized queries go is large growth of a table without any vacuuming or analyzing ... and you're going to have problems anyway if you don't analyze after loading a table. We may in fact find that our problem is now too many replans rather than too few. * Track dependencies in function bodies and recompile/invalidate This is particularly important for references to temporary tables in PL/PgSQL because PL/PgSQL caches query plans. This is done. Also, is this done: * Invalidate prepared queries, like INSERT, when the table definition is altered This too. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] array type name mangling
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: In connection with completing David Fetter's array of composites patch, I am looking at doing some better name mangling for array types as recently discussed. What I'm thinking of is prepending one or more underscores to the type name up to some limit (NAMEDATALEN / 2 ?) and if necessary truncating the result, and then looking to see if there is a name clash. That would, I hope, enable us to get rid of all the places where we require names to be no more than NAMEDATALEN - 2 chars. Does that seem like a reasonable approach? Will it break anything, i.e., is there somewhere that has assumes the array type for foo will be called _foo rather than ___foo ? makeArrayTypeName and users thereof. Or are you going to extend pg_type to have a direct link? I am going to change makeArrayTypeName() to do the mangling. Its users will need to pass in a namespace as well as a typename so it can do the checking. There's a direct link via typelem - do you think we need a reverse mapping? cheers andrew ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Integer datetimes
On Sat, 2007-05-05 at 11:03 -0400, Tom Lane wrote: We've so far managed to avoid having any hard dependency on a working int64 type, but this would certainly be one. I don't really think the code-size-reduction argument is strong enough to justify that. What benefit do we get from avoiding this dependency? Can we really avoid a dependency on a 64-bit integral type in the long run? I'm not necessarily opposed to changing the default configure selection, but I am opposed to removing the FP code entirely. I would be satisfied with changing the default to integer and deprecating the FP code (but keeping it around as a configure option). Are there any objections to doing this for 8.3? -Neil ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Cache plan invalidation
I removed the cardinality item and marked the others as done: * -Flush cached query plans when the dependent objects change or when new ANALYZE statistics are available * -Track dependencies in function bodies and recompile/invalidate * -Invalidate prepared queries, like INSERT, when the table definition is altered Let's see if the cardinality issue is still needed after this release. --- Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Bruce Momjian wrote: The current TODO list has: Dependency Checking === * Flush cached query plans when the dependent objects change, when the cardinality of parameters changes dramatically, or when new ANALYZE statistics are available A more complex solution would be to save multiple plans for different cardinality and use the appropriate plan based on the EXECUTE values. This is partially done --- you'll have to split it into multiple items if you want to preserve the bit about keeping different plans for different parameter values. Note that in the current code, any VACUUM or ANALYZE on a table will force relcache inval and hence replan; see vac_update_relstats. So the only case not covered as far as non-parameterized queries go is large growth of a table without any vacuuming or analyzing ... and you're going to have problems anyway if you don't analyze after loading a table. We may in fact find that our problem is now too many replans rather than too few. * Track dependencies in function bodies and recompile/invalidate This is particularly important for references to temporary tables in PL/PgSQL because PL/PgSQL caches query plans. This is done. Also, is this done: * Invalidate prepared queries, like INSERT, when the table definition is altered This too. regards, tom lane -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Patch Status in the wiki
Jaime Casanova wrote: On 5/5/07, Stefan Kaltenbrunner [EMAIL PROTECTED] wrote: As promised I added a Patch Status site to the wiki: http://developer.postgresql.org/index.php/Todo:PatchStatus The original autor of the temp_tablespace GUC patch is Albert Cervera Areny albertca ( at ) hotpop ( dot ) com http://archives.postgresql.org/pgsql-patches/2006-10/msg00141.php thanks - I have added Albert now Stefan ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] New idea for patch tracking
--- Original Message --- From: Bruce Momjian [EMAIL PROTECTED] To: Dave Page [EMAIL PROTECTED] Sent: 05/05/07, 11:06:37 Subject: Re: [HACKERS] New idea for patch tracking snip tracker outline Barring a few trivial details, that sounds almost identical to what I proposed. Well, Andrew says everyone he talks to doesn't want it. They want a more comprehensive solution that goes from bug to patch. I don't recall him saying that, though I do know that's /his/ opinion. It's certainly *not* the opinion of most of the people I've spoken with. I don't disagree with the idea in principle though, but I don't believe it will work for us because it's so fundamentally different from the way we currently work and still wouldn't solve the problem of capturing all the relevant discussion regarding a given patch (or bug) without a reasonable amount of manual work, or grafting a large part of what I'm proposing on the side. Regards, Dave ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Integer datetimes
Neil Conway wrote: So, are there any corresponding benefits to providing both FP and integer datetimes? AFAIK the following differences in user-visible behavior exist: There should be also problem with floating point implementation on client and server side. For example if somebody use floating point optimalization (-fast switch in Sun Studio) for server compilation and client will be connected from another machine with standard floating point behavior. Result could be wrong. P.S. One thing to verify is that the performance of integer datetimes is no worse than the perf. of FP datetimes. I'd intuitively expect this to be true, but it would be worth investigating. Some multi core/thread CPUs has only one FPU (e.g. Niagara). Zdenek ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] iterating over relation's attributes
What is the approved way to iterate over a relation's attributes? I see that lsyscache.c::get_relnatts() is marked NOT_USED and has been for nearly seven years. Maybe it's time to remove that code ;-) cheers andrew ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] array type name mangling
Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: makeArrayTypeName and users thereof. Or are you going to extend pg_type to have a direct link? I am going to change makeArrayTypeName() to do the mangling. Its users will need to pass in a namespace as well as a typename so it can do the checking. You missed the point: there is a need to find the array type associated with an existing element type, not only the other way round. See LookupTypeName() and get_array_type(). regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] iterating over relation's attributes
Andrew Dunstan [EMAIL PROTECTED] writes: What is the approved way to iterate over a relation's attributes? Most places scan through the relation's tuple descriptor, rather than expending multiple catalog lookups in pg_attribute. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] array type name mangling
Andrew Dunstan [EMAIL PROTECTED] writes: Actually, looking back in the email history I see Tom suggested this, which I'll try instead: prepend _, truncate to less than 64 bytes if necessary, then substitute numbers at the end if needed to get something unique. Your idea of multiple underscores seems just as reasonable, maybe more so. Either way, remember that the truncation needs to be multibyte-aware. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] array type name mangling
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: makeArrayTypeName and users thereof. Or are you going to extend pg_type to have a direct link? I am going to change makeArrayTypeName() to do the mangling. Its users will need to pass in a namespace as well as a typename so it can do the checking. You missed the point: there is a need to find the array type associated with an existing element type, not only the other way round. See LookupTypeName() and get_array_type(). OK, in that case I think we should extend pg_type with a direct link, don't you? cheers andrew ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] iterating over relation's attributes
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: What is the approved way to iterate over a relation's attributes? Most places scan through the relation's tuple descriptor, rather than expending multiple catalog lookups in pg_attribute. Doesn't that require me to open the relation? Is that a good thing if I wouldn't otherwise be doing that? This is in the context of making CheckAttributeType recurse into composite types. cheers andrew ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] iterating over relation's attributes
Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: What is the approved way to iterate over a relation's attributes? Most places scan through the relation's tuple descriptor, rather than expending multiple catalog lookups in pg_attribute. Doesn't that require me to open the relation? Is that a good thing if I wouldn't otherwise be doing that? Sure, because whatever work gets done is likely to be amortized across multiple uses of the relcache entry anyway. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Integer datetimes
Zdenek Kotala wrote: Neil Conway wrote: So, are there any corresponding benefits to providing both FP and integer datetimes? AFAIK the following differences in user-visible behavior exist: There should be also problem with floating point implementation on client and server side. For example if somebody use floating point optimalization (-fast switch in Sun Studio) for server compilation and client will be connected from another machine with standard floating point behavior. Result could be wrong. What? We don't pass float as a binary to clients. The client can be any OS. -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Integer datetimes
On Sat, 2007-05-05 at 20:52 -0400, Bruce Momjian wrote: What? We don't pass float as a binary to clients. Sure we do, if the client is sending or receiving data in binary format. -Neil ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Integer datetimes
Neil Conway wrote: On Sat, 2007-05-05 at 20:52 -0400, Bruce Momjian wrote: What? We don't pass float as a binary to clients. Sure we do, if the client is sending or receiving data in binary format. But in those cases, we assume the client and server have the same configuration, right? -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] plperl vs. bytea
I have been talking with Theo some more about his recent problem with bytea arguments and results (see recent discussion on -bugs and also recent docs patch), what he needs is a way to have bytea (and possibly other unknown types) passed as binary data to and from plperl. The conversion overhead is too big both computationally and in increased memory usage. After discussing some possibilities, we decided that maybe the best approach would be to allow a custom GUC variable that would specify a list of types to be passed in binary form with no conversion, e.g. plperl.pass_as_binary = 'bytea, other-type' This would affect function args, trigger data, return results, and I think it should also apply to arguments for SPI prepared queries and to SPI returned results. If this seems like a good idea maybe it should go on the TODO list in whatever is the current incarnation. cheers andrew ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Integer datetimes
Bruce Momjian wrote: Neil Conway wrote: On Sat, 2007-05-05 at 20:52 -0400, Bruce Momjian wrote: What? We don't pass float as a binary to clients. Sure we do, if the client is sending or receiving data in binary format. But in those cases, we assume the client and server have the same configuration, right? Certainly the client and server must have the same notion of the binary format. cheers andrew ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] plperl vs. bytea
Andrew Dunstan [EMAIL PROTECTED] writes: After discussing some possibilities, we decided that maybe the best approach would be to allow a custom GUC variable that would specify a list of types to be passed in binary form with no conversion, e.g. plperl.pass_as_binary = 'bytea, other-type' At minimum this GUC would have to be superuser-only, and even then the security risks seem a bit high. But the real problem with this thinking is the same one I already pointed out to Theo: why do you think this issue is plperl-specific? regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] plperl vs. bytea
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: After discussing some possibilities, we decided that maybe the best approach would be to allow a custom GUC variable that would specify a list of types to be passed in binary form with no conversion, e.g. plperl.pass_as_binary = 'bytea, other-type' At minimum this GUC would have to be superuser-only, and even then the security risks seem a bit high. But the real problem with this thinking is the same one I already pointed out to Theo: why do you think this issue is plperl-specific? It's not. If we really want to tackle this root and branch without upsetting legacy code, I think we'd need to have a way of marking data items as binary in the grammar, e.g. create function myfunc(myarg binary bytea) returns binary bytea language plperl as $$ ...$$; That's what I originally suggested to Theo. It would be a lot more work, though :-) cheers andrew ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] Managing the community information stream
Let me give you my approach to tracking. It might help set the stage for moving forward. My goal has always been to foster discussion and pull as many TODO items and patches from the discussion as possible (and others do that as well by saying Please add to TODO or applying patches). I see the process much more as pulling things from a stream of data, rather than tracking every event. We already record everything in the archive. The current discussion is how and who should summarize/track that information. Right now, the TODO list is a good summary, and URLs help to give detail. I am not sure seeing all treads of a TODO item would help. In a way, the summarization is more valuable than the details for most people. Again, the question is what is the cost of summarizing the stream at a more detailed level vs. its value. Because I see us operating on a stream, it is unclear when to pull an item from the stream and track it off-stream, such as in a bug tracker database. I am also concerned that tracking itself not inhibit the volume of the stream, particularly if discussion participants have to do something more difficult than what they do now. The idea of the patch number in the subject line works with that streaming model because it merely marks streams so they can be grouped. The defining event that marks the stream is a post to the patches list. We already number posts to the bugs list, so in a way we could improve tracking there and somehow link it to TODO items and patch submissions, but because many TODO items are not the result of bug reports but come out of general discussions, I am not sure tracking would work as well there. And what about features? Do you start assigning numbers there, and what is your trigger event? In my opinion, as you start trying to place more structure on the stream, the stream itself starts to degrade in its dynamism and ease of use. To me, that is the fundamental issue, and risk. I think a lot of this relates to the volume of work we do per participant. I think we are probably near the top for open source projects, and while more detailed tracking might help, it also might hurt. I am hoping the stream analogy might help people understand why we do what we do, why we are so successful, and how we can improve what we currently have. -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [COMMITTERS] pgsql: Teach tuplesort.c about top N sorting, in which only the first
On May 4, 2007, at 7:49 PM, Tom Lane wrote: Jim Nasby [EMAIL PROTECTED] writes: On a related note, it would also be *really* nice if we kept stats on how many sorts or hashes had spilled to disk, perhaps along with how much had spilled. Right now the only way to monitor that in a production system is to setup a cron job to watch pgsql_tmp, which is far from elegant. No, you can turn on trace_sort and track it from watching the log. If pgfouine hasn't got something for that already, I'd be surprised. There's several problems with that. First, trace_sort isn't documented (or at least it's not in postgresql.conf), so most folks don't know it exists. Second, in order to see it's output you have to drop log_min_messages to debug. That results in a huge log volume, especially on a production system. Aside from that, log files are not a good way to monitor performance, they should be used for reporting on exception conditions. If the log was meant to be the means for monitoring performance, then why have the statistics system at all? As for pgfouine, I've never been to a customer that knew what it was. But almost all of them have other monitoring tools such as cricket, MRTG and Nagios setup. Those that don't at least know they exist. -- Jim Nasby[EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] autovacuum starvation
On May 2, 2007, at 5:39 PM, Alvaro Herrera wrote: The recently discovered autovacuum bug made me notice something that is possibly critical. The current autovacuum code makes an effort not to leave workers in a starting state for too long, lest there be failure to timely tend all databases needing vacuum. This is how the launching of workers works: 1) the launcher puts a pointer to a WorkerInfo entry in shared memory, called the starting worker pointer 2) the launcher sends a signal to the postmaster 3) the postmaster forks a worker 4) the new worker checks the starting worker pointer 5) the new worker resets the starting worker pointer 6) the new worker connects to the given database and vacuums it The problem is this: I originally added some code in the autovacuum launcher to check that a worker does not take too long to start. This is autovacuum_naptime seconds. If this happens, the launcher resets the starting worker pointer, which means that the newly starting worker will not see anything that needs to be done and exit quickly. The problem with this is that on a high load machine, for example lionfish during buildfarm runs, this would cause autovacuum starvation for the period in which the high load is sustained. This could prove dangerous. The problem is that things like fork() failure cannot be communicated back to the launcher. So when the postmaster tries to start a process and it fails for some reason (failure to fork, or out of memory) we need a way to re-initiate the worker that failed. The current code resets the starting worker pointer, and leave the slot free for another worker, maybe in another database, to start. I recently added code to resend the postmaster signal when the launcher sees the starting worker pointer not invalid -- step 2 above. I think this is fine, but 1) we should remove the logic to remove the starting worker pointer. It is not needed, because database-local failures will be handled by subsequent checks 2) we should leave the logic to resend the postmaster, but we should make an effort to avoid sending it too frequently Opinions? If I haven't stated the problem clearly please let me know and I'll try to rephrase. Isn't there some way to get the postmaster to signal the launcher? Perhaps stick an error code in shared memory and send it a signal? -- Jim Nasby[EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] temporal variants of generate_series()
On May 2, 2007, at 8:24 PM, JEAN-PIERRE PELLETIER wrote:
On the date variant, I wasn't sure how to handle intervals with
parts smaller than days:
floor, ceiling, round or error out
Hrm... I'm not sure what would be better there... I'm leaning towards
round (floor or ceil don't make much sense to me), but I could also
see throwing an error if trunc('day', $3) != $3. Comments?
Also, what would be the appropriate way to put this into initdb?
These seem a bit long to try and cram into a one-line DATA statement
in pg_proc.h. Should I add a new .sql file ala
information_schema.sql? Is it possible to still add pg_catalog
entries after the postgresql.bki stage of initdb?
Finally, should I also add a timestamp without time zone version? I
know we'll automatically cast timestamptz to timestamp, but then you
get a timestamptz back, which seems odd.
To get round, the last parameters of generate_series would be
extract('epoch' FROM '1 day'::interval)::bigint * round(extract
('epoch' FROM $3) / extract('epoch' FROM '1 day'::interval))::bigint
CREATE OR REPLACE FUNCTION generate_series (
start_ts timestamptz,
end_ts timestamptz,
step interval
) RETURNS SETOF timestamptz
STRICT
LANGUAGE sql
AS $$
SELECT
'epoch'::timestamptz + s.i * '1 second'::interval AS
generate_series
FROM
generate_series(
extract('epoch' FROM $1)::bigint,
extract('epoch' FROM $2)::bigint,
extract('epoch' FROM $3)::bigint
) s(i);
$$;
CREATE OR REPLACE FUNCTION generate_series (
start_ts date,
end_ts date,
step interval
) RETURNS SETOF date
STRICT
LANGUAGE sql
AS $$
SELECT
('epoch'::date + s.i * '1 second'::interval)::date AS
generate_series
FROM
generate_series(
extract('epoch' FROM $1)::bigint,
extract('epoch' FROM $2)::bigint,
extract('epoch' FROM date_trunc('day', $3))::bigint -- does
a floor
) s(i);
$$;
Jean-Pierre Pelletier
e-djuster
---(end of
broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
--
Jim Nasby[EMAIL PROTECTED]
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
