[Postgres-xl-general] gtm_proxy cannot connect to gtm

Pavan Deolasee pavan.deolasee at gmail.com
Thu Aug 28 05:28:27 PDT 2014


On Thu, Aug 28, 2014 at 1:30 PM, Han Pingtian <hanpt at linux.vnet.ibm.com>
wrote:

> On Wed, Aug 27, 2014 at 10:54:41AM +0530, Pavan Deolasee wrote:
> > I am kind of curious why initializing optval to 0 is helping this case.
> > getsockopt() call above should have set optval to some sane value in any
> > case. I wonder if some kind of compiler optimization is forcing us to
> take
> > the "else if" path even if getsockopt() might be setting optval to 0 in
> any
> > case. IOW the "if" and "else" conditions are evaluated in parallel and
> > since "optval" is uninitialized in the original code, compiler decides to
> > take the "else if" branch once "if" is evaluated to false.
> >
> > Can you please check if taking getsockopt() out of the "if" condition or
> > marking optval as volatile help? BTW this code is borrowed from PG code,
> so
> > I assume similar problem may show up there too on this platform.
>
> Both Taking getsockopt() out of if condition and marking optval as
> volatile don't help.
>
>
Thanks for testing that. That rules out any kind of compiler bug. Looks
like getsockopt() is then neither returning an error nor setting optval to
some sane value. Do you think it could be something to do with the platform
you are testing? That code is borrowed from fe-connect.c in PG code, so
similar issue might exists on vanilla Postgres as well on that platform.

Thanks,
Pavan
-- 
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.postgres-xl.org/pipermail/postgres-xl-general-postgres-xl.org/attachments/20140828/a98a2059/attachment.htm>


More information about the postgres-xl-general mailing list