Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uvB8f-008rNV-M2 for pgpool-hackers@arkaria.postgresql.org; Sun, 07 Sep 2025 08:52:46 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1uvB8d-00Gego-9T for pgpool-hackers@arkaria.postgresql.org; Sun, 07 Sep 2025 08:52:43 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uvB8c-00GegW-Qk for pgpool-hackers@lists.postgresql.org; Sun, 07 Sep 2025 08:52:43 +0000 Received: from mail-yw1-x112b.google.com ([2607:f8b0:4864:20::112b]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1uvB8Y-000yE9-2B for pgpool-hackers@lists.postgresql.org; Sun, 07 Sep 2025 08:52:41 +0000 Received: by mail-yw1-x112b.google.com with SMTP id 00721157ae682-71d601859f5so30509067b3.0 for ; Sun, 07 Sep 2025 01:52:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tailorbrands.com; s=google; t=1757235157; x=1757839957; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=mqZvI3R6FBIFxXB8kW0B0sVXgxQn4G/suXet7wbTsIQ=; b=VDRROdbq9nV+f0lencaUoAX/QFT93OlzkznQgFBZC9vUzEgYlUkDnDmuWk1uSJZPyM FyLmUQdGR5KjZ8U7copgE9YxLRfB0EOeLOQC9aCCRRMQEy4Y0w47MERGYYdXtImhcm+y a/cTqAMOtmSgD6z2A5BmlS8Teorwmbd5itabcFGGiJ05o4AP6O2awb3JRvSJgTRgdIs6 zdbyJwmCItn/trXgpyIhmXCinCQpXjAgxrirySSJMW71eYAR0MAAt8VBdDd2BcxA728a M9YXOJ0AOHTBe3xADHEIGxVlbZ3lH1Qt86yWr1VHjDGMG2CQGGeLNpAqfrz5DPYaWnUF 1+iA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1757235157; x=1757839957; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=mqZvI3R6FBIFxXB8kW0B0sVXgxQn4G/suXet7wbTsIQ=; b=WhIHWPjF2/j70hhqenlvgZpPbTHQSArFNd7lyaPwPr+0y+9uNz3E0e2PWAVsnk29gq IxxaFc7zL+a9kvd/hdq+5lUJH5FzC/m6iVXvvaxQMFCjA7JNnwI8h5hwfInRIIpl4poY tb/6ieN6F0QN9wpMoPqixq7AJS53Fo9hpx2PLtgR4cAM/s9Vjzrq5/bf52yC72Zv/8vO q7ZC1DTQ/LeJY2hSLezp3vLMyOpmLhgxns/zvDlj98QohZLSqBhPESi3DE0kODRjqYg2 NQUclOxf5us+K/YwTQGIoxU0Iwhzdzlz18Zjop27IlfvNpvdy7Tkt41J7ntPQ1Zbozob 4vCw== X-Gm-Message-State: AOJu0Yz+SdwGk/a2322MVP8oHb05BUj8wECyLxSrdMJhs8K5gFFddW4t kHxr9T7RTF6E6x3/gce+lY+HKsWMkciR1VCCZpG1O2Ti/rliCwnPVWitZsKW+dvuyX/KeonFI2Z 4JMShzWL3oe44TUrT/GlMaxe43/FM7UPX8clhtVIf/HOW7C1gifjj3pjCyZ/q X-Gm-Gg: ASbGncvpfKX4IqZN8/6y5WH3GMIW2vsibrsmC4O7QDrsvN6SMI9wwAOnGs7BtbwATwI eO4lJetTWKqTpLnLLlXF/wOx+UsidewwtX2EFnURQLPiEdas7SbOzhIhCZNqNTfD1D67t93NP6r LVbkfw38qX4z2EJliXqgXUuKWOQbOmAj+30WD/qAE4clMSV9+2D/bcqWcXEo/QDFMmj5K99Nmg1 Gv/ow== X-Google-Smtp-Source: AGHT+IH12LnD04lpJjcllGYqMQOvDNTbo6HaG2/gzMhgThONKU+i0E7ktM8mtZoEiVot8HUv1Gx/flCveOFcRQcBnvc= X-Received: by 2002:a05:690c:950c:b0:729:64a0:1cd7 with SMTP id 00721157ae682-72964a01e14mr10428087b3.35.1757235157235; Sun, 07 Sep 2025 01:52:37 -0700 (PDT) MIME-Version: 1.0 References: <20250902.074118.343005423574242823.ishii@postgresql.org> <20250904.083615.1569744760401897215.ishii@postgresql.org> In-Reply-To: <20250904.083615.1569744760401897215.ishii@postgresql.org> From: Nadav Shatz Date: Sun, 7 Sep 2025 11:52:25 +0300 X-Gm-Features: Ac12FXwRWWgC70c_3uPU12rrWsep7vQOHMKTKkXNbjurYvqAvNhV7pWd_6o6cNA Message-ID: Subject: Re: Proposal: recent access based routing for primary-replica setups To: Tatsuo Ishii Cc: pgpool-hackers@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000559e16063e32313b" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000559e16063e32313b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Tatsuo, Thanks for getting back to me. Let me clarify the ordering concern and provide an example to make it clearer: Currently, replication_delay_source_cmd executes without awareness of the replica list or the order in which Pgpool loads them. For Aurora, since we=E2=80=99re bypassing the internal DB tables and fetching lag data direct= ly via the AWS CloudWatch API, we need to ensure the returned lag values are mapped to the correct instances. For example, assume Pgpool has the following configuration: primary: db-primary replicas: db-replica-a, db-replica-b, db-replica-c If the command retrieves lag values [15, 120, 60] from CloudWatch, we need to guarantee these are consistently mapped as: - db-replica-a =E2=86=92 15ms - db-replica-b =E2=86=92 120ms - db-replica-c =E2=86=92 60ms Without explicitly passing the instance identifiers and their order to the command, there=E2=80=99s a risk that mismatched ordering will cause Pgpool = to make incorrect routing decisions. To address this, I suggest extending replication_delay_source_cmd to accept an ordered list of instance identifiers as arguments. This way, the command can fetch the metrics in the same sequence Pgpool expects, ensuring alignment between configuration and returned data. Would you agree this approach makes sense? If so, I can provide an updated patch to demonstrate how the command would handle ordered instance mapping. Best regards, On Thu, Sep 4, 2025 at 2:36=E2=80=AFAM Tatsuo Ishii = wrote: > Hi, > > > Hi, > > > > All good. > > > > The usual way the Pgpool accesses the lag params is through the relevan= t > > tables in the DB. for aurora that isn't available. > > The numbers are available directly from AWS API calls tho. This solutio= n > > will work with Aurora by circumventing this issue. > > > > What i mentioned as a concern is that since the command doesn't current= ly > > accept the actual DB instance list (primary/replicas) and their order i= t > > can't guarantee it'll return the lag values in the expected order. > > > > Except the primary being the first, how will the running command know t= he > > order in which pgpool has loaded the replicas into it's > > memory/configuration? > > > > Hope this makes more sense - if not let me know and i'll provide some > > examples. > > Yes, examples would be helpful. > > Best regards, > -- > Tatsuo Ishii > SRA OSS K.K. > English: http://www.sraoss.co.jp/index_en/ > Japanese:http://www.sraoss.co.jp > > > Thanks, > > > > On Tue, Sep 2, 2025 at 1:41=E2=80=AFAM Tatsuo Ishii > wrote: > > > >> Hi Nadav, > >> > >> Sorry for late reply. > >> > >> >> I haven=E2=80=99t tried it yet but the whole premise of having it r= un a > command > >> is > >> >> that it=E2=80=99s not dependent on the specific DB. As you mentione= d earlier. > >> >> > >> >> The issue blocking the regular lag extraction from aurora is that i= t > >> >> doesn=E2=80=99t update the tables in the DB. It does have a CloudWa= tch API to > >> get > >> >> the numbers tho. > >> > >> I am not familiar with CloudWatch API and am not sure I fully > >> understand you issue. What is your issue with CloudWatch API? Is it a > >> technical problem, or some cost issue (I guess CloudWatch is a paid > >> service)? > >> > >> >> Ordering here could get tricky since we couple the command with the > >> >> instance order. > >> >> > >> >> Maybe we can expand the command to receive some arguments as to > instance > >> >> order. > >> > >> Can you elaborate what "ordering" is? > >> > >> Best regards, > >> -- > >> Tatsuo Ishii > >> SRA OSS K.K. > >> English: http://www.sraoss.co.jp/index_en/ > >> Japanese:http://www.sraoss.co.jp > >> > >> > Hi Tatsuo, > >> > > >> > I don't want to rush at all - did you get a chance to look at what I > >> sent? > >> > Can I share more relevant information with you? > >> > > >> > What do you think? > >> > > >> > On Tue, Aug 26, 2025 at 9:54=E2=80=AFAM Nadav Shatz > >> wrote: > >> > > >> >> Hi Tatsuo, > >> >> > >> >> I haven=E2=80=99t tried it yet but the whole premise of having it r= un a > command > >> is > >> >> that it=E2=80=99s not dependent on the specific DB. As you mentione= d earlier. > >> >> > >> >> The issue blocking the regular lag extraction from aurora is that i= t > >> >> doesn=E2=80=99t update the tables in the DB. It does have a CloudWa= tch API to > >> get > >> >> the numbers tho. > >> >> > >> >> You can see the metric AuroraReplicaLag under > >> >> > >> >> > >> > https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/metrics-refe= rence.html > >> >> > >> >> So if we have a simple command to either get it or have something > else > >> >> update a file with the numbers based on it we=E2=80=99ll be fine. > >> >> > >> >> Ordering here could get tricky since we couple the command with the > >> >> instance order. > >> >> > >> >> Maybe we can expand the command to receive some arguments as to > instance > >> >> order. > >> >> > >> >> What do you think? > >> >> > >> >> > >> >> Nadav Shatz > >> >> Tailor Brands | CTO > >> >> > >> >> > >> >> On Tue, Aug 26, 2025 at 4:42=E2=80=AFAM Tatsuo Ishii > >> wrote: > >> >> > >> >>> Hi Nadav, > >> >>> > >> >>> Thank you for updating the patch. I will look into that. > >> >>> > >> >>> I have a question. Have you actually tried the patch with AWS > Aurora? > >> >>> I am wondering how patched pgpool works with Aurora. I am asking > >> >>> because in the doc "8.5. Aurora Configuration Example": > >> >>> > >> >>> Set sr_check_period to 0 to disable streaming replication delay > >> >>> checking. This is because Aurora does not provide necessary > functions > >> >>> to check the replication delay. > >> >>> > >> >>> sr_check_period =3D 0 > >> >>> > >> >>> So streaming replication checking is disabled, and it means that > your > >> >>> patch is also effectively disabled too. > >> >>> > >> >>> Best regards, > >> >>> -- > >> >>> Tatsuo Ishii > >> >>> SRA OSS K.K. > >> >>> English: http://www.sraoss.co.jp/index_en/ > >> >>> Japanese:http://www.sraoss.co.jp > >> >>> > >> >>> > Hi Tatsuo, > >> >>> > > >> >>> > Thank you for the notes - please find attached an updated versio= n. > >> >>> > > >> >>> > What do you think? > >> >>> > > >> >>> > Thanks, > >> >>> > > >> >>> > On Mon, Aug 25, 2025 at 5:18=E2=80=AFAM Tatsuo Ishii < > ishii@postgresql.org> > >> >>> wrote: > >> >>> > > >> >>> >> Hi Nadav, > >> >>> >> > >> >>> >> Thank you for the patch! > >> >>> >> > >> >>> >> I have one question. How do you provide a password > >> (sr_check_password) > >> >>> >> while executing replication_delay_source_cmd as sr_check_user? > In my > >> >>> >> understanding replication_delay_source_cmd is executed through = su > >> >>> >> command in your patch. In this case su command tries to read th= e > >> >>> >> password from terminal. I don't see such a code in the patch. > >> >>> >> > >> >>> >> BTW, I start to think that executing > replication_delay_source_cmd as > >> >>> >> sr_check_user might not be a good idea. sr_check_user is a > database > >> >>> >> user, not OS user. In PostgreSQL they are not necessarily the > >> >>> >> same. Also doing su in pgpool process needs to be very carefull= y > to > >> >>> >> avoid vulnerability. Probably we just execute it as pgpool OS > user? > >> >>> >> > >> >>> >> Lastly when I apply the patches using git apply, there are some > >> >>> >> trailing space errors. > >> >>> >> > >> >>> >> $ git apply ~/external-lag-feature-implementation.patch > >> >>> >> /home/t-ishii/external-lag-feature-implementation.patch:314: > >> trailing > >> >>> >> whitespace. > >> >>> >> > >> >>> >> /home/t-ishii/external-lag-feature-implementation.patch:317: > >> trailing > >> >>> >> whitespace. > >> >>> >> > >> >>> >> /home/t-ishii/external-lag-feature-implementation.patch:318: > >> trailing > >> >>> >> whitespace. > >> >>> >> cmd_len =3D strlen(escaped_cmd) + > >> >>> >> /home/t-ishii/external-lag-feature-implementation.patch:320: > >> trailing > >> >>> >> whitespace. > >> >>> >> > >> >>> >> /home/t-ishii/external-lag-feature-implementation.patch:322: > >> trailing > >> >>> >> whitespace. > >> >>> >> snprintf(full_command, cmd_len, "su - %= s > -c > >> >>> '%s'", > >> >>> >> warning: squelched 4 whitespace errors > >> >>> >> warning: 9 lines add whitespace errors. > >> >>> >> > >> >>> >> $ git apply ~/external-lag-feature-tests.patch > >> >>> >> /home/t-ishii/external-lag-feature-tests.patch:87: trailing > >> whitespace. > >> >>> >> - test_parsing.sh: Unit test for parsing logic > >> >>> >> /home/t-ishii/external-lag-feature-tests.patch:440: trailing > >> >>> whitespace. > >> >>> >> # Test 2: Float values > >> >>> >> warning: 2 lines add whitespace errors. > >> >>> >> > >> >>> >> Also I have some compilation errors after patching the source > >> >>> >> code. See attached compilation log. > >> >>> >> > >> >>> >> Best regards, > >> >>> >> -- > >> >>> >> Tatsuo Ishii > >> >>> >> SRA OSS K.K. > >> >>> >> English: http://www.sraoss.co.jp/index_en/ > >> >>> >> Japanese:http://www.sraoss.co.jp > >> >>> >> > >> >>> > > >> >>> > > >> >>> > -- > >> >>> > Nadav Shatz > >> >>> > Tailor Brands | CTO > >> >>> > >> >> > >> > > >> > -- > >> > Nadav Shatz > >> > Tailor Brands | CTO > >> > > > > > > -- > > Nadav Shatz > > Tailor Brands | CTO > --=20 Nadav Shatz Tailor Brands | CTO --000000000000559e16063e32313b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Tatsuo,

Thanks for getting back to me. Let me clarify the ord= ering concern and provide an example to make it clearer:

Currently, replication_delay= _source_cmd executes without awareness of the replica list or the or= der in which Pgpool loads them. For Aurora, since we=E2=80=99re bypassing t= he internal DB tables and fetching lag data directly via the AWS CloudWatch= API, we need to ensure the returned lag values are mapped to the correct i= nstances.

For example, assume Pgpool has the following configur= ation:

primary: db-primary =20
replicas: db-replica-a, db-replica-b, db-replica-c

If the command retrieves lag values [15, 120, 60] from CloudWatch, we need to guarantee these ar= e consistently mapped as:

  • db-replica-a =E2=86=92 15ms<= /span>

  • db-replica-b =E2=86=92 120ms=

  • db-replica-c =E2=86=92 60ms<= /span>

Without explicitly passing the instance identifiers a= nd their order to the command, there=E2=80=99s a risk that mismatched order= ing will cause Pgpool to make incorrect routing decisions.

To address this, I suggest extending replication_delay_source_cmd to accept an ordered list of i= nstance identifiers as arguments. This way, the command can fetch the metri= cs in the same sequence Pgpool expects, ensuring alignment between configur= ation and returned data.

Would you agree this approach makes sense? If so, I c= an provide an updated patch to demonstrate how the command would handle ord= ered instance mapping.


Best regards,

=
On Thu, Sep 4, 2025 at 2:36=E2=80=AFAM Tatsuo Ishii <ishii@postgresql.org> wrote:
Hi,

> Hi,
>
> All good.
>
> The usual way the Pgpool accesses the lag params is through the releva= nt
> tables in the DB. for aurora that isn't available.
> The numbers are available directly from AWS API calls tho. This soluti= on
> will work with Aurora by circumventing this issue.
>
> What i mentioned as a concern is that since the command doesn't cu= rrently
> accept the actual DB instance list (primary/replicas) and their order = it
> can't guarantee it'll return the lag values in the expected or= der.
>
> Except the primary being the first, how will the running command know = the
> order in which pgpool has loaded the replicas into it's
> memory/configuration?
>
> Hope this makes more sense - if not let me know and i'll provide s= ome
> examples.

Yes, examples would be helpful.

Best regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp

> Thanks,
>
> On Tue, Sep 2, 2025 at 1:41=E2=80=AFAM Tatsuo Ishii <ishii@postgresql.org> wr= ote:
>
>> Hi Nadav,
>>
>> Sorry for late reply.
>>
>> >> I haven=E2=80=99t tried it yet but the whole premise of h= aving it run a command
>> is
>> >> that it=E2=80=99s not dependent on the specific DB. As yo= u mentioned earlier.
>> >>
>> >> The issue blocking the regular lag extraction from aurora= is that it
>> >> doesn=E2=80=99t update the tables in the DB. It does have= a CloudWatch API to
>> get
>> >> the numbers tho.
>>
>> I am not familiar with CloudWatch API and am not sure I fully
>> understand you issue. What is your issue with CloudWatch API?=C2= =A0 Is it a
>> technical problem, or some cost issue (I guess CloudWatch is a pai= d
>> service)?
>>
>> >> Ordering here could get tricky since we couple the comman= d with the
>> >> instance order.
>> >>
>> >> Maybe we can expand the command to receive some arguments= as to instance
>> >> order.
>>
>> Can you elaborate what "ordering" is?
>>
>> Best regards,
>> --
>> Tatsuo Ishii
>> SRA OSS K.K.
>> English: http://www.sraoss.co.jp/index_en/
>> Japanese:http://www.sraoss.co.jp
>>
>> > Hi Tatsuo,
>> >
>> > I don't want to rush at all - did you get a chance to loo= k at what I
>> sent?
>> > Can I share more relevant information with you?
>> >
>> > What do you think?
>> >
>> > On Tue, Aug 26, 2025 at 9:54=E2=80=AFAM Nadav Shatz <nadav@tailorbrands.c= om>
>> wrote:
>> >
>> >> Hi Tatsuo,
>> >>
>> >> I haven=E2=80=99t tried it yet but the whole premise of h= aving it run a command
>> is
>> >> that it=E2=80=99s not dependent on the specific DB. As yo= u mentioned earlier.
>> >>
>> >> The issue blocking the regular lag extraction from aurora= is that it
>> >> doesn=E2=80=99t update the tables in the DB. It does have= a CloudWatch API to
>> get
>> >> the numbers tho.
>> >>
>> >> You can see the metric AuroraReplicaLag under
>> >>
>> >>
>> https://= docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/metrics-reference.html=
>> >>
>> >> So if we have a simple command to either get it or have s= omething else
>> >> update a file with the numbers based on it we=E2=80=99ll = be fine.
>> >>
>> >> Ordering here could get tricky since we couple the comman= d with the
>> >> instance order.
>> >>
>> >> Maybe we can expand the command to receive some arguments= as to instance
>> >> order.
>> >>
>> >> What do you think?
>> >>
>> >>
>> >> Nadav Shatz
>> >> Tailor Brands | CTO
>> >>
>> >>
>> >> On Tue, Aug 26, 2025 at 4:42=E2=80=AFAM Tatsuo Ishii <= ishii@postgresql.= org>
>> wrote:
>> >>
>> >>> Hi Nadav,
>> >>>
>> >>> Thank you for updating the patch. I will look into th= at.
>> >>>
>> >>> I have a question. Have you actually tried the patch = with AWS Aurora?
>> >>> I am wondering how patched pgpool works with Aurora. = I am asking
>> >>> because in the doc "8.5. Aurora Configuration Ex= ample":
>> >>>
>> >>>=C2=A0 Set sr_check_period to 0 to disable streaming r= eplication delay
>> >>>=C2=A0 checking. This is because Aurora does not provi= de necessary functions
>> >>>=C2=A0 to check the replication delay.
>> >>>
>> >>>=C2=A0 sr_check_period =3D 0
>> >>>
>> >>> So streaming replication checking is disabled, and it= means that your
>> >>> patch is also effectively disabled too.
>> >>>
>> >>> Best regards,
>> >>> --
>> >>> Tatsuo Ishii
>> >>> SRA OSS K.K.
>> >>> English: http://www.sraoss.co.jp/index_en/
>> >>> Japanese:http://www.sraoss.co.jp
>> >>>
>> >>> > Hi Tatsuo,
>> >>> >
>> >>> > Thank you for the notes - please find attached a= n updated version.
>> >>> >
>> >>> > What do you think?
>> >>> >
>> >>> > Thanks,
>> >>> >
>> >>> > On Mon, Aug 25, 2025 at 5:18=E2=80=AFAM Tatsuo I= shii <ishii@po= stgresql.org>
>> >>> wrote:
>> >>> >
>> >>> >> Hi Nadav,
>> >>> >>
>> >>> >> Thank you for the patch!
>> >>> >>
>> >>> >> I have one question. How do you provide a pa= ssword
>> (sr_check_password)
>> >>> >> while executing replication_delay_source_cmd= as sr_check_user? In my
>> >>> >> understanding replication_delay_source_cmd i= s executed through su
>> >>> >> command in your patch. In this case su comma= nd tries to read the
>> >>> >> password from terminal. I don't see such= a code in the patch.
>> >>> >>
>> >>> >> BTW, I start to think that executing replica= tion_delay_source_cmd as
>> >>> >> sr_check_user might not be a good idea. sr_c= heck_user is a database
>> >>> >> user, not OS user. In PostgreSQL they are no= t necessarily the
>> >>> >> same. Also doing su in pgpool process needs = to be very carefully to
>> >>> >> avoid vulnerability. Probably we just execut= e it as pgpool OS user?
>> >>> >>
>> >>> >> Lastly when I apply the patches using git ap= ply, there are some
>> >>> >> trailing space errors.
>> >>> >>
>> >>> >> $ git apply ~/external-lag-feature-implement= ation.patch
>> >>> >> /home/t-ishii/external-lag-feature-implement= ation.patch:314:
>> trailing
>> >>> >> whitespace.
>> >>> >>
>> >>> >> /home/t-ishii/external-lag-feature-implement= ation.patch:317:
>> trailing
>> >>> >> whitespace.
>> >>> >>
>> >>> >> /home/t-ishii/external-lag-feature-implement= ation.patch:318:
>> trailing
>> >>> >> whitespace.
>> >>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0cmd_len =3D strlen(escaped_cmd= ) +
>> >>> >> /home/t-ishii/external-lag-feature-implement= ation.patch:320:
>> trailing
>> >>> >> whitespace.
>> >>> >>
>> >>> >> /home/t-ishii/external-lag-feature-implement= ation.patch:322:
>> trailing
>> >>> >> whitespace.
>> >>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0snprintf(full_command, cmd_len= , "su - %s -c
>> >>> '%s'",
>> >>> >> warning: squelched 4 whitespace errors
>> >>> >> warning: 9 lines add whitespace errors.
>> >>> >>
>> >>> >> $ git apply ~/external-lag-feature-tests.pat= ch
>> >>> >> /home/t-ishii/external-lag-feature-tests.pat= ch:87: trailing
>> whitespace.
>> >>> >> - test_parsing.sh: Unit test for parsing log= ic
>> >>> >> /home/t-ishii/external-lag-feature-tests.pat= ch:440: trailing
>> >>> whitespace.
>> >>> >> # Test 2: Float values
>> >>> >> warning: 2 lines add whitespace errors.
>> >>> >>
>> >>> >> Also I have some compilation errors after pa= tching the source
>> >>> >> code. See attached compilation log.
>> >>> >>
>> >>> >> Best regards,
>> >>> >> --
>> >>> >> Tatsuo Ishii
>> >>> >> SRA OSS K.K.
>> >>> >> English: http://www.sraoss.co.jp/ind= ex_en/
>> >>> >> Japanese:http://www.sraoss.co.jp
>> >>> >>
>> >>> >
>> >>> >
>> >>> > --
>> >>> > Nadav Shatz
>> >>> > Tailor Brands | CTO
>> >>>
>> >>
>> >
>> > --
>> > Nadav Shatz
>> > Tailor Brands | CTO
>>
>
>
> --
> Nadav Shatz
> Tailor Brands | CTO


--
Nadav Shatz
<= font color=3D"#000000">Tailor Brands=C2=A0| CTO
--000000000000559e16063e32313b--