I have a number of User Defined Data Collector Sets running on a Windows 2008R2 server, collecting perfmon stats from various servers.
Whenever there is a network interruption, or a server rebooted (at worst, when the server which is running all these DCSs is rebooted), I have to manually restart some or all of the Data Collector Sets.
Is there a way to configure them to automatically restart, or otherwise be more resilient?
I've restored a database which came from a server on which Slony was running. The server on which the database has been restored does not have Slony installed.
When the database restored, there were a lot of errors reported, with Slony related objects not getting created due to Slony related logins being missing. This I thought was not a problem, as losing the Slony objects didn't seem to matter, and infact seemed desirable.
However, now I've got an anoying, if not critical problem. Whenever one clicks on a table in the newly restored DB in PGAdmin, a Slony related error popup ... pops up.
The first one reads: "An error has occured: ERROR: function _rmscl.getlocalnodeid(unknown) does not exist"
I notice that under the Replication node in PGAdmin, that there is a Slony replication cluster. Trying to drop this cluster results in more object missing type errors.
Does anyone have any ideas how we can remove the last vestiges of Slony from this database?
Running PostgreSQL 9.0.1, with streaming replication keeping one read-only mirror instance up to date. Auto-vaccuum is on on the primary, except for a few tables which are not vacuumed by the auto-vacuum daemon, in an effort to reduce business-hour IO. These tables are "materialised views".
Each night at midnight, we run a vacuum across the database in order to clean up those tables that are excluded from the auto-vacuum. I'm wondering if that process replicates across to the mirror, or if I need to set up vacuum on the mirror as well?
According to the PostgreSQL documentation, "The useful range for shared_buffers on Windows systems is generally from 64MB to 512MB.".
I'm wondering how this might alter when running multiple database clusters (in PostgreSQL parlance) on a single server?
I've done some installs of PostgreSQL 9.0 64 bit on Windows Server 2008 R2 Standard.
When I connect to these instances, PGAdmin complains of the following:
The server lacks instrumentation Functions.
Apparently one is supposed to use the "official" pgInstaller program to install contrib modules in Windows PostgreSQL installs, including the server instrumentation.
However, the pgInstaller is only being maintained up to the PG9.0 RC, not the latest 9.0.1 version.
Given that, how do I get non-default contrib modules installed?