"Matthew T. O'Connor" 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 incoming processe
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 throug
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 tim
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 <[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 InitPostgr
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
