[GENERAL] Configure Different Databases on One Server
I have a question about Postgres management. Our situation is probably similar to many data shops. We have one (Linux) server, and one Postgres installation (v9.4), hence one Postgres process-daemon set running on the server, but we have multiple databases created: ddev1, ddev2, ddev3. I would like to do a different vacuum configuration on ddev2 than on ddev1, such as turning off autovacuum, etc. How do I do this? E.g. how do I turn off autovacuum on one database .. using different postgres.conf files(?) or within the database, without affecting the other database(s) on the same localhost? Is there a relatively easy way to do this? --o--o--o--o--o--o--o--o--o--o--o--o-- Jim Longwill jlongw...@psmfc.org --o--o--o--o--o--o--o--o--o--o--o--o-- -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Configure Different Databases on One Server
Ok, Thanks! I think the ALTER DATABASE.. commands will work well for what I'm doing now. I want to experiment with one database (doing manual vacuuming, etc.) while leaving the other databases undisturbed. Regards, --Jim Longwill On 10/29/2015 12:36 PM, John R Pierce wrote: On 10/29/2015 12:14 PM, Tom Lane wrote: Might be better to settle for configuring specific large tables using per-table vacuum settings, and not sweat the small stuff at a per-DB level. indeed, since you ALSO need to vacuum the system tables occasionally, or things go pear-shaped if you do lots of DDL. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Configure Different Databases on One Server
Mr. Pierce, others, I spoke too soon on this. I'd like to do your alter database.. command but it isn't working. I've tried: postgres=# ALTER DATABASE ddev2 SET autovacuum = off; both as 'postgres' user, and the ddev2 owner user (which has owner privs), and I'm always getting this error: ERROR: parameter "autovacuum" cannot be changed now I've checked some documentation, tried many variations of the command, (e.g. = off, false, 0, etc.) tried other variations as well. As you can see in the above example, I'm connected to 'postgres' database. I tried 'ddev2' also, etc. The above error is *always* the response. I'm certain that there are no other user sessions in this database. So.. what are the magic words? Thanks again! -- --o--o--o--o--o--o--o--o--o--o--o--o-- Jim Longwill jlongw...@psmfc.org --o--o--o--o--o--o--o--o--o--o--o--o-- On 10/29/2015 12:05 PM, John R Pierce wrote: On 10/29/2015 11:52 AM, Jim Longwill wrote: I have a question about Postgres management. Our situation is probably similar to many data shops. We have one (Linux) server, and one Postgres installation (v9.4), hence one Postgres process-daemon set running on the server, but we have multiple databases created: ddev1, ddev2, ddev3. I would like to do a different vacuum configuration on ddev2 than on ddev1, such as turning off autovacuum, etc. How do I do this? E.g. how do I turn off autovacuum on one database .. using different postgres.conf files(?) or within the database, without affecting the other database(s) on the same localhost? Is there a relatively easy way to do this? alter database dbname set autovacuum = false; -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Configure Different Databases on One Server
Ok. The reason I wanted to experiment with autovacuum disable for 'ddev2' database is that it is a mostly read-only database -- to support querying from our web apps. I.e. there are only 1 or 2 small tables ever updated all day on it, and only about 20 or so records total per day (compared to 'ddev1' which has much more frequent activity). Also, it's rebuilt periodically from the other db, so I had the idea that we didn't need autovacuum running for 'ddev2'. However, given that it is connected to the Postgres processes (launcher) and I can't turn it off per database, it may not be worth the trouble to configure this. I plan to experiment with other parameters as well, but this is not critical at this time. Thanks again. --Jim Longwill :^) On 10/29/2015 01:52 PM, Adrian Klaver wrote: On 10/29/2015 01:35 PM, Jim Longwill wrote: Mr. Pierce, others, I spoke too soon on this. I'd like to do your alter database.. command but it isn't working. I've tried: postgres=# ALTER DATABASE ddev2 SET autovacuum = off; both as 'postgres' user, and the ddev2 owner user (which has owner privs), and I'm always getting this error: ERROR: parameter "autovacuum" cannot be changed now I've checked some documentation, tried many variations of the command, (e.g. = off, false, 0, etc.) tried other variations as well. As you can see in the above example, I'm connected to 'postgres' database. I tried 'ddev2' also, etc. The above error is *always* the response. I'm certain that there are no other user sessions in this database. So.. what are the magic words? Thanks again! Look for SEE in below: http://www.postgresql.org/docs/9.4/interactive/runtime-config-autovacuum.html "autovacuum (boolean) Controls whether the server should run the autovacuum launcher daemon. This is on by default; however, track_counts must also be enabled for autovacuum to work. SEE--> This parameter can only be set in the postgresql.conf file or on the server command line. <---SEE Note that even when this parameter is disabled, the system will launch autovacuum processes if necessary to prevent transaction ID wraparound. See Section 23.1.5 for more information. " -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Configure Different Databases on One Server
Thanks to Mr. Nasby & others for these references & input. Indeed. I'm rather sure we don't have tables updated heavily enough to warrant any adjustments to autovacuum, or to do extra 'vacuuming' of the database. So I'll be leaving it alone (i.e. there's nothing broke so no fixes needed!) --Jim :^) On 10/30/2015 11:52 AM, Jim Nasby wrote: On 10/29/15 5:01 PM, Thomas Kellerer wrote: So no harm in keeping it enabled - plus this smells like premature optimization. I would not touch this unless you _really_ see a performance problem that is cause by autovacuum on that database. Moreso, if you think the problem is autovacuum (in this case) it's probably something else. If I can toot my own horn, you might want to watch the recording of http://www.pgcon.org/2015/schedule/events/829.en.html. -- --o--o--o--o--o--o--o--o--o--o--o--o-- Jim Longwill jlongw...@psmfc.org --o--o--o--o--o--o--o--o--o--o--o--o-- -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Checkpoint Err on Startup of Rsynced System
I am trying to setup a 2nd, identical, db server (M2) for development and I've run into a problem with starting up the 2nd Postgres installation. Here's what I've done: 1) did a 'clone' of 1st (production) machine M1 (so both machines on Cent OS 7.2) 2) setup an rsync operation, did a complete 'rsync' from M1 to M2 3) did a final 'CHECKPOINT' command on M1 postgres 4) shutdown postgres on M1 with 'pg_ctl stop' 5) did final 'rsync' operation (then restarted postgres on M1 with 'pg_ctl start') 6) tried to startup postgres on M2 It won't start, & in the log file gives the error message: ... < 2016-05-31 09:02:52.337 PDT >LOG: invalid primary checkpoint record < 2016-05-31 09:02:52.337 PDT >LOG: invalid secondary checkpoint record < 2016-05-31 09:02:52.337 PDT >PANIC: could not locate a valid checkpoint record < 2016-05-31 09:02:53.184 PDT >LOG: startup process (PID 26680) was terminated by signal 6: Aborted < 2016-05-31 09:02:53.184 PDT >LOG: aborting startup due to startup process failure I've tried several times to do this but always get this result. So, do I need to do a new 'initdb..' operation on machine M2 + restore from M1 backups? Or is there another way to fix this? --o--o--o--o--o--o--o--o--o--o--o--o-- Jim Longwill PSMFC Regional Mark Processing Center jlongw...@psmfc.org --o--o--o--o--o--o--o--o--o--o--o--o-- -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Checkpoint Err on Startup of Rsynced System
Scott,
Thanks. If I understand you correctly.. Actually, we did have M1
shutdown when the inital clone was done (some weeks ago). That was done
using the VMWare system, not rsync. My main problem is that I don't
have WAL archiving setup yet (I've not changed the Postgres defaults on
this so far). That's part of what the new machine M2 is for.. to
practice doing this before adjusting our production machine (M1). As
regards doing a snapshot, I thought that the manual 'CHECKPOINT' would
take care of it.
So, this time around I may try to do a manual (initdb.. & pg_restore
from backup files) on the new machine in order to get a roughly
equivalent installation going. One early goal I have is to get
archiving setup & working at beyond the minimal level.
Jim Longwill
On 05/31/2016 11:50 AM, Scott Mead wrote:
On Tue, May 31, 2016 at 1:13 PM, Jim Longwill <mailto:longw...@psmfc.org>> wrote:
I am trying to setup a 2nd, identical, db server (M2) for
development and I've run into a problem with starting up the 2nd
Postgres installation.
Here's what I've done:
1) did a 'clone' of 1st (production) machine M1 (so both
machines on Cent OS 7.2)
2) setup an rsync operation, did a complete 'rsync' from M1 to M2
3) did a final 'CHECKPOINT' command on M1 postgres
4) shutdown postgres on M1 with 'pg_ctl stop'
5) did final 'rsync' operation (then restarted postgres on M1
with 'pg_ctl start')
6) tried to startup postgres on M2
It won't start, & in the log file gives the error message:
...
< 2016-05-31 09:02:52.337 PDT >LOG: invalid primary checkpoint record
< 2016-05-31 09:02:52.337 PDT >LOG: invalid secondary checkpoint
record
< 2016-05-31 09:02:52.337 PDT >PANIC: could not locate a valid
checkpoint record
< 2016-05-31 09:02:53.184 PDT >LOG: startup process (PID 26680)
was terminated by signal 6: Aborted
< 2016-05-31 09:02:53.184 PDT >LOG: aborting startup due to
startup process failure
I've tried several times to do this but always get this result.
So, do I need to do a new 'initdb..' operation on machine M2 +
restore from M1 backups? Or is there another way to fix this?
You should have stopped M1 prior to taking the backup. If you can't do
that, it can be done online via:
1. Setup archiving
2. select pg_start_backup('some label');
3.
4. select pg_stop_backup();
Without archiving and the pg_[start|stop]_backup, you're not
guaranteed anything. You could use an atomic snapshot (LVM, storage,
etc...), but it's got to be a true snapshot. Without that, you need
archiving + start / stop backup.
Last section of:
https://wiki.postgresql.org/wiki/Simple_Configuration_Recommendation#Physical_Database_Backups
will take you to:
https://www.postgresql.org/docs/current/static/continuous-archiving.html
--Scott
--o--o--o--o--o--o--o--o--o--o--o--o--
Jim Longwill
PSMFC Regional Mark Processing Center
jlongw...@psmfc.org <mailto:jlongw...@psmfc.org>
--o--o--o--o--o--o--o--o--o--o--o--o--
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org
<mailto:pgsql-general@postgresql.org>)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
--
--
Scott Mead
Sr. Architect
/OpenSCG <http://openscg.com>/
http://openscg.com
Re: [GENERAL] Checkpoint Err on Startup of Rsynced System
Jeff Janes, Ok. I checked this further and just found that the pg_xlog area is symlinked to another area.. and indeed that other area was not being rsynced (!) and I thought it was. So, I just fixed this, re-ran it and now it is working. Now I believe I have a stable postgres running on M2. So, thanks Jeff for mentioning pg_xlog. Thanks to others as well for your input. --Jim Longwill On 06/01/2016 08:44 AM, Jeff Janes wrote: On Tue, May 31, 2016 at 10:13 AM, Jim Longwill wrote: I am trying to setup a 2nd, identical, db server (M2) for development and I've run into a problem with starting up the 2nd Postgres installation. Here's what I've done: 1) did a 'clone' of 1st (production) machine M1 (so both machines on Cent OS 7.2) 2) setup an rsync operation, did a complete 'rsync' from M1 to M2 3) did a final 'CHECKPOINT' command on M1 postgres 4) shutdown postgres on M1 with 'pg_ctl stop' 5) did final 'rsync' operation (then restarted postgres on M1 with 'pg_ctl start') 6) tried to startup postgres on M2 It won't start, & in the log file gives the error message: ... < 2016-05-31 09:02:52.337 PDT >LOG: invalid primary checkpoint record < 2016-05-31 09:02:52.337 PDT >LOG: invalid secondary checkpoint record < 2016-05-31 09:02:52.337 PDT >PANIC: could not locate a valid checkpoint record < 2016-05-31 09:02:53.184 PDT >LOG: startup process (PID 26680) was terminated by signal 6: Aborted < 2016-05-31 09:02:53.184 PDT >LOG: aborting startup due to startup process failure I've tried several times to do this but always get this result. So, do I need to do a new 'initdb..' operation on machine M2 + restore from M1 backups? Or is there another way to fix this? It sounds like you did not include pg_xlog in your rsync. What you have done is basically a cold backup. Cold backups must include pg_xlog, at least if you want them to work without WAL archival. If you look farther up in the log, it should tell you what xlog file it needs, and you can copy that from M1 if it is still there. Cheers, Jeff -- --o--o--o--o--o--o--o--o--o--o--o--o-- Jim Longwill PSMFC Regional Mark Processing Center Ph:503-595-3146; FAX:503-595-3446 jlongw...@psmfc.org --o--o--o--o--o--o--o--o--o--o--o--o-- -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Error when building new db using pg_restore
We have a (Linux CentOS) server, and one Postgres installation (v9.5). We have long been experiencing an error when doing a 'pg_restore' database build from a tar file. Our procedure is as follows (err. is just after start of restoring our schema 'rradmin'): First, an export is done to a .tar file from the maindb. Second, the rdev1 db is created with this command: CREATE DATABASE rdev1 TEMPLATE template0 OWNER rradmin; Then, we load in the tar file from the other db as follows: pg_restore -U rradmin -d rdev1 -v $PG_EXPORT/maindb-cron.tar > $PG_VAR/log/cron-rdev1-build-via-tar.log The build goes just fine; however, there is an 'error' in the above log file. The error seems of little consequence, but I'm curious as to the implications and how it can be fixed. The log entries start in typical fashion, as follows: pg_restore: connecting to database for restore pg_restore: creating SCHEMA "public" pg_restore: creating COMMENT "SCHEMA public" pg_restore: creating SCHEMA "rradmin" pg_restore: creating EXTENSION "plpgsql" pg_restore: creating COMMENT "EXTENSION plpgsql" ..however, we then get the error corresponding roughly to the following lines: pg_restore: [archiver (db)] Error while PROCESSING TOC: pg_restore: [archiver (db)] Error from TOC entry 4100; 0 0 COMMENT EXTENSION plpgsql pg_restore: [archiver (db)] could not execute query: ERROR: must be owner of extension plpgsql Command was: COMMENT ON EXTENSION plpgsql IS 'PL/pgSQL procedural language'; pg_restore: creating FUNCTION "rradmin.rarsr_check_upd_4days()" pg_restore: creating FUNCTION ... .. which continues w/ remainder of our objects. Then.. it mentions the 1 error only at the end: WARNING: errors ignored on restore: 1 Now, during all this, the pg log file: ../pg_log/postgresql-Fri.log has these entries: < 2017-06-16 21:21:27.694 PDT >ERROR: must be owner of extension plpgsql < 2017-06-16 21:21:27.694 PDT >STATEMENT: COMMENT ON EXTENSION plpgsql IS 'PL/pgSQL procedural language'; < 2017-06-16 21:22:39.719 PDT >ERROR: canceling autovacuum task < 2017-06-16 21:22:39.720 PDT >CONTEXT: automatic analyze of table "rdev1.rradmin.rar_criteria_release" < 2017-06-16 21:22:52.997 PDT >ERROR: canceling autovacuum task < 2017-06-16 21:22:52.997 PDT >CONTEXT: automatic analyze of table "rdev1.rradmin.recoveries_041" < 2017-06-16 21:26:01.625 PDT >WARNING: no privileges could be revoked for "public" < 2017-06-16 21:26:01.625 PDT >WARNING: no privileges could be revoked for "public" < 2017-06-16 21:26:01.625 PDT >WARNING: no privileges were granted for "public" < 2017-06-16 21:26:01.625 PDT >WARNING: no privileges were granted for "public" .. So, these errors don't appear to cause problems on the target database (rdev1), but it might be an issue if we tried to do more things with PL/pgSQL. Is it cancelling the autovacuum task on a long term basis? This same result also occurs when creating using 'template1' db. Any thoughts on this? -- --o--o--o--o--o--o--o--o--o--o--o--o-- Jim Longwill PSMFC Regional Mark Processing Center Ph:503-595-3146; FAX:503-595-3446 jlongw...@psmfc.org --o--o--o--o--o--o--o--o--o--o--o--o-- -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Error when building new db using pg_restore
On 06/21/2017 11:05 AM, Jerry Sievers wrote: Jim Longwill writes: We have a (Linux CentOS) server, and one Postgres installation (v9.5). We have long been experiencing an error when doing a 'pg_restore' database build from a tar file. Our procedure is as follows (err. is just after start of restoring our schema 'rradmin'): First, an export is done to a .tar file from the maindb. Second, the rdev1 db is created with this command: CREATE DATABASE rdev1 TEMPLATE template0 OWNER rradmin; Then, we load in the tar file from the other db as follows: pg_restore -U rradmin -d rdev1 -v $PG_EXPORT/maindb-cron.tar > $PG_VAR/log/cron-rdev1-build-via-tar.log The build goes just fine; however, there is an 'error' in the above log file. The error seems of little consequence, but I'm curious as to the implications and how it can be fixed. The log entries start in typical fashion, as follows: pg_restore: connecting to database for restore pg_restore: creating SCHEMA "public" pg_restore: creating COMMENT "SCHEMA public" pg_restore: creating SCHEMA "rradmin" pg_restore: creating EXTENSION "plpgsql" pg_restore: creating COMMENT "EXTENSION plpgsql" ..however, we then get the error corresponding roughly to the following lines: pg_restore: [archiver (db)] Error while PROCESSING TOC: pg_restore: [archiver (db)] Error from TOC entry 4100; 0 0 COMMENT EXTENSION plpgsql pg_restore: [archiver (db)] could not execute query: ERROR: must be owner of extension plpgsql Command was: COMMENT ON EXTENSION plpgsql IS 'PL/pgSQL procedural language'; Your extension plpgsql is probably being created as result of having been a part of template0. If so, then it's not owned by your DB owner role but very likely 'postgres' which assuming your DB owner is *not* a superuser role, fails on the create comment statement. The create extension command that the pg_restore probably ran included the IF NOT EXISTS clause and was a no-op. Your logs may include a message at level NOTICE to indicate same. HTH pg_restore: creating FUNCTION "rradmin.rarsr_check_upd_4days()" pg_restore: creating FUNCTION ... .. which continues w/ remainder of our objects. Then.. it mentions the 1 error only at the end: WARNING: errors ignored on restore: 1 Now, during all this, the pg log file: ../pg_log/postgresql-Fri.log has these entries: < 2017-06-16 21:21:27.694 PDT >ERROR: must be owner of extension plpgsql < 2017-06-16 21:21:27.694 PDT >STATEMENT: COMMENT ON EXTENSION plpgsql IS 'PL/pgSQL procedural language'; < 2017-06-16 21:22:39.719 PDT >ERROR: canceling autovacuum task < 2017-06-16 21:22:39.720 PDT >CONTEXT: automatic analyze of table "rdev1.rradmin.rar_criteria_release" < 2017-06-16 21:22:52.997 PDT >ERROR: canceling autovacuum task < 2017-06-16 21:22:52.997 PDT >CONTEXT: automatic analyze of table "rdev1.rradmin.recoveries_041" < 2017-06-16 21:26:01.625 PDT >WARNING: no privileges could be revoked for "public" < 2017-06-16 21:26:01.625 PDT >WARNING: no privileges could be revoked for "public" < 2017-06-16 21:26:01.625 PDT >WARNING: no privileges were granted for "public" < 2017-06-16 21:26:01.625 PDT >WARNING: no privileges were granted for "public" .. So, these errors don't appear to cause problems on the target database (rdev1), but it might be an issue if we tried to do more things with PL/pgSQL. Is it cancelling the autovacuum task on a long term basis? This same result also occurs when creating using 'template1' db. Any thoughts on this? -- --o--o--o--o--o--o--o--o--o--o--o--o-- Jim Longwill PSMFC Regional Mark Processing Center Ph:503-595-3146; FAX:503-595-3446 jlongw...@psmfc.org --o--o--o--o--o--o--o--o--o--o--o--o-- Thank you Jerry S. Ok.. Indeed, our 'rradmin' user does not have SUPERUSER role. So.. as I understand this.. * This fails on creating the COMMENT about object: extension plpgsql, not on creation of the object itself? * It is a no-op because extension plpgsql already exists in the target db rdev1 when this error occurs.. yes? (i.e. so there was NO problem w/ creation of plpgsql)? Given this, I wonder how we can avoid this 'error' situation .. short of giving SUPERUSER role to rradmin? I tried just removing the '-v' flag from pg_restore, but the error is still put in the log file (but nothing else is). A related (rookie!) question: How do I easily look at comment entries for objects? I tried this in psql as either postgres or rradmin .. on several of our databases.. but got 0 rows: rdev1=# \dd Object descriptions Schema | Name | Object | Description +--++- (0 rows) So.. our databases have no COMMENT entries? Just wondering. --Jim :^) -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Error when building new db using pg_restore
On 06/21/2017 01:21 PM, David G. Johnston wrote: On Wed, Jun 21, 2017 at 1:10 PM, Jim Longwill wrote: rdev1=# \dd Object descriptions Schema | Name | Object | Description +--++- (0 rows) Nothing user created has comments by default. \dd only shows a very limited subset of user created objects by default. That you didn't explicit add comments to any of those types objects is unsurprising. See the docs for exactly what "\dd" and "\ddS" will consider. David J. Ok.. I've tried again using psql \dd.. type commands to locate this COMMENT object, including as 'postgres' and in the source database of the tar file but it does not show up. Yes.. we have never put in any object comments, so it must have come in from the postgres installation. It'll be tough to delete this thing if I can't find it, but oh well! I won't worry about this much more, but if the system identifies it as an error then I thought it was at least worth making the inquiry. Thanks! --Jim :^) -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Error when building new db using pg_restore
On 06/21/2017 05:30 PM, Adrian Klaver wrote: On 06/21/2017 05:06 PM, Jim Longwill wrote: On 06/21/2017 01:21 PM, David G. Johnston wrote: On Wed, Jun 21, 2017 at 1:10 PM, Jim Longwill wrote: rdev1=# \dd Object descriptions Schema | Name | Object | Description +--++- (0 rows) Nothing user created has comments by default. \dd only shows a very limited subset of user created objects by default. That you didn't explicit add comments to any of those types objects is unsurprising. See the docs for exactly what "\dd" and "\ddS" will consider. David J. Ok.. I've tried again using psql \dd.. type commands to locate this COMMENT object, including as 'postgres' and in the source database of the tar file but it does not show up. Yes.. we have never put in any object comments, so it must have come in from the postgres installation. It'll be tough to delete this thing if I can't find it, but oh well! Did you try \dL?: test=> \dL List of languages Name| Owner | Trusted | Description ---+--+-+-- plpgsql | postgres | t | PL/pgSQL procedural language plpythonu | postgres | f | PL/PythonU untrusted procedural language I won't worry about this much more, but if the system identifies it as an error then I thought it was at least worth making the inquiry. Thanks! --Jim :^) Ok. Thank you for the input. I do see the 'Description' of plpgsql there. So, if I can determine the source table(s) of this information perhaps I could delete that particular value.I tried the following as per documentation: COMMENT ON EXTENSION plpgsql IS NULL; But it did not appear to remove the comment/description. will investigate further.. --Jim :^) -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
