Hi,
> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> David Rowley writes:
> > On 16 May 2018 at 02:01, Tom Lane wrote:
> >> I'm not particularly fussed about getting credit for that. However,
> >> looking again at how that patch series turned out --- ie, that we
> >> ensured POSIX behavior for N
Hi,
> From: David Rowley [mailto:david.row...@2ndquadrant.com]
> Sent: Tuesday, May 15, 2018 3:01 PM
> To: Bruce Momjian
> Cc: Đặng Minh Hướng ; PostgreSQL-development
>
> Subject: Re: Postgres 11 release notes
>
> On 15 May 2018 at 08:28, Bruce Momjian wrote:
> > Consistently return N
> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> > I updated the patch as David Rowley mentioned.
>
> Pushed. I'd mainly note that you need to update all the variant float8
> expected-files, not just the primary one. (Sometimes this requires a bit
Thank you.
I will be careful next time.
> of gue
> > I updated the patch as David Rowley mentioned.
>
> Looks fine to me. Please add to the next commitfest.
Thanks. Added.
> --
> David Rowley http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services
>
---
Thanks and best regards,
Dang Minh Hu
Thanks for confirming.
> 2018-04-11 0:13 GMT-03:00 David Rowley :
> > I can recreate this when building with MSVC 2012. I confirm that I see
> > the same as you. Microsoft are setting errno to EDOM in the above 3
> > cases, where in Linux the result is still NaN, just the errno is not
> > set.
>
Hi,
Thanks for response
# I will add this thread to current CF soon.
> 2018-04-10 5:30 GMT-03:00 Huong Dangminh :
> > There are some cases that power() function does not work correctly
> > with 'NaN' arguments in Windows environment.
> > Something like,
> >
Hi,
There are some cases that power() function does not work
correctly with 'NaN' arguments in Windows environment.
Something like,
postgres=# select power('NaN',11);
ERROR: value out of range: underflow
postgres=# select power('NaN','NaN');
ERROR: value out of range: underflow
postgres=# sele
Hi,
Thanks for response and the fix patch.
> >>>>> "Huong" == Huong Dangminh writes:
>
> Huong> Hi,
>
> Huong> I have found a case which could get segmentation fault when Huong>
> using GROUPING SETS. It occurs when columns in GRO
Hi,
> I have found a case which could get segmentation fault when using GROUPING
> SETS.
> It occurs when columns in GROUPING SETS are all unsortable but hashable.
I have added this thread to current CF.
please let me know if you need more information.
---
Thanks and best regards,
Dang Minh Huo
> Masahiko Sawada wrote:
>
> > Regarding to regression test, I added a new test module
> > test_subscription that creates a new user-defined data type. In a
> > subscription regression test, using test_subscription we make
> > subscriber call slot_store_error_callback and check if the subscriber
>
> From: Masahiko Sawada [mailto:sawada.m...@gmail.com]
> >> Attached a new version patch incorporated the aboves. Please review it.
> >
> > Thanks for updating the patch.
> > It looks fine to me.
I mean that it passes make check, and subscription TAP tests too.
> >
>
> Thank you for confirmation
Hi Sawada-san,
> Thank you for quick response. The changes look good to me. But I wonder
> if the following changes needs some comments to describe what each checks
> does for.
>
> -if (errarg->attnum < 0)
> +if (errarg->local_attnum <0)
> +return;
> +
> +rel = errarg->rel;
>
Hi Sawada-san,
> >> eventually we'll need to map types to local oid (and possibly more)
> >> where the local info is cached so that we can interpret binary
> >> representation of replicated data (which we'll add at some point
> >> since it's big performance boost).
>
> Sounds good.
>
> >>
> >> S
Hi Petr Jelineks, Sawada-san
> I think the changes make sense in terms of how it all works now.
>
> That said I don't think the renaming idea is a good one, the naming was
> chosen to be future proof because eventually we'll need to map types to
> local oid (and possibly more) where the local inf
t; > On Sun, Dec 10, 2017 at 12:33 AM, Dang Minh Huong
> >
> > wrote:
> > > On 2017/12/08 13:18, Huong Dangminh wrote:
> > >
> > >> Hi Sawada-san,
> > >>
> > >>> On Thu, Dec 7, 2017 at 11:07 AM, Masahiko Sawada
&g
h Huong
> wrote:
> > On 2017/12/08 13:18, Huong Dangminh wrote:
> >
> >> Hi Sawada-san,
> >>
> >>> On Thu, Dec 7, 2017 at 11:07 AM, Masahiko Sawada
> >>>
> >>> wrote:
> >>>>
> >>>> On Thu, Dec 7, 20
Hi Sawada-san,
> On Thu, Dec 7, 2017 at 11:07 AM, Masahiko Sawada
> wrote:
> > On Thu, Dec 7, 2017 at 12:23 AM, Dang Minh Huong
> wrote:
> >> Hi Sawada-san,
> >>
> >> Sorry for my late response.
> >>
> >> On 2017/12/05 0:11, Masahiko Sawada wrote:
> >>
> >> There is one more case that user-defin
Hi,
> From: Huong Dangminh [mailto:huo-dangm...@ys.jp.nec.com]
> I attached a patch based on Sawada-san's patch with a bit of messages
> modified and remove the above check.
> Could somebody check it for me or should I add it into CF?
Sorry, I have added this thread to the next
Sorry for not replying sooner.
> > Attached draft patch fixed this issue, at least on my environment.
>
> It works good for me.
>
> > Please review it.
>
> I will review it soon.
There is one more case that user-defined data type is not supported in Logical
Replication.
That is when remote da
Sawada-san,
Thanks for your response.
# And sorry again because I could not reply to your gmail
# address from my environment due to security restriction.
> >> We are getting the bellow error while trying use Logical Replication
> >> with user defined data types in a C program (when call elog fu
Hi,
> We are getting the bellow error while trying use Logical Replication with
> user defined data types in a C program (when call elog function).
>
> ERROR: XX000: cache lookup failed for type X
>
Sorry for continuously disturbing in this topic, but am I missing something
here?
I mean
21 matches
Mail list logo
