Re: Wrong defeinition of pq_putmessage_noblock since 9.5

From: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
To: tgl(at)sss(dot)pgh(dot)pa(dot)us
Cc: masao(dot)fujii(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Wrong defeinition of pq_putmessage_noblock since 9.5
Date: 2016-07-29 03:18:32
Message-ID: 20160729.121832.200301649.horiguchi.kyotaro@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Thu, 28 Jul 2016 10:46:00 -0400, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote in <4313(dot)1469717160(at)sss(dot)pgh(dot)pa(dot)us>
> Fujii Masao <masao(dot)fujii(at)gmail(dot)com> writes:
> > 3. Several source comments in pqcomm.c have not been updated.
> > Some comments still use the old function name like pq_putmessage().
>
> > Attached patch fixes the above issues.
>
> I dunno, this seems like it's doubling down on some extremely poor
> decisions. Why is it that you now have to flip a coin to guess whether
> the prefix is pq_ or socket_ for functions in this module? I would
> rather see that renaming reverted.

The set of functions in PQcommMethods doesn't seem clean. They
are choosed arbitrary just so that other pq_* functions used in
parallel workers will work as expected. I suppose that it needs
some refactoring.

By the way, pq_start/endcopyout() are used only in FE protocols
below 3.0, which had already bacome obsolete as of PG7.4. While
the next dev cycle is for PG10, if there is no particular reason
to support such acient protocols, removing them would make things
easier and cleaner.

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2016-07-29 03:34:55 Re: old_snapshot_threshold allows heap:toast disagreement
Previous Message Robert Haas 2016-07-29 03:08:13 Re: old_snapshot_threshold allows heap:toast disagreement