procform = (Form_pg_proc) GETSTRUCT(proctup);
> + elog(ERROR, "function %s does not allow RESPECT/IGNORE NULLS",
> + NameStr(procform->proname));
> ```
>
> “Procform” is assigned but not used.
I think procform is used in the following elog(ERROR, ...).
Best regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
hes?
>>
>
> Looks good, tried it on the nth_value test script from a bit ago - I added
> a 1 million rows test and it takes an average of 12 seconds on my i7.
I would like to push the patch by the end of this month or early in
October if there's no objection.
Comments/su
Hi,
> Hi Tatsuo san,
>
> I just rebased the commit for the GUC change.
>
> On Sep 3, 2025, at 09:57, Tatsuo Ishii wrote:
>
> That's 0.3% difference, definitely noise-level. Ok, I withdraw my
> claim and commit the patch without unlikely().
>
> I also remove
you wrote the former in
>> your patch.
>>
>
> Please use the former one that is my company email address. Because it
> doesn’t work very well with the Mail Archive, so I use my personal Gmail for
> daily community communication.
Okay. I have just pushed v7 patch. Thank yo
my
claim and commit the patch without unlikely().
Best regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
t master
anymore.
$ git apply ~/v5-0001-Add-support-for-dumping-raw-parse-tree-with-debug.patch
error: patch failed: src/backend/utils/misc/guc_tables.c:1385
error: src/backend/utils/misc/guc_tables.c: patch does not apply
Best regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.s
63085.646278 (without initial connection time)
tps = 61361.373551 (without initial connection time)
average: 62303.272793
case 1 (62871.697866) / case 2 (62303.272793) = 1.009213
It seems case 1 (unlikely() is used) is about 0.9% faster than case
2 (unlikely() is used).
Comments?
--
Tatsuo Ishi
> On 2025/8/18 17:13, Tatsuo Ishii wrote:
>> + if (unlikely(Debug_print_parse))
>>
>> This should be:
>>
>> +if (unlikely(Debug_print_raw_parse))
>
> My bad! Such a stupid mistake. Fixed. And I did a test by turning
> on/off the flag in postgr
op/postgres.c
+++ b/src/backend/tcop/postgres.c
@@ -649,6 +649,10 @@ pg_parse_query(const char *query_string)
TRACE_POSTGRESQL_QUERY_PARSE_DONE(query_string);
+ if (unlikely(Debug_print_parse))
This should be:
+ if (unlikely(Debug_print_raw_parse))
Best regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
F bot to catch the v18
patches.
Best regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
ssage to explain the patch.
>
> 0001: parse and analysis
> 0002: rewriter
> 0003: planner
> 0004: executor
> 0005: documents
> 0006: tests
Best regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
v18-0001-Modify-
nts elsewhere
(e.g. Debug_print_parse), maybe we should keep it for a separate
commit.
Best regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
> On Fri, Aug 1, 2025 at 8:55 PM Fujii Masao wrote:
>> Unless there are any objections, I plan to commit this and
>> back-patch to v15.
>
> I've pushed the patch. Thanks!
Thanks. Great!
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
> Before submitting this trivial patch, I still want to confirm with the
> community if it's intentional to not dump raw parse tree?
For your reference, here's the past discussion:
https://www.postgresql.org/message-id/flat/20080730.172949.132921436.t-ishii%40sraoss.co.jp
Best re
> On Thu, Jul 31, 2025 at 11:03 AM Tatsuo Ishii wrote:
>> > Yes. When an error occurs and an error response message returned from
>> > backend, pgbench will send one more sync message, then sends ROLLBACK
>> > if necessary. I think the code above should be ch
> Hi, Tatsuo.
> Do you understand why there is an assertion error in the immediate shutdown
> case?
No. I was not able to reproduce the case so far.
Best regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
LL. However, it seems that another
>> PGRES_PIPELINE_SYNC can appear consecutively, which violates that assumption
>> and causes the assertion to fail. Thought?
>
> Yes. When an error occurs and an error response message returned from
> backend, pgbench will send one more sync message, then sends ROLLBACK
> if necessary. I think the code above should be changed to call
> PQgetResult repeatably until it returns NULL.
Correction. That would not be a proper fix. Just removing inner
PQgetResult and the Assert is enough?
Best regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
ssumes that PGRES_PIPELINE_SYNC
> is always followed by a NULL. However, it seems that another
> PGRES_PIPELINE_SYNC can appear consecutively, which violates that assumption
> and causes the assertion to fail. Thought?
Yes. When an error occurs and an error response message returned from
back
ssage to explain the patch.
0001: parse and analysis
0002: rewriter
0003: planner
0004: executor
0005: documents
0006: tests
Best regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
v17-0001-Modify-parse-analysis-modules-to-accept-RE
nd modified window.out
Question is, how could we put this kind of test into core if it worth
the effort? The simplest idea is just adding the modified window.sql
to the end of existing window.sql and update window.out. Thoughts?
Best regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://
by the result: the ROLLBACK case failed to
complete the transaction, while the other succeeded to complete it. I
did not expect the extended query protocol (INSERT part) gives
different result depending on the subsequent simple query (ROLLBACK or
COMMIT). I have not tested other queries than ROLLBACK and COMMIT, but
I am afraid other queries give even weirder results.
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
> On Thu, 3 Jul 2025 at 04:11, Tatsuo Ishii wrote:
>> After thinking more, I reached a conclusion it would better to apply
>> attached simple patch to v18 since v18 is already in the beta phase
>> and we want to make changes to it minimal.
>
> I thought that clarify
ance is enhanced because tuple is fetched only when it's
necessary.
Note that now the first argument of row_is_in_frame has been changed
from WindowAggState to WindowObject so that row_is_in_frame can call
window_gettupleslot inside.
Best regards,
--
Tatsuo Ishii
SRA OSS K.K.
Englis
> A similar issue was discussed, and a patch was proposed in [1].
> That thread might be worth reading.
Thanks. I will take a look at it.
Best regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
protocol version (i.e. 3)
minor version (number):
The least significant 16 bits of the protocol version (i.e. 2)
major protocol version:
The major version part of the protocol version. Only used in
NegotiateProtocolVersion.
minor protocol version:
The whole protocol version including minor version (3.2
what the field actually represents.
Best regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
.
After thinking more, I reached a conclusion it would better to apply
attached simple patch to v18 since v18 is already in the beta phase
and we want to make changes to it minimal.
For master, I would like to push your patch because your patch
includes a fix plus enhancement, therefore better fits
GE" or "GROUPS"
and the frame end is "CURRENT ROW"? I am asking because in these cases
the optimization in the v14 (and v15) patches do not apply and you may
not be satisfied by the performance.
Best regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
Attached is the v15 patch to fix CFbot complains.
Other than that, nothing has been changed since v14.
Best regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
v15-0001-Add-IGNORE-NULLS-RESPECT-NULLS-option-to-Window-.patch
; (at least until we reach protocol version 3.10).
Yeah. I always translate deciaml to hexa using bc command when reading
the docs.
If there's no objection, I would like to push the patch.
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
Formats)
is for 3.2, is gone. But maybe it's okay since "54.1.4. Protocol
versions" already stats that the whole F/B protocol docs is for 3.2.
What do you think?
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
d here).
Why do you remove the info?
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
connection string. But in the BackendKeyData section
of the doc, it clearly explains v3.2 format. So I suspect this is just
a typo.
Best regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
Dear Kuroda-san,
> Dear Ishii-san,
>
> Actually Saito-san has already been registered [1]. And cfbot said OK.
>
> [1]: https://commitfest.postgresql.org/patch/5775/
Thank you for pointing it out. Also I see Peter has been already
registered as a committer. Great.
Best regards,
> The PDF file looks good to me.
I think it's better to register the patch to CommitFest.
https://commitfest.postgresql.org/
Best regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
t help much
because v14 does not optimize the case. However if it's not, the v14
patch is close to commitable form, I think. Comments are welcome.
Best regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
v14-0001-Add-IGNORE-NULLS-RESP
rsation with a Pgpool-II user. He tried to use Pgpool-II with
Amazon RDS Proxy and failed.
https://github.com/pgpool/pgpool2/issues/111
Best regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
> On Mon, 23 Jun 2025 at 03:37, Tatsuo Ishii wrote:
>> And I found "Author" column is shown as "+4207-35" which does not seem
>> to be an author name. Likewise followings columns seem to show
>> inappropriate contents.
>
> Thanks for the report. Tha
which does not seem
to be an author name. Likewise followings columns seem to show
inappropriate contents.
Best regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
#x27;s a implementation limitation which I
want to eliminate someday).
> FWIW my reading of the protocol docs is that BackendKeyData is
> optional.
If majority of developers think so, do we want to update the protocol
docs? For me the docs is not clear enough.
Best regards
>=3.2
> is chosen and not if a lower, notionally less secure version is
> chosen.
I would say the server does wrong a decision. I think even if the key
is not long, it's still useful than nothing.
Best regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
o that it can
handle directly null treatment procedures.
BTW I am still not satisfied by the performance improvement for window
functions for frames, that was only 40%. I will study the code to look
for more optimization.
Best regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
v13-0001-Add-IGNORE-NULLS-RESPECT-NULLS-option-to-Window-.patch
Description: Binary data
compatible
> way of not supporting query cancel is to send dummy BackendKeyData
> values and then just ignore cancel requests. So I don't see that
> you need to do anything towards this goal, if it is a goal and
> not merely a broken implementation.)
Agreed.
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
to frontend. I wonder if this is a protocol
violation.
[1]
https://www.postgresql.org/docs/current/protocol-flow.html#PROTOCOL-FLOW-START-UP
Best regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
ersion.
> I attach a PDF of the US letter version created with the following
> command after applying the patch.
>
> ```
> make "XSLTPROCFLAGS= --stringparam rootid functions" postgres-US.pdf
> ```
The PDF file looks good to me.
Best regards,
--
Tatsuo Ishii
es.
I wonder how your patches apply to non A4 format (letter). Can you
please share the PDF file in letter format after patching? Also I
would like to get comments from native English speakers. Are they
comfortable with the proposed changes?
Best regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
Note that I have not modified ignorenulls_getfuncarginpartition yet. I
think we could optimize it using the not null info infrastructure as
well. Will come up with it.
Best regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
v12-0001-Add-IGNORE-NULLS-RESPECT-
erver encoding. The only way to save GB18030 data into database is,
converting GB18030 to UTF-8 (which can be done automatically).
Best regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
> Yeah, that's a good point. I would also question what's the benefit
> in using GB18030 over UTF-8, though. An obvious one I can see is
> because legacy applications never get updated.
Plus users have too many GB18030 encoded files, I guess.
--
Tatsuo Ishii
SRA OSS
they
support, but PostgreSQL would not in the future, that could be a
reason to move away from PostgreSQL.
As far as I know MySQL, Oracle and SQL server support GB18030.
Best regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
ber and email
> the thread to release a new canary on-demand. It would also provide some
> data/feedback while designing and implementing a more integrated solution.
Okay, next time I face a cfbot error like I explained upthread, I will
create a "canary".
Best regards
typically know it because
> the buildfarm is also unhappy, so I'm not clear on what a null patch
> in the queue would add.
The particular CF test I am seeing failure is "Windows - Server 2019,
VS 2019 - Meson & ninja". As far as I know there's no equiv
patch test results easily.
- Test method. By letting cfbot run the test, one can easily compare
test results because the test method is identical.
[1]
https://www.postgresql.org/message-id/20250422.39.1502127917165838403.ishii%40postgresql.org
Best regards,
--
Tatsuo Ishii
SRA OSS K.K.
English
r
>> semantic correctness.
>
> Thanks for the patch, it looks correct to me so I will apply it in a bit.
Sorry I havent' noticed your email when I posted. Please go ahead.
Best regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
ru Saito
Looks good to me.
Best regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
one object if I put together some patches to add regdatabase?
I think regdatabase is a good idea.
Best regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
; parameter to see if it passes Windows Server 2019, VS 2019 - Meson &
> ninja test.
Now I see it passes the test.
https://cirrus-ci.com/build/5671612202090496
Best regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
- Neason & ninja test
had failed.
Best regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
some issues on the platform
2) CFbot has some issues on the platform
or both. Any idea?
Best regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
on.
>
> +1
The patch pushed. thanks.
Best regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
In the "Asynchronous Command Processing" section of libpq.sgml,
there's a line which misses a comma at the end. Attached patch should
fix it. I am going to push attached patch into master and
REL_17_STABLE branches if there's no objection.
Best regards,
--
Tatsuo Ishii
SRA OS
orage: Disk Maximum Storage: 65kB
>
> Thank you for testing that. I've just pushed a patch to bump it up to 2500.
>
> I suspect the buildfarm didn't catch this due to the tuplestore
> consuming enough memory in MEMORY_CONTEXT_CHECKING builds.
David,
Christoph,
nt with real data and didn't find any bugs, so It is ready for
> committer status.
One thing I worry about the patch is, now the non-nulls array
optimization was removed. Since then I have been thinking about if
there could be other way to optimize searching for non null rows.
Best r
=5721e5453ebc59360b6756fe72d7499c4a02177c;hpb=cd3c45125d2d92e86ad7530b162562a23d063c26
Same thing can be said to "blob" and "blame".
"history" seems to be Ok.
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
> Attached version removes the non-nulls array. That seems to speed
> everything up. Running the above query with 1 million rows averages 450ms,
> similar when using lead/lag.
Great. However, CFbot complains about the patch:
https://cirrus-ci.com/task/6364194477441024
Best reagards,
587.05
6000843.23
70001196.177
80001508.52
90001920.593
1 2514.069
As you can see, when the number of rows = 1k, it took 28 ms. For 10k
rows, it took 2514 ms, which is 86 times slower than the 1k case. Can
we enhance this?
Graph attached.
Best reagards,
--
Tatsuo Is
>> On Thu, Feb 20, 2025 at 10:53 PM Tatsuo Ishii wrote:
>> > I noticed some of entries are shown with the author field being empty.
>> > e.g. https://commitfest.postgresql.org/patch/5525/
>>
>> When the layout of https://commitfest.postgresql.org/52/ changed,
st:pgtest as user & password for the http auth. If you want to
> make edits you need to create a new account, read-only doesn't need an
> account.
>
> [1]: https://commitfest-test.postgresql.org/
I noticed some of entries are shown with the author field being empty.
e.g.
sts.
I applied the v7 patch and ran regression and tap test. There was no
errors. Great!
BTW, I noticed that in the code path where
ignorenulls_getfuncarginframe() is called, WinSetMarkPosition() is
never called?
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.srao
> Nathan Bossart writes:
>> On Fri, Feb 07, 2025 at 01:10:04PM -0500, Tom Lane wrote:
>>> My thought was that duplicating the logic isn't so bad, as attached.
>
>> WFM!
>
> It does fix the problem here, so I'll make it so.
Sorry for the problem and
s_getfuncarginframe and the code path in
WinGetFuncArgInFrame, which takes care of EXCLUDE like this.
case FRAMEOPTION_EXCLUDE_CURRENT_ROW:
if (abs_pos >= winstate->currentpos &&
winstate->curren
e it in the array and return 6.
>
> It will be unordered when the EXCLUDE clause is used but the code
> should handle this correctly.
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
T ROW);
(gdb) p *winobj->win_nonnulls @ winobj->nonnulls_len
$8 = {1, 0, 3, 6, 5}
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
e PARSER_RESPECT_NULLS 1
+#define NO_NULLTREATMENT 0
This looks strange to me. Why do you start the define value from 4
down to 0? Also there is no place to use RESPECT_NULLS. Do we need it?
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
ls stores currentpos in
a partition, when the partition ends, win_nonnulls needs to be
reset. Otherwise, it mistakenly represents currentpos in the previous
partition.
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
are called in the per tuple memory context,
which means win_nonnulls disappears when next tuple is supplied to the
window function. If my understanding is correct, winobj->win_nonnulls
needs to survive across processing tuples.
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
GNORE NULLS OVER (ORDER BY x) FROM
(VALUES(1,NULL),(2,2),(3,NULL)) AS v(x,y);
x | y | lead
---+---+--
1 | |2
2 | 2 |2
3 | |2
(3 rows)
I think correct result of "lead" column is 2, NULL, NULL.
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: htt
ould add an API to WinObject access functions to
export ignore_nulls value. Then let each window function check it. If
the window function should not take IGNORE/RESPECT NULLS option, throw
an error.
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
nt that to be hard-wired in some centralized
> spot.
I agree. That's the right direction.
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
> Tatsuo Ishii writes:
>>> The latest version restricts it to lag, lead, first_value, last_value,
>>> and nth_value. We can extend it in a subsequent patch if there's
>>> demand?
>
>> The restriction is required by the SQL standard. So I don't thi
ignorenulls_getfuncarginframe() does not take account EXCLUSION frame
options.
(2) New member ignore_nulls are added to some structs. Its value is 0,
1 or -1. It's better to use a DEFINE for the value of ignore_nulls,
rather than 0, 1, or -1.
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
Englis
> No objections here.
V4 patch pushed. Thanks.
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
ize);
Note, I changed "initsize > 0" to "initsize >= 1" to better match with
the comment:
> * The valid range for 'initsize' is 1 to MaxAllocSize.
If there's no objection, I am going to commit the patch.
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
Eng
x27;s worth saving whatever cycles we can.
Ok, I have created v3 patch to do more inlining as you suggested. With
the patch I confirmed that there's no call to functions except palloc
in makeStringInfo, makeStringInfoExt, initStringInfo and
initStringInfoExt in the asm codes (see attached stringin
nternal(str, STRINGINFO_DEFAULT_SIZE);
> }
>
> void
> initStringInfoExt(StringInfo str, int initsize)
> {
> initStringInfoInternal(str, initsize);
> }
>
> That's admittedly quite verbose, but it ensures that all of these functi
propose to refactor the function to
mitigate the issue. With attached patch, the large switch case is
moved to a new static function WinGetSlotInFrame().
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
v1-0001-Refactor
Hi David,
Thanks for the review.
> On Sun, 5 Jan 2025 at 21:03, Tatsuo Ishii wrote:
>> Attached is the v2 patch to reflect above.
>
> A quick review.
>
> I don't see any users of STRINGINFO_SMALL_SIZE, so I question the
> value in defining it.
>
> I think
> Hi Gurjeet,
>
> Thanks for looking into my patch.
>
>> On Fri, Jan 3, 2025 at 8:54 PM Tatsuo Ishii wrote:
>>>
>>> Attached is the patch for this.
>>
>> Hi Tatsuo,
>>
>> I believe the newline endings in your patches are causing t
Hi Gurjeet,
Thanks for looking into my patch.
> On Fri, Jan 3, 2025 at 8:54 PM Tatsuo Ishii wrote:
>>
>> Attached is the patch for this.
>
> Hi Tatsuo,
>
> I believe the newline endings in your patches are causing the patch
> application
> to fail. I experie
> If you have trouble convincing people we need this for some new
> reason, then maybe you could review the existing callers to see if
> some of the existing call sites make it any more convincing.
>
> A very quick review, I found:
>
> send_message_to_frontend() initStringInfo(&buf) 1024 is proba
, int initsize);
>>
>
>
> Seems like a good idea.
Thanks.
> Minor nit: the definition of the macro should contain parentheses, like so:
> #define makeStringInfo() ....
Indeed. Thanks for pointing it out.
Attached is the patch for this.
Best reagards,
--
Tatsuo I
nitStringInfoExtended(StringInfo str, int initsize);
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
> On Wed, Dec 25, 2024 at 12:37:04PM +0900, Tatsuo Ishii wrote:
>> Attached is a patch to implement it. In the patch I add two new APIs.
>>
>> extern StringInfo makeStringInfoWithSize(int size);
>> extern void initStringInfoWithSize(StringInfo str, int size);
>>
str, int size);
Maybe I could re-invent the wheel by copying stringinfo.c, but I think
there are some uses cases like me, and it could justify in adding more
code to stringinfo.c.
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.c
standby server ...
> """
>
> If we wrote just "collation" here I think it would be less clear,
> because what's the problem is whether the order is different, not
> whether the collation objects are different.
That makes sense. Thanks for the ex
:collation order and character classification,
overriding the setting
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
ch for v13! I've now pushed the patches.
Yeah, maybe git apply is not smart enough.
Thank you for pushing the patches!
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
nch-Ensure-previous-progress-message-is-fully-pg13-14.patch
error: patch failed: src/bin/pgbench/pgbench.c:4222
error: src/bin/pgbench/pgbench.c: patch does not apply
So I created a patch for pg13 using patch command. Attached is the
patch for pg13.
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
Eng
/Makefile | 6 +++-
> src/Makefile.global.in | 1 +
You don't need to include the patch for configure. Committer will
generate configure when it gets committed. See the discussion:
https://www.postgresql.org/message-id/20241126.102906.1020285543012274306.ishii%40postgresql.org
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
> Tatsuo Ishii writes:
>> I ran autoconf 2.69 on my Ubuntu 20.04 laptop and got the same diffs
>> plus diffs related runstatedir:
>
>> + --runstatedir=DIR modifiable per-process data [LOCALSTATEDIR/run]
>
>> If my understanding is correct, configure
1 - 100 of 629 matches
Mail list logo
