Thread: contrib uninstall scripts need some love
Awhile back, someone went around and made sure that all the contrib
modules had uninstall scripts, but most of the new contributions since
then don't have 'em:adminpack hstore pg_freespacemap pgrowlocks sslinfo
all seem to need one. Also, I tested a few of the existing uninstall
scripts in passing while fixing the contains/contained mess, and two
out of four were broken (failed to remove everything installed by the
module, as shown by getting errors if you then try to reinstall it).
Seems like this area needs more attention ... anyone want to work on it?
regards, tom lane
Tom Lane wrote: > Awhile back, someone went around and made sure that all the contrib > modules had uninstall scripts, but most of the new contributions since > then don't have 'em: > adminpack hstore pg_freespacemap pgrowlocks sslinfo > all seem to need one. Also, I tested a few of the existing uninstall > scripts in passing while fixing the contains/contained mess, and two > out of four were broken (failed to remove everything installed by the > module, as shown by getting errors if you then try to reinstall it). > Seems like this area needs more attention ... anyone want to work on it? I'll take it. How long do I have? Joshua D. Drake > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 2: Don't 'kill -9' the postmaster > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
On Sun, Sep 10, 2006 at 12:09:24PM -0700, Joshua D. Drake wrote: > Tom Lane wrote: > >Awhile back, someone went around and made sure that all the contrib > >modules had uninstall scripts, but most of the new contributions since > >then don't have 'em: > > adminpack hstore pg_freespacemap pgrowlocks sslinfo > >all seem to need one. Also, I tested a few of the existing uninstall > >scripts in passing while fixing the contains/contained mess, and two > >out of four were broken (failed to remove everything installed by the > >module, as shown by getting errors if you then try to reinstall it). > >Seems like this area needs more attention ... anyone want to work on it? > > I'll take it. How long do I have? For reference, here are some comments about the cleanup work I did a while back: http://archives.postgresql.org/pgsql-patches/2006-03/msg00163.php -- Michael Fuhr
"Joshua D. Drake" <jd@commandprompt.com> writes:
> Tom Lane wrote:
>> Seems like this area needs more attention ... anyone want to work on it?
> I'll take it. How long do I have?
Since it's contrib, I don't think we need to hold you to being done
before beta1. But the sooner the better of course.
regards, tom lane
Tom Lane wrote: > "Joshua D. Drake" <jd@commandprompt.com> writes: >> Tom Lane wrote: >>> Seems like this area needs more attention ... anyone want to work on it? > >> I'll take it. How long do I have? > > Since it's contrib, I don't think we need to hold you to being done > before beta1. But the sooner the better of course. O.k., I will start working through it and report at the end of the week. Joshua D. Drake > > regards, tom lane > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
Let me know if you need an extra pair of eyes. G.- On 9/10/06, Joshua D. Drake <jd@commandprompt.com> wrote: > Tom Lane wrote: > > "Joshua D. Drake" <jd@commandprompt.com> writes: > >> Tom Lane wrote: > >>> Seems like this area needs more attention ... anyone want to work on it? > > > >> I'll take it. How long do I have? > > > > Since it's contrib, I don't think we need to hold you to being done > > before beta1. But the sooner the better of course. > > O.k., I will start working through it and report at the end of the week. > > Joshua D. Drake > > > > > > regards, tom lane > > > > > -- > > === The PostgreSQL Company: Command Prompt, Inc. === > Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 > Providing the most comprehensive PostgreSQL solutions since 1997 > http://www.commandprompt.com/ > > > > ---------------------------(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 > -- Guido Barosio ----------------------- http://www.globant.com guido.barosio@globant.com
On Sun, Sep 10, 2006 at 01:50:39PM -0700, Joshua D. Drake wrote: > O.k., I will start working through it and report at the end of the week. I spent a few minutes doing the same tests I did a few months ago and found problems with dblink and ltree; I'll submit patches for those. Tom, do you recall which modules gave you trouble? -- Michael Fuhr
Michael Fuhr <mike@fuhr.org> writes:
> I spent a few minutes doing the same tests I did a few months ago
> and found problems with dblink and ltree; I'll submit patches for
> those. Tom, do you recall which modules gave you trouble?
Um ... hstore and tsearch2, I think. I fixed those, but was thinking
that other stuff might crawl out from under similar rocks.
regards, tom lane
On Sun, Sep 10, 2006 at 07:38:24PM -0400, Tom Lane wrote: > Michael Fuhr <mike@fuhr.org> writes: > > I spent a few minutes doing the same tests I did a few months ago > > and found problems with dblink and ltree; I'll submit patches for > > those. Tom, do you recall which modules gave you trouble? > > Um ... hstore and tsearch2, I think. I fixed those, but was thinking > that other stuff might crawl out from under similar rocks. I don't see an uninstall script for hstore; that one needs to be written. The latest untsearch2.sql looks good in my tests. Should untsearch2.sql be renamed to uninstall_tsearch2.sql to be consistent with all the other uninstall scripts? -- Michael Fuhr
Michael Fuhr <mike@fuhr.org> writes:
> Should untsearch2.sql be renamed to uninstall_tsearch2.sql to be
> consistent with all the other uninstall scripts?
Yeah, that and lo_drop are outliers that probably ought to be renamed.
Offhand I don't see any serious compatibility objection --- who does
module removals except by hand? --- but if anyone sees a problem
speak now ...
I'm also wondering why the heck contrib/lo installs lo_test.sql.
That ought to be a regression test anyway, and we don't install
regression scripts.
regards, tom lane
"Joshua D. Drake" <jd@commandprompt.com> writes:
> I have seen some patches come across with this. Is this done, or do I
> still need to work on it?
Teodor added an uninstall for hstore, and I think Michael has fixed all
the problems in the existing scripts, but we still lack uninstall
scripts for the other modules I mentioned.
regards, tom lane
The following is a proposal for work I'd like to do to force long-running backend processes to reprepare their prepared statements. It would be used in cases where the user knows they have made a database change that will invalidate an existing prepared statement. I look forward to comments from the community. ------------ I propose creating a new system administration function to force repreparation of prepared statements in all backends. The functionality could be extended to include re-initialization of other kinds of "per-backend" data. This proposal addresses, to some degree, the prepare-alter-exec issue discussed in various mailing list postings, and the following wish-list item: # Invalidate prepared queries, like INSERT, when the table definition is altered However, the solution would only be partial, as it would be the responsibility of database clients to call the system administration function when needed. Alternately, additional integration work could be done to invoke this logic automatically whenever the columns of any table are altered. ------ Here is what I propose: We define a new system administration function called pg_reload_per_backend_data. This function would work much like pg_reload_conf, i.e. it would require superuser privileges and would work by sending a signal to the postmaster that would then be propagated to all the child backends (but not the special ones, like the bgwriter). The signal handling logic for the backends would be modified to respond to the signal by reinitializing any data cached in the backend's memory space, such as prepared statements. Each kind of data that would be reinitialized would require special logic, as they would all be reinitialized in their own particular way. Choosing an appropriate signal to send might be difficult, as the list of available signals is somewhat restricted. The "user-defined" signals would be a natural choice, but it appears SIGUSR1 is used for "sinval" or catchup events, while SIGUSR2 is used for asynchronous notification. Use of the "real time" signals (signal numbers >= 32) might be possible, but could have portability problems. Another alternative would be to overload SIGHUP, so that it causes both configuration reloads and reloading of per-backend data. This makes some sense, since most configuration parameters are basically a special form of per-backend data. However, changing the behavior of an existing signal might have undesirable side effects. Overall, I'm very open to suggestions regarding the appropriate signal to use. To implement the repreparation logic, a new function called RepreparePreparedStatements() could be added to source files backend/commands/prepare.[ch]. This function would be called by a signal handler installed the backends within backend/tcop/postgres.c. RepreparePreparedStatements would do the equivalent of iterating over the prepared_queries hash table and executing DropPreparedStatement() and PrepareQuery on each. However, it is possible that some refactoring of the logic would be needed to improve performance and make the code more robust. The scope of pg_reload_per_backend_data could also be expanded to include reinitialization of other data that resides in the memory space of individual backend processes. An example of such cached entities are reusable modules associated with a particular procedural language, e.g. the TCL modules found in the table pltcl_modules. Once a such a module is used in a particular backend, it remains held in backend memory and changes to the disk version are not noticed. There is also no way to undefine any global variables associated with such modules. I have not given much consideration to the implementation for reloading modules, but doing the equivalent of the SQL command "LOAD '<libname>' for all dynamically loaded libraries should have the desired effect (at least it does for the library that implements the PL/TCL language, pltcl.so). Perhaps the the general response should be to reload any libraries that have been dynamically-loaded by the particular backend. ------ Here are few permutations of this plan that could be considered: 1. Bundle pg_reload_per_backend_data functionality with pg_reload_conf. Pros: Avoids having to find an appropriate unused signal Logical consistancy with reloading config, which could be considereda special case of reloading per-backend data. Cons: Changes behavior of an existing functionality, which has the risk of unintended side-effects. Gives less fine-grainedcontrol over when per-backend data is reloaded. 2. Break pg_reload_per_backend_data functional into multiple functions. Pros: Can assign more descriptive names to the functionality, e.g. pg_reload_ddl, pg_reprepare_statements, etc. Finergrained control over which kind of reloading is performed. Cons: Require more use of the scarce list of available signals.
Stephen Marshall <smarshall@wsi.com> writes:
> The following is a proposal for work I'd like to do to force
> long-running backend processes to reprepare their prepared statements.
> It would be used in cases where the user knows they have made a database
> change that will invalidate an existing prepared statement.
There should be no need for users to concern themselves with this. The
direction we've been intending to go in is to automatically invalidate
stored plans when any related schema or statistics change occurs,
forcing a re-plan on any subsequent use. See past discussions (IIRC,
Neil Conway actually did some work on this idea earlier this year, but
didn't get it done).
The appropriate cross-backend communication mechanism already exists:
it's the catcache/relcache invalidation code. No need to fool with
finding a spare signal; and you can't do any meaningful work in a signal
handler anyway.
regards, tom lane
Guido Barosio wrote: > Let me know if you need an extra pair of eyes. O.k. I do :) Writing the scripts up are easy enough, but I am unsure how the whole make file foo works... Joshua D. Drake > > G.- > > On 9/10/06, Joshua D. Drake <jd@commandprompt.com> wrote: >> Tom Lane wrote: >> > "Joshua D. Drake" <jd@commandprompt.com> writes: >> >> Tom Lane wrote: >> >>> Seems like this area needs more attention ... anyone want to work >> on it? >> > >> >> I'll take it. How long do I have? >> > >> > Since it's contrib, I don't think we need to hold you to being done >> > before beta1. But the sooner the better of course. >> >> O.k., I will start working through it and report at the end of the week. >> >> Joshua D. Drake >> >> >> > >> > regards, tom lane >> > >> >> >> -- >> >> === The PostgreSQL Company: Command Prompt, Inc. === >> Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 >> Providing the most comprehensive PostgreSQL solutions since 1997 >> http://www.commandprompt.com/ >> >> >> >> ---------------------------(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 >> > > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
"Joshua D. Drake" <jd@commandprompt.com> writes:
> O.k. I do :) Writing the scripts up are easy enough, but I am unsure how
> the whole make file foo works...
About all you have to do is add the uninstall script to the "DATA = "
line in the makefile.
regards, tom lane
Joshua D. Drake wrote: > Guido Barosio wrote: > > Let me know if you need an extra pair of eyes. > > O.k. I do :) Writing the scripts up are easy enough, but I am unsure how > the whole make file foo works... OK, are all the uninstall scripts done? --------------------------------------------------------------------------- > > Joshua D. Drake > > > > > > G.- > > > > On 9/10/06, Joshua D. Drake <jd@commandprompt.com> wrote: > >> Tom Lane wrote: > >> > "Joshua D. Drake" <jd@commandprompt.com> writes: > >> >> Tom Lane wrote: > >> >>> Seems like this area needs more attention ... anyone want to work > >> on it? > >> > > >> >> I'll take it. How long do I have? > >> > > >> > Since it's contrib, I don't think we need to hold you to being done > >> > before beta1. But the sooner the better of course. > >> > >> O.k., I will start working through it and report at the end of the week. > >> > >> Joshua D. Drake > >> > >> > >> > > >> > regards, tom lane > >> > > >> > >> > >> -- > >> > >> === The PostgreSQL Company: Command Prompt, Inc. === > >> Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 > >> Providing the most comprehensive PostgreSQL solutions since 1997 > >> http://www.commandprompt.com/ > >> > >> > >> > >> ---------------------------(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 > >> > > > > > > > -- > > === The PostgreSQL Company: Command Prompt, Inc. === > Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 > Providing the most comprehensive PostgreSQL solutions since 1997 > http://www.commandprompt.com/ > > > > ---------------------------(end of broadcast)--------------------------- > TIP 2: Don't 'kill -9' the postmaster -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian wrote: > Joshua D. Drake wrote: >> Guido Barosio wrote: >>> Let me know if you need an extra pair of eyes. >> O.k. I do :) Writing the scripts up are easy enough, but I am unsure how >> the whole make file foo works... > > OK, are all the uninstall scripts done? Crap... yes they are, at least the ones I know about. I will submit a patch again -HEAD today. Joshua D. Drake > > --------------------------------------------------------------------------- > > >> Joshua D. Drake >> >> >>> G.- >>> >>> On 9/10/06, Joshua D. Drake <jd@commandprompt.com> wrote: >>>> Tom Lane wrote: >>>>> "Joshua D. Drake" <jd@commandprompt.com> writes: >>>>>> Tom Lane wrote: >>>>>>> Seems like this area needs more attention ... anyone want to work >>>> on it? >>>>>> I'll take it. How long do I have? >>>>> Since it's contrib, I don't think we need to hold you to being done >>>>> before beta1. But the sooner the better of course. >>>> O.k., I will start working through it and report at the end of the week. >>>> >>>> Joshua D. Drake >>>> >>>> >>>>> regards, tom lane >>>>> >>>> >>>> -- >>>> >>>> === The PostgreSQL Company: Command Prompt, Inc. === >>>> Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 >>>> Providing the most comprehensive PostgreSQL solutions since 1997 >>>> http://www.commandprompt.com/ >>>> >>>> >>>> >>>> ---------------------------(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 >>>> >>> >> >> -- >> >> === The PostgreSQL Company: Command Prompt, Inc. === >> Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 >> Providing the most comprehensive PostgreSQL solutions since 1997 >> http://www.commandprompt.com/ >> >> >> >> ---------------------------(end of broadcast)--------------------------- >> TIP 2: Don't 'kill -9' the postmaster > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
"Joshua D. Drake" <jd@commandprompt.com> writes:
> Here is adminpack...
Applied with minor corrections (the .sql file is DATA not DATA_built,
as you'd have found out if you'd tried "make clean"). Likewise for
the pgrowlocks script.
regards, tom lane
Tom Lane wrote:
> "Joshua D. Drake" <jd@commandprompt.com> writes:
>> Here is adminpack...
>
> Applied with minor corrections (the .sql file is DATA not DATA_built,
> as you'd have found out if you'd tried "make clean"). Likewise for
> the pgrowlocks script.
Noted, thanks.
>
> regards, tom lane
>
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/