Greetings,
* Stephen Frost (sfr...@snowman.net) wrote:
> * Stephen Frost (sfr...@snowman.net) wrote:
> > * Michael Paquier (mich...@paquier.xyz) wrote:
> > > On Mon, Mar 22, 2021 at 04:07:12PM -0400, Robert Haas wrote:
> > > > On Mon, Mar 22, 2021 at 1:48 PM Stephen Frost
> > > > wrote:
> > > >>
Greetings,
* Stephen Frost (sfr...@snowman.net) wrote:
> * Michael Paquier (mich...@paquier.xyz) wrote:
> > On Mon, Mar 22, 2021 at 04:07:12PM -0400, Robert Haas wrote:
> > > On Mon, Mar 22, 2021 at 1:48 PM Stephen Frost wrote:
> > >> Thanks for that. Attached is just a rebased version with a co
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Mon, Mar 22, 2021 at 04:07:12PM -0400, Robert Haas wrote:
> > On Mon, Mar 22, 2021 at 1:48 PM Stephen Frost wrote:
> >> Thanks for that. Attached is just a rebased version with a commit
> >> message added. If there aren't any other
On Mon, Mar 22, 2021 at 04:07:12PM -0400, Robert Haas wrote:
> On Mon, Mar 22, 2021 at 1:48 PM Stephen Frost wrote:
>> Thanks for that. Attached is just a rebased version with a commit
>> message added. If there aren't any other concerns, I'll commit this in
>> the next few days and back-patch i
On Mon, Mar 22, 2021 at 1:48 PM Stephen Frost wrote:
> Thanks for that. Attached is just a rebased version with a commit
> message added. If there aren't any other concerns, I'll commit this in
> the next few days and back-patch it. When it comes to 12 and older,
> does anyone want to opine abo
Greetings,
* Thomas Munro (thomas.mu...@gmail.com) wrote:
> On Fri, Dec 11, 2020 at 7:57 AM Stephen Frost wrote:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > > The if-we're-going-to-delay-anyway path in vacuum_delay_point seems
> > > OK to add a touch more overhead to, though.
> >
> > Alright,
On Fri, Dec 11, 2020 at 7:57 AM Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > The if-we're-going-to-delay-anyway path in vacuum_delay_point seems
> > OK to add a touch more overhead to, though.
>
> Alright, for this part at least, seems like it'd be something like the
> attache
On Fri, Dec 11, 2020 at 8:34 AM Robert Haas wrote:
> On Thu, Oct 29, 2020 at 5:36 PM Alvaro Herrera
> wrote:
> > Maybe instead of thinking specifically in terms of vacuum, we could
> > count buffer accesses (read from kernel) and check the latch once every
> > 1000th such, or something like that
On Thu, Oct 29, 2020 at 5:36 PM Alvaro Herrera wrote:
> Maybe instead of thinking specifically in terms of vacuum, we could
> count buffer accesses (read from kernel) and check the latch once every
> 1000th such, or something like that. Then a very long query doesn't
> have to wait until it's run
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Alvaro Herrera writes:
> > On 2020-Oct-29, Stephen Frost wrote:
> >> I do think it'd be good to find a way to check every once in a while
> >> even when we aren't going to delay though. Not sure what the best
> >> answer there is.
>
> > Maybe
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Alvaro Herrera writes:
> > On 2020-Oct-29, Stephen Frost wrote:
> >> I do think it'd be good to find a way to check every once in a while
> >> even when we aren't going to delay though. Not sure what the best
> >> answer there is.
>
> > Maybe
Alvaro Herrera writes:
> On 2020-Oct-29, Stephen Frost wrote:
>> I do think it'd be good to find a way to check every once in a while
>> even when we aren't going to delay though. Not sure what the best
>> answer there is.
> Maybe instead of thinking specifically in terms of vacuum, we could
> c
On 2020-Oct-29, Stephen Frost wrote:
> I do think it'd be good to find a way to check every once in a while
> even when we aren't going to delay though. Not sure what the best
> answer there is.
Maybe instead of thinking specifically in terms of vacuum, we could
count buffer accesses (read from
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2020-10-29 12:27:53 -0400, Tom Lane wrote:
> > Maybe put a check into vacuum_delay_point, and poll the pipe when we're
> > about to sleep anyway?
>
> Perhaps we should just replace the pg_usleep() with a latch wait?
I'm not sure why, bu
Hi,
On 2020-10-29 12:27:53 -0400, Tom Lane wrote:
> Maybe put a check into vacuum_delay_point, and poll the pipe when we're
> about to sleep anyway?
Perhaps we should just replace the pg_usleep() with a latch wait?
Greetings,
Andres Freund
On 2020-Oct-28, Alexander Kukushkin wrote:
> Hello,
>
> I know, nobody in their mind should do that, but, if the postmaster
> process is killed with SIGKILL signal, most backend processes
> correctly notice the fact of the postmaster process absence and exit.
> There is one exception though, when
On 2020-Oct-29, Stephen Frost wrote:
> > It's hard to do better than that, because on most platforms there's
> > no way to get a signal on parent-process death, so the only way to
> > notice would be to poll the postmaster-death pipe constantly; which
> > would be hugely expensive in comparison to
Stephen Frost writes:
> I agree that 'constantly' wouldn't be great, but with some periodicity
> that's more frequent than 'not until a few hours later when we finally
> finish vacuuming this relation' would be nice. At least with autovauum
> we may be periodically sleeping anyway so it doesn't s
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Victor Yegorov writes:
> > ср, 28 окт. 2020 г. в 19:44, Alexander Kukushkin :
> >> I know, nobody in their mind should do that, but, if the postmaster
> >> process is killed with SIGKILL signal, most backend processes
> >> correctly notice the f
Victor Yegorov writes:
> ср, 28 окт. 2020 г. в 19:44, Alexander Kukushkin :
>> I know, nobody in their mind should do that, but, if the postmaster
>> process is killed with SIGKILL signal, most backend processes
>> correctly notice the fact of the postmaster process absence and exit.
>> There is o
ср, 28 окт. 2020 г. в 19:44, Alexander Kukushkin :
> I know, nobody in their mind should do that, but, if the postmaster
> process is killed with SIGKILL signal, most backend processes
> correctly notice the fact of the postmaster process absence and exit.
> There is one exception though, when the
21 matches
Mail list logo