[PATCHES] tiny patch to make vacuumdb -a's database order match pg_dumpall
Hiya, I've been having trouble running vacuumdb -a and pg_dumpall concurrently because they run through the databases in a different order (so dumpall was getting stuck behind vacuum's lock, and my firewall was rather unhelpfully closing the idle connection). I can't see a good reason for them to be using a different order, and as it will only affect those that have created new databases since restoring from a dump, may not be instantly obvious. It appears slightly more thought has gone into pg_dumpall's code (in that it actually includes an ORDER BY), so I elected to fiddle with vacuumdb. I hope this is in the correct format (this is the first patch I've submitted for anything), please let me know if I've done something daft. Dan 237c237 < result = executeQuery(conn, "SELECT datname FROM pg_database WHERE datallowconn;", progname, echo); --- result = executeQuery(conn, "SELECT datname FROM pg_database WHERE datallowconn ORDER BY 1;", progname, echo); ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [PATCHES] plpgsql, return can contains any
This has been saved for the 8.3 release: http://momjian.postgresql.org/cgi-bin/pgpatches_hold --- Pavel Stehule wrote: > > > > > >"Pavel Stehule" <[EMAIL PROTECTED]> writes: > > >> This patch doesn't seem to cope with cases where the supplied tuple has > > >> the wrong number of columns, and it doesn't look like it's being > >careful > > >> about dropped columns either. Also, that's a mighty bizarre-looking > > >> choice of cache memory context in coerce_to_tuple ... but then again, > > >> why are you bothering with a cache at all for temporary arrays? > > > > > I am sorry, Tom. But I don't understand. I can check number of columns, > > > ofcourse and I'll do it. What cache for temporary arrays do you mean? > > > >I thought that making coerce_to_tuple depend on estate->err_func was > >pretty bizarre, and that there was no need for any "cache" at all for > >arrays that need only live as long as the function runs. All you are > >saving here is a palloc/pfree cycle, which is not worth the obscurantism > >and risk of bugs (are you sure natts can never change?). > > No, cache there is ugly. But I don't have idea about more efective > implementation of it :-(. First version of this patch was more clean. and > little bit slow. This cache save 10%. > > > > >BTW, if you want this patch to make it into 8.2, it needs to be fixed > >and resubmitted *very* soon. > > I understand, but I am not able work on it in next four days. And I need > help with it from Neil. It will be for 8.3. > > Thank you > Pavel > > _ > Emotikony a pozadi programu MSN Messenger ozivi vasi konverzaci. > http://messenger.msn.cz/ > > > ---(end of broadcast)--- > TIP 5: don't forget to increase your free space map settings -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] [HACKERS] Timezone List
"Magnus Hagander" <[EMAIL PROTECTED]> writes: >>> Assuming we can sneak this in even though it's feature-freeze, >>> want me to look for it? >> Yeah, please take a look --- seeing the size of the code will >> probably help us decide if it's too late for 8.2 or not. > Here goes. Tested only on win32 so far, but works there. No docs yet > either - need to know if it goes in first ;) I've applied this along with some extra work to get it to show GMT offsets and DST status, which should be useful for helping people to choose which setting they want. This effectively obsoletes Table B-5 as well as B-4 in the SGML docs ... we should probably remove both of those in favor of recommending people look at the views. I did the basic documentation work in catalogs.sgml for these views, but Appendix B still needs an update. Joachim, you were going to do that, right? regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] patch for contrib/xml2
"Nikolay Samokhvalov" <[EMAIL PROTECTED]> writes: > Here is the patch for contrib/xml2 (attached), that: > - renames xml_valid() to xml_is_well_formed() > - adds PG_MODULE_MAGIC; at the beginning of xpath.c > - introduces xpath_array() function > - adds some words about that function and caution about libraries to README I've applied the part of this patch that renames xml_valid() to xml_is_well_formed(), as well as the documentation fix. The PG_MODULE_MAGIC problem was already fixed a few days ago. I did not apply the addition of xpath_array, on the grounds that it's well past feature freeze and there doesn't seem to be any consensus in favor of adding it now. We should revisit this in 8.3 instead. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] Tiny plpython fix
"Magnus Hagander" <[EMAIL PROTECTED]> writes: >> If we need this change in plpython, why not also >> src/include/port/win32.h? > That's a very good question. It is because something that's pulled in > from the python headers causes the deprecation to show. Whereas when we > compile other things, the deprecation is hidden somewhere in an #ifdef > or so. But its definitly not *wrong* to fix it in win32.h as well. OK, changed it both places. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] Tiny plpython fix
> > Seems __vc_errcode was used during Visual C++ beta at some > point, and > > is now declared deprecated in the system headers. This > patch renames > > our use of it to __msvc_errcode, so we don't conflict anymore. > > If we need this change in plpython, why not also > src/include/port/win32.h? That's a very good question. It is because something that's pulled in from the python headers causes the deprecation to show. Whereas when we compile other things, the deprecation is hidden somewhere in an #ifdef or so. But its definitly not *wrong* to fix it in win32.h as well. The level of header files can be quite horrible to find this in, so I haven't dug deep enough to find exactly which define it comes from. But given that it's somewhere in the python headers, it's not something we can change anyway. //Magnus ---(end of broadcast)--- TIP 6: explain analyze is your friend
