Re: [HACKERS] autovacuum starvation
Alvaro Herrera <[EMAIL PROTECTED]> writes: > We could have the postmaster signal the launcher, but the signal cannot > contain much useful info because the postmaster does generally not want > to write in shared memory. The postmaster already touches/writes in shared memory in pmsignal.c. The trick here is that whatever it does should be sufficiently constrained that arbitrarily-bad corruption of shared memory can't crash or freeze the postmaster. If you can meet that restriction, feel free to introduce some more signaling knowledge. 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] Re: [COMMITTERS] psqlodbc - psqlodbc: Put Autotools-generated files into subdirectory
Tom Lane wrote: > Hiroshi Inoue <[EMAIL PROTECTED]> writes: >> Could someone confirm the following my recognition ? > >> The LPGL package could add and release a copy of some Postgres BSD >> licensed code as LGPL ones together with the current LGPL code and >> then the package is still entirely LGPL. > > No, the files you borrowed from Postgres remain BSD --- you cannot > unilaterally relicense someone else's code. Oops I've completely misunderstood it. Probably I misread some articles about the coexistence. Many thanks. > This does not actually affect anything, since the BSD license terms are > more liberal than LGPL: you can distribute the combined package just as > easily as if it were all-LGPL, and anyone using the package is still > effectively bound by the LGPL terms for the useful parts. But it would > be appropriate to note that "files X,Y,Z are distributed under a > different license, namely ". Thanks for your clear explanation. regards, Hiroshi Inoue ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Behavior of GENERATED columns per SQL2003
Oracle 10g, MySQL 5, and SQL Server 2005 don't appear to support the syntax. The SQL:2003 SIGMOD paper [1] indicates pretty clearly that their intention is for the values of generated columns to be stored on disk: "... commonly used expressions are evaluated once and their results stored for future use" "Generated columns can lead to higher performance... because of reduced computation" -Dave [1] Eisenberg, A., Melton, J., Kulkarni, K., Michels, J., and Zemke, F. 2004. SQL:2003 has been published. SIGMOD Rec. 33, 1 (Mar. 2004), 119-126. http://www.sigmod.org/record/issues/0403/E.JimAndrew-standard.pdf Tom Lane wrote: I've been studying the SQL spec in a bit more detail and I'm suddenly thinking that we've got the behavior all wrong in the current GENERATED/IDENTITY patch. In particular, it looks to me like we've been implementing GENERATED ALWAYS AS (expr) according to the rules that the spec in fact lays down only for GENERATED ALWAYS AS IDENTITY. You'd think the two constructs would be pretty closely related but the behaviors specified by the spec are light-years apart. If you look closely, a "generated column" in the meaning of section 4.14.8 is one that has GENERATED ALWAYS AS (expr), and identity columns are *not* in this class. It looks to me like the behavior the spec intends for a generated column is actually that it can be implemented as a "virtual column" occupying no space on disk and instead computed on-the-fly when retrieved. Identity columns can have their values overridden by the user (it's a little harder if GENERATED ALWAYS, but still possible), and they don't change during an UPDATE unless specifically forced to. In contrast, generated columns cannot be overridden by assignment, and are recomputed from their base columns during updates. This realization also explains the following, otherwise rather strange, facts: * There is no GENERATED BY DEFAULT AS (expr) in the spec. * GENERATED expressions are specifically disallowed from containing subselects, calling functions that access any SQL-data, or being nondeterministic; hence their values depend solely on the regular columns in the same row. * While identity columns are updated (if needed) before execution of BEFORE triggers, generated columns are updated after BEFORE triggers; hence a BEFORE trigger can override the value in one case and not the other. (The current patch gets this wrong, btw.) * Generated columns are forcibly updated when their base columns change as a result of FK constraints (such as ON UPDATE CASCADE). It looks to me like a BEFORE trigger is actually the only place that can (transiently) see values of a generated column that are different from the result of applying the generation expression on the rest of the row. It's unclear whether that's intentional or an oversight. Is anyone familiar with a database that implements SQL-spec generated columns? Do they actually store the columns? regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Re: [COMMITTERS] psqlodbc - psqlodbc: Put Autotools-generated files into subdirectory
Hiroshi Inoue <[EMAIL PROTECTED]> writes: > Could someone confirm the following my recognition ? > The LPGL package could add and release a copy of some Postgres BSD > licensed code as LGPL ones together with the current LGPL code and > then the package is still entirely LGPL. No, the files you borrowed from Postgres remain BSD --- you cannot unilaterally relicense someone else's code. This does not actually affect anything, since the BSD license terms are more liberal than LGPL: you can distribute the combined package just as easily as if it were all-LGPL, and anyone using the package is still effectively bound by the LGPL terms for the useful parts. But it would be appropriate to note that "files X,Y,Z are distributed under a different license, namely ". This is not really different from the legal situation before, where you had in effect copied some Postgres code into acinclude.m4 without bothering to acknowledge it. But it would be more polite to acknowledge it. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Re: [COMMITTERS] psqlodbc - psqlodbc: Put Autotools-generated files into subdirectory
Joshua D. Drake wrote: Hiroshi Inoue wrote: Joshua D. Drake wrote: Andrew Dunstan wrote: Hiroshi Inoue wrote: Maybe it's BSD which is different from the license of psqlodbc (LGPL). Is there no problem with their coexistence ? Or is it possible for psqlodbc to be LGPL entirely ? I am having difficulty in understanding what the problem is. My understanding is that using BSD licensed code is ok in an LGPL project, but (probably) not vice versa. To my knowledge you can do it either way, as long as you remember that any changes to the lgpl code have to be released. Could you tell me a recommendation ? I feel completely LGPL one is simpler. If you are asking me, which code you should release under, I would suggest the LGPL as the psqlodbc driver is licensed under the LGPL. Thanks a lot. Could someone confirm the following my recognition ? The LPGL package could add and release a copy of some Postgres BSD licensed code as LGPL ones together with the current LGPL code and then the package is still entirely LGPL. When some changes are made on the LGPL but originally BSD licencsed code, we can't reflect the changes to the orignal Postgres code. regards, Hiroshi Inoue ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Re: [COMMITTERS] psqlodbc - psqlodbc: Put Autotools-generated files into subdirectory
Andrew Dunstan wrote: Hiroshi Inoue wrote: Maybe it's BSD which is different from the license of psqlodbc (LGPL). Is there no problem with their coexistence ? Or is it possible for psqlodbc to be LGPL entirely ? I am having difficulty in understanding what the problem is. My understanding is that using BSD licensed code is ok in an LGPL project, but (probably) not vice versa. Thanks. I'm not an expert about licence at all. Though it's impossible to release (L)GPL code as BSD one, it seems possible to release BSD code as (L)GPL one. I feel strange a little that there's no *give and take*. regards, Hiroshi Inoue ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_type
Tom Lane wrote: Yeah, adding a column to one of the core "bootstrap" tables is a real PITA. But I guess we don't do it often enough to justify having more infrastructure for that. Maybe we should beef up the comments in those few stratgegic headers files a bit though. Now to use the field If it hasn't occurred to you already: please add a test or two in typ_sanity.sql to check that the column is sane, eg the type it points to is a varlena type that points back to the element type. Yeah, I have the test below so far - will fix more when I have the name generation bit done. cheers andrew -- Make sure typarray points to a varlena array type of our own base SELECT p1.oid, p1.typname as basetype, p2.typname as arraytype, p2.typelem, p2.typlen FROM pg_type p1 left join pg_type p2 on (p1.typarray = p2.oid) WHERE p1.typarray <> 0 AND (p2.oid IS NULL OR p2.typelem <> p1.oid OR p2.typlen <> -1); ---(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] Re: [COMMITTERS] psqlodbc - psqlodbc: Put Autotools-generated files into subdirectory
Peter Eisentraut wrote: > Hiroshi Inoue wrote: >> I've not seen your reply yet. > > You keep sending your emails to randomly invented addresses, so I don't > get them. Must I mail them directly to you in the first place ? I'm sending the emails to pgsql-committes and pgsql-hackers also. Please note that the question is to your recent sudden change to psqlodbc. regards, Hiroshi Inoue ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] pg_type
Andrew Dunstan <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> One thing I've been burnt by in the past is failing to update the >> pg_class.h DATA statement to show the right number of columns. Also, >> you fixed both representations of the attribute list in pg_attribute.h, >> right? > Thanks. Yes, it was both pg_class and pg_attribute that I had missed. > All better now. ;-) Yeah, adding a column to one of the core "bootstrap" tables is a real PITA. But I guess we don't do it often enough to justify having more infrastructure for that. > Now to use the field If it hasn't occurred to you already: please add a test or two in typ_sanity.sql to check that the column is sane, eg the type it points to is a varlena type that points back to the element type. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_type
Tom Lane wrote: Andrew Dunstan <[EMAIL PROTECTED]> writes: I added a field to pg_type, updated all the bootstrap catalog entries, changed Natts_pg_type, and (I think) fixed the two places in pg_type.c that construct pg_type entries. However, initdb fails at the sysviews creation stage - the core dump shows it failing as shown below. Anyone have a quick idea what I might have missed / done wrong? One thing I've been burnt by in the past is failing to update the pg_class.h DATA statement to show the right number of columns. Also, you fixed both representations of the attribute list in pg_attribute.h, right? Thanks. Yes, it was both pg_class and pg_attribute that I had missed. All better now. ;-) Now to use the field 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
Re: [HACKERS] pg_type
Andrew Dunstan <[EMAIL PROTECTED]> writes: > I added a field to pg_type, updated all the bootstrap catalog entries, > changed Natts_pg_type, and (I think) fixed the two places in pg_type.c > that construct pg_type entries. However, initdb fails at the sysviews > creation stage - the core dump shows it failing as shown below. Anyone > have a quick idea what I might have missed / done wrong? One thing I've been burnt by in the past is failing to update the pg_class.h DATA statement to show the right number of columns. Also, you fixed both representations of the attribute list in pg_attribute.h, right? 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] BufFileWrite across MAX_PHYSICAL_FILESIZE boundary
"Kurt Harriman" <[EMAIL PROTECTED]> writes: > Just noticed buffile.c:292 doesn't look quite right where > BufFileDumpBuffer calls FileWrite: > bytestowrite = FileWrite(thisfile, file->buffer, bytestowrite); > It looks as though it would write the same data each time the > loop is iterated. Would this be better? > bytestowrite = FileWrite(thisfile, file->buffer + wpos, bytestowrite); Yeah, I think you're right. We've probably not seen this because in most usages the buffer is always block-aligned, but it looks possible for tuplestore.c to get out of alignment if its concurrent write/read feature is exercised just so. Do you want to try demonstrating the bug with a smaller-than-normal setting of MAX_PHYSICAL_FILESIZE? regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] pg_type
I added a field to pg_type, updated all the bootstrap catalog entries, changed Natts_pg_type, and (I think) fixed the two places in pg_type.c that construct pg_type entries. However, initdb fails at the sysviews creation stage - the core dump shows it failing as shown below. Anyone have a quick idea what I might have missed / done wrong? At this stage the new field is not actually used anywhere, so it can't be a problem with that. thanks andrew Program terminated with signal 11, Segmentation fault. #0 0x00444eac in heap_formtuple (tupleDescriptor=0xa59930, values=0x7fff81f7c800, nulls=0x7fff81f7c930 ' ' , "nn�") at heaptuple.c:157 157 if (ATT_IS_PACKABLE(att[i]) && (gdb) bt #0 0x00444eac in heap_formtuple (tupleDescriptor=0xa59930, values=0x7fff81f7c800, nulls=0x7fff81f7c930 ' ' , "nn�") at heaptuple.c:157 #1 0x004b3cbb in TypeCreate (typeName=0x7fff81f7cbb0 "pg_roles", typeNamespace=11, relationOid=10958, relationKind=118 'v', internalSize=, typeType=99 'c', typDelim=44 ',', inputProcedure=2290, outputProcedure=2291, receiveProcedure=2402, sendProcedure=2403, typmodinProcedure=0, typmodoutProcedure=0, analyzeProcedure=0, elementType=0, baseType=0, defaultTypeValue=0x0, defaultTypeBin=0x0, passedByValue=0 '\0', alignment=100 'd', storage=120 'x', typeMod=-1, typNDims=0, typeNotNull=0 '\0') at pg_type.c:332 #2 0x004a2e83 in heap_create_with_catalog (relname=0x7fff81f7cbb0 "pg_roles", relnamespace=11, reltablespace=0, relid=10958, ownerid=10, tupdesc=0xb30098, relkind=118 'v', shared_relation=0 '\0', oidislocal=0 '\0', oidinhcount=0, oncommit=ONCOMMIT_NOOP, reloptions=0, allow_system_table_mods=1 '\001') at heap.c:740 #3 0x00507774 in DefineRelation (stmt=0xb2ee28, relkind=optimized out>) at tablecmds.c:435 #4 0x0051ee95 in DefineView (stmt=0xacc538, queryString=optimized out>) at view.c:209 ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
[HACKERS] Behavior of GENERATED columns per SQL2003
I've been studying the SQL spec in a bit more detail and I'm suddenly thinking that we've got the behavior all wrong in the current GENERATED/IDENTITY patch. In particular, it looks to me like we've been implementing GENERATED ALWAYS AS (expr) according to the rules that the spec in fact lays down only for GENERATED ALWAYS AS IDENTITY. You'd think the two constructs would be pretty closely related but the behaviors specified by the spec are light-years apart. If you look closely, a "generated column" in the meaning of section 4.14.8 is one that has GENERATED ALWAYS AS (expr), and identity columns are *not* in this class. It looks to me like the behavior the spec intends for a generated column is actually that it can be implemented as a "virtual column" occupying no space on disk and instead computed on-the-fly when retrieved. Identity columns can have their values overridden by the user (it's a little harder if GENERATED ALWAYS, but still possible), and they don't change during an UPDATE unless specifically forced to. In contrast, generated columns cannot be overridden by assignment, and are recomputed from their base columns during updates. This realization also explains the following, otherwise rather strange, facts: * There is no GENERATED BY DEFAULT AS (expr) in the spec. * GENERATED expressions are specifically disallowed from containing subselects, calling functions that access any SQL-data, or being nondeterministic; hence their values depend solely on the regular columns in the same row. * While identity columns are updated (if needed) before execution of BEFORE triggers, generated columns are updated after BEFORE triggers; hence a BEFORE trigger can override the value in one case and not the other. (The current patch gets this wrong, btw.) * Generated columns are forcibly updated when their base columns change as a result of FK constraints (such as ON UPDATE CASCADE). It looks to me like a BEFORE trigger is actually the only place that can (transiently) see values of a generated column that are different from the result of applying the generation expression on the rest of the row. It's unclear whether that's intentional or an oversight. Is anyone familiar with a database that implements SQL-spec generated columns? Do they actually store the columns? regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] BufFileWrite across MAX_PHYSICAL_FILESIZE boundary
Just noticed buffile.c:292 doesn't look quite right where BufFileDumpBuffer calls FileWrite: bytestowrite = FileWrite(thisfile, file->buffer, bytestowrite); It looks as though it would write the same data each time the loop is iterated. Would this be better? bytestowrite = FileWrite(thisfile, file->buffer + wpos, bytestowrite); ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Re: [COMMITTERS] psqlodbc - psqlodbc: Put Autotools-generated files into subdirectory
Andrew Dunstan wrote: Hiroshi Inoue wrote: Maybe it's BSD which is different from the license of psqlodbc (LGPL). Is there no problem with their coexistence ? Or is it possible for psqlodbc to be LGPL entirely ? I am having difficulty in understanding what the problem is. My understanding is that using BSD licensed code is ok in an LGPL project, but (probably) not vice versa. To my knowledge you can do it either way, as long as you remember that any changes to the lgpl code have to be released. Joshua D. Drake cheers andrew ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Re: [COMMITTERS] psqlodbc - psqlodbc: Put Autotools-generated files into subdirectory
Hiroshi Inoue wrote: Maybe it's BSD which is different from the license of psqlodbc (LGPL). Is there no problem with their coexistence ? Or is it possible for psqlodbc to be LGPL entirely ? I am having difficulty in understanding what the problem is. My understanding is that using BSD licensed code is ok in an LGPL project, but (probably) not vice versa. cheers andrew ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] Re: [COMMITTERS] psqlodbc - psqlodbc: Put Autotools-generated files into subdirectory
Maybe it's BSD which is different from the license of psqlodbc (LGPL). Is there no problem with their coexistence ? Or is it possible for psqlodbc to be LGPL entirely ? Thanks a lot. Hiroshi Inoue Jim Nasby wrote: On May 6, 2007, at 4:38 PM, Hiroshi Inoue wrote: Under what license is this file distributed ? Could you please reply to my question ? It's from the PostgreSQL source tree, so whatever license that has. So what's it ? Could you please take account of developers in the psqlodbc project a little more ? [EMAIL PROTECTED]:59]~/pgsql/HEAD:61%cat COPYRIGHT PostgreSQL Database Management System (formerly known as Postgres, then as Postgres95) Portions Copyright (c) 1996-2007, PostgreSQL Global Development Group Portions Copyright (c) 1994, The Regents of the University of California Permission to use, copy, modify, and distribute this software and its documentation for any purpose, without fee, and without a written agreement is hereby granted, provided that the above copyright notice and this paragraph and the following two paragraphs appear in all copies. IN NO EVENT SHALL THE UNIVERSITY OF CALIFORNIA BE LIABLE TO ANY PARTY FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, INCLUDING LOST PROFITS, ARISING OUT OF THE USE OF THIS SOFTWARE AND ITS DOCUMENTATION, EVEN IF THE UNIVERSITY OF CALIFORNIA HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. THE UNIVERSITY OF CALIFORNIA SPECIFICALLY DISCLAIMS ANY WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE PROVIDED HEREUNDER IS ON AN "AS IS" BASIS, AND THE UNIVERSITY OF CALIFORNIA HAS NO OBLIGATIONS TO PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS. [EMAIL PROTECTED]:59]~/pgsql/HEAD:62% -- Jim Nasby[EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] autovacuum does not start in HEAD
ITAGAKI Takahiro wrote: > Alvaro Herrera <[EMAIL PROTECTED]> wrote: > > > ITAGAKI Takahiro wrote: > > > > I found that autovacuum launcher does not launch any workers in HEAD. > > > > > > The attached autovacuum-fix.patch could fix the problem. I changed > > > to use 'greater or equal' instead of 'greater' at the decision of > > > next autovacuum target. > > > > I have committed a patch which might fix this issue in autovacuum.c rev > > 1.44. > > Please retest. > > HEAD (r1.45) is still broken. We skip entries using the test > adl_next_worker - autovacuum_naptime < current_time <= adl_next_worker, > but the second inequation should be > adl_next_worker - autovacuum_naptime < current_time < adl_next_worker, > because adl_next_worker can equal current_time. Ok, I'll change this. > By the way, why do we need the upper bounds to decide a next target? > Can we use simplify it to "current_time < adl_next_worker"? No, we can't take that check out, because otherwise a database could be skipped forever if it happens to fall behind for some reason (for example when a new database is created and autovac decides to work on that one instead of the one that was scheduled). -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] Re: [COMMITTERS] psqlodbc - psqlodbc: Put Autotools-generated files into subdirectory
I've not seen your reply yet. Do you have a mind to cooperate with us ? I wrote: > Peter Eisentraut wrote: >> Hiroshi Inoue wrote: >>> Hiroshi Inoue wrote: User Petere wrote: > Log Message: > --- > Put Autotools-generated files into subdirectory config/; add macro > files used from PostgreSQL there so you don't need a PostgreSQL > source tree to bootstrap the code. > Added Files: > --- > psqlodbc/config: > general.m4 (r1.1) Under what license is this file distributed ? >>> Could you please reply to my question ? >> It's from the PostgreSQL source tree, so whatever license that has. > > So what's it ? > Could you please take account of developers in the psqlodbc project > a little more ? ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] autovacuum starvation
Jim Nasby wrote: > 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. > 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? We could have the postmaster signal the launcher, but the signal cannot contain much useful info because the postmaster does generally not want to write in shared memory. Perhaps we could have the postmaster send a SIGUSR2 signal, which would mean "couldn't start the worker" without any other info. Anything else the launcher needs can be deduced from shmem state anyway. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] plperl vs. bytea
Tom Lane wrote: Andrew Dunstan <[EMAIL PROTECTED]> writes: Tino Wildenhain wrote: Andrew Dunstan schrieb: This does not need to be over-engineered, IMNSHO. Well could you explain where it would appear over-engineered? Anything that imposes extra requirements on type creators seems undesirable. I'm not sure either that the UUID example is a very good one. This whole problem arose because of performance problems handling large gobs of data, not just anything that happens to be binary. Well, we realize that bytea has got a performance problem, but are we so sure that nothing else does? I don't want to stick in a one-purpose wart only to find later that we need a few more warts of the same kind. An example of something else we ought to be considering is binary transmission of float values. The argument in favor of that is not so much performance (although text-and-back conversion is hardly cheap) as it is that the conversion is potentially lossy, since float8out doesn't by default generate enough digits to ensure a unique back-conversion. ISTM there are three reasons for considering non-text-based transmission: 1. Performance, as in the bytea case 2. Avoidance of information loss, as for float 3. Providing a natural/convenient mapping to the PL's internal data types, as we already do --- but incompletely --- for arrays and records It's clear that the details of #3 have to vary across PLs, but I'd like it not to vary capriciously. For instance plperl currently has special treatment for returning perl arrays as SQL arrays, but AFAICS from the manual not for going in the other direction; plpython and pltcl overlook arrays entirely, even though there are natural mappings they could and should be using. I don't know to what extent we should apply point #3 to situations other than arrays and records, but now is the time to think about it. An example: working with the geometric types in a PL function is probably going to be pretty painful for lack of simple access to the constituent float values (not to mention the lossiness problem). We should also be considering some non-core PLs such as PL/Ruby and PL/R; they might provide additional examples to influence our thinking. OK, we have a lot of work to do here, then. I can really only speak with any significant knowledge on the perl front. Fundamentally, it has 3 types of scalars: IV, NV and PV (integer, float, string). IV can accomodate at least the largest integer or pointer type on the platform, NV a double, and PV an arbitrary string of bytes. As for structured types, as I noted elsewhere we have some of the work done for plperl. My suggestion would be to complete it for plperl and get it fully orthogonal and then retrofit that to plpython/pltcl. I've actually been worried for some time that the conversion glue was probably imposing significant penalties on the non-native PLs, so I'm glad to see this getting some attention. 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
Re: [HACKERS] plperl vs. bytea
Andrew Dunstan <[EMAIL PROTECTED]> writes: > Tino Wildenhain wrote: >> Andrew Dunstan schrieb: >>> This does not need to be over-engineered, IMNSHO. >> >> Well could you explain where it would appear over-engineered? > Anything that imposes extra requirements on type creators seems undesirable. > I'm not sure either that the UUID example is a very good one. This whole > problem arose because of performance problems handling large gobs of > data, not just anything that happens to be binary. Well, we realize that bytea has got a performance problem, but are we so sure that nothing else does? I don't want to stick in a one-purpose wart only to find later that we need a few more warts of the same kind. An example of something else we ought to be considering is binary transmission of float values. The argument in favor of that is not so much performance (although text-and-back conversion is hardly cheap) as it is that the conversion is potentially lossy, since float8out doesn't by default generate enough digits to ensure a unique back-conversion. ISTM there are three reasons for considering non-text-based transmission: 1. Performance, as in the bytea case 2. Avoidance of information loss, as for float 3. Providing a natural/convenient mapping to the PL's internal data types, as we already do --- but incompletely --- for arrays and records It's clear that the details of #3 have to vary across PLs, but I'd like it not to vary capriciously. For instance plperl currently has special treatment for returning perl arrays as SQL arrays, but AFAICS from the manual not for going in the other direction; plpython and pltcl overlook arrays entirely, even though there are natural mappings they could and should be using. I don't know to what extent we should apply point #3 to situations other than arrays and records, but now is the time to think about it. An example: working with the geometric types in a PL function is probably going to be pretty painful for lack of simple access to the constituent float values (not to mention the lossiness problem). We should also be considering some non-core PLs such as PL/Ruby and PL/R; they might provide additional examples to influence our thinking. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] plperl vs. bytea
Tino Wildenhain wrote: Andrew Dunstan schrieb: Tino Wildenhain wrote: Martijn van Oosterhout schrieb: ... > I do have one problem though: for bytea/integers/floats Perl has > appropriate internel representations. But what about other user-defined > types? Say the user-defined UUID type, it should probably also passed > by a byte string, yet how could Perl know that. That would imply that > user-defined types need to be able to specify how they are passed to > PLs, to *any* PL. > Yes exactly. One way could be to pass the type binary and provide a hull class for the PL/languages which then call the input/output routines on the string boundaries of the type unless overridden by user implementation. So default handling could be done in string representation of the type whatever that is and for a defined set of types every pl/language could implement special treatment like mapping to natural types. This handling can be done independently for every pl implementation since it would for the most types just move the current type treatment just a bit closer to the user code instead of doing all of it in the call handler. 2nd problem is language interface for outside of the database scripting. Efficient and lossless type handling there would improve some situations - maybe a similar approach could be taken here. This seems like an elaborate piece of scaffolding for a relatively small problem. This does not need to be over-engineered, IMNSHO. Well could you explain where it would appear over-engineered? All I was proposing is to move the rather hard-coded type mapping to a softer approach where the language is able to support it. Is there any insufficience in perl which makes it harder to do in a clean way? Anything that imposes extra requirements on type creators seems undesirable. I'm not sure either that the UUID example is a very good one. This whole problem arose because of performance problems handling large gobs of data, not just anything that happens to be binary. cheers andrew ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [COMMITTERS] pgsql: Teach tuplesort.c about "top N" sorting, in which only the first
Alvaro Herrera wrote: > Jim Nasby wrote: > >> If we really want to make the logfile the approved method for >> monitoring performance, then why do we have the stats infrastructure >> at all? It could all be replaced with logging output and pgfouine. > > First we'd have to fix the usability problem of our redirect_stderr > stuff for pgfouine (multiline messages from different backends are > mixed, according to Guillaume). I'd like to sign on to the list of people saying that logging isn't the best way to do performance measuring. Providing a way to get at the counters in realtime for monitoring or graphing or whatever is what AFAIK everybody else do, and it's for a good reason - it fits in to existing monitoring/management solutions. It may be that our current stats system isn't the best way to do this, but if it isn't that just means we have to come up with a better way. //Magnus ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] plperl vs. bytea
Andrew Dunstan schrieb: Tino Wildenhain wrote: Martijn van Oosterhout schrieb: ... > I do have one problem though: for bytea/integers/floats Perl has > appropriate internel representations. But what about other user-defined > types? Say the user-defined UUID type, it should probably also passed > by a byte string, yet how could Perl know that. That would imply that > user-defined types need to be able to specify how they are passed to > PLs, to *any* PL. > Yes exactly. One way could be to pass the type binary and provide a hull class for the PL/languages which then call the input/output routines on the string boundaries of the type unless overridden by user implementation. So default handling could be done in string representation of the type whatever that is and for a defined set of types every pl/language could implement special treatment like mapping to natural types. This handling can be done independently for every pl implementation since it would for the most types just move the current type treatment just a bit closer to the user code instead of doing all of it in the call handler. 2nd problem is language interface for outside of the database scripting. Efficient and lossless type handling there would improve some situations - maybe a similar approach could be taken here. This seems like an elaborate piece of scaffolding for a relatively small problem. This does not need to be over-engineered, IMNSHO. Well could you explain where it would appear over-engineered? All I was proposing is to move the rather hard-coded type mapping to a softer approach where the language is able to support it. Is there any insufficience in perl which makes it harder to do in a clean way? Regards Tino ---(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] [COMMITTERS] psqlodbc - psqlodbc: Put Autotools-generated files into subdirectory
On May 6, 2007, at 4:38 PM, Hiroshi Inoue wrote: Under what license is this file distributed ? Could you please reply to my question ? It's from the PostgreSQL source tree, so whatever license that has. So what's it ? Could you please take account of developers in the psqlodbc project a little more ? [EMAIL PROTECTED]:59]~/pgsql/HEAD:61%cat COPYRIGHT PostgreSQL Database Management System (formerly known as Postgres, then as Postgres95) Portions Copyright (c) 1996-2007, PostgreSQL Global Development Group Portions Copyright (c) 1994, The Regents of the University of California Permission to use, copy, modify, and distribute this software and its documentation for any purpose, without fee, and without a written agreement is hereby granted, provided that the above copyright notice and this paragraph and the following two paragraphs appear in all copies. IN NO EVENT SHALL THE UNIVERSITY OF CALIFORNIA BE LIABLE TO ANY PARTY FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, INCLUDING LOST PROFITS, ARISING OUT OF THE USE OF THIS SOFTWARE AND ITS DOCUMENTATION, EVEN IF THE UNIVERSITY OF CALIFORNIA HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. THE UNIVERSITY OF CALIFORNIA SPECIFICALLY DISCLAIMS ANY WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE PROVIDED HEREUNDER IS ON AN "AS IS" BASIS, AND THE UNIVERSITY OF CALIFORNIA HAS NO OBLIGATIONS TO PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS. [EMAIL PROTECTED]:59]~/pgsql/HEAD:62% -- 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] plperl vs. bytea
Martijn van Oosterhout <[EMAIL PROTECTED]> writes: > On Sun, May 06, 2007 at 08:48:28PM -0400, Tom Lane wrote: >> What we've basically got here is a complaint that the default >> textual-representation-based method for transmitting PL function >> parameters and results is awkward and inefficient for bytea. > I must say I was indeed surprised by the idea that bytea is passed by > text, since Perl handles embedded nulls in strings without any problem > at all. Does this mean integers are passed as text also? Pretty much everything is passed as text. This is a historical accident, in part: our first PL with an external interpreter was pltcl, and Tcl of the day had no other variable type besides "text string". (They've gotten smarter since then, but from a user's-eye point of view it's still true that every value in Tcl is a string.) So it was natural to decree that the value transmission protocol was just to convert to text and back with the SQL datatype I/O functions. Later PLs copied that decision without thinking hard about it. We've wedged a few bits of custom transmission protocol into plperl for arrays and records, but it's been pretty ad-hoc each time. Seems it's time to take a step back and question the assumptions. 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] New idea for patch tracking
On May 7, 2007, at 7:47 AM, Zdenek Kotala wrote: Jim Nasby wrote: And you describe current processes based on email communication. But if we setup some tracker some process will be changed. I think first step is determine what we really want and after we can discuss how to reach it. If we lived in an ideal world I'd agree with you 100%. But we live in PostgreSQL-community-world. :) There is a *lot* of resistance in the development community to going to any kind of a tracker, even if it would mean essentially zero change to how the development has to work. If you don't believe me go look in the archives; I believe this debate happens about twice a year, and every time the result is the same: lots of emails, zero change. Create own tracker is reinvent a wheel and waste a time. There are a lot of trackers and I believe that one of them fit postgres requirements. I agree with your idea to try one and if it will be necessary we can add some functionality. But I think that there are not clear requirements and I also afraid that there is not unified view of core team on this. Yes, when it comes to doing a full-blown tracker it would be a huge amount of wheel reinvention. But that's not the case with a simple patch tracker. Let's take the baby step of a patch tracker first and see what we learn from it. -- Jim Nasby[EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] plperl vs. bytea
Tino Wildenhain wrote: Martijn van Oosterhout schrieb: ... > I do have one problem though: for bytea/integers/floats Perl has > appropriate internel representations. But what about other user-defined > types? Say the user-defined UUID type, it should probably also passed > by a byte string, yet how could Perl know that. That would imply that > user-defined types need to be able to specify how they are passed to > PLs, to *any* PL. > Yes exactly. One way could be to pass the type binary and provide a hull class for the PL/languages which then call the input/output routines on the string boundaries of the type unless overridden by user implementation. So default handling could be done in string representation of the type whatever that is and for a defined set of types every pl/language could implement special treatment like mapping to natural types. This handling can be done independently for every pl implementation since it would for the most types just move the current type treatment just a bit closer to the user code instead of doing all of it in the call handler. 2nd problem is language interface for outside of the database scripting. Efficient and lossless type handling there would improve some situations - maybe a similar approach could be taken here. This seems like an elaborate piece of scaffolding for a relatively small problem. This does not need to be over-engineered, IMNSHO. 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] temporal variants of generate_series()
On May 6, 2007, at 8:07 PM, Tom Lane wrote:
Jim Nasby <[EMAIL PROTECTED]> writes:
Also, what would be the appropriate way to put this into initdb?
You seem to have missed a step here, which is to convince people that
these belong in core at all. So far I've not even seen an argument
that
would justify putting them in contrib.
These are all examples of using generate series plus additional math
to generate a series of dates/timestamps:
http://archives.postgresql.org/pgsql-general/2007-01/msg01292.php
http://archives.postgresql.org/pgsql-sql/2006-02/msg00249.php
http://archives.postgresql.org/pgsql-general/2005-06/msg01254.php
http://archives.postgresql.org/pgsql-sql/2007-03/msg00093.php
http://archives.postgresql.org/pgsql-novice/2007-01/msg2.php
http://archives.postgresql.org/pgsql-sql/2006-03/msg00391.php
http://archives.postgresql.org/pgsql-hackers/2006-09/msg00330.php
That's from the first page of search results for 'generate_series
timestamp'.
FWIW, I could also make use of this in some of my code.
If they *were* of sufficiently
wide use to justify putting them into core, a more efficient
implementation would probably be expected.
Ok, I'll look into a C version, but why do SQL functions have such a
high overhead? I'm seeing an SQL function taking ~2.6x longer than
the equivalent code run directly in a query. With 100 days, the
difference drops a bit to ~2.4x. (this is on HEAD from a few months ago)
This is on my MacBook Pro with the Jean-Pierre's version of
generate_series:
decibel=# select count(*) from generate_series(now(),now()+'10
days'::interval,'1'::interval);
Time: 1851.407 ms
decibel=# select count(*) from generate_series(1,86400*10);
Time: 657.894 ms
decibel=# select count(*) from (select now() + (generate_series
(1,86400*10) * '1 second'::interval)) a;
Time: 733.592 ms
decibel=# select count(*) from (select 'epoch'::timestamptz + s.i *
'1 second'::interval AS "generate_series" from generate_series(extract
('epoch' from now())::bigint, extract('epoch' from now()+'10
days'::interval)::bigint, extract('epoch' from
'1'::interval)::bigint) s(i)) a;
Time: 699.606 ms
--
Jim Nasby[EMAIL PROTECTED]
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
---(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] plperl vs. bytea
Tom Lane wrote: My GUC proposal would have made it language+type specific, but Tom didn't like that approach. It may indeed need to be language+type specific; what I was objecting to was the proposal of an ad-hoc plperl-specific solution without any consideration for other languages (or other data types for that matter). I think that's working at the wrong level of detail, at least for initial design. What we've basically got here is a complaint that the default textual-representation-based method for transmitting PL function parameters and results is awkward and inefficient for bytea. So the first question is whether this is really localized to only bytea, and if not which other types have got similar issues. (Even if you make the case that no other scalar types need help, what of bytea[] and composite types containing bytea or bytea[]?) Well, the proposal would have allowed the user to specify the types to be passed binary, so it wouldn't have been bytea only. Array types are currently passed as text. This item used to be on the TODO list but it disappeared at some stage: . Pass arrays natively instead of as text between plperl and postgres (Perhaps it's naughty of me to observe that if we had a tracker we might know why it disappeared). Arrays can be returned as arrayrefs, and plperl has a little postprocessing magic that turns that into text which will in turn be parsed back into a postgres array. Not very efficient but it's a placeholder until we get better array support. Composites are in fact passed as hashrefs and can be returned as hashrefs. Unfortunately, this is not true recursively - a composite within a composite will be received as text. Another aspect of this is how we deal with SPI arguments and results. I need to look into that, but sufficient unto the day ... cheers andrew ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Patch queue triage
Sorry for late responce due to very long vacation season in Japan. Tom Lane wrote: > > * Re: [PATCHES] [HACKERS] Full page writes improvement, code update > >/Koichi Suzuki/ > > > > I feel that we have to insist that this be modified to not create any WAL > > bloat in the pre-compression form. That will be more efficient and will > > avoid the whole argument about whether a switch is needed. There was also > > doubt about whether the external programs (pg_compresslog etc) were ready > > for prime time. At this point we could accept a patch that makes whatever > > small tweaks are needed to ensure that an incremental-format WAL record > > can be extracted from a full-page-write record, at least for the most > > common WAL record types for which compression is actually important. I > > think the actual compression/decompression programs could undergo further > > development on pgfoundry with an eye to merging them into core before 8.4 > > release. As suggested by Tom, I agree that WAL should not include "both" full page write and incremental (logical) log. I began to examine WAL record format to see if incremental log can be made from full page writes. It will be okay even before 8.4, if simplified patch to the core is accepted. I will post simplified patch to the core as follows: 1. Mark the flag to indicate that the WAL record is compressable from full page writes to incremental log. This flag will be set if a) It is not written during the hot backup, and b) Archive command is active, and c) WAL contains full page writes, and d) full_page_writes=on. No logical log will be written to WAL in this case, and 2. During recovery, xl_tot_len check will be skipped for compressed WAL records. With this patch, compress/decompress can be developped outside the core. I'd like to post them to PG foundary first for the review for 8.4. I'd be very grateful if this patch can be considered again. Best Regards; Koichi Suzuki ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] New idea for patch tracking
Jim Nasby wrote: People have suggested different trackers that have varying amounts of email capability, but I don't think any of them have had the full capability that we'd need. At best they might accept comments on a bug/issue via email, but to work for the community they'd need to go beyond that. You'd have to be able to resolve via email (preferably tied to -commiters). You'd need to be able to make a bug as invalid. You'd need to be able to open a new issue via email. And change status. And assign it to someone. And it would have to actually thread discussion to be useful. Probably some other things as well. As I wrote few days ago. You can see how and what use e.g. Apache Derby community. I guess more of mentioned issues they have solved and we can take some of their ideas. However I still miss list of tracker requirements - what tracker MUST have and what is nice to have. And you describe current processes based on email communication. But if we setup some tracker some process will be changed. I think first step is determine what we really want and after we can discuss how to reach it. Since a system like that doesn't exist I think it's going to be up to us to create one. When it comes to the full set of features you'd expect out of an issue tracker, it would probably make sense to start with an existing project and try and add this functionality. But right now I don't think such an effort would work well, because we don't know well enough how all these new features should work. Create own tracker is reinvent a wheel and waste a time. There are a lot of trackers and I believe that one of them fit postgres requirements. I agree with your idea to try one and if it will be necessary we can add some functionality. But I think that there are not clear requirements and I also afraid that there is not unified view of core team on this. I suggest following process: 1) create list of requirements - MUST HAVE/NICE TO HAVE 2) create list of tracker 3) reject trackers which does not fit "MUST HAVE" 4) each member of core team create own order 5) results will be put together and one tracker will be select for testing. 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: [PATCHES] [HACKERS] Full page writes improvement, code update
Hi,
As replied to "Patch queue triage" by Tom, here's simplified patch to
mark WAL record as "compressable", with no increase in WAL itself.
Compression/decompression commands will be posted separately to PG
Foundary for further review.
---
As suggested by Tom, I agree that WAL should not include "both" full
page write and incremental (logical) log. I began to examine WAL
record format to see if incremental log can be made from full page
writes. It will be okay even before 8.4, if simplified patch to the
core is accepted. I will post simplified patch to the core as follows:
1. Mark the flag to indicate that the WAL record is compressable from
full page writes to incremental log. This flag will be set if
a) It is not written during the hot backup, and
b) Archive command is active, and
c) WAL contains full page writes, and
d) full_page_writes=on.
No logical log will be written to WAL in this case, and
2. During recovery, xl_tot_len check will be skipped for compressed WAL
records.
Please note that new GUC is not needed in this patch.
With this patch, compress/decompress can be developped outside the core.
I'd be very grateful if this patch can be considered again.
Best Regards;
--
-
Koichi Suzuki
diff -cr pgsql_org/src/backend/access/transam/xlog.c
pgsql/src/backend/access/transam/xlog.c
*** pgsql_org/src/backend/access/transam/xlog.c 2007-05-02 15:56:38.0
+0900
--- pgsql/src/backend/access/transam/xlog.c 2007-05-07 16:30:38.0
+0900
***
*** 837,842
--- 837,854
return RecPtr;
}
+ /*
+* If online backup is not in progress and WAL archiving is active, mark
+* backup blocks removable if any.
+* This mark will be referenced during archiving to remove needless
backup
+* blocks in the record and compress WAL segment files.
+*/
+ if (XLogArchivingActive() && fullPageWrites &&
+ (info & XLR_BKP_BLOCK_MASK) && !Insert->forcePageWrites)
+ {
+ info |= XLR_BKP_REMOVABLE;
+ }
+
/* Insert record header */
record = (XLogRecord *) Insert->currpos;
***
*** 2738,2750
blk += blen;
}
! /* Check that xl_tot_len agrees with our calculation */
! if (blk != (char *) record + record->xl_tot_len)
{
! ereport(emode,
! (errmsg("incorrect total length in record at
%X/%X",
! recptr.xlogid,
recptr.xrecoff)));
! return false;
}
/* Finally include the record header */
--- 2750,2778
blk += blen;
}
! /*
!* If physical log has not been removed, check the length to see
!* the following.
!* - No physical log existed originally,
!* - WAL record was not removable because it is generated during
!* the online backup,
!* - Cannot be removed because the physical log spanned in
!* two segments.
!* The reason why we skip the length check on the physical log removal
is
!* that the flag XLR_SET_BKB_BLOCK(0..2) is reset to zero and it
prevents
!* the above loop to proceed blk to the end of the record.
!*/
! if (!(record->xl_info & XLR_BKP_REMOVABLE) ||
! record->xl_info & XLR_BKP_BLOCK_MASK)
{
! /* Check that xl_tot_len agrees with our calculation */
! if (blk != (char *) record + record->xl_tot_len)
! {
! ereport(emode,
! (errmsg("incorrect total length in
record at %X/%X",
! recptr.xlogid,
recptr.xrecoff)));
! return false;
! }
}
/* Finally include the record header */
pgsql/src/backend/access/transamã ãã«çºè¦: xlog.c.orig
diff -cr pgsql_org/src/include/access/xlog.h pgsql/src/include/access/xlog.h
*** pgsql_org/src/include/access/xlog.h 2007-01-06 07:19:51.0 +0900
--- pgsql/src/include/access/xlog.h 2007-05-07 16:30:38.0 +0900
***
*** 66,73
/*
* If we backed up any disk blocks with the XLOG record, we use flag bits in
* xl_info to signal it. We support backup of up to 3 disk blocks per XLOG
! * record.(Could support 4 if we cared to dedicate all the xl_info bits
for
! * this purpose; currently bit 0 of xl_info is unused and available.)
*/
#define XLR_BKP_BLOCK_MASK0x0E/* all info bits used for bkp
blocks */
#define XLR_MAX_BKP_BLOCKS3
--- 66,74
/*
* If we backed up any disk blocks with the XLOG record, we use flag bits in
* xl_info to signal it. We support backup of up to 3 disk blocks per XLOG
! * record.
! * Bit 0 of xl_info is used to re
Re: [HACKERS] Managing the community information stream
On May 6, 2007, at 8:18 AM, Andrew Dunstan wrote: Oh, the answer to Bruce's question about when to create a feature item? You could well do it at the time when today you create a TODO item. However, we might even do better. For example, we might well add feature requests that are denied. That would help people to see if something has been proposed before. The problem with our current TODO process is that whether an item makes it onto the list is essentially determined by did the idea catch a committer's attention, and did that committer happen to think it was a good idea. That sets the bar pretty high for getting stuff on the list (which you need for a simple list like TODO), but it also means it's very subjective. (Of course 98% of the time that committer is Bruce, but I don't think that matters here...) The subjectivity is because we don't have an effective means to get information about how PostgreSQL is used in the field. Sometimes you can mine that information out of the archives, but that's a pretty tedious process (and therefor one that's unlikely to happen). But that's also not necessarily representative... many people will try and find an answer to something on their own and not post anything to the lists at all, even if the 'answer' they find isn't very optimal. Instead, if all feature requests are tracked then users can vote on what's most important to them. That provides immediate feedback to the community on how important something is to the users. http:// lnk.nu/bugzilla.mozilla.org/edc.cgi is an example of that for Firefox. -- Jim Nasby[EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] plperl vs. bytea
Martijn van Oosterhout schrieb: ... > I do have one problem though: for bytea/integers/floats Perl has > appropriate internel representations. But what about other user-defined > types? Say the user-defined UUID type, it should probably also passed > by a byte string, yet how could Perl know that. That would imply that > user-defined types need to be able to specify how they are passed to > PLs, to *any* PL. > Yes exactly. One way could be to pass the type binary and provide a hull class for the PL/languages which then call the input/output routines on the string boundaries of the type unless overridden by user implementation. So default handling could be done in string representation of the type whatever that is and for a defined set of types every pl/language could implement special treatment like mapping to natural types. This handling can be done independently for every pl implementation since it would for the most types just move the current type treatment just a bit closer to the user code instead of doing all of it in the call handler. 2nd problem is language interface for outside of the database scripting. Efficient and lossless type handling there would improve some situations - maybe a similar approach could be taken here. Regards Tino ---(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
On Sun, May 06, 2007 at 08:48:28PM -0400, Tom Lane wrote: > What we've basically got here is a complaint that the default > textual-representation-based method for transmitting PL function > parameters and results is awkward and inefficient for bytea. > So the first question is whether this is really localized to only > bytea, and if not which other types have got similar issues. > (Even if you make the case that no other scalar types need help, > what of bytea[] and composite types containing bytea or bytea[]?) I must say I was indeed surprised by the idea that bytea is passed by text, since Perl handles embedded nulls in strings without any problem at all. Does this mean integers are passed as text also? I would have expected an array argument to be passed as an array, but now I'm not so sure. So I'm with Tom on this one: there needs to be a serious discussion about how types are passed to Perl and the costs associated with it. I do have one problem though: for bytea/integers/floats Perl has appropriate internel representations. But what about other user-defined types? Say the user-defined UUID type, it should probably also passed by a byte string, yet how could Perl know that. That would imply that user-defined types need to be able to specify how they are passed to PLs, to *any* PL. So fixing it for bytea is one thing, but there's a bigger issue here that needs discussion. Have a nice day, -- Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to > litigate. signature.asc Description: Digital signature
