Re: [HACKERS] Explicit psqlrc
On Jun 23, 2010, at 5:36 PM, Mark Wong wrote: > On Jun 22, 2010, at 1:34 AM, Simon Riggs wrote: > >> On Mon, 2010-06-21 at 20:53 -0400, Robert Haas wrote: >>> On Mon, Jun 21, 2010 at 7:51 PM, gabrielle wrote: On Thu, 2010-06-17 at 14:50 -0400, Alvaro Herrera asked: > How does it play with ON_ERROR_STOP/ROLLBACK? With ON_ERROR_STOP=ON, psql issues an error when it encounters one, stops processing the file that contains the error, and then continues to process any remaining files. >> >> That would be undesirable. >> I'm still investigating ON_ERROR_ROLLBACK. I need to tinker with it some more before I say anything concrete. On Fri, Jun 18, 2010 at 1:48 AM, Simon Riggs wrote: > Also, how does it play with --single-transaction. That was buried in our original report :) "BEGIN-COMMIT statements within the files cause warnings when the command is wrapped in a transaction with the -1 switch (as specified in the patch submission)" To expand upon that a bit: when psql encounters a file that contains a BEGIN statement, you get the expected "WARNING: there is already a transaction in progress" message. The COMMIT at the end of that file (assuming the user doesn't forget it) generates a COMMIT. Commands after that commit, or in any remaining files to be processed, are dealt with according to the user's autocommit settings: - if autocommit is ON, statements in the remaining files are processed & committed; the implicit COMMIT at the end of the whole thing then generates a "WARNING: there is no transaction in progress" message - if autocommit is OFF, statements in the remaining files generate "ERROR: current transaction is aborted, commands ignored until end of transaction block" messages. >> >> This is the existing behaviour. >> >>> So none of the above sounds like desired behavior to me... is that just me? >> >> Single transaction needs some help, but that's not the fault of this >> patch. > > I took a closer look at what was going on and what it would take to meet some > of these expectations. In main() the patch adds BEGIN and COMMIT statements > outside the call to process_file() in src/bin/psql/command.c. Here lies the > previous logic for handling single transaction. Since it remains, it appears > that BEGIN can be issued twice before any statements are executed if the > single transaction switch is used. Plus there are other a couple of places > that call this particular process_file() function, but I think those are > straightforward cases to deal with. Heh, not close enough. I was wrong about that scenario. I can see now that the single transaction flag is always set to false in process_file(). I think that turns the single transaction handling in process_file() into dead code with the patch like this. Regards, Mark -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] TCP keepalive support for libpq
On Tue, Jun 22, 2010 at 12:32 PM, Magnus Hagander wrote: > I looked around quickly earlier when we chatted about this, and I > think I found an API call to change them for a socket as well - but a > Windows specific one, not the ones you'd find on Unix... Magnus - or anyone who knows Windows - Now that I've committed this patch, any chance you want to add a few lines of code to make this work on Windows also? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Explicit psqlrc
On Jun 22, 2010, at 1:34 AM, Simon Riggs wrote: > On Mon, 2010-06-21 at 20:53 -0400, Robert Haas wrote: >> On Mon, Jun 21, 2010 at 7:51 PM, gabrielle wrote: >>> On Thu, 2010-06-17 at 14:50 -0400, Alvaro Herrera asked: How does it play with ON_ERROR_STOP/ROLLBACK? >>> >>> With ON_ERROR_STOP=ON, psql issues an error when it encounters one, >>> stops processing the file that contains the error, and then continues >>> to process any remaining files. > > That would be undesirable. > >>> I'm still investigating ON_ERROR_ROLLBACK. I need to tinker with it >>> some more before I say anything concrete. >>> >>> On Fri, Jun 18, 2010 at 1:48 AM, Simon Riggs wrote: Also, how does it play with --single-transaction. >>> That was buried in our original report :) "BEGIN-COMMIT statements >>> within the files cause warnings when the command is wrapped in a >>> transaction with the -1 switch (as specified in the patch submission)" >>> >>> To expand upon that a bit: when psql encounters a file that contains >>> a BEGIN statement, you get the expected "WARNING: there is already a >>> transaction in progress" message. The COMMIT at the end of that file >>> (assuming the user doesn't forget it) generates a COMMIT. Commands >>> after that commit, or in any remaining files to be processed, are >>> dealt with according to the user's autocommit settings: >>> - if autocommit is ON, statements in the remaining files are processed >>> & committed; the implicit COMMIT at the end of the whole thing then >>> generates a "WARNING: there is no transaction in progress" message >>> - if autocommit is OFF, statements in the remaining files generate >>> "ERROR: current transaction is aborted, commands ignored until end of >>> transaction block" messages. > > This is the existing behaviour. > >> So none of the above sounds like desired behavior to me... is that just me? > > Single transaction needs some help, but that's not the fault of this > patch. I took a closer look at what was going on and what it would take to meet some of these expectations. In main() the patch adds BEGIN and COMMIT statements outside the call to process_file() in src/bin/psql/command.c. Here lies the previous logic for handling single transaction. Since it remains, it appears that BEGIN can be issued twice before any statements are executed if the single transaction switch is used. Plus there are other a couple of places that call this particular process_file() function, but I think those are straightforward cases to deal with. Regards, Mark -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] extensible enum types
Tom Lane wrote: Bruce Momjian writes: Well, we don't need the enum value to map into the entire oid range. Can't we just add one to the top-most value and see if there is a conflict? If you don't use the OID counter to generate the new value, you're going to have problems with race conditions. There's also that small chance that there is no free value before 2^32. The bottom line here is not wanting a feature that "usually" works but fails once in awhile on the basis of conditions the user can't control. Yeah, what I'm now hoping to be able to do, following good suggestions from Tom, is to provide a way to get virtually no degradation in bulk comparison performance in the common case where any additions have been made at the end of the list with no oid wraparound, and acceptable performance otherwise, but provide for an ability to add new values at arbitrary places in the ordering, with no limit. If we can do that why would we want less? cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] extensible enum types
Bruce Momjian writes: > Well, we don't need the enum value to map into the entire oid range. > Can't we just add one to the top-most value and see if there is a > conflict? If you don't use the OID counter to generate the new value, you're going to have problems with race conditions. There's also that small chance that there is no free value before 2^32. The bottom line here is not wanting a feature that "usually" works but fails once in awhile on the basis of conditions the user can't control. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] extensible enum types
Tom Lane wrote: > Bruce Momjian writes: > > Sorry to be commenting late, but don't most people want to add to the > > end or beginning of the enum list, rather than in the middle, and can't > > we support that already? > > We could allow adding a value, but we couldn't guarantee where it would > appear in the type's sort ordering. Depending on the current OID > counter it would usually show up either at the end or the beginning. > I think the general feeling is that this is too implementation-dependent > to be acceptable. Well, we don't need the enum value to map into the entire oid range. Can't we just add one to the top-most value and see if there is a conflict? -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] extensible enum types
Bruce Momjian writes: > Sorry to be commenting late, but don't most people want to add to the > end or beginning of the enum list, rather than in the middle, and can't > we support that already? We could allow adding a value, but we couldn't guarantee where it would appear in the type's sort ordering. Depending on the current OID counter it would usually show up either at the end or the beginning. I think the general feeling is that this is too implementation-dependent to be acceptable. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] extensible enum types
Tom Lane wrote: > Andrew Dunstan writes: > > Robert Haas wrote: > >> I like the idea of being able to modify enums on the fly, but I'm > >> skeptical of an implementation that won't always work. Maybe it's > >> still better than what we have now, but it seems grotty. > > > I'd be perfectly happy to hear a reasonable alternative. > > Insert a sort order column into pg_enum, and rearrange the values in > that whenever the user wants to add a new value in a particular place. > You give up cheap comparisons in exchange for flexibility. I think lots > of people would accept that tradeoff, especially if they could make it > per-datatype. > > One point here is that you'd have to restrict the rearrangements so that > the relative sort order of existing values never changes, else you break > (for example) indexes on columns of that type. Sorry to be commenting late, but don't most people want to add to the end or beginning of the enum list, rather than in the middle, and can't we support that already? -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Cannot cancel the change of a tablespace
Le 23/06/2010 22:54, Tom Lane a écrit : > Robert Haas writes: >> On Mon, Jun 21, 2010 at 12:46 PM, Guillaume Lelarge >> wrote: >>> I added a CHECK_FOR_INTERRUPTS call in the copy_relation_data(), >>> copy_dir(), and copy_file() functions. Works for me on ALTER TABLE ... >>> SET TABLESPACE and ALTER DATABASE ... SET TABLESPACE, in 9.0 and 8.4. > >> Adding a CHECK_FOR_INTERRUPTS() to copy_relation_data seems like it >> ought to be OK (though I haven't tested), but copydir() is in >> src/port, and I fear that putting CHECK_FOR_INTERRUPTS() in there >> might cause problems. > > copydir.c is already backend-specific thanks to all the ereport calls. > If we ever tried to make it usable in frontend code, we could easily > deal with CHECK_FOR_INTERRUPTS() via #ifndef FRONTEND --- changing the > error management would be far more painful. > I'm not sure I get it right. Do I need to do something on the patch so that it can get commited? -- Guillaume http://www.postgresql.fr http://dalibo.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] TCP keepalive support for libpq
On Wed, Jun 23, 2010 at 4:56 PM, Tom Lane wrote: > Fujii Masao writes: >> On Wed, Jun 23, 2010 at 5:32 AM, Robert Haas wrote: >>> OK, here's a new version with several fewer bugs. > >> Since valid values for keepalives parameter are 0 and 1, its field size >> should >> be 1 rather than 10. > > Right ... although maybe it should be considered a boolean and not an > int at all? Well, really, all libpq parameters are just strings, at this level. The dispsize is just a hint for, I guess, things like PGadmin; it's not actually used by libpq. >> In this case, you can check the value of keepalives parameter by seeing >> conn->keepalives[0] instead of using strtol() in useKeepalives(). > > I disagree with that idea, though. The field size has nothing to do > with most of the possible sources of the variable's value ... That is my thought also. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] TCP keepalive support for libpq
Fujii Masao writes: > On Wed, Jun 23, 2010 at 5:32 AM, Robert Haas wrote: >> OK, here's a new version with several fewer bugs. > Since valid values for keepalives parameter are 0 and 1, its field size should > be 1 rather than 10. Right ... although maybe it should be considered a boolean and not an int at all? > In this case, you can check the value of keepalives parameter by seeing > conn->keepalives[0] instead of using strtol() in useKeepalives(). I disagree with that idea, though. The field size has nothing to do with most of the possible sources of the variable's value ... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Cannot cancel the change of a tablespace
Robert Haas writes: > On Mon, Jun 21, 2010 at 12:46 PM, Guillaume Lelarge > wrote: >> I added a CHECK_FOR_INTERRUPTS call in the copy_relation_data(), >> copy_dir(), and copy_file() functions. Works for me on ALTER TABLE ... >> SET TABLESPACE and ALTER DATABASE ... SET TABLESPACE, in 9.0 and 8.4. > Adding a CHECK_FOR_INTERRUPTS() to copy_relation_data seems like it > ought to be OK (though I haven't tested), but copydir() is in > src/port, and I fear that putting CHECK_FOR_INTERRUPTS() in there > might cause problems. copydir.c is already backend-specific thanks to all the ereport calls. If we ever tried to make it usable in frontend code, we could easily deal with CHECK_FOR_INTERRUPTS() via #ifndef FRONTEND --- changing the error management would be far more painful. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ECPG FETCH readahead
Boszormenyi Zoltan wrote: > Hi, > > we improved ECPG quite a lot in 9.0 because we worked and > still working with an Informix to PostgreSQL migration project. > > We came across a pretty big performance problem that can be seen in > every "naive" application that uses only FETCH 1, FETCH RELATIVE > or FETCH ABSOLUTE. These are almost the only FETCH variations > usable in Informix, i.e. it doesn't have the grammar for fetching N rows > at once. Instead, the Client SDK libraries do caching themselves > behind the scenes to reduce network turnaround time. I assume our ecpg version supports >1 fetch values, even in Informix mode. Does it make sense to add lots of code to our ecpg then? -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [BUGS] Server crash while trying to read expression using pg_get_expr()
On Mon, Jun 21, 2010 at 7:50 PM, Heikki Linnakangas wrote: > On 15/06/10 10:31, Heikki Linnakangas wrote: >> >> You could avoid changing the meaning of fn_expr by putting the check in >> the parse analysis phase, into transformFuncCall(). That would feel >> safer at least for back-branches. > > Here's a patch using that approach. > > I grepped through PostgreSQL and pgadmin source code to find the system > columns where valid node-strings are stored: > > pg_index.indexprs > pg_index.indprep > pg_attrdef.adbin > pg_proc.proargdefaults > pg_constraint.conbin > > Am I missing anything? I think that pg_type.typdefaultbin is used by pg_dump. pg_rewrite.ev_qual, pg_rewrite.ev_action, pg_trigger.tgqual also contain nodeToString() output but I didn't have any luck using them with pg_get_expr() so maybe they don't need to be included. The only other thing I notice is that, obviously, the FIXME comment needs to be FIXMEd before commit. I'd still be in favor of inserting at least some basic error checks into readfuncs.c, though just in HEAD. The restrictions implemented here seem adequate to prevent a security vulnerability, but superusers can still invoke those functions manually, and while superusers can clearly crash the system in any number of ways, that doesn't seem (to me) like an adequate justification for ignoring the return value of strtok(). YMMV, of course. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] access method: are disk pages mandatory?
Heikki Linnakangas writes: > On 23/06/10 18:17, Leonardo F wrote: >> I'm not getting it: am I supposed to use the "disk page format" when >> writing an index access method, or it's just a "good practice" because >> it makes the handling easier? Given the docs it looks "recommended", >> but the comment on the code sounds more "mandatory". > It's recommened because it makes life easier. Even if you don't use the > normal page format, I think you need to have the LSN at the beginning of > the page. The rest is up to you. The bufpage.h comment is ancient and might not be 100% gospel anymore. However, I believe the buffer manager does assume that any page in shared buffers has a standard page header including LSN. It definitely assumes there's an LSN, and I think we have validity checks on the other page header fields somewhere inside ReadBuffer. You don't however need to use the item-and-item-pointer-array structure if it's not useful to you. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Partitioning syntax
On Wed, Jun 23, 2010 at 10:41 AM, Kevin Grittner wrote: > > It should have been. Neither the reviewer nor the author updated > the CF web page (as they should have done). I've just made the > entries to bring the patch it up to date in the web app. > Yeah! sorry i got bussy with other things... i will make a complete review in next days... -- Jaime Casanova www.2ndQuadrant.com Soporte y capacitación de PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] dividing money by money
Andy Balholm wrote: > On Jun 21, 2010, at 11:47 AM, Kevin Grittner wrote: >> The only issue is with the general guideline to make the new code >> blend in with existing code: > I deleted the excess comments and moved some lines around. Here it > is with the changes. I ran pgindent to standardize the white space. (No changes of substance.) Patch attached. I'll mark it "Ready for Committer". Thanks, Andy! Note to committer: I'm not set up to generate docs, so I just eyeballed the sgml. -Kevin dividing-money-2.diff Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Partitioning syntax
Hitoshi Harada wrote: > 2010/6/18 Takahiro Itagaki : >> I attached an updated patch set for partitioning syntax. > > Isn't this linked from the RF web app?? It should have been. Neither the reviewer nor the author updated the CF web page (as they should have done). I've just made the entries to bring the patch it up to date in the web app. I apologize for not picking up on the emails earlier. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] access method: are disk pages mandatory?
On 23/06/10 18:17, Leonardo F wrote: in bufpage.h: "all blocks written out by an access method must be disk pages" but in http://www.postgresql.org/docs/8.4/static/storage-page-layout.html "Actually, index access methods need not use this page format. All the existing index methods do use this basic format, but the data kept on index metapages usually doesn't follow the item layout rules." I'm not getting it: am I supposed to use the "disk page format" when writing an index access method, or it's just a "good practice" because it makes the handling easier? Given the docs it looks "recommended", but the comment on the code sounds more "mandatory". It's recommened because it makes life easier. Even if you don't use the normal page format, I think you need to have the LSN at the beginning of the page. The rest is up to you. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Partitioning syntax
2010/6/18 Takahiro Itagaki : > > Jaime Casanova wrote: > >> This one, doesn't apply to head anymore... please update > > Thank you for reviewing my patch! > > I attached an updated patch set for partitioning syntax. Isn't this linked from the RF web app?? Regards, -- Hitoshi Harada -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] access method: are disk pages mandatory?
in bufpage.h: "all blocks written out by an access method must be disk pages" but in http://www.postgresql.org/docs/8.4/static/storage-page-layout.html "Actually, index access methods need not use this page format. All the existing index methods do use this basic format, but the data kept on index metapages usually doesn't follow the item layout rules." I'm not getting it: am I supposed to use the "disk page format" when writing an index access method, or it's just a "good practice" because it makes the handling easier? Given the docs it looks "recommended", but the comment on the code sounds more "mandatory". -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] testing plpython3u on 9.0beta2
On Wed, Jun 23, 2010 at 10:30 AM, Tom Lane wrote: > Robert Haas writes: >> I can reproduce this, here. The problem seems to be that plpython >> only build either plpython2.so or plython3.so, but both languages >> expect a call handler called plython_call_handler. So once we load >> the shared library for one language, the other language just grabs the >> same call handler. > > We had better fix that --- I can definitely foresee installations > wanting to use both plpython2 and plpython3. This'd require a change in > the default contents of pg_pltemplate, though. Does it seem important > enough to bump catversion for? Yeah, I think so. As for using both plpython2 and plpython3, it looks to me like right now you can only use one or the other. I think if you somehow manage to install both, you're really just getting the same one twice (I have not tested this, however). -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] testing plpython3u on 9.0beta2
Robert Haas writes: > I can reproduce this, here. The problem seems to be that plpython > only build either plpython2.so or plython3.so, but both languages > expect a call handler called plython_call_handler. So once we load > the shared library for one language, the other language just grabs the > same call handler. We had better fix that --- I can definitely foresee installations wanting to use both plpython2 and plpython3. This'd require a change in the default contents of pg_pltemplate, though. Does it seem important enough to bump catversion for? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Explicit psqlrc
On Wed, Jun 23, 2010 at 9:17 AM, gabrielle wrote: > On Mon, Jun 21, 2010 at 6:16 PM, Robert Haas wrote: >> Well, that might be a good idea, too, but my expectation is that: >> >> psql -f one -f two -f three >> >> ought to behave in a manner fairly similar to: >> >> cat one two three > all >> psql -f all >> >> and it sounds like with this patch that's far from being the case. > > Correct. Each is handled individually. > > Should I continue to check on ON_ERROR_ROLLBACK results, or bounce > this back to the author? It doesn't hurt to continue to review and find other problems so that the author can try to fix them all at once, but it certainly seems clear that it's not ready to commit at this point, so it definitely needs to go back to the author for a rework. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Explicit psqlrc
On Mon, Jun 21, 2010 at 6:16 PM, Robert Haas wrote: > Well, that might be a good idea, too, but my expectation is that: > > psql -f one -f two -f three > > ought to behave in a manner fairly similar to: > > cat one two three > all > psql -f all > > and it sounds like with this patch that's far from being the case. Correct. Each is handled individually. Should I continue to check on ON_ERROR_ROLLBACK results, or bounce this back to the author? gabrielle -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Cannot cancel the change of a tablespace
On Mon, Jun 21, 2010 at 12:46 PM, Guillaume Lelarge wrote: > Today, I tried to cancel the change of a tablespace for a table (ALTER > TABLE ... SET TABLESPACE). I got the "Cancel request sent" but the query > continued and finally succeed. It was a big issue for my customer, and I > wanted to look more into that issue. So, I got a look at the source code > and found we didn't check for interrupts in this part of the code. I > added them, and it seems to work as I wanted. > > I added a CHECK_FOR_INTERRUPTS call in the copy_relation_data(), > copy_dir(), and copy_file() functions. Works for me on ALTER TABLE ... > SET TABLESPACE and ALTER DATABASE ... SET TABLESPACE, in 9.0 and 8.4. > > Not sure we really want that change, and it don't feel like a bug to me. > Should I add it to to the next commitfest? Adding a CHECK_FOR_INTERRUPTS() to copy_relation_data seems like it ought to be OK (though I haven't tested), but copydir() is in src/port, and I fear that putting CHECK_FOR_INTERRUPTS() in there might cause problems. I think that whatever portion of this we end up applying should be back-patched. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] testing plpython3u on 9.0beta2
On Tue, Jun 22, 2010 at 10:41 PM, Chris wrote: > I received two errors (described below) in installing 9.0beta2 on Kubuntu > 10.04 , RhodiumToad on IRC recommended I post them here. > I did not have a 2.x or 3.x python dev installed, but I was really only > interested in python3 via plython3u. > So... > sudo apt-get install python3-all-dev > Configure works fine... > "./configure --with-pgport=5433 --with-python --with-ossp-uuid --with-libxml > --with-libxslt --with-perl" > "make" fails while trying to build plpython, Cannot find python.h i > believe(I sadly did not save the text of the error and have since > continued onward. But it was not finding a file while building plpython. I > believe I would have to uninstall a few things to reproduce.) > So I tried installing the 2.x dev. After running "sudo apt-get install > python-all-dev" then "make;make check;sudo make install", it all worke fine. > However, when issuing a "createlang plpython3u template1", I get > "createlang: language installation failed: ERROR: could not access file > "$libdir/plpython3": No such file or directory". But if I "createlang > plpython2u template1" first, then it will allow "createlang plpython3u > template1". > Am I doing something incorrect, or...? > (As an aside, functions created with LANGUAGE plpython3u appear to work.) I can reproduce this, here. The problem seems to be that plpython only build either plpython2.so or plython3.so, but both languages expect a call handler called plython_call_handler. So once we load the shared library for one language, the other language just grabs the same call handler. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Parallel pg_restore versus old dump files
On Wed, Jun 23, 2010 at 2:26 AM, Tom Lane wrote: > Uh, that doesn't fix anything: if you can't seek, a TOC at the end of > the file is useless. And the cases where the writer can't seek are > likely to be identically the ones where the reader can't seek, viz > pg_dump piped to pg_restore (perhaps with some other programs between). That seems like a tenuous leap. A typical reason for the pipe is to transfer it to a different machine and that only has to be done once. But I'm not convinced it's such a great idea either for the reason I described -- It makes the case where pg_restore has to read through the whole archive that much harder to explain to users. So I'm not really going to argue for it too strongly. It's also a fair amount of extra complexity for not much gain. We would still need the fallback code anyways. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Parallel pg_restore versus old dump files
On Wed, Jun 23, 2010 at 03:26, Tom Lane wrote: > Andrew Dunstan writes: >>> 4. Is there any value in back-porting the Windows FSEEKO support into >>> 8.3 and 8.2? Arguably, not writing the data offsets is a performance >>> bug. However a back-port won't do anything for people who are dumping >>> with less than the latest minor release of pg_dump, so doing this might >>> be largely wasted effort. > >> I doubt it's worth it, but I could be persuaded otherwise. > > I'm leaning in that direction too. Anybody who's doing a version > upgrade really ought to be using the newer pg_dump version anyway ... +1 on not backpatching that stuff - it's build system related, so it's kind of fragile on the windows side :-) -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
