Michael Monnerie a écrit :
> On Mittwoch 06 August 2008 Torsten Luettgert wrote:
>> reindexdb dbname
>> vacuumdb -f -z dbname
>
> Just a question on this: Is the order correct or would a vacuum+reindex
> be more correct?
>
You should do a VACUUM and then a REINDEX.
--
Guillaume.
http://www.
I think i'll answer my own question, after. Since this is a write ahead
log, the only thing contained would be the "Drop Table"
statement. Since there are many databases in this instance, we would
have to restore the instance somewhere else, replaying
until just before the drop, then extract w
Everyone,
-
The guys on one of our servers deleted a table and need the data from
it. Somehow, our backup job did not run.
We have the pg_xlog that should (may) contain the deleted data. We
need to know if there is a way to extract the
records that were deleted from the file and write them b
# select version();
version
---
PostgreSQL 8.1.11 on x86_64-unknown-linux-gnu, compiled by GCC gcc
(GCC) 4.1.2 20061115 (prerelease
Brad Nicholson wrote:
> Does this mean that if you are using autovac on 8.1, you should not use
> the cost delay feature?
No, because the fix was also applied to 8.1.10.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
On Wed, 2008-12-17 at 13:31 -0300, Alvaro Herrera wrote:
> Michael Fuhr wrote:
> > On Wed, Dec 17, 2008 at 09:47:23AM -0500, Tom Lane wrote:
> > > "John Lister" writes:
> > > > Cheers for the quick reply. I've tweaked them quite a bit, but we have
> > > > quite
> > > > a few heavily updated tabl
A couple of questions about these files:
1) When are these generated? Is this once an archive is generated, or
once the full archive_command has run?
2) Is there any harm in removing these files by appending an rm command
at the end of archive_command?
-salman
--
Sent via pgsql-admin maili
Michael Fuhr wrote:
> On Wed, Dec 17, 2008 at 09:47:23AM -0500, Tom Lane wrote:
> > "John Lister" writes:
> > > Cheers for the quick reply. I've tweaked them quite a bit, but we have
> > > quite
> > > a few heavily updated tables that i'd like vacuuming to keep them in
> > > check.
> > > Unfor
On Wed, Dec 17, 2008 at 09:47:23AM -0500, Tom Lane wrote:
> "John Lister" writes:
> > Cheers for the quick reply. I've tweaked them quite a bit, but we have
> > quite
> > a few heavily updated tables that i'd like vacuuming to keep them in check.
> > Unfortunately the autovacuum does a FULL vac
John Lister wrote:
>> John Lister wrote:
>>
>>> bizarre... Its been turned off for a while, but from memory the
>>> autovacuum process was causing the table it was running on to be locked
>>> - I assumed this was an equivalent to VACUUM FULL - causing all other
>>> connections to wait until it had
John Lister wrote:
bizarre... Its been turned off for a while, but from memory the
autovacuum process was causing the table it was running on to be locked
- I assumed this was an equivalent to VACUUM FULL - causing all other
connections to wait until it had finished. Could this happen another wa
John Lister wrote:
> bizarre... Its been turned off for a while, but from memory the
> autovacuum process was causing the table it was running on to be locked
> - I assumed this was an equivalent to VACUUM FULL - causing all other
> connections to wait until it had finished. Could this happen
"John Lister" writes:
Cheers for the quick reply. I've tweaked them quite a bit, but we have
quite
a few heavily updated tables that i'd like vacuuming to keep them in
check.
Unfortunately the autovacuum does a FULL vacuum every so often locking
the
tables for quite a long time, i'd like to
"John Lister" writes:
> Cheers for the quick reply. I've tweaked them quite a bit, but we have quite
> a few heavily updated tables that i'd like vacuuming to keep them in check.
> Unfortunately the autovacuum does a FULL vacuum every so often locking the
> tables for quite a long time, i'd lik
"John Lister" writes:
I'd like to use autovacuum to clean up the tables rather than schedule a
full vacuum with cron as it will be more selective/intelligent about what
gets cleaned. But is it possible to stop it running during peak/office
hours?
No. Instead, set the vacuum cost parameters
"John Lister" writes:
> I'd like to use autovacuum to clean up the tables rather than schedule a
> full vacuum with cron as it will be more selective/intelligent about what
> gets cleaned. But is it possible to stop it running during peak/office
> hours?
No. Instead, set the vacuum cost param
I'd like to use autovacuum to clean up the tables rather than schedule a
full vacuum with cron as it will be more selective/intelligent about what
gets cleaned. But is it possible to stop it running during peak/office
hours?
I've seen a post mention using pg_autovacuum.enabled to do this, but
On Samstag 16 August 2008 Devrim GÜNDÜZ wrote:
> http://www.pgcluster.org
Just tried it, site not reachable. Says something about a Subversion
problem. I can't find any notes about who to inform, so I try here .
mfg zmi
--
// Michael Monnerie, Ing.BSc- http://it-management.at
// Te
On Mittwoch 06 August 2008 Torsten Luettgert wrote:
> reindexdb dbname
> vacuumdb -f -z dbname
Just a question on this: Is the order correct or would a vacuum+reindex
be more correct?
mfg zmi
--
// Michael Monnerie, Ing.BSc- http://it-management.at
// Tel: 0660 / 415 65 31
19 matches
Mail list logo
