At Wed, 28 Feb 2018 10:08:59 +0900, Michael Paquier wrote
in <20180228010859.gb1...@paquier.xyz>
> On Tue, Feb 27, 2018 at 02:53:55PM -0500, Tom Lane wrote:
> > Andres Freund writes:
> >> On 2018-02-27 14:41:47 -0500, Tom Lane wrote:
> >>> What I didn't understand about it was what kind of testi
On Tue, Feb 27, 2018 at 11:30 PM, Tom Lane wrote:
> I'd be in favor of having some normally-ifdef'd-out facility for causing
> failures of this kind. (As I mentioned upthread, I do not think "always
> fail" is sufficient.) That's very different from having a user-visible
> option, though. We do
Robert Haas writes:
> On Tue, Feb 27, 2018 at 2:50 PM, Andres Freund wrote:
>> What I'm concerned about isn't so much testing paths specific to
>> dynamic_shared_memory_type=none, but paths where we currently need
>> fallbacks for the case we couldn't actually allocate dynamic shared
>> memory. W
On Tue, Feb 27, 2018 at 2:50 PM, Andres Freund wrote:
> What I'm concerned about isn't so much testing paths specific to
> dynamic_shared_memory_type=none, but paths where we currently need
> fallbacks for the case we couldn't actually allocate dynamic shared
> memory. Which I think we at least so
On Tue, Feb 27, 2018 at 02:53:55PM -0500, Tom Lane wrote:
> Andres Freund writes:
>> On 2018-02-27 14:41:47 -0500, Tom Lane wrote:
>>> What I didn't understand about it was what kind of testing this'd make
>>> harder. If we desupport dynamic_shared_memory_type=none, there aren't
>>> any code path
On Tue, Feb 27, 2018 at 02:00:36PM -0500, Robert Haas wrote:
> I think the two issues you are pointing out are the same issue --
> namely, if initdb probes for a max_connections setting with an invalid
> DSM implementation configured, it will fail the test for every value
> of max_connections and t
Andres Freund writes:
> On 2018-02-27 14:41:47 -0500, Tom Lane wrote:
>> What I didn't understand about it was what kind of testing this'd make
>> harder. If we desupport dynamic_shared_memory_type=none, there aren't
>> any code paths that need to cope with the case, and we should just
>> remove
On 2018-02-27 14:41:47 -0500, Tom Lane wrote:
> Robert Haas writes:
> > On Thu, Feb 15, 2018 at 1:00 PM, Andres Freund wrote:
> >> Hm, I'm not quite convinced by this. Seems to make testing a bunch of
> >> codepaths harder. I think it's fine to say that pg doesn't work
> >> correctly with them d
Robert Haas writes:
> On Thu, Feb 15, 2018 at 1:00 PM, Andres Freund wrote:
>> Hm, I'm not quite convinced by this. Seems to make testing a bunch of
>> codepaths harder. I think it's fine to say that pg doesn't work
>> correctly with them disabled though.
> I'm not sure I understand this. Do y
On Thu, Feb 15, 2018 at 1:00 PM, Andres Freund wrote:
> Hm, I'm not quite convinced by this. Seems to make testing a bunch of
> codepaths harder. I think it's fine to say that pg doesn't work
> correctly with them disabled though.
I'm not sure I understand this. Do you mean we should just add a
On Thu, Feb 15, 2018 at 5:58 AM, Kyotaro HORIGUCHI
wrote:
> It is amost a just-to-delete work but I see two issues raised so
> far.
I think the two issues you are pointing out are the same issue --
namely, if initdb probes for a max_connections setting with an invalid
DSM implementation configure
Hello, thank you for the comment.
At Fri, 16 Feb 2018 13:07:08 +0900, Michael Paquier wrote
in <20180216040708.ga1...@paquier.xyz>
> On Thu, Feb 15, 2018 at 07:58:57PM +0900, Kyotaro HORIGUCHI wrote:
> > It is amost a just-to-delete work but I see two issues raised so
> > far.
>
> The patch loo
On Thu, Feb 15, 2018 at 10:00:39AM -0800, Andres Freund wrote:
> Hm, I'm not quite convinced by this. Seems to make testing a bunch of
> codepaths harder. I think it's fine to say that pg doesn't work
> correctly with them disabled though.
Well, for what it's worth that's one thing less to be for
On Thu, Feb 15, 2018 at 07:58:57PM +0900, Kyotaro HORIGUCHI wrote:
> It is amost a just-to-delete work but I see two issues raised so
> far.
The patch looks good as-is. This simplifies a couple of code paths
deciding if parallel queries can be used or not, so future features in
need of doing the
Hi,
On 2018-02-15 19:58:57 +0900, Kyotaro HORIGUCHI wrote:
> As in the other threads[1][2], we have had several good reasons
> to remove DSM_IMPL_NONE in PG11. The attached patch doesn that.
>
> [1]
> https://www.postgresql.org/message-id/CA+Tgmoa0e23YC3SCwB85Yf5oUTRyirV=sq_rxyxaxabldpp...@mail.
Hello.
As in the other threads[1][2], we have had several good reasons
to remove DSM_IMPL_NONE in PG11. The attached patch doesn that.
[1]
https://www.postgresql.org/message-id/CA+Tgmoa0e23YC3SCwB85Yf5oUTRyirV=sq_rxyxaxabldpp...@mail.gmail.com
[2]
https://www.postgresql.org/message-id/20180214
16 matches
Mail list logo
