[GENERAL] Re: RFC tool to support development / operations work with slony replicated databases
Andrew Hammond wrote: Hello All, I've been working on designing a tool to facilitate both developers and operations staff working with slony replicated databases. I think that the problem described below is a general problem for people working with systems that are both in production and under on-going development / maintenance. As a result I would like to both solicit the input of the community and share the results. Documentation (which is still somewhat drafty) follows. Andrew, I think this is a useful idea, that I would be interested in trying myself. One suggestion: It would be great if there was an option for the downgrade path to be determined automatically, or ignored as option. I think in some scenarios, it's just not very practical to go back without restoring from a dump file of the old state. Perhaps there could be some integration with a diff tool like APG? http://pgfoundry.org/projects/apgdiff Given two databases schemas, it could generate /both/ upgrade and downgrade paths. That would work for some simple cases, and manual changes could be used for more complex cases, which as were data needs to be changed and changed back as part of an upgrade/downgrade. Thanks again for your work on this tool! Mark ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[GENERAL] pg_autovacuum should allow NULL values
I just tried to add something to the pg_autovacuum table for the first time today (with 8.1). I wanted to make the simplest possible entry: Disable auto-vacuuming for a table. However, the data model requires that I also enter values for: vac_base_thresh vac_scale_factor anl_base_thres anl_scale_factor vac_cost_delay vac_cost_limit None of those values matter when vacuuming is disabled for the table! I suggest all these fields be nullable, and default to global values if they are NULL. These are guts and I should have to learn about them or fake them if I just want to disable vacuuming for a table. Likewise, if I just want to set one of the values, I shouldn't have to set /all/ of them if the defaults are otherwise reasonable. For the moment, I suppose I'll go and fake all these values so I can disable a table from Vacuuming. Mark ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org/
Re: [GENERAL] pg_autovacuum should allow NULL values
Jim C. Nasby wrote: On Fri, Feb 23, 2007 at 04:08:45PM -0300, Alvaro Herrera wrote: Mark Stosberg wrote: I just tried to add something to the pg_autovacuum table for the first time today (with 8.1). I wanted to make the simplest possible entry: Disable auto-vacuuming for a table. However, the data model requires that I also enter values for: vac_base_thresh You can use any negative value on these settings (-1 works fine, for example). We should really make that the default so that you don't have to worry about other fields... A default would be helpful, but I think NULL is a lot more intuitive as a placeholder don't know/ don't care, than -1 is. Adding a default of -1 seems like a more cumbersome way to express the same thing to me. Mark ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[GENERAL] Addressing: ERROR: could not access status of transaction
PostgreSQL has been providing reliable service for our web hosting company since 1997. Thanks! Last night we got the following error during a dump of an 8.0.6 database: pg_dump: SQL command failed pg_dump: Error message from server: ERROR: could not access status of transaction 245900066 DETAIL: could not open file /usr/local/pgsql/data/pg_clog/00EA: No such file or directory pg_dump: The command was: SELECT tableoid, oid, oprname, oprnamespace, (select usename from pg_user where oprowner = usesysid) as usename, oprcode::oid as oprcode FROM pg_operator Another dump run during the same time frame did not have this problem, and running the mentioned command in 'psql' produces no error. Research shows that this could be a corrupted tuple, but it's not clear what it means to me if it sometimes work. This follows behavior in the past few days where we noticed PostgreSQL core dumping repeatedly, with this error: PANIC: right sibling's left-link doesn't match The core dumps stopped when we REINDEX'ed the table mentioned in the PANIC statement. We were already planning to upgrade to 8.1.x Real Soon. Are their further insights about this new error? And is my expectation correct that a full/dump restore into 8.1.x would address it? Thanks! Mark . . . . . . . . . . . . . . . . . . . . . . . . . . . Mark StosbergPrincipal Developer [EMAIL PROTECTED] Summersault, LLC 765-939-9301 ext 202 database driven websites . . . . . http://www.summersault.com/ . . . . . . . . ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[GENERAL] tips document available for 6.5 to 7.0.x upgrade
Hello! We just now got around to upgrading our production Postgres server to 7.0.3 (from 6.5.3). I've written up a tips document for people who have not yet done this. I believe it also contains some tips that may be generally helpful when dump/restoring Postgres. The document is here: http://mark.stosberg.com/tech/postgres/pg-65-7-upgrade.html Thanks! -mark http://mark.stosberg.com/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
