On Fri, Feb 5, 2021 at 5:47 PM Thomas Munro wrote:
> On Sun, Jan 31, 2021 at 6:07 PM Tom Lane wrote:
> > Thomas Munro writes:
> > > So that gives a very simple back-patchable patch.
> >
> > Hmm, so is the *rest* of that function perfectly okay with being
> > interrupted?
>
> It looks OK to me.
On Sun, Jan 31, 2021 at 6:07 PM Tom Lane wrote:
> Thomas Munro writes:
> > So that gives a very simple back-patchable patch.
>
> Hmm, so is the *rest* of that function perfectly okay with being
> interrupted?
It looks OK to me. There aren't any CFI()s in there.
Thomas Munro writes:
>> +1, this seems like a good idea. This is a little bit like the code
>> near the comments "Don't joggle the elbow of proc_exit".
> So that gives a very simple back-patchable patch.
Hmm, so is the *rest* of that function perfectly okay with being
interrupted?
On Wed, Jan 27, 2021 at 9:34 AM Thomas Munro wrote:
> On Wed, Jan 27, 2021 at 12:22 AM Kyotaro Horiguchi
> wrote:
> > At Tue, 26 Jan 2021 11:00:56 +0200, Heikki Linnakangas
> > wrote in
> > > Don't we potentially have the same problem with all on_dsm_detach
> > > callbacks? Looking at the other
On Wed, Jan 27, 2021 at 12:22 AM Kyotaro Horiguchi
wrote:
> At Tue, 26 Jan 2021 11:00:56 +0200, Heikki Linnakangas
> wrote in
> > Don't we potentially have the same problem with all on_dsm_detach
> > callbacks? Looking at the other on_dsm_detach callbacks, I don't see
> > any CHECK_FOR_INTERRUPT
At Tue, 26 Jan 2021 11:00:56 +0200, Heikki Linnakangas wrote
in
> On 26/01/2021 06:46, Kyotaro Horiguchi wrote:
> > Looking the comment of SharedFileSetOnDetach:
> > | * everything in them. We can't raise an error on failures, because this
> > | * runs
> > | * in error cleanup paths.
> > I feel
On 26/01/2021 06:46, Kyotaro Horiguchi wrote:
Looking the comment of SharedFileSetOnDetach:
| * everything in them. We can't raise an error on failures, because this runs
| * in error cleanup paths.
I feel that a function that shouldn't error-out also shouldn't be
cancellable. If that's the ca
At Wed, 28 Oct 2020 19:03:14 +0900, Masahiko Sawada
wrote in
> On Wed, 29 Jul 2020 at 10:37, Justin Pryzby wrote:
> >
> > On Mon, Jul 27, 2020 at 05:39:02AM -0500, Justin Pryzby wrote:
> > > On Mon, Jul 27, 2020 at 08:00:46PM +1200, Thomas Munro wrote:
> > > > Why can't tuplesort_end do it?
> >
On Wed, 29 Jul 2020 at 10:37, Justin Pryzby wrote:
>
> On Mon, Jul 27, 2020 at 05:39:02AM -0500, Justin Pryzby wrote:
> > On Mon, Jul 27, 2020 at 08:00:46PM +1200, Thomas Munro wrote:
> > > Why can't tuplesort_end do it?
> >
> > Because then I think the parallel workers remove their own files, wit
On Mon, Jul 27, 2020 at 05:39:02AM -0500, Justin Pryzby wrote:
> On Mon, Jul 27, 2020 at 08:00:46PM +1200, Thomas Munro wrote:
> > Why can't tuplesort_end do it?
>
> Because then I think the parallel workers remove their own files, with tests
> failing like:
>
> +ERROR: could not open temporary
On Mon, Jul 27, 2020 at 08:00:46PM +1200, Thomas Munro wrote:
> On Tue, Jul 21, 2020 at 4:33 PM Justin Pryzby wrote:
> > /*
> > * clean up a spool structure and its substructures.
> > */
> > static void
> > _bt_spooldestroy(BTSpool *btspool)
> > {
> > + void *fileset = tuplesort_shar
On Tue, Jul 21, 2020 at 4:33 PM Justin Pryzby wrote:
> /*
> * clean up a spool structure and its substructures.
> */
> static void
> _bt_spooldestroy(BTSpool *btspool)
> {
> + void *fileset = tuplesort_shared_fileset(btspool->sortstate);
> + if (fileset)
> + Share
On Fri, Dec 13, 2019 at 03:03:47PM +1300, Thomas Munro wrote:
> On Fri, Dec 13, 2019 at 7:05 AM Justin Pryzby wrote:
> > I have a nagios check on ancient tempfiles, intended to catch debris left by
> > crashed processes. But triggered on this file:
> >
> > $ sudo find /var/lib/pgsql/12/data/base/
On Fri, Dec 13, 2019 at 3:13 PM Justin Pryzby wrote:
> On Fri, Dec 13, 2019 at 03:03:47PM +1300, Thomas Munro wrote:
> > On Fri, Dec 13, 2019 at 7:05 AM Justin Pryzby wrote:
> > > 2019-12-07 01:35:56 | 11025 | postgres | canceling statement due to
> > > statement timeout
On Fri, Dec 13, 2019 at 03:03:47PM +1300, Thomas Munro wrote:
> On Fri, Dec 13, 2019 at 7:05 AM Justin Pryzby wrote:
> > I have a nagios check on ancient tempfiles, intended to catch debris left by
> > crashed processes. But triggered on this file:
> >
> > $ sudo find /var/lib/pgsql/12/data/base/
On Fri, Dec 13, 2019 at 7:05 AM Justin Pryzby wrote:
> I have a nagios check on ancient tempfiles, intended to catch debris left by
> crashed processes. But triggered on this file:
>
> $ sudo find /var/lib/pgsql/12/data/base/pgsql_tmp -ls
> 1429774 drwxr-x--- 3 postgres postgres 4096 De
16 matches
Mail list logo