to a error"?
I don't think so.
>> Also:
>> + --exit-on-abort is specified . Otherwise in the
>> worst
>>
>> There is an extra space between "specified" and ".".
>
> Fixed.
>
> Also, I fixed the place of the description in the documentation
> to alphabetical order
>
> Attached is the updated patch.
Looks good to me. If there's no objection, I will commit this next week.
Best reagards,
--
Tatsuo Ishii
SRA OSS LLC
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
ted due to some error. Without
should be:
Exit immediately when any client is aborted due to some errors. Without
(error vs. erros)
Also:
+ --exit-on-abort is specified . Otherwise in the worst
There is an extra space between "specified" and ".".
Best reagards,
--
Tatsuo Ishii
SRA OSS LLC
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
age = 4.628 ms (including failures)
initial connection time = 49.526 ms
tps = 2160.827556 (without initial connection time)
Depite the 4 failed transactions (could not serialize access due to
concurrent update) pgbench ran normally, rather than aborting the
test. Is this an expected behavior?
Best
> On Wed, Aug 16, 2023 at 06:25:09AM +0900, Tatsuo Ishii wrote:
>> Currently pqcomm.h needs c.h which is not problem for Pgpool-II. But
>> what about other middleware?
>
> Why do you need to include directly c.h? There are definitions in
> there that are not intended to b
> On Tue, Aug 15, 2023 at 02:46:24PM +0900, Tatsuo Ishii wrote:
>> Is it possible to put the new define staff into protocol.h then let
>> pqcomm.h include protocol.h? This makes Pgpool-II and other middle
>> ware/drivers written in C easier to use the defines so that
w the added macros.
> So, this is where I landed...
Is it possible to put the new define staff into protocol.h then let
pqcomm.h include protocol.h? This makes Pgpool-II and other middle
ware/drivers written in C easier to use the defines so that they only
include protocol.h to use the defines.
ket read is
> finished, the data is already in your target buffer". As opposed to
> "you can now call recv() without blocking", so you avoid another trip
> into the kernel. But that's also something we'll eventually want to
> figure out in the server.
Agre
esting. In my understanding this also needs to make Latch
frontend-friendly?
Best reagards,
--
Tatsuo Ishii
SRA OSS LLC
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
s not to have more than 26 variables. I hope 26 is
enough for most use cases.
Best reagards,
--
Tatsuo Ishii
SRA OSS LLC
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
>From 5c6430e171ab9f9a75df92fac25949cb96fe1da2 Mon Sep 17 00:00:00 2001
From: Tatsuo Ishii
Da
> On Mon, 7 Aug 2023 at 16:50, Tatsuo Ishii wrote:
>
>> > On Mon, Aug 07, 2023 at 04:02:08PM -0400, Tom Lane wrote:
>> >> Dave Cramer writes:
>> >>> On Mon, 7 Aug 2023 at 12:59, Robert Haas
>> wrote:
>> >>>> PqMsgEmptyQueryR
+1.
Also we need to decide what to do with them:
> #define PQMSG_REQ_PREPARED 'S'
> #define PQMSG_REQ_PORTAL 'P'
If we go "PqMsgEmptyQueryResponse", probably we should go something
like for these?
#define PqMsgReqPrepared 'S'
#define PqMsgReqPortal 'P'
Best reagards,
--
Tatsuo Ishii
SRA OSS LLC
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
ed.
>
> Attached is the patch to add the option --exit-on-abort.
> If this option is specified, when any client is aborted, pgbench
> immediately quit by calling exit(2).
>
> What do you think about it?
I think aborting pgbench by calling exit(2) is enough. It's not worth
> On Thu, 3 Aug 2023 at 16:59, Tatsuo Ishii wrote:
>
>> > On Thu, 3 Aug 2023 at 13:25, Tatsuo Ishii wrote:
>> >
>> >> > Greetings,
>> >> >
>> >> > Attached is a patch which introduces a file protocol.h. Instead of
>>
> On Thu, 3 Aug 2023 at 13:25, Tatsuo Ishii wrote:
>
>> > Greetings,
>> >
>> > Attached is a patch which introduces a file protocol.h. Instead of using
>> > the actual characters everywhere in the code this patch names the
>> > ch
;
> +#define DESCRIBE_PORTAL 'P'
You use these for Close message as well. I don't like the idea because
Close is different message from Describe message.
What about adding following for Close too use them instead?
#define CLOSE_PREPARED 'S'
#define CLOSE_PO
a = 'B'
> )
>
> produces this result:
>
> a | wcnt | count
> ---+--+---
> A |0 | 0
> (1 row)
>
> In this case, the pattern is B? instead of just B, which produces an
> *empty match* for the MEASURES to be applied over.
Thank you for the detailed explanation. I think I understand now.
Best reagards,
--
Tatsuo Ishii
SRA OSS LLC
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
match and empty match, but that does not apply
> here.
Can you elaborate more? I understand that "no match" and "empty match"
are different things. But I do not understand how the difference
affects the result of count.
>> I am going to add this thread to CommitFest and plan to add both of
>> you as reviewers. Thanks in advance.
>
> My pleasure. Thank you for working on this difficult feature.
Thank you for accepting being registered as a reviewer. Your comments
are really helpful.
--
Tatsuo Ishii
SRA OSS LLC
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
> I am going to add this thread to CommitFest and plan to add both of
> you as reviewers. Thanks in advance.
Done.
https://commitfest.postgresql.org/44/4460/
Best reagards,
--
Tatsuo Ishii
SRA OSS LLC
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
ause attributes appearing in DEFINE are not added to the
target list. I am looking for way to teach planner to add attributes
appearing in DEFINE.
I am going to add this thread to CommitFest and plan to add both of
you as reviewers. Thanks in advance.
--
Tatsuo Ishii
SRA OSS LLC
English: http://www.
Hi,
> diff --git a/src/test/regress/expected/rpr.out
> b/src/test/regress/expected/rpr.out
> index 6bf8818911..f3fd22de2a 100644
> --- a/src/test/regress/expected/rpr.out
> +++ b/src/test/regress/expected/rpr.out
> @@ -230,6 +230,79 @@ SELECT company, tdate, price, rpr(price) OVER w FROM
> stock
le by defining *support functions. See
windowfuncs.c.
> WinGetFuncArgInFrame should answer yes or no and the window function
> just works on that. Otherwise we will get extension (and possibly even
> core) functions that don't handle the frame properly.
Maybe I can move row_is_in_re
> On 7/22/23 03:11, Tatsuo Ishii wrote:
>>>>> Maybe
>>>>> that can help clarify the design? It feels like it'll need to
>>>>> eventually
>>>>> be a "real" function that operates on the window state, even if it
>&
V/NEXT
etc. are defined as window function.
> Or
> does it make sense to split the pattern navigation "functions" into
> their own new concept, and maybe borrow some of the window function
> infrastructure for it?
Maybe. Suppose a window function executes row pattern matc
Hi,
> Hi Ishii-san,
>
> On 7/19/23 22:15, Tatsuo Ishii wrote:
>> Currently my patch has a limitation for the sake of simple
>> implementation: a pattern like "A+" is parsed and analyzed in the raw
>> parser. This makes subsequent process much easier becaus
XT implementation part is
welcome. Currently the DEFINE expression like "price > PREV(price)" is
prepared in ExecInitWindowAgg using ExecInitExpr,tweaking var->varno
in Var node so that PREV uses OUTER_VAR, NEXT uses INNER_VAR. Then
evaluate the expression in ExecWindow
ce),
> DOWN AS price < PREV(price)
> );
> LAST(DOWN) AS lowest
should be "LAST(DOWN.price) AS lowest"?
Best reagards,
--
Tatsuo Ishii
SRA OSS LLC
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
>
> Without backtracking, I don't see how we could do it without have a
> separate tuplestore for every current possible match.
Maybe an insane idea but what about rewriting MATCH_RECOGNIZE clause
into Window clause with RPR?
> I looked at your v2 patches a little bit and the only comment that I
> currently have on the code is you spelled PERMUTE as
> PREMUTE. Everything else is hopefully explained above.
Thanks. Will fix.
Best reagards,
--
Tatsuo Ishii
SRA OSS LLC
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
pr starts from i = 1 and find that row i = 1
satisfies A, and row i = 2 satisfies B (same as above). Then rpr moves
to row i = 2, rather than 3 because AFTER MATCH SKIP TO NEXT ROW is
specified.
Best reagards,
--
Tatsuo Ishii
SRA OSS LLC
English: http://www.sraoss.co.jp/inde
because modifying main SELECT clause could be a hard
work. Another reason is, I had no idea how to implement PREV/NEXT in
other than in WINDOW clause. Other people might feel differently
though.
> In any case, I will be watching this with a close eye, and I am eager
> to help in any way I can.
Thank you! I am looking forward to comments on my patch. Also any
idea how to implement MEASURES clause is welcome.
Best reagards,
--
Tatsuo Ishii
SRA OSS LLC
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
implementation.
Comments and suggestions are welcome.
[1]
https://sqlperformance.com/2019/04/t-sql-queries/row-pattern-recognition-in-sql
[2] https://link.springer.com/article/10.1007/s13222-022-00404-3
[3] https://trino.io/docs/current/sql/pattern-recognition-in-window.html
--
Tatsuo Ishii
SRA OSS
y too.
>>
>> Regards,
>>
>> [1] https://en.wikipedia.org/wiki/Ctags#Etags_2
>
> Sorry for late reply and thanks for the patch!
>
> I have confirmed the error with make_etags on my Mac (emacs 28.1 +
> non-Exuberant ctags), and the error is fixed by your patch. Also I
> have confirmed the patch does not affect make_etags on my Linux (emacs
> 26.3 + Exuberant ctags).
>
> I will push the fix to REL_15_STABLE and master branch if there's no
> objection.
Fix pushded. Thanks!
Best reagards,
--
Tatsuo Ishii
SRA OSS LLC
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
he error is fixed by your patch. Also I
have confirmed the patch does not affect make_etags on my Linux (emacs
26.3 + Exuberant ctags).
I will push the fix to REL_15_STABLE and master branch if there's no
objection.
Best reagards,
--
Tatsuo Ishii
SRA OSS LLC
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
libc provider, which multiple people have agreed is not
>> acceptable.
Note that most of PostgreSQL users in Japan do initdb
--no-locale. Almost never use other than C locale because the users do
not rely on system collation. Most database have an extra column which
represents the
;, dateiculocale=NULL.
So in this case the only way to keep the same behavior in v16 with "initdb
--locale=C" (--no-locale) in v15 is, bulding PostgreSQL --without-icu?
Best reagards,
--
Tatsuo Ishii
SRA OSS LLC
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
QL 7 days) I modified PostgreSQL to threaded
implementation so that it runs on Windows because there's was no
Windows port of PostgreSQL at that time. I don't remember the details
but it was desperately hard for me.
Best reagards,
--
Tatsuo Ishii
SRA OSS LLC
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
> On Sat, May 6, 2023 at 4:44 PM Tatsuo Ishii wrote:
>
>> Currently Window function nth_value is coded as following:
>>
>> nth = DatumGetInt32(WinGetFuncArgCurrent(winobj, 1, &isnull));
>> if (isnull)
>> P
stick to limiting it to
> several specific functions, or making it generalized yet agreeing the rules
> to limit it (such as no agg functions, and no functions with multiple
> column arguments).
Let's see the discussion...
Best reagards,
--
Tatsuo Ishii
SRA OSS LLC
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
ereport(ERROR,
:
:
Is there any reason why argument 'nth' is not checked earlier?
IMO, it is more natural "if (nth <= 0)..." is placed right after "nth =
DatumGetInt32...".
Attached is the patch which does this.
Best reagards
o pg_proc.
>
> - allow user defined window functions to decide by themselves whether
> they can accept null treatment option.
Attached is the patch to implement this (on top of your patch).
test=# SELECT row_number() RESPECT NULLS OVER () FROM (SELECT 1) AS s;
ERROR: window
ious patch I did the check in parse/analysis but I think
it's better to be checked in each window function. This way,
- need not to add a column to pg_proc.
- allow user defined window functions to decide by themselves whether
they can accept null treatment option.
Best reagards,
--
Tatsuo Ishi
> Vik Fearing writes:
>> On 4/22/23 14:14, Tatsuo Ishii wrote:
>>> Note that RESPECT/IGNORE are not registered as reserved keywords in
>>> this patch (but registered as unreserved keywords). I am not sure if
>>> this is acceptable or not.
>
>> For
ument nor test patches are included for now.
>
> I can volunteer to work on these if you want.
Thanks! I think you can work on top of the last patch posted by Krasiyan
Andreev:
https://www.postgresql.org/message-id/CAN1PwonAnC-KkRyY%2BDtRmxQ8rjdJw%2BgcOsHruLr6EnF7zSMH%3DQ%40mail.gmai
make much sense with other window functions, but that doesn't seem
> like it's our problem.
Yes, probably we could make WinGetFuncArgXXX a little bit smarter in
this direction (not implemented in the patch at this point).
Best reagards,
--
Tatsuo Ishii
SRA OSS LLC
English: http:/
> I think it's fine to remove it. It originated from postmaster.c, where
> I copied the original implementation of libpq_prng_init from.
I agree to remove unlikely macro here.
Best reagards,
--
Tatsuo Ishii
SRA OSS LLC
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
ed(&conn->prng_state)))
> return;
>
> /* fallback seeding */
> }
+1.
Best reagards,
--
Tatsuo Ishii
SRA OSS LLC
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
Hi,
"unlikely" macro is used in libpq_prng_init() in the patch. I wonder
if the place is really 'hot' to use "unlikely" macro.
Best reagards,
--
Tatsuo Ishii
SRA OSS LLC
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
to refer to objects
other than files.
Best reagards,
--
Tatsuo Ishii
SRA OSS LLC
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
limited to at most 1000 due to implementation restrictions of the
> + COPY command.
>
>
>
Best reagards,
--
Tatsuo Ishii
SRA OSS LLC
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
>> I fixed the above issues and refactored the code.
>> Attached is the updated version of the patch. Thought?
>
> Thank you! Looks good to me.
Fix pushed. Thank you!
Best reagards,
--
Tatsuo Ishii
SRA OSS LLC
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
have the option.
>
> This code seems to assume that there is non-Exuberant ctags
> supporting -e option. But does such ctags really exist?
Good question. I vaguely recalled so、but I haven't been able to find
any evidence for it.
>
> I fixed the above issues and refactored the code.
> Attached is the updated version of the patch. Thought?
Thank you! Looks good to me.
Best reagards,
--
Tatsuo Ishii
SRA OSS LLC
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
using?
>
> $ ./src/tools/make_etags -a
> Usage: /.../make_ctags [-e][-n]
That's hard to fix without some code duplication. We decided that
make_etags is not a symlink to make_ctags, rather execs make_ctags. Of
course we could let make_etags perform the same option check, but I
doubt it&#
tely if etags is available
>> in case that we don't have Exuberant-type ctags.
>
> That makes sense.
Attached is the v2 patch.
Best reagards,
--
Tatsuo Ishii
SRA OSS LLC
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
diff --git a/src/tools/make_ctags
> Therefore,
> it seems to me that it is better to check immediately if etags is available
> in case that we don't have Exuberant-type ctags.
That makes sense.
Best reagards,
--
Tatsuo Ishii
SRA OSS LLC
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
If etags is not available, give up (new).
Best reagards,
--
Tatsuo Ishii
SRA OSS LLC
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
diff --git a/src/tools/make_ctags b/src/tools/make_ctags
index 102881667b..8fb9991db0 100755
--- a/src/tools/make_ctags
+++ b/src/tool
.6) does not have etags. Thus before
the commit make_etags on Mac failed anyway. Do we want make_etags to
restore the previous behavior? i.e. 'etags' program not found
>> If so, we should revert the changes of make_etags by the commit and
>> make make_etags work with that ctags?
I think ctags on Mac cannot produce tags file for emacs.
Best reagards,
--
Tatsuo Ishii
SRA OSS LLC
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
> On 2022/10/19 13:25, Tatsuo Ishii wrote:
>> Thanks. the v6 patch pushed to master branch.
>
> Since this commit, make_etags has started failing to generate
> tags files with the following error messages, on my MacOS.
>
> $ src/tools/make_etags
> /Applications/X
This is a test. Please ignore...
--
Tatsuo Ishii
SRA OSS LLC
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
> On Sat, Jan 14, 2023 at 7:32 AM Tatsuo Ishii wrote:
>>
>> There seem to be a small typo in backup.sgml
>> (archive_command is unnecessarily
>> repeated). Attached is a patch to fix that.
>>
>
> LGTM.
Fix pushed. Thanks.
Best reagards,
--
There seem to be a small typo in backup.sgml
(archive_command is unnecessarily
repeated). Attached is a patch to fix that.
Best reagards,
--
Tatsuo Ishii
SRA OSS LLC
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml
sers never
invoke make_etags (same thing can be said to emacs users). So why
should we bother?
Best reagards,
--
Tatsuo Ishii
SRA OSS LLC
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
lat/CAFcNs%2BrG-DASXzHcecYKvAj%2Brmxi8CpMAgbpGpEK-mjC96F%3DLg%40mail.gmail.com
It seems the consensus was to avoid to put this sort of things into
.gitignore in the PostgreSQL source tree. Rather, put into personal
.gitignore or whatever so that developers don't need to care about
other'
> Hi,
>
> On Sat, 15 Oct 2022 10:40:29 +0900 (JST)
> Tatsuo Ishii wrote:
>
>> > On Thu, 13 Oct 2022 15:35:09 +0900 (JST)
>> > Tatsuo Ishii wrote:
>> >
>> >> > OK, that sounds good then. I would make a feature request to have a
&g
> On Thu, 13 Oct 2022 15:35:09 +0900 (JST)
> Tatsuo Ishii wrote:
>
>> > OK, that sounds good then. I would make a feature request to have a
>> > switch that supresses creation of these links, then.
>>
>> Ok, I have added "-n" option to m
seems
to be the consensus.
Best reagards,
--
Tatsuo Ishii
SRA OSS LLC
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
diff --git a/src/tools/make_ctags b/src/tools/make_ctags
index 912b6fafac..086db417e3 100755
--- a/src/tools/make_ctags
+++ b/src/tools/make_ctags
@@ -1,12 +1,
ically named symlinks
> doesn't strike me as a great arrangement though. I would definitely not
> use make_ctags if this is unavoidable. I see both scripts do likewise
> currently.
Well, I often visit different tags file for different development
projects (for example Pgpool-II) and I don't want to have fixed
location of tags file in emacs setting. For this reason make_etags's
approach is acceptable for me.
Best reagards,
--
Tatsuo Ishii
SRA OSS LLC
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
r ctags.
I tried to apply the v2 patch approach to make_etags but noticed that
make_ctags and make_etags have quite a few duplicate codes, that would
bring maintenance headache. I think we could merge make_etags into
make_ctags, then add "-e" option (or whatever) to make_ctags so that
it
Hi,
Now we are ready to have debug_print_raw_parse (or something like
that)? Pgpool-II has been importing and using PostgreSQL's raw
parser for years. I think it would be great for PostgreSQL and
Pgpool-II developers to have such a feature.
Best reagards,
--
Tatsuo Ishii
SRA OSS, Inc.
Of course the internal representation of timestamp with time zone data
type is not affected by the time zone setting. But why other form of
to_timestamp is labeled as stable? If your theory is correct, then
other form of to_timestamp shouldn't be labeled immutable as well?
Best reagards,
--
rm of to_timestamp has correct
attribute value ('s': stable) for provolatile in pg_proc.
Do we want to fix this for PG16? I think it's too late for 15.
Best reagards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
> Greetings,
>
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Bruce Momjian writes:
>> > On Wed, May 11, 2022 at 08:59:26PM -0400, Bruce Momjian wrote:
>> >> On Thu, May 12, 2022 at 09:04:38AM +0900, Tatsuo Ishii wrote:
>> >>> The last line sho
> At Thu, 12 May 2022 14:44:15 +0900 (JST), Tatsuo Ishii
> wrote in
>> >> Thank you for the info, but unfortunately it hasn't worked.
>> >> I'm going to try a slightly different steps..
>> >
>> > And finally I succeeded to clone from
>> Thank you for the info, but unfortunately it hasn't worked.
>> I'm going to try a slightly different steps..
>
> And finally I succeeded to clone from git.postgresql.org and to push a
> commit.
Is it git.postgresql.org, not gitmaster.postgresql.org? Interesti
t; is absolutely not something we should advertise widely.
Agreed. Probably we should remove
ssh://g...@git.postgresql.org/postgresql.git from the page.
Best reagards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
> On Thu, May 12, 2022 at 10:34:49AM +0900, Tatsuo Ishii wrote:
>> Last year we faced a similar problem, namely, a new committer for
>> pgpool.git could not access the git repository (Permission denied
>> (publickey)). Magnus kindly advised following and it worked. Hope this
y.
> 2. *then* go back to the main website and delete the ssh key
> 3. Now add the ssh key again on the main website
> 4. Wait 10-15 minutes and then it should work
Best reagards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
ot;ssh://g...@gitmaster.postgresql.org/postgresql.git"?
Best reagards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
esql.git
works, but ssh://g...@git.postgresql.org/postgresql.git does not work
for me.
Best reagards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
for me neither. However, in my case following works:
ssh://g...@gitmaster.postgresql.org/pgtranslation/messages.git
Also Tom Lane said:
On Sun, May 1, 2022 at 4:52 PM Tom Lane wrote:
> Tatsuo Ishii writes:
> > This is ok:
> > git clone ssh://g...@gitmaster.postgresql.
lications" section in the PG 14 release note.
I think you missed this:
commit 06ba4a63b85e5aa47b325c3235c16c05a0b58b96
Use COPY FREEZE in pgbench for faster benchmark table population.
Best reagards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
quot;Additional Modules" section. I think this should be in
the "Client Applications" section because pgbench lives in bin
directory, not in contrib directory. Actually, pgbench was in the
"Client Applications" section in the PG 14 release note.
Best reagards,
-
> Tatsuo Ishii writes:
>> This is ok:
>> git clone ssh://g...@gitmaster.postgresql.org/postgresql.git
>
> That's the thing to use if you're a committer.
>
>> But this fails:
>> $ git clone ssh://g...@git.postgresql.org/postgresql.git
>
> Pe
Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
Is accessing git.postgresql.org wrong and should we access
gitmaster.postgresql.org instead?
Best reagards,
--
Tatsuo Ish
It find it a little annoying that there is no change in tests, it
> means that the format is not checked at all:-(
Yeah. Perhaps it's a little bit hard to perform this kind of tests in
the TAP test?
Best reagards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
t; been questions about the failures detailed option, or whether the
> reports should always be detailed, and the result may be some kind of
> not convincing compromise.
Attached is the patch to remove the column.
Best reagards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.srao
has been mangled for error retries,
> and will be probably be submitting a proposal to change that.
> But that's a different issue.)
Best reagards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
with other fails.
>
> Ok, I have adjusted the patch. V2 patch attached.
Patch pushed. Thanks.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
suggest to reorder the last chunk to:
>
>... retried retries failures serfail dlfail
>
> because I intend to add connection failures handling at some point,
> and it would make more sense to add the corresponding count at the end
> with other fails.
Ok, I have adjusted the patch. V2 p
dering PDF. I
did not use &zwsp; because it does not enhance HTML output.
- split explanation of the log output into multiple paragraphs to
enhance readability.
- replace the example output with full options are specified.
Best reagards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English:
g ... [ skipped ] ] ?
>
> I think it's easier to just say "if feature X is not enabled, then
> columns XYZ are always zeroes".
Ok, I will come up with a patch in this direction.
Best reagards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
s one.
interval_start num_transactions sum_latency sum_latency_2 min_latency
max_latency
[sum_lag sum_lag_2 min_lag max_lag [ skipped [
failures serialization_failures deadlock_failures retried retries ] ] ]
Best reagards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
ies is 1, the default)
sum of serialization_failures and deadlock_failures (if --max-tries is not 1)
serialization_failures and deadlock_failures:
always 0 (if --max-tries is 1, the default)
0 or more (if --max-tries is not 1)
retried and retries:
always 0 (if --max-tries is 1, the default)
0 or
if the syntax diagram were such that columns could
> only be dropped from right to left.
Or those three columns always, sum_lag sum_lag_2, min_lag max_lag, skipped,
retried retries?
Anyway now that current CF is closing, it will not be possible to
change those logging design soon. Or can we change
> Hello,
>
> On 2022-Mar-27, Tatsuo Ishii wrote:
>
>> After:
>> interval_start num_transactions sum_latency sum_latency_2 min_latency
>> max_latency
>> { failures | serialization_failures deadlock_failures } [ sum_lag
>> sum_lag_2 min_lag max_lag [ s
_2 min_lag max_lag [ skipped ] ] [ retried retries ]
>
> Why can't we use just line feeds instead of &zwsp;? Although it's not
> a command usage but the SELECT manual already uses line feeds to
> nicely break into multiple lines of command usage.
>
> Best reagards,
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> English: http://www.sraoss.co.jp/index_en.php
> Japanese:http://www.sraoss.co.jp
interval_start num_transactions sum_latency sum_latency_2 min_latency
max_latency { failures | serialization_failures deadlock_failures } [ sum_lag
sum_lag_2 min_lag max_lag [ skipped ] ] [ retried retries ]
Why can't we use just line feeds instead of &zwsp;? Although it's not
;
^
reference.sgml:296: parser error : chunk is not well balanced
^
postgres.sgml:240: parser error : Failure to process entity reference
&reference;
^
postgres.sgml:240: parser error : Entity 'reference' not defined
&reference;
,
retrying failed transactions due to srialization error is an essential
technique. Also the retry rate of transactions will deeply affect the
performance and in such use cases the newly added items will be
precisou information. I would suggest leave the log items as it is.
Patch attached.
Best
>> Oops. Thanks. New patch attached. Test has passed on my machine.
>
> This patch works for me. I think it is ok to use \N instead of \gN.
Thanks. Patch pushed.
Best reagards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
> I reproduced the failure on another machine with perl 5.8.8,
> and I can confirm that this patch fixes it.
Thank you for the test. I have pushed the patch.
Best reagards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
> Note that the \\g2 just above also needs to be changed.
Oops. Thanks. New patch attached. Test has passed on my machine.
Best reagards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
diff --git a/src/bin/pgbenc
101 - 200 of 488 matches
Mail list logo
