-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Rajesh Kumar Mallah wrote:
| Dear Grega ,
|
| Thanks for the useful tips and error spotting,
| i am incorporating some of them and testing
| the script in my server . I have concerns regarding
| some of your optimisations that makes the script le
On 3/31/06, Sriram Dandapani <[EMAIL PROTECTED]> wrote:
> We have high volume inserts happening with wal files being generated
> very rapidly. Will the fact that the files change as the tar happens
> have any effect at all on the recovery..assuming all the appropriate wal
> archive logs are availab
On 3/30/06, Grega Bremec <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: RIPEMD160
>
> Rajesh Kumar Mallah wrote:
> |
> | OK i am posting my full script [ its not heavy programming i guess :) ]
> | shall be grateful if you/someone could review it . (its well
> commented i t
The handwriting on the wall says that autovac will soon be on by
default, and perhaps become not-disablable some day after that
(like the second or third time we hear from someone who's lost
their data to XID wraparound after disabling it).
So if there's a really convincing use-case for locking
"Matthew T. O'Connor" writes:
> I think the closest approximation of disabling autovacuum on a per
> database basis is to connect to the database in question and perform:
> update pg_autovacuum set enabled = 'false';
Not really gonna help unless you insert a row into pg_autovacuum for
each table
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Jim C. Nasby wrote:
>> Currently there is no way to exclude entire databases from autovacuum.
> IIRC in one of the original patches I had added a way to do it. It was
> rejected however; it was argued that there was another mechanism to
> disable it.
I think the closest approximation of disabling autovacuum on a per
database basis is to connect to the database in question and perform:
update pg_autovacuum set enabled = 'false';
This will prevent autovacuum from vacuuming or analyzing any of the
tables in the database, but will still chec
On Fri, Mar 31, 2006 at 04:36:10PM -0500, Matthew T. O'Connor wrote:
> Alvaro Herrera wrote:
> >Jim C. Nasby wrote:
> >>On Wed, Mar 29, 2006 at 03:36:36PM +0530, Gourish Singbal wrote:
> >>>we are using postgresql 8.1.3 and wanted to enable autovacuuming for only
> >>>one of the many databases on t
On Thu, Mar 30, 2006 at 04:04:04PM -0800, Mark Liberman wrote:
> Re-sending: for some reason original post was truncated and did not have
> carriage returns.
If you're going to hard-code CR/LF in, you should do it at the
traditional width of 72 characters. Your second email looks way worse on
my
Alvaro Herrera wrote:
Jim C. Nasby wrote:
On Wed, Mar 29, 2006 at 03:36:36PM +0530, Gourish Singbal wrote:
we are using postgresql 8.1.3 and wanted to enable autovacuuming for only
one of the many databases on the same postgresql cluster.
pg_autovacuum seems to allow to ignore only a particular
Jim C. Nasby wrote:
> On Wed, Mar 29, 2006 at 03:36:36PM +0530, Gourish Singbal wrote:
> > we are using postgresql 8.1.3 and wanted to enable autovacuuming for only
> > one of the many databases on the same postgresql cluster.
> > pg_autovacuum seems to allow to ignore only a particular table and n
On Wed, Mar 29, 2006 at 07:19:10PM +0200, Rafael Martinez wrote:
> On Tue, 2006-03-28 at 17:17 -0600, Jim C. Nasby wrote:
> > On Wed, Mar 29, 2006 at 01:05:59AM +0200, Rafael Martinez wrote:
> > > I work with postgresql every day and I am very happy with it, but this
> > > does not mean I can not s
We have high volume inserts happening with wal files being generated
very rapidly. Will the fact that the files change as the tar happens
have any effect at all on the recovery..assuming all the appropriate wal
archive logs are available.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:
On Wed, Mar 29, 2006 at 09:46:30AM -0500, Tom Lane wrote:
> It definitely is a pain in the neck that GNU tar complains about files
> changing underneath it --- I've looked for a way to disable that, or at
> least reduce it to a warning instead of an error condition, but gtar
> doesn't seem to have
On Wed, Mar 29, 2006 at 06:15:59PM +0530, Rajesh Kumar Mallah wrote:
> > Also you wouldn't particular need any heavy programming ? I'm sure a simple
> > shell script could be written in bash to pick out the correct files.
>
> OK i am posting my full script [ its not heavy programming i guess :) ]
On Wed, Mar 29, 2006 at 03:36:36PM +0530, Gourish Singbal wrote:
> we are using postgresql 8.1.3 and wanted to enable autovacuuming for only
> one of the many databases on the same postgresql cluster.
> pg_autovacuum seems to allow to ignore only a particular table and not the
> database since colu
At risk of going off the original subject:
To re-enable root access in Ubuntu, login as your first created user, and
type "sudo passwd root" - type in a new root password, confirm it and bingo,
your root account is ready for direct login, should you need it.
Andy
-Original Message-
From:
sudo /sbin/service postgresql stop/start
You will need to add your own userid to the sudoers list if it's
not already there.
Just for reference, Ubuntu automatically adds the first user created to
the sudoers file and actually disables the ability to "log in" as root.
Sincerely,
Jos
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> sudo su -
> /etc/init.d/postgresql (or /etc/init.d/postgresql8) stop/start
Or easier, just
sudo /sbin/service postgresql stop/start
You will need to add your own userid to the sudoers list if it's
not already there.
Sidar López Cruz wrote:
How to start and stop automatically PostgreSQL over Ubuntu when
postgres user have password.
I'd try with su - postgres but this fails because it request me the
password
You would be better served to use #ubuntu on chat.us.freenode.net.
However in answer to your quest
How to start and stop automatically PostgreSQL over Ubuntu when postgres
user have password.
I'd try with su - postgres but this fails because it request me the password
Please help
_
Charla con tus amigos en línea mediante MS
21 matches
Mail list logo
