Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Note that currently there's no way for a backend to know whether another
backend is autovacuum or not. I thought about adding a flag to PGPROC,
but eventually considered it ugly,
No, that was exactly the way I thought we'd do it.
Alvaro Herrera [EMAIL PROTECTED] writes:
Here it is.
I'd drop the InitProcess API change, which touches many more places than
you really need, and just have InitProcess check IsAutoVacuumProcess(),
which should be valid by the time control gets to it. This is more like
the way that InitPostgres
I wrote:
Please release the LWLock *before* executing a kernel call ...
Oh, and there had definitely better be a CHECK_FOR_INTERRUPTS in
this loop ...
regards, tom lane
---(end of broadcast)---
TIP 7: You can help support
Alvaro Herrera wrote:
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Here it is.
I'd drop the InitProcess API change, which touches many more places than
you really need, and just have InitProcess check IsAutoVacuumProcess(),
which should be valid by the time control gets
Alvaro Herrera wrote:
Alvaro Herrera wrote:
New version of the patch attached.
I'll probably apply this tomorrow morning unless there are objections.
An important difference from the previous patch is that
DatabaseHasActiveBackends (now renamed to
DatabaseCancelAutovacuumActivity) cycles
Matthew T. O'Connor matthew@zeut.net writes:
Is there any chance of a race condition here? That is, can the launcher
process start a new autovacuum process against that database that your
code will miss since it was started after you began your search?
No; we're holding a lock against
