agora inbox for postgres@postgres.berkeley.edu
help / color / mirror / Atom feedvacuum
6+ messages / 3 participants
[nested] [flat]
* vacuum
@ 1992-05-05 19:02 Banco de Dados Ambiental <ambdata@dpi.inpe.br>
0 siblings, 1 reply; 6+ messages in thread
From: Banco de Dados Ambiental @ 1992-05-05 19:02 UTC (permalink / raw)
To: legacy
I am trying to vacuum (v3r1) a database and I am quite sure I have no other vacu
um cleaner running. Why do I receive this message?
Query sent to backend is "vacuum "
WARN:May 5 16:37:57:can't create lock file -- another vacuum cleaner running?
Can someone tell me more about the vacuum cleaner?
^ permalink raw reply [nested|flat] 6+ messages in thread
* vacuum
@ 1992-05-06 12:15 Banco de Dados Ambiental <ambdata@dpi.inpe.br>
0 siblings, 1 reply; 6+ messages in thread
From: Banco de Dados Ambiental @ 1992-05-06 12:15 UTC (permalink / raw)
To: legacy
I think my last message sent yesterday claims for more details.
I have a database where indexes and rules are defined along with nearly 40 relat
ions. This database is used by sometime more than 8 users through copies of t
he same application running in different Sun's. At the beginning of the datab
ase's life everything seems to run OK, but some relatively long time latter t
he backend begins not to respond for some of the frontend processes. To solve
this problem I use to vacuum the database and call ipcclean to clean up shar
ed memories. I don't know if this is the best action to take, so I would be g
rateful for any suggestions or advices about the issue.
Thanks.
JPedro ambdata@dpi.inpe.br
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: vacuum
@ 1992-05-07 16:53
parent: Banco de Dados Ambiental <ambdata@dpi.inpe.br>
0 siblings, 0 replies; 6+ messages in thread
From: @ 1992-05-07 16:53 UTC (permalink / raw)
To: legacy
you write:
> I am trying to vacuum (v3r1) a database and I am quite sure I have no other vacuum cleaner running. Why do I receive this message?
>
> Query sent to backend is "vacuum "
> WARN:May 5 16:37:57:can't create lock file -- another vacuum cleaner running
+?
>
> Can someone tell me more about the vacuum cleaner?
In order to guarantee that there is only one vacuum cleaner command running
at a time the backend creates a file "pg_vlock" in the database directory.
If this file already exists the current vacuum command aborts assuming that
another vacuum is currently being run. If a vacuum command caused a crash
it is entirely possible that the pg_vlock file was not removed. If you are
sure there is no vacuum running you should remove the pg_vlock file by hand.
Jeff Meredith
mer@postgres.berkeley.edu
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: vacuum
@ 1992-05-12 09:27
parent: Banco de Dados Ambiental <ambdata@dpi.inpe.br>
0 siblings, 0 replies; 6+ messages in thread
From: @ 1992-05-12 09:27 UTC (permalink / raw)
To: legacy
you write:
>I have a database where indexes and rules are defined along with nearly 40 relations. This database is used by sometime more than 8 users through copies of the same application running in different Sun's. At the beginning of the database's life everything seems to run OK, but some relatively long time latter the backend begins not to respond for some of the frontend processes. To solve this problem I use to vacuum the database and call ipcclean to clean up shared memories. I don't know if this is the best action to take, so I would be grateful for any suggestions or advices about the issue.
When you say the backend isn't responding, what exactly is happening?
Are you able to connect on a second try?
There is a known problem that crops up only every once in a while. When
you start a handful (more than 1) front-end process concurrently one or
more of them will not successfully connect to the backend. I have been
able to sporatically reproduce this, but am not sure what the problem could
be. I would like to blame it on os bugs, but it happens on both sparc and
decstations in the same manner...
Jeff Meredith
mer@postgres.berkeley.edu
^ permalink raw reply [nested|flat] 6+ messages in thread
* Vacuum
@ 1993-02-02 16:44 Glen Niebur <gln@hercules.mayo.edu>
0 siblings, 0 replies; 6+ messages in thread
From: Glen Niebur @ 1993-02-02 16:44 UTC (permalink / raw)
To: legacy
What is the deal with vacuum? It is given some brief mentions in some of
the support papers, but i don't see any mention in the installation
instructions, the reference manual, or the users manual. Should i ever
run this command?
This is with postgres 4.0.1, in case it is just leftover from older versions.
Glen
Glen Niebur | If i die today, i'll be the happy phantom
Mayo Clinic | and i'll go chasing the nuns out in the yard.
Biomechanics Lab|
gln@mayo.edu | ~Tori Amos
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: vacuum
@ 1995-02-06 21:34 Robert.Patrick@cs.cmu.edu
0 siblings, 0 replies; 6+ messages in thread
From: Robert.Patrick@cs.cmu.edu @ 1995-02-06 21:34 UTC (permalink / raw)
To: legacy; +Cc: legacy
I have a similar problem; every time I run vacuum, I get the following error:
FATAL: no response from backend: detected in PQexec
Removing the pg_vlock allows me to run the command again but I still get
the error.
The thing is that I can here the command working (i.e., the disk grinds
for 15-20 seconds even though the database is small). It seems to me
that the problem is being caused by the vacuum command itself.
Robert
==============================================================================
To add/remove yourself to/from the POSTGRES mailing list: send mail with
the subject line ADD or DEL to "postgres-request@postgres.Berkeley.EDU".
If this fails, send mail to "post_questions@postgres.Berkeley.EDU" and
a human will deal with it. DO NOT post to the "postgres" mailing list.
==============================================================================
URL: http://s2k-ftp.CS.Berkeley.EDU:8000/postgres/
^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~1995-02-06 21:34 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
1992-05-05 19:02 vacuum Banco de Dados Ambiental <ambdata@dpi.inpe.br>
1992-05-07 16:53 `
1992-05-06 12:15 vacuum Banco de Dados Ambiental <ambdata@dpi.inpe.br>
1992-05-12 09:27 `
1993-02-02 16:44 Vacuum Glen Niebur <gln@hercules.mayo.edu>
1995-02-06 21:34 Re: vacuum Robert.Patrick@cs.cmu.edu
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox