Re: [HACKERS] PostgreSQL configuration
Tom Lane wrote: I've recently had some very unpleasant experiences trying to install test versions of MySQL on machines that already had older versions installed normally. It seems that MySQL *will* read /etc/my.cnf if it exists, whether it's appropriate or not, and so it's impossible to have a truly independent test installation, even though you can configure it to build/install into nonstandard directories. Let's not emulate that bit of brain damage. regards, tom lane It seems to me that this is a packaging problem and not a postgresql problem. If someone wants to package PostgreSQL so that there's a symlink to a config file in /etc/pgsql or vice versa for the main database they're welcome to do that, and why not? As for test databases, there's already a -D for the datadir, why not add a -C for the config file as many software packages allow. Then packagers could put the config file anywhere they wanted. I would certainly welcome this feature as it would allow for easy tweaking/benchmarking. I agree that we should avoid the viral-like MySQL configuration plague. As to pgsql AT mohawksoft.com requested, here are a few widely used software packages that keep configuration close to the data, some in /var, some in /usr: Mailman OpenSSL Cyrus-IMAP Apache I believe doesn't install anything to /etc/ when you build from source. ---(end of broadcast)--- TIP 3: 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: [HACKERS] Collaboration Tool Proposal
Josh Berkus wrote: Folks, Discuss: Has anyone talked to the people at collabnet (http://www.collab.net)? I wonder if they'd be willing to put something together for the PostgreSQL team? They run the tigris.org site, which is one of the nicest OSS collaboration sites I've worked with. GForge is nice, but seems more kludgey than Tigris. What does the Apache project run? Another option is something like Drupal (http://www.drupal.org). Drupal is a CMS system with tons of plugins. I'm not sure that it could handle a project as large as PostgreSQL, but Drupal's own development work is self hosted. It may merit some investigation. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] pg_restore problems and suggested resolution
Tom Lane wrote: This is a dead end. The --disable-triggers hack is already a time bomb waiting to happen, because all dump scripts using it will break if we ever change the catalog representations it is hacking. Disabling rules by such methods is no better an idea; it'd double our exposure to compatibility problems. If we're going to do something about this then it needs to be cleaner. As an implementation issue, I wonder why these things are hacking permanent on-disk data structures anyway, when what is wanted is only a temporary suspension of triggers/rules within a single backend. Some kind of superuser-only SET variable might be a better idea. It'd not be hard to implement, and it'd be much safer to use since failures wouldn't leave you with bogus catalog contents. regards, tom lane I like that idea. I didn't at first, but then I saw the super-user only bit. Where would I start to implement this? Do we want two separate properties for rules and triggers, or one to rule them all? Joseph ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] pg_restore problems and suggested resolution
I've got a custom (-Fc) pg_dump output from a fairly complex 7.2.x db schema. It has such things as user defined functions, OIDs, rules and triggers, etc. When I try to restore it to a 7.4 database, it fails because of some differences in the CREATE TABLE commands (I've got a column of type TIMESTAMP WITH TIMEZONE and the DEFAULT's default type is TEXT). Also, when the data is restored, and the OIDs are fixed, the rules and triggers aren't disabled on the columns/tables that are UPDATEd during the restore process, so those rules and triggers fire. Since these rules and triggers are designed to be executed within a transaction that includes a call to a setup type function which creates a temporary table, the rules fail. I've filed a bug on the OID problem before, but have so far been able to work around the problem. However, when tied to the CREATE TABLE error above, I can't get this data restored. Usually what I do is grep -v the rules and triggers from the DB schema restore, restore the data, then restore the rules and triggers. However now I can't restore the schema at all. I could rebuild the db with my ddl without the rules and triggers, and then restore the data, but I'd rather fix this at the source. I propose pg_restore --disable-triggers be modified so that triggers are disabled on the tables that OID fixing is going to UPDATE. I'll hopefully have a patch against REL7_4_STABLE for this soon, but I haven't started it yet. Does anyone have any suggestions? Has someone already done this in HEAD so that it can be backported to 7.4? Joseph ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_restore problems and suggested resolution
Joseph Tate wrote: I propose pg_restore --disable-triggers be modified so that triggers are disabled on the tables that OID fixing is going to UPDATE. I'll hopefully have a patch against REL7_4_STABLE for this soon, but I haven't started it yet. Does anyone have any suggestions? Has someone already done this in HEAD so that it can be backported to 7.4? So now that I've looked at the code, I think that this solution is a little too simplistic unfortunately. Now I'm leaning towards --diable-rules. Am I correct in thinking that if I change pg_class.relhasrules to 'f' that the rules will not be processed? Or is there more involved here? Joseph ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
