On Tue, Nov 06, 2018 at 06:45:02PM +1300, Thomas Munro wrote:
> Like this?
Ah, my mistake. I thought that the limitations with dsm_resize were not
documented but those actually return an error if trying to use
DSM_OP_RESIZE and I did not notice that, so we may be fine without a
comment or such in
On Tue, Nov 6, 2018 at 6:15 PM Michael Paquier wrote:
> On Tue, Nov 06, 2018 at 05:29:36PM +1300, Thomas Munro wrote:
> > Thanks. Pushed to master only.
>
> Just a wild idea while this thread is hot: could we add in the
> description of the broken APIs or in their headers more information
> about
On Tue, Nov 06, 2018 at 05:29:36PM +1300, Thomas Munro wrote:
> Thanks. Pushed to master only.
Just a wild idea while this thread is hot: could we add in the
description of the broken APIs or in their headers more information
about how to not use them so as users are warned if trying to use them
On Tue, Nov 6, 2018 at 10:18 AM Robert Haas wrote:
> On Mon, Nov 5, 2018 at 2:28 AM Michael Paquier wrote:
> > Hm. Don't we need to worry about anybody potentially using these APIs
> > in a custom module on platforms where it was actually working? I
> > imagine that their reaction is not going
On Mon, Nov 5, 2018 at 2:28 AM Michael Paquier wrote:
> Hm. Don't we need to worry about anybody potentially using these APIs
> in a custom module on platforms where it was actually working? I
> imagine that their reaction is not going be nice if any code breaks
> suddenly after a minor release.
On Tue, Sep 25, 2018 at 06:22:19PM +1200, Thomas Munro wrote:
> On Sat, Sep 22, 2018 at 4:52 PM Amit Kapila wrote:
>> I went through and check the original proposal [1] to see if any use
>> case is mentioned there, but nothing related has been discussed. I
>> couldn't think of much use of this f
On Sat, Sep 22, 2018 at 4:52 PM Amit Kapila wrote:
> On Sat, Sep 22, 2018 at 2:28 AM Andres Freund wrote:
> > On 2018-09-22 08:54:57 +1200, Thomas Munro wrote:
> > > On Fri, Sep 21, 2018 at 4:43 PM Tom Lane wrote:
> > > > Unless it looks practical to support this behavior in the Windows
> > > >
On Sat, Sep 22, 2018 at 2:28 AM Andres Freund wrote:
>
> On 2018-09-22 08:54:57 +1200, Thomas Munro wrote:
> > On Fri, Sep 21, 2018 at 4:43 PM Tom Lane wrote:
> > > Thomas Munro writes:
> > > > On Fri, Sep 21, 2018 at 4:06 PM Tom Lane wrote:
> > > >> Why would we fix it rather than just removin
On 2018-09-22 08:54:57 +1200, Thomas Munro wrote:
> On Fri, Sep 21, 2018 at 4:43 PM Tom Lane wrote:
> > Thomas Munro writes:
> > > On Fri, Sep 21, 2018 at 4:06 PM Tom Lane wrote:
> > >> Why would we fix it rather than just removing it?
> >
> > > I assumed we wouldn't remove an extern C function
On Fri, Sep 21, 2018 at 4:43 PM Tom Lane wrote:
> Thomas Munro writes:
> > On Fri, Sep 21, 2018 at 4:06 PM Tom Lane wrote:
> >> Why would we fix it rather than just removing it?
>
> > I assumed we wouldn't remove an extern C function extension code
> > somewhere might use. Though admittedly I'd
Thomas Munro writes:
> On Fri, Sep 21, 2018 at 4:06 PM Tom Lane wrote:
>> Why would we fix it rather than just removing it?
> I assumed we wouldn't remove an extern C function extension code
> somewhere might use. Though admittedly I'd be surprised if anyone
> used this one.
Unless it looks pr
On Fri, Sep 21, 2018 at 4:06 PM Tom Lane wrote:
> Thomas Munro writes:
> > ... There may be ways to fix the dsm_resize() path
> > based on the observation that you don't need to fallocate() if you
> > made the mapping smaller, and if you made it bigger then you could
> > always undo that on error
On 2018-09-20 23:46:54 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I've made sure that the setting is off now however, I'm not
> > trusting the related logic very much...
>
> Was it on before?
Yes.
Thomas Munro writes:
> ... There may be ways to fix the dsm_resize() path
> based on the observation that you don't need to fallocate() if you
> made the mapping smaller, and if you made it bigger then you could
> always undo that on error (or not) and you haven't thrown away any
> data. Hmm... I
On Fri, Sep 21, 2018 at 3:21 PM Andres Freund wrote:
> I'm quite suspicious of the logic around:
>
> /*
> * If we received a query cancel or termination signal, we
> will have
> * EINTR set here. If the caller said that errors are OK
> here, che
Andres Freund writes:
> On 2018-09-20 23:15:45 -0400, Tom Lane wrote:
>> https://www.postgresql.org/docs/devel/static/kernel-resources.html#SYSTEMD-REMOVEIPC
> That shouldn't be relevant here - I'm not running the buildfarm from an
> interactive session and then logging out. So that code shouldn'
On 2018-09-20 23:15:45 -0400, Tom Lane wrote:
> Thomas Munro writes:
> > On Fri, Sep 21, 2018 at 2:59 PM Tom Lane wrote:
> >> I was just looking at that, and my guess is that it was caused by
> >> something doing an ipcrm or equivalent, and is unrelated to your patch.
> >> Especially since skink
On 2018-09-20 22:59:29 -0400, Tom Lane wrote:
> Thomas Munro writes:
> > Andres pinged me off-list to point out this failure after my commit
> > fb389498be:
>
> > ! FATAL: semop(id=332464133) failed: Invalid argument
>
> I was just looking at that, and my guess is that it was caused by
> somet
Thomas Munro writes:
> On Fri, Sep 21, 2018 at 2:59 PM Tom Lane wrote:
>> I was just looking at that, and my guess is that it was caused by
>> something doing an ipcrm or equivalent, and is unrelated to your patch.
>> Especially since skink has succeeded with that patch in several other
>> branch
On Fri, Sep 21, 2018 at 2:59 PM Tom Lane wrote:
> Thomas Munro writes:
> > Andres pinged me off-list to point out this failure after my commit
> > fb389498be:
>
> > ! FATAL: semop(id=332464133) failed: Invalid argument
>
> I was just looking at that, and my guess is that it was caused by
> some
Thomas Munro writes:
> Andres pinged me off-list to point out this failure after my commit
> fb389498be:
> ! FATAL: semop(id=332464133) failed: Invalid argument
I was just looking at that, and my guess is that it was caused by
something doing an ipcrm or equivalent, and is unrelated to your pa
21 matches
Mail list logo
