On Thu, Nov 9, 2023 at 9:15 PM Drouvot, Bertrand
wrote:
>
>
> You mean here?
>
> /*
> * Check to see if promotion is requested. Note that we do
> * this only after failure, so when you promote, we still
> * finish replaying as much as we can from archive and
> * pg_wal before failover.
>
On Fri, Nov 10, 2023 at 12:50 PM Drouvot, Bertrand
wrote:
>
> On 11/10/23 6:41 AM, Amit Kapila wrote:
> > On Thu, Nov 9, 2023 at 7:29 PM Drouvot, Bertrand
> > wrote:
> >
> > Are you saying that we change the state of the already existing slot
> > on standby?
>
> Yes.
>
> > And, such a state
Hi
On 02.11.23 17:27, Gilles Darold wrote:
> Hi,
>
>
> Look like the tab completion for CREATE TABLE ... AS is not proposed.
>
>
> gilles=# CREATE TABLE test
> ( OF PARTITION OF
>
> The attached patch fix that and also propose the further completion
> after the AS keyword.
On 09.11.23 00:05, Michael Paquier wrote:
Attached is a Perl version of the sed script, converted by hand (so not the
super-verbose s2p thing). It's basically just the sed script with
semicolons added and the backslashes in the regular expressions moved
around. I think we could use something
Hi,
On 11/10/23 6:41 AM, Amit Kapila wrote:
On Thu, Nov 9, 2023 at 7:29 PM Drouvot, Bertrand
wrote:
Are you saying that we change the state of the already existing slot
on standby?
Yes.
And, such a state would indicate that we are trying to
sync the slot with the same name from the
On Thu, Nov 9, 2023 at 7:29 PM Drouvot, Bertrand
wrote:
>
> On 11/9/23 3:41 AM, Amit Kapila wrote:
> > On Wed, Nov 8, 2023 at 8:09 PM Drouvot, Bertrand
> > wrote:
> >>
> >>> Unrelated to above, if there is a user slot on standby with the same
> >>> name which the slot-sync worker is trying to
On Thu, Nov 9, 2023 at 4:55 PM Alvaro Herrera wrote:
>
> IMO the whole area of SLRU buffering is in horrible shape and many users
> are struggling with overall PG performance because of it. An
> improvement doesn't have to be perfect -- it just has to be much better
> than the current situation,
On Thu, Nov 9, 2023 at 9:39 PM Robert Haas wrote:
>
> On Wed, Nov 8, 2023 at 6:41 AM Dilip Kumar wrote:
> > Here is the updated version of the patch, here I have taken the
> > approach suggested by Andrey and I discussed the same with Alvaro
> > offlist and he also agrees with it. So the idea
On Tue, Nov 07, 2023 at 05:20:27PM +0900, Michael Paquier wrote:
> On Mon, Nov 06, 2023 at 05:39:02PM -0400, David Steele wrote:
> I've retested today, and miss the failure. I'll let you know if I see
> this again.
I've done a few more dozen runs, and still nothing. I am wondering
what this
Hi,
On November 8, 2023 11:28:08 PM PST, Michael Paquier
wrote:
>On Thu, Nov 09, 2023 at 01:50:34PM +0900, torikoshia wrote:
>> PGSTAT_KIND_SLRU cannot be reset by pg_stat_reset_shared(), so I feel
>> uncomfortable to delete it all together.
>> It might be better after pg_stat_reset_shared()
On Fri, Nov 10, 2023 at 12:33:50PM +0900, torikoshia wrote:
> On 2023-11-09 16:28, Michael Paquier wrote:
>> Not sure how to feel about that, TBH, but I would not include SLRUs
>> here if we have already a separate function.
>
> IMHO I agree with you.
The comments added could be better
Hi,
I just created a primary with wal_segment_size=512. Then tried to create a
standby via pg_basebackup. The pg_basebackup appeared to just hang, for quite
a while, but did eventually complete. Over a minute for an empty cluster, when
using -c fast.
In this case I had used
Dear hackers,
> Next we should add some test codes. I will continue considering but please
> post
> anything
> If you have idea.
And I did, PSA the patch. This patch adds two parts in hash_index.sql.
In the first part, the primary bucket page is filled by live tuples and some
overflow
pages
On 2023-11-09 16:28, Michael Paquier wrote:
Thanks for your review.
Attached v2 patch.
On Thu, Nov 09, 2023 at 01:50:34PM +0900, torikoshia wrote:
PGSTAT_KIND_SLRU cannot be reset by pg_stat_reset_shared(), so I feel
uncomfortable to delete it all together.
It might be better after
Here is a new attempt to fix this mess. Disclaimer: this based
entirely on reading the manual and vicariously hacking a computer I
don't have via CI.
The two basic ideas are:
* keep per-socket event handles in a hash table
* add our own level-triggered event memory
The socket table entries
On Thu, Nov 9, 2023 at 9:15 PM Drouvot, Bertrand
wrote:
>
> Hi,
>
> On 11/9/23 11:54 AM, shveta malik wrote:
> >
> > PFA v32 patches which has below changes:
>
> Thanks!
>
> > 7) Added warning for cases where a user-slot with the same name is
> > already present which slot-sync worker is trying
Hi,
On 2023-11-10 08:17:48 +0530, vignesh C wrote:
> On Thu, 9 Nov 2023 at 21:12, Tristan Partin wrote:
> >
> > On Thu Nov 9, 2023 at 9:31 AM CST, Nazir Bilal Yavuz wrote:
> > > Hi,
> > >
> > > On Thu, 9 Nov 2023 at 18:27, Tristan Partin wrote:
> > > >
> > > > Can you try with Meson v1.2.3?
> >
On Thu, 9 Nov 2023 at 21:12, Tristan Partin wrote:
>
> On Thu Nov 9, 2023 at 9:31 AM CST, Nazir Bilal Yavuz wrote:
> > Hi,
> >
> > On Thu, 9 Nov 2023 at 18:27, Tristan Partin wrote:
> > >
> > > Can you try with Meson v1.2.3?
> >
> > I tried with Meson v1.2.3 and upstream, both failed with the
On Thu, Nov 09, 2023 at 04:52:32PM +0900, Michael Paquier wrote:
> Thanks!
Also, please see also a patch about switching the logirep launcher to
rely on IsBinaryUpgrade to prevent its startup. Any thoughts about
that?
--
Michael
diff --git a/src/backend/replication/logical/launcher.c
On Fri, 10 Nov 2023 at 00:58, Peter Geoghegan wrote:
> On Tue, Nov 7, 2023 at 5:53 PM Peter Geoghegan wrote:
> > If you end up finding a bug in this v6, it'll most likely be a case
> > where nbtree fails to live up to that. This project is as much about
> > robust/predictable performance as
Hi Jacob,
Wanted to follow up on one of the topics discussed here in the past:
Do you plan to support adding an extension hook to validate the token?
It would allow a more efficient integration, then spinning a separate
process.
Thanks!
Andrey.
On Wed, Nov 8, 2023 at 11:00 AM Jacob Champion
On Tue, Nov 7, 2023 at 5:53 PM Peter Geoghegan wrote:
> If you end up finding a bug in this v6, it'll most likely be a case
> where nbtree fails to live up to that. This project is as much about
> robust/predictable performance as anything else -- nbtree needs to be
> able to cope with
On Thu, Nov 9, 2023 at 06:44:42PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > On Wed, Oct 24, 2018 at 04:01:29PM -0400, Robert Haas wrote:
> >>> This was complained of already,
> >>> https://www.postgresql.org/message-id/flat/3876.1531261875%40sss.pgh.pa.us
>
> >> I guess you never
Bruce Momjian writes:
> On Wed, Oct 24, 2018 at 04:01:29PM -0400, Robert Haas wrote:
>>> This was complained of already,
>>> https://www.postgresql.org/message-id/flat/3876.1531261875%40sss.pgh.pa.us
>> I guess you never followed up on that part, though. Any special
>> reason for that, or just
On Sun, Oct 21, 2018 at 04:24:16PM -0400, Tom Lane wrote:
> Oleg Bartunov writes:
> > The commit 9b5c8d45f62bd3d243a40cc84deb93893f2f5122 is now 10+ years
> > old, may be we could remove deprecated @@@ operator ?
>
> Is it actually causing any problem? AFAICS it's just a couple extra
>
On Wed, Oct 24, 2018 at 04:01:29PM -0400, Robert Haas wrote:
> On Mon, Oct 22, 2018 at 9:47 AM Tom Lane wrote:
> > Dilip Kumar writes:
> > > As part of the security fix
> > > (e2d4ef8de869c57e3bf270a30c12d48c2ce4e00c), we have restricted the
> > > users from accessing the statistics of the table
On Fri, Nov 10, 2023 at 08:25:35AM +0900, Michael Paquier wrote:
> On Thu, Nov 09, 2023 at 04:14:07PM -0500, Bruce Momjian wrote:
> > Attached is the full patch that changes pg_walfile_name_offset() and
> > pg_walfile_name(). There is no need for doc changes. We need to
> > document this as
On Thu, Nov 09, 2023 at 04:14:07PM -0500, Bruce Momjian wrote:
> Attached is the full patch that changes pg_walfile_name_offset() and
> pg_walfile_name(). There is no need for doc changes. We need to
> document this as incompatible in case users are realying on the old
> behavior for WAL
On Thu, Nov 09, 2023 at 03:41:53PM +0100, Peter Eisentraut wrote:
> On 08.11.23 00:12, Michael Paquier wrote:
>> - Should the subdirectory pg_basebackup be renamed into something more
>> generic at this point? All these things are frontend tools that deal
>> in some way with the replication
Hi,
On November 9, 2023 10:41:01 AM PST, Tom Lane wrote:
>Also, pg_upgrade is often invoked indirectly via scripts, so I do
>not especially buy the idea that we're going to get useful control
>input from some human somewhere. I think we'd be better off to
>assume that pg_upgrade is on its own
On Tue, Nov 07, 2023 at 04:58:16PM -0800, Andres Freund wrote:
> On 2023-11-07 11:02:49 -0600, Nathan Bossart wrote:
>> Is there something special about all other backends being shut down that
>> ensures this returns the most up-to-date value and not something from "some
>> point in the past" as
On Thu, Nov 9, 2023 at 09:49:48PM +0100, Matthias van de Meent wrote:
> > I have attached fix #1 as offset1.diff and fix #2 as offset2.diff.
>
> I believe you got the references wrong; fix #1 looks like the output
> of offset2's changes, and fix #2 looks like the result of offset1's
> changes.
Hi,
On 2023-11-08 13:10:34 +0530, Bharath Rupireddy wrote:
> > > + /*
> > > + * The fact that we acquire WALBufMappingLock while reading
> > > the WAL
> > > + * buffer page itself guarantees that no one else
> > > initializes it or
> > > + *
On Thu, 9 Nov 2023 at 20:22, Bruce Momjian wrote:
> I know this bug report is four years old, but it is still a
> pg_walfile_name_offset() bug. Here is the bug:
>
> SELECT *
> FROM (VALUES ('0/16ff'), ('0/1700'), ('0/1701')) AS
> t(lsn),
> LATERAL
On 2023-11-09 Th 10:42, Tristan Partin wrote:
On Thu Nov 9, 2023 at 9:31 AM CST, Nazir Bilal Yavuz wrote:
Hi,
On Thu, 9 Nov 2023 at 18:27, Tristan Partin wrote:
>
> Can you try with Meson v1.2.3?
I tried with Meson v1.2.3 and upstream, both failed with the same error.
Please open a bug
On Fri, Jul 26, 2019 at 11:30:19AM +0200, Jehan-Guillaume de Rorthais wrote:
> On Fri, 26 Jul 2019 17:21:20 +0900 (Tokyo Standard Time)
> Kyotaro Horiguchi wrote:
>
> > Hello.
> >
> > While looking [1], I noticed that pg_walfile_name_offset behaves
> > somewhat oddly at segment boundary.
> >
>
Laurenz Albe writes:
> Thanks for the feedback. I'll set the patch to "ready for committer" then.
So, just to clarify, we're settling on your v4 from [1]?
regards, tom lane
[1]
I wrote:
> Jacob Champion writes:
>> Is this approach backportable?
> The code fix would surely work in the back branches. Whether the
> behavioral change is too big to be acceptable in minor releases
> is something I don't have a strong opinion on.
I'm hearing nothing but crickets :-(
If
On Thu, 2023-11-09 at 15:59 +, Dean Rasheed wrote:
> On Thu, 9 Nov 2023 at 15:16, Laurenz Albe wrote:
> > I have thought some more about this, and I believe that if FOR SELECT
> > policies are used to check new rows, you should be allowed to specify
> > WITH CHECK on FOR SELECT policies. Why
[ Jacob's email address updated ]
"Kumar, Sachin" writes:
> Hi Everyone , I want to continue this thread , I have rebased the patch to
> latest
> master and fixed an issue when pg_restore prints to file.
Um ... you didn't attach the patch?
FWIW, I agree with Jacob's concern about it being a
Hi,
On 2023-11-09 15:32:39 +0100, Peter Eisentraut wrote:
> On 09.11.23 01:59, Andres Freund wrote:
> > > I think we could build doc/src/sgml/postgres-full.xml by default. That
> > > takes less than 0.5 seconds here and it's an intermediate target for html
> > > and man.
> > That does require
Hi Everyone , I want to continue this thread , I have rebased the patch to
latest
master and fixed an issue when pg_restore prints to file.
`
╰─$ pg_restore dump_small.custom --restore-blob-batch-size=2 --file=a
--
-- End BLOB restore batch
--
COMMIT;
`
> On 09/11/2023, 17:05, "Jacob
On 11/9/23 05:47, Peter Eisentraut wrote:
I went over the patch
v17-0001-Add-temporal-PRIMARY-KEY-and-UNIQUE-constraints.patch in more
detail
Thanks Peter!
I'm about halfway through jian he's last two emails. I'll address your
feedback also. I wanted to reply to this without waiting though:
I wrote:
> This comes out when you write something like '{foo"bar"}', and I'd
> say the choice of message is not great. On the other hand, it's
> consistent with what you get from '{"foo""bar"}', and if we wanted
> to change that too then some tweaking of the state machine in
> ReadArrayStr would
That looks good to me!
The new status of this patch is: Ready for Committer
Aleksander Alekseev,
> Maxim,
> I see both of us accounted for Alexanders feedback and submitted v59.
> Your newer version seems to have issues on cfbot, so resubmitting the
> previous patchset that passes the tests. Please feel free to add
> changes.
For unknown reasons, I do not receive any of
On 18/09/2023 07:08, David Rowley wrote:
On Fri, 15 Sept 2023 at 22:37, Heikki Linnakangas wrote:
I've added a call to LockAssertNoneHeld(false) in there.
I don't see it in the patch?
hmm. I must've git format-patch before committing that part.
I'll try that again... see attached.
This
On Wed, Nov 8, 2023 at 6:41 AM Dilip Kumar wrote:
> Here is the updated version of the patch, here I have taken the
> approach suggested by Andrey and I discussed the same with Alvaro
> offlist and he also agrees with it. So the idea is that we will keep
> the bank size fixed which is 16 buffers
On Thu, 9 Nov 2023 at 15:16, Laurenz Albe wrote:
>
> I have thought some more about this, and I believe that if FOR SELECT
> policies are used to check new rows, you should be allowed to specify
> WITH CHECK on FOR SELECT policies. Why not allow a user to specify
> different conditions for
Hi,
On 11/9/23 11:54 AM, shveta malik wrote:
PFA v32 patches which has below changes:
Thanks!
7) Added warning for cases where a user-slot with the same name is
already present which slot-sync worker is trying to create. Sync for
such slots is skipped.
I'm seeing assertion and segfault
On Thu Nov 9, 2023 at 9:31 AM CST, Nazir Bilal Yavuz wrote:
Hi,
On Thu, 9 Nov 2023 at 18:27, Tristan Partin wrote:
>
> Can you try with Meson v1.2.3?
I tried with Meson v1.2.3 and upstream, both failed with the same error.
Please open a bug in the Meson repository which also mentions the
Hi,
On Thu, 9 Nov 2023 at 18:27, Tristan Partin wrote:
>
> Can you try with Meson v1.2.3?
I tried with Meson v1.2.3 and upstream, both failed with the same error.
--
Regards,
Nazir Bilal Yavuz
Microsoft
Can you try with Meson v1.2.3?
--
Tristan Partin
Neon (https://neon.tech)
On Wed, 2023-10-25 at 09:45 +0200, Laurenz Albe wrote:
> I can accept that the error is intentional, even though it violated the
> POLA for me. I can buy into the argument that an UPDATE should not make
> a row seem to vanish.
>
> I cannot buy into the constraint argument. If the table owner
Hi,
Adding Kyotaro to CC because Kyotaro reported a similar issue before [1].
On Thu, 9 Nov 2023 at 11:59, Shlok Kyal wrote:
>
> Hi,
> I am trying to build postgres with meson on Windows. And I am stuck in
> the process.
>
> Steps I followed:
>
> 1. I clone postgres repo
>
> 2.Installed meson
David Rowley writes:
> I've pushed this. I backpatched due to the typo in the fsync GUC
> description. I'd have only pushed to master if it were just the
> comment typos.
FTR, I do not think you should have back-patched. You created extra
work for the translation team, and the mistake is
On Thu, Nov 9, 2023 at 4:56 PM torikoshia wrote:
>
> On 2023-11-09 16:11, Ashutosh Bapat wrote:
> > On Thu, Nov 9, 2023 at 12:03 PM torikoshia
> > wrote:
> >> >>
> >> >> 1. When a backend is running nested queries, we will see the plan of
> >> >> the innermost query. That query may not be the
On 08.11.23 00:12, Michael Paquier wrote:
- Should the subdirectory pg_basebackup be renamed into something more
generic at this point? All these things are frontend tools that deal
in some way with the replication protocol to do their work. Say
a replication_tools?
Seems like unnecessary
On 09.11.23 00:21, Andres Freund wrote:
Example output:
This is very nice!
$ ninja help
[0/1 1 0%] Running external command help (wrapped by meson to set env)
Code Targets:
all Build everything other than documentation
backend Build
On 09.11.23 01:59, Andres Freund wrote:
I think we could build doc/src/sgml/postgres-full.xml by default. That
takes less than 0.5 seconds here and it's an intermediate target for html
and man.
That does require the docbook dtd to be installed, afaict. I think we would
need a configure test
I went and had another look at this. The patch has been around for 18
commitfests and is widely considered to add a good feature, so it seems about
time to get reach closure.
As I've mentioned in the past I'm not a big fan of the parser, but the thread
has overruled on that. Another thing I
On 2023-Nov-09, Amit Kapila wrote:
> These comments appear mostly repetitive to what is already mentioned
> in start_postmaster(). So, I have changed those referred to already
> written comments, and slightly adjusted the comments at another place.
> See attached.
I'd still rather mention
Hi,
On 11/9/23 3:41 AM, Amit Kapila wrote:
On Wed, Nov 8, 2023 at 8:09 PM Drouvot, Bertrand
wrote:
Unrelated to above, if there is a user slot on standby with the same
name which the slot-sync worker is trying to create, then shall it
emit a warning and skip the sync of that slot or shall
On Thu, 9 Nov 2023 at 15:01, Amul Sul wrote:
>
> Here is the updated version patch. Did minor changes to documents and
> tests.
>
Overall patch looks good to me. Since Peter did withdraw his comment on
triggers and no open problems
are present, we can make this patch RfC, shall we? It would be
On 02.11.23 21:21, Paul Jungwirth wrote:
New patches attached (rebased to 0bc726d9).
I went over the patch
v17-0001-Add-temporal-PRIMARY-KEY-and-UNIQUE-constraints.patch in more
detail. Attached is a fixup patch that addresses a variety of cosmetic
issues.
Some details:
- Renamed
On Thu, Nov 9, 2023 at 4:09 PM Alvaro Herrera wrote:
>
> On 2023-Nov-02, Kyotaro Horiguchi wrote:
>
> > diff --git a/src/backend/access/transam/xlog.c
> > b/src/backend/access/transam/xlog.c
> > index b541be8eec..46833f6ecd 100644
> > --- a/src/backend/access/transam/xlog.c
> > +++
On Sun, 5 Nov 2023 at 11:52, Dean Rasheed wrote:
>
> OK, that's a fair point. Attached is a new version, replacing those
> parts of the implementation with a new MergingFunc node. It doesn't
> add that much more complexity, and I think the new code is much
> neater.
>
Rebased version attached,
On Tue, Nov 7, 2023 at 8:21 PM Peter Eisentraut
wrote:
> On 25.10.23 08:12, Amul Sul wrote:
> > Here is the rebase version for the latest master head(673a17e3120).
> >
> > I haven't done any other changes related to the ON UPDATE trigger since
> that
> > seems non-trivial; need a bit of work to
Hello,
> On 9 Nov 2023, at 01:30, Michael Paquier wrote:
>
> I am not really convinced that this is worth complicating the skipped
> path for this goal. In my experience, I've seen complaints where WAL
> archiving bloat was coming from the archive command not able to keep
> up with the amount
zhihuifan1...@163.com writes:
Hi,
Here is the v3, the mainly changes is it maintains the UniqueKey on
joinrel level, which probabaly is the most important part of this
feature. It shows how the UnqiueKey on joinrel is generated and how it
is discarded due to non-interesting-uniquekey and also
Hi,
On Wed, 8 Nov 2023 at 04:19, Andres Freund wrote:
>
> Hi,
>
> On 2023-11-08 09:52:16 +0900, Michael Paquier wrote:
> > By the way, if the write/sync quantities and times begin to be tracked
> > by pg_stat_io, I'd see a pretty good argument in removing the
> > equivalent columns in
On 2023-11-09 16:11, Ashutosh Bapat wrote:
On Thu, Nov 9, 2023 at 12:03 PM torikoshia
wrote:
>>
>> 1. When a backend is running nested queries, we will see the plan of
>> the innermost query. That query may not be the actual culprit if the
>> user query is running slowly. E.g a query being run
IMO the whole area of SLRU buffering is in horrible shape and many users
are struggling with overall PG performance because of it. An
improvement doesn't have to be perfect -- it just has to be much better
than the current situation, which should be easy enough. We can
continue to improve later,
On Thu, 9 Nov 2023 at 14:22, Michael Paquier wrote:
>
> On Wed, Nov 08, 2023 at 08:31:28PM +1300, David Rowley wrote:
> > Those all look fine to me too.
>
> +1.
I've pushed this. I backpatched due to the typo in the fsync GUC
description. I'd have only pushed to master if it were just the
On 2023-Nov-09, Peter Smith wrote:
> Notice that NOT QUOTED is the far more common pattern, so my vote
> would be just to standardise on making everything this way. I know
> there was some concern raised about ambiguous words like "timezone"
> and "datestyle" etc but in practice, those are rare.
On 2023-Nov-02, Kyotaro Horiguchi wrote:
> diff --git a/src/backend/access/transam/xlog.c
> b/src/backend/access/transam/xlog.c
> index b541be8eec..46833f6ecd 100644
> --- a/src/backend/access/transam/xlog.c
> +++ b/src/backend/access/transam/xlog.c
> @@ -2063,6 +2063,29 @@
On Wed, Nov 8, 2023 at 11:05 PM vignesh C wrote:
>
> On Wed, 8 Nov 2023 at 08:43, vignesh C wrote:
>
> Here is a small improvisation where num_slots need not be initialized
> as it will be used only after assigning the result now. The attached
> patch has the changes for the same.
>
Pushed!
--
Hi,
Thanks for all the feedback!
On Wed, 8 Nov 2023 at 08:59, Michael Paquier wrote:
>
> By the way, note that the patch is failing to apply, and that I've
> switched it as waiting on author on 10/26.
Here is an updated patchset in attachment. Rebased on the latest HEAD
and changed
> On 9 Nov 2023, at 00:51, Peter Smith wrote:
>
> Hi,
>
> I happened to notice that some GUC names "max_fsm_pages" and
> "max_fsm_relations" are still mentioned in these translation files
> (from the REL_16_1 source zip)
>
> src\backend\po\fr.po
> src\backend\po\tr.po
>
> ~~
>
> Should those
Hi,
I am trying to build postgres with meson on Windows. And I am stuck in
the process.
Steps I followed:
1. I clone postgres repo
2.Installed meson and ninja
pip install meson ninja
3. Then running following command:
meson setup build --buildtype debug
4. Then I ran
cd build
ninja
Got
On Thu, 9 Nov 2023 at 07:15, Ashutosh Bapat
wrote:
>
> Just to test whether that bug fix also fixes the failure seen with
> this patchset, I am attaching the patchset including the patch with
> the fix.
>
> 0001 - fix in other thread
> 0002 and 0003 are 0001 and 0002 in the previous patch set.
>
Dear Horiguchi-san, hackers,
> Thanks you for the comments!
Thanks for updating the patch!
I'm not sure it is intentional, but you might miss my post...I suggested to add
a
testcase.
I attached the updated version which is almost the same as Horiguchi-san's one,
but has a test. How do you
82 matches
Mail list logo
