Re: [PATCHES] Configurable Penalty Costs for Levenshtein
Hi, Sorry for the delay, but the reply of Tom didn't reach me. I've modified the patch according to Tom's comments. I hope I am not too late. Regards. fuzzystrmatch-levenshtein.patch.1 Description: Binary data On Wed, 2 Apr 2008, Bruce Momjian <[EMAIL PROTECTED]> writes: > Because of lack of reply from the author, this has been saved for the > next commit-fest: > > http://momjian.postgresql.org/cgi-bin/pgpatches_hold > > --- > > Tom Lane wrote: >> Volkan YAZICI <[EMAIL PROTECTED]> writes: >> > I noticed a small typo in the patch. >> > prev = palloc((m + n) * sizeof(char)); >> > line should look like >> > prev = palloc(2 * m * sizeof(char)); >> > instead. >> >> If that's wrong, aren't the comments and the length restriction limit >> also wrong? -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] actualized SQL/PSM patch
Hello > > I'm not against having SQL/PSM support. I'm just saying I'm not > willing to support two copies of plpgsql to do it. > > regards, tom lane > I understand it well. Pending development of plpgpsm I respected unbreakability plpgsql. So I can move duplicate parts to separate files and I'll do it. I thinking about new directory structure (some like) pl/sqlsp/ .. sql Stored Procedures pl/sqlsp/utils pl/sqlsp/plpgsql - only plpgpsm code pl/sqlsp/plpgpsm - only plpgsql code Regards Pavel Stehule -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] actualized SQL/PSM patch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 03 Apr 2008 00:57:11 -0400 Tom Lane <[EMAIL PROTECTED]> wrote: > "Joshua D. Drake" <[EMAIL PROTECTED]> writes: > > Tom Lane <[EMAIL PROTECTED]> wrote: > >> The fundamental problem I've got with this patch is that it adds > >> 400K of new code (and that's just the code, not counting > >> documentation or regression tests) that we'll have to maintain, to > >> obtain a feature that so far as I've heard there is precisely zero > >> demand for. > > > That is likely because everyone knew he was working on it. > > By "everyone" I suppose you mean the dozen or three people who are > paying close attention to who's doing what in PG development. Well I think that is a bit of an understatement. I know that I have talked to people about this patch for some time. Even well before 8.3 came out. > I'm not against having SQL/PSM support. I'm just saying I'm not > willing to support two copies of plpgsql to do it. I didn't disagree with you Tom. Joshua D. Drake - -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH9GTnATb/zqfZUUQRAlaqAJ0bU/N625e5+BoVQRepETsU4Lij5gCfQ5qo xOqTAATx8P9AW7ZKE0qAE+I= =g2v9 -END PGP SIGNATURE- -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] actualized SQL/PSM patch
Andrew Dunstan <[EMAIL PROTECTED]> writes: > ... I suspect anyone wanting to migrate > their existing SQL/PSM stuff to Postgres will be less than impressed by > our "function body as a string" mechanism. Yeah, that's the other little problem with claiming standards-compliance as a reason for doing this. We'd really have to suck it up and figure some other way of parsing function bodies. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] actualized SQL/PSM patch
"Joshua D. Drake" <[EMAIL PROTECTED]> writes: > Tom Lane <[EMAIL PROTECTED]> wrote: >> The fundamental problem I've got with this patch is that it adds 400K >> of new code (and that's just the code, not counting documentation or >> regression tests) that we'll have to maintain, to obtain a feature >> that so far as I've heard there is precisely zero demand for. > That is likely because everyone knew he was working on it. By "everyone" I suppose you mean the dozen or three people who are paying close attention to who's doing what in PG development. The above argument is hogwash, really. If SQL/PSM support were so widely desired as to justify a code addition of this size, then the archives would be littered with requests for it. Try to find some. (As a reasonable comparison point for what it takes to justify a large code addition, compare that to the number of times that text search requests show up --- most of them coming from people who don't know who Oleg and Teodor are.) I'm not against having SQL/PSM support. I'm just saying I'm not willing to support two copies of plpgsql to do it. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] actualized SQL/PSM patch
Jonah H. Harris wrote: On Tue, Apr 1, 2008 at 5:55 PM, Tom Lane <[EMAIL PROTECTED]> wrote: The fundamental problem I've got with this patch is that it adds 400K of new code (and that's just the code, not counting documentation or regression tests) that we'll have to maintain, to obtain a feature that so far as I've heard there is precisely zero demand for. We have a customer that wants to use it as part of a MySQL-to-Postgres migration. Using an implementation like this? I suspect anyone wanting to migrate their existing SQL/PSM stuff to Postgres will be less than impressed by our "function body as a string" mechanism. cheers andrew -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] actualized SQL/PSM patch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 01 Apr 2008 17:55:45 -0400 Tom Lane <[EMAIL PROTECTED]> wrote: > "Pavel Stehule" <[EMAIL PROTECTED]> writes: > > I actualized sql/psm patch. This patch can be downloaded from > > http://www.pgsql.cz/patches/plpgpsm.diff.gz > > The fundamental problem I've got with this patch is that it adds 400K > of new code (and that's just the code, not counting documentation or > regression tests) that we'll have to maintain, to obtain a feature > that so far as I've heard there is precisely zero demand for. That is likely because everyone knew he was working on it. Consider this my +1 for pl/psm support. > > The duplicativeness of the code with plpgsql doesn't make this > prospect any more pleasant, either. However, I do agree with you here. I would much prefer it be cleaned up into its own space. > > The idea would be a lot easier to swallow if the code were refactored > to avoid the duplication with plpgsql. +1. Sincerely, Joshua D. Drake - -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH9EIYATb/zqfZUUQRAmkiAJ9Q5s2Lsit7lW60sczr1/wxEGX2LACdH2rl 079G3tiL/Jj+B7FU6G5e65c= =nnba -END PGP SIGNATURE- -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Consistent \d commands in psql
"Tom Lane" <[EMAIL PROTECTED]> writes: > "Greg Sabino Mullane" <[EMAIL PROTECTED]> writes: >>> \df Lists all user functions >>> \df [pattern] Lists both system and user functions matching [pattern] >>> \df * Lists all system and user functions > >> I don't like this for two reasons: the items returned changes based on >> the existence of args, rather than on the command itself, and more >> importantly, this would make it inconsistent with the other backslash >> commands. > > I think you misunderstood the context of the discussion. Whatever we do > will be done to the whole family of \d commands --- we are just using > \df as an exemplar. Hm, I didn't realize that. I thought the reason \df was special was that users often need to refer to "system" functions. Whereas they never need to refer to system tables or system sequences etc unless they know that's what they're looking for. However, now that I look at the list of \d commands that argument kind of falls flat. Users also need to find "system" operators, data types, etc. And I think the same logic as \df applies for those other things too. \dt pg_class should "just work". And if you create a macaddr data type it doesn't seem like too much of an imposition to play it safe and have \dT macaddr show the user that there are now two matching data types. So I guess I should just play along and pretend that's what I meant all along :) -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS support! -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] psql command aliases support
"Peter Eisentraut" <[EMAIL PROTECTED]> writes: > Am Dienstag, 1. April 2008 schrieb Tom Lane: >> Do we really want such a thing? > > Yes! > >> The space of backslash command names >> is so densely populated already that it's hard to imagine creating >> aliases without conflicting with existing (or future) command names >> --- as indeed your example does. It seems like mostly a recipe for >> confusion. > > This is a standard feature and effect on shells. Shells have even more > likely > commands and conflicts, and still aliases are widely used. If people are > concerned about conflicts, they shouldn't use aliases. I think you're crazy to think shells are more likely to have conflicts. Shells require a whole token match, not just the first letter. In other words, any alias *starting with* the letters c, d, e, f, g, h, i, o, s, w, z would be a conflict. Just for maximum confusion the list of letters which cause conflicts when capitalized would be entirely different. Picture a newbie typoing on their \old alias and trying to figure out where all their data is going... Hopefully they weren't too attached to whatever was in their "ldd" file yesterday. I could see it being handy being able to save commonly executed queries and access them with a shortcut but I think you need to use a separate namespace from psql's backslash commands. Perhaps `query` or invent a single backslash command to execute them like "\query current_query". Actually I like that last idea the most. One thing to think about is how to pass arguments to the aliases. Csh put us in the soup by hacking in arguments in a terrible way. As a result quoting in csh aliases is awful. Even if it's not implemented right away I think we should figure out what the syntax would be for passing arguments to be interpolated into the query before backing ourselves into a corner. I can't imagine much of a use case for being able to alias backslash commands themselves. They're already ridiculously terse anyways. How many keystrokes can you possibly save? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's On-Demand Production Tuning -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] actualized SQL/PSM patch
On Tue, Apr 1, 2008 at 5:55 PM, Tom Lane <[EMAIL PROTECTED]> wrote: > The fundamental problem I've got with this patch is that it adds 400K > of new code (and that's just the code, not counting documentation or > regression tests) that we'll have to maintain, to obtain a feature that > so far as I've heard there is precisely zero demand for. We have a customer that wants to use it as part of a MySQL-to-Postgres migration. -- Jonah H. Harris, Sr. Software Architect | phone: 732.331.1324 EnterpriseDB Corporation | fax: 732.331.1301 499 Thornall Street, 2nd Floor | [EMAIL PROTECTED] Edison, NJ 08837 | http://www.enterprisedb.com/ -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] [8.4] Updated WITH clause patch (non-recursive)
There is little support for adding this patch without the recursive part, so I added the URLs for this thread to the TODO list under recursive queries. --- Neil Conway wrote: > Attached is an updated version of Greg Stark's patch to add support for > the non-recursive variant of the SQL99 WITH clause[1]. I haven't looked > at the actual functionality of the patch yet (which is quite trivial) -- > I just fixed up bitrot and the like. I also removed support for > RECURSIVE and the search/cycle clause, along with their associated > keywords -- the current patch doesn't approach anything close to adding > support for the non-recursive case, so it seems like a net loss to add > additional keywords for no gain in functionality. > > Remaining work is to review the guts of the patch (which shouldn't take > long), and write documentation and regression tests. I'm personally > hoping to see this get into the tree fairly early in the 8.4 cycle, > pending discussion of course. > > -Neil > > [1] http://archives.postgresql.org/pgsql-patches/2007-03/msg00139.php > http://archives.postgresql.org/pgsql-patches/2007-04/msg00055.php [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 5: don't forget to increase your free space map settings -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] actualized SQL/PSM patch
The author has received feedback so this has been saved for the next commit-fest: http://momjian.postgresql.org/cgi-bin/pgpatches_hold --- Pavel Stehule wrote: > Hello > > On 01/04/2008, Tom Lane <[EMAIL PROTECTED]> wrote: > > "Pavel Stehule" <[EMAIL PROTECTED]> writes: > > > I actualized sql/psm patch. This patch can be downloaded from > > > http://www.pgsql.cz/patches/plpgpsm.diff.gz > > > > The fundamental problem I've got with this patch is that it adds 400K > > of new code (and that's just the code, not counting documentation or > > regression tests) that we'll have to maintain, to obtain a feature that > > so far as I've heard there is precisely zero demand for. > > > > The duplicativeness of the code with plpgsql doesn't make this prospect > > any more pleasant, either. > > > > The idea would be a lot easier to swallow if the code were refactored > > to avoid the duplication with plpgsql. > > > > This is long run and needs hard reorganisation of plpgsql code. And > moving some plpgsql code to core. But I don't expect so plpgpsm code > can be less than 200KB. > > Regards > Pavel Stehule > > > regards, tom lane > > > > -- > Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-patches -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Consistent \d commands in psql
The patch author has been given feedback, so this has been saved for the next commit-fest: http://momjian.postgresql.org/cgi-bin/pgpatches_hold --- Greg Sabino Mullane wrote: [ There is text before PGP section. ] > > -BEGIN PGP SIGNED MESSAGE- > Hash: RIPEMD160 > > > > \df Lists all user functions > > \df [pattern] Lists both system and user functions matching [pattern] > > \df * Lists all system and user functions > > I don't like this for two reasons: the items returned changes based on > the existence of args, rather than on the command itself, and more > importantly, this would make it inconsistent with the other backslash > commands. > > > One question: should \df really list *all* nonsystem functions? Or just > > the ones that are visible in your search path? I'd be inclined to say > > the second. > > Agreed, we should respect the search path like the other commands do. > Although I wonder if a long-term idea would be to at least indicate > that there are other same-named things in your path? > > - -- > Greg Sabino Mullane [EMAIL PROTECTED] [EMAIL PROTECTED] > End Point Corporation 610-983-9073 > PGP Key: 0x14964AC8 200804020915 > http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 > -BEGIN PGP SIGNATURE- > > iEYEAREDAAYFAkfzh0IACgkQvJuQZxSWSsgTCgCdEv1vl7c0uIpIU3pSiH/VLvEg > m5wAni5/gJ0K2w1gpaNaWpVFCRJX200f > =ZnTm > -END PGP SIGNATURE- > > > > -- > Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-patches -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Configurable Penalty Costs for Levenshtein
Because of lack of reply from the author, this has been saved for the next commit-fest: http://momjian.postgresql.org/cgi-bin/pgpatches_hold --- Tom Lane wrote: > Volkan YAZICI <[EMAIL PROTECTED]> writes: > > I noticed a small typo in the patch. > > prev = palloc((m + n) * sizeof(char)); > > line should look like > > prev = palloc(2 * m * sizeof(char)); > > instead. > > If that's wrong, aren't the comments and the length restriction limit > also wrong? > > regards, tom lane > > -- > Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-patches -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Patch to add a feature to pg_standby
On Wed, 2008-04-02 at 12:43 -0400, [EMAIL PROTECTED] wrote: > Please consider incorporating this feature. Thanks, sounds very interesting. I'll have a look in more detail over next few days. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Changes to building dynamically loadable modules
Peter Eisentraut <[EMAIL PROTECTED]> writes: > The attached patch implements a few changes to how shared libraries and > dynamically loadable modules are built. Looks like a good idea to me, though I've not read it in great detail (I hate unidiffs). regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Consistent \d commands in psql
Andrew Dunstan wrote: > > > Tom Lane wrote: > > One question: should \df really list *all* nonsystem functions? Or > > just the ones that are visible in your search path? I'd be > > inclined to say the second. > > > > > > > > > +1 (although maybe that discussion belongs on -hackers, or even > -general) +1. It seems to be what would follow from the principle of least surprise that this works the same way as \dt does - as close as possible, that is. //Magnus -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
[PATCHES] Changes to building dynamically loadable modules
The attached patch implements a few changes to how shared libraries and dynamically loadable modules are built. Foremost, it creates a solid distinction between these two types of targets based on what had already been implemented and duplicated in ad hoc ways before. Specifically, - Dynamically loadable modules no longer get a soname. The numbers previously set in the makefiles were dummy numbers anyway, and the presence of a soname upset a few packaging tools, so it is nicer not to have one. - The cumbersome detour taken on installation (build a libfoo.so.0.0.0 and then override the rule to install foo.so instead) is removed. - Lots of duplicated code simplified. diff --git a/src/Makefile.shlib b/src/Makefile.shlib index ba488d5..75b2494 100644 --- a/src/Makefile.shlib +++ b/src/Makefile.shlib @@ -19,13 +19,18 @@ # variables: # # NAME Name of library to build (no suffix nor "lib" prefix) -# SO_MAJOR_VERSION Major version number to use for shared library -# SO_MINOR_VERSION Minor version number to use for shared library # OBJS List of object files to include in library # SHLIB_LINKIf shared library relies on other libraries, # additional stuff to put in its link command # SHLIB_EXPORTS (optional) Name of file containing list of symbols to # export +# +# When building a shared library, the following version information +# must also be set. It should be omitted when building a dynamically +# loadable module. +# +# SO_MAJOR_VERSION Major version number to use for shared library +# SO_MINOR_VERSION Minor version number to use for shared library # (If you want a patchlevel, include it in SO_MINOR_VERSION, e.g., "6.2".) # # Optional flags when building DLL's (only applicable to win32 and cygwin @@ -42,6 +47,7 @@ # # all-lib build the static and shared (if applicable) libraries # install-lib install the libraries into $(libdir) +# installdirs-lib create installation directory $(libdir) # uninstall-lib remove the libraries from $(libdir) # clean-lib delete the static and shared libraries from the build dir # maintainer-clean-lib delete .def files built for win32 @@ -72,18 +78,34 @@ LINK.static = $(AR) $(AROPT) -ifeq ($(enable_shared), yes) - # Insert -L from LDFLAGS after any -L already present in SHLIB_LINK SHLIB_LINK := $(filter -L%, $(SHLIB_LINK)) $(filter -L%, $(LDFLAGS)) $(filter-out -L%, $(SHLIB_LINK)) # Need a -L-free version of LDFLAGS to use in combination with SHLIB_LINK LDFLAGS_NO_L = $(filter-out -L%, $(LDFLAGS)) -# Default shlib naming convention used by the majority of platforms +ifdef SO_MAJOR_VERSION +# Default library naming convention used by the majority of platforms +ifeq ($(enable_shared), yes) shlib = lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION).$(SO_MINOR_VERSION) shlib_major = lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION) shlib_bare = lib$(NAME)$(DLSUFFIX) +endif +# Testing the soname variable is a reliable way to determine whether a +# linkable library is being built. +soname = $(shlib_major) +stlib = lib$(NAME).a +else +# Naming convention for dynamically loadable modules +ifeq ($(enable_shared), yes) +shlib = $(NAME)$(DLSUFFIX) +endif +endif + +ifndef soname +# additional flags for backend modules +SHLIB_LINK := $(BE_DLLLIBS) $(SHLIB_LINK) +endif # For each platform we support shared libraries on, set shlib to the # name of the library (if default above is not right), set @@ -94,29 +116,29 @@ shlib_bare = lib$(NAME)$(DLSUFFIX) override CFLAGS += $(CFLAGS_SL) -soname = lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION) - ifeq ($(PORTNAME), aix) - shlib = lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION) + ifdef SO_MAJOR_VERSION +shlib = lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION) + endif haslibarule = yes exports_file = lib$(NAME).exp endif ifeq ($(PORTNAME), darwin) - ifneq ($(SO_MAJOR_VERSION), 0) -version_link = -compatibility_version $(SO_MAJOR_VERSION) -current_version $(SO_MAJOR_VERSION).$(SO_MINOR_VERSION) - endif - ifeq ($(DLTYPE), library) + ifdef soname # linkable library DLSUFFIX = .dylib +ifneq ($(SO_MAJOR_VERSION), 0) + version_link = -compatibility_version $(SO_MAJOR_VERSION) -current_version $(SO_MAJOR_VERSION).$(SO_MINOR_VERSION) +endif LINK.shared = $(COMPILER) -dynamiclib -install_name $(libdir)/lib$(NAME).$(SO_MAJOR_VERSION)$(DLSUFFIX) $(version_link) $(exported_symbols_list) -multiply_defined suppress +shlib = lib$(NAME).$(SO_MAJOR_VERSION).$(SO_MINOR_VERSION)$(DLSUFFIX) +shlib_major = lib$(NAME).$(SO_MAJOR_VERSION)$(DLSUFFIX) else -# loadable module (default case) +# loadable module DLSUFFIX = .so LINK.shared = $(COMPILER) -bundle -multiply_defined suppress endif - shlib = lib$(NAME).$(SO_MAJOR_VERSION).$(SO_MINOR_VERSION)$(DLSUFFIX) - shlib_major = lib$(NAME).$(SO_M
[PATCHES] Patch to add a feature to pg_standby
When using pg_standby to remain in recovery mode on a warm standby system, if there is a need to perform other actions in coordination with recovery actions, the -x option implemented by this patch enables that coordination. I considered adding the ability to override the restoreCommand, however by keeping this separate and optional it is possible to force retries of the auxiliary command until successful and still utilize pg_usleep instead of looping within an external script or command. And the previous behavior of pg_standby remains unchanged (other than debug logging and documenting the option in usage) if the new option is omitted. I added this feature to help with synchronization of a content repository consisting of a PostgreSQL db for meta-information and a separate file store for content. The auxiliary command enables forcing an rsync of the file store that is at least as current as the found WAL segment file's db changes, and prevents recovery of that WAL file unless the rsync can be performed successfully. (See attached file: pg_standby.c.diff) Please consider incorporating this feature. Chris _ Christopher K. Johnson Director of IT DeskNet Inc. RHCE# 804005699817957 "A society grows great when old men plant trees whose shade they know they shall never sit in" - Greek Proverb pg_standby.c.diff Description: Binary data -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] [HACKERS] POSIX shared memory support
Yes, that is understandable. I'm not sure that there is a robust portable solution that doesn't involve a major rearchitecture. I'm not sure that would be worth the risk given the reward. Thanks, Chris On Apr 2, 2008, at 8:50 AM, Bruce Momjian wrote: The original patch author: Chris Marcellino <[EMAIL PROTECTED]> was not CC'ed as part of this email thread. That was a mistake. Chris, the email thread discussing your patch is here: http://archives.postgresql.org/pgsql-hackers/2008-03/ msg01262.php Please read the discussion --- the bottom line is that there isn't much support for the patch. Magnus was able to do the POSIX usage without relying on shared memory, but I just talked to him via IM and he said it used a Win32-specific feature that isn't portable to Unix. I am holding this patch for the next commit fest in hopes you can adjust it, but if not the patch will be rejected at that time. --- Stephen Frost wrote: -- Start of PGP signed section. Chris, et al, (commit-fest consensus discussion) * Chris Marcellino wrote: In case you haven't had enough, here is another version of the code to make Postgres use POSIX shared memory. Along with the issues that have already been addressed, this version ensures that orphaned backends are not in the database when restarting Postgres by using a single 1 byte SysV segment to see who is attached to the segment using shmctl/IPC_STAT/nattach. This really feels like a deal-breaker to me. My first reaction to this patch, honestly, is that it's being justified for all the wrong reasons. Changing to POSIX shm seems like a reasonable goal in general, provided it can do what we need, but doing it to work around silly defaults doesn't really work for me. If the real issue you have is with the SysV limits then I'd suggest you bring that up with the kernel/ distribution folks to get them to use something more sane. Looking around a bit, it looks like it's already being addressed in some places, for example Solaris 10 apparently uses 1/4th of memory, while Centos 5 uses 4GB. Suse also uses a larger default, from what I understand. Supporting this effort to get it raised on various platforms and distributions seems like a much better approach. Additionally, it strikes me that there *is* a limit on POSIX shared memory too, generally half of ram on the systems I've looked at, but there's no guarentee that'll always be the default or that half of ram will always be enough for us. So, even with this change, the problem isn't completely 'solved'. Finding a way for POSIX shm to do what we need, including Tom's concerns, without depending on SvsV shm as a crutch work around, would make this change much more reasonable and could be justified as moving to a well defined POSIX standard, and means we may be able to support platforms which either are new and don't implement SysV but just POSIX, or cases where SysV is being actively depreceated. Neither of which is possible if we're stuck with using it in some cases. Thanks, Stephen -- End of PGP section, PGP failed! -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Consistent \d commands in psql
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/04/2008, Greg Sabino Mullane wrote: > > \df Lists all user functions > > \df [pattern] Lists both system and user functions matching [pattern] > > \df * Lists all system and user functions > > I don't like this for two reasons: the items returned changes based on > the existence of args, rather than on the command itself, and more > importantly, this would make it inconsistent with the other backslash > commands. > To address your first complaint, I think it makes perfect sense to behave differently based on whether an argument has been supplied. The existence of a pattern tells you something about the user's intention in issuing the command. If they provide a pattern, they probably want to /search/ for something. If they don't provide a pattern they probably want to get a /listing/ of some set. Regards, BJ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: http://getfiregpg.org iD8DBQFH86u15YBsbHkuyV0RAmcMAKCy44zQaEcPA+QDpXr2+3vrSPucDwCgg3FG 8cq7P2DvI/ogqrHwM9Zpzx0= =IEvi -END PGP SIGNATURE- -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Consistent \d commands in psql
"Greg Sabino Mullane" <[EMAIL PROTECTED]> writes: >> \df Lists all user functions >> \df [pattern] Lists both system and user functions matching [pattern] >> \df * Lists all system and user functions > I don't like this for two reasons: the items returned changes based on > the existence of args, rather than on the command itself, and more > importantly, this would make it inconsistent with the other backslash > commands. I think you misunderstood the context of the discussion. Whatever we do will be done to the whole family of \d commands --- we are just using \df as an exemplar. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Consistent \d commands in psql
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 > \df Lists all user functions > \df [pattern] Lists both system and user functions matching [pattern] > \df * Lists all system and user functions I don't like this for two reasons: the items returned changes based on the existence of args, rather than on the command itself, and more importantly, this would make it inconsistent with the other backslash commands. > One question: should \df really list *all* nonsystem functions? Or just > the ones that are visible in your search path? I'd be inclined to say > the second. Agreed, we should respect the search path like the other commands do. Although I wonder if a long-term idea would be to at least indicate that there are other same-named things in your path? - -- Greg Sabino Mullane [EMAIL PROTECTED] [EMAIL PROTECTED] End Point Corporation 610-983-9073 PGP Key: 0x14964AC8 200804020915 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iEYEAREDAAYFAkfzh0IACgkQvJuQZxSWSsgTCgCdEv1vl7c0uIpIU3pSiH/VLvEg m5wAni5/gJ0K2w1gpaNaWpVFCRJX200f =ZnTm -END PGP SIGNATURE- -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Friendly help for psql
Index: mainloop.c
===
RCS file: /projects/cvsroot/pgsql/src/bin/psql/mainloop.c,v
retrieving revision 1.87
diff -c -r1.87 mainloop.c
*** mainloop.c 1 Jan 2008 19:45:56 - 1.87
--- mainloop.c 2 Apr 2008 12:51:36 -
***
*** 171,176
--- 171,187
continue;
}
+/* A request for help? Be friendly and give them some guidance */
+if (pset.cur_cmd_interactive && query_buf->len == 0 &&
+ pg_strncasecmp(line, "help", 4) == 0) {
+ free(line);
+ puts("You are using psql, the command-line interface to PostgreSQL.");
+ puts("Enter SQL commands, or type \\? for a list of backslash options.");
+ puts("Use \\q to quit.");
+ puts("Visit http://postgresql.org for help on PostgreSQL\n");
+ continue;
+}
+
/* echo back if flag is set */
if (pset.echo == PSQL_ECHO_ALL && !pset.cur_cmd_interactive)
puts(line);
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Show login privilege in psql \du command
This feature is being added by another patch so this patch is no longer needed --- See the INHERIT \du thread. --- Bernd Helmle wrote: > Please find attached a tiny patch which adds a "Login" field to the \du > command, displaying wether a role has the LOGIN privilege granted or not. I > found this useful, since you have to query the system catalog directly to > find out which role is permitted to login. > > -- > Thanks > > Bernd [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 4: Have you searched our list archives? > >http://archives.postgresql.org -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Improve shutdown during online backup
Simon Riggs wrote:
>> Few comments:
>>
>> * smart shutdown waits for sessions to complete, yet this just ignores
>> smart shutdowns which is something a little different. I think we
>> should wait for the backup to complete and then shutdown.
That would be more consistent, I agree.
I'll undo my changes to pg_ctl as well, as they make no more sense then.
>> * The #defines at top of postmaster.c are duplicated from xlog.c
>> If we can't agree on a common header file then we should at least add a
>> comment to mention they are duplicated (in both locations).
>
> If we add a function called something like BackupInProgress()
> to xlog.c,
> exported via miscadmin.h then we can use it within the
> PostmasterStateMachine() function like this
>
> if (pmState == PM_WAIT_BACKENDS)
> {
> if (CountChildren() == 0 &&
> StartupPID == 0 &&
> (BgWriterPID == 0 || !FatalError) &&
> WalWriterPID == 0 &&
> AutoVacPID == 0 &&
> !BackupInProgress()) < new line
>
> so that the postmaster doesn't need to know about how we do backups.
>
> That way you don't need any of the special cases in your patch, nor is
> there any need to duplicate the #defines.
I realized that duplicating the #defines was ugly, and will do it
like that.
Thanks for the hints.
Yours,
Laurenz Albe
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
