and "\gN"
> backreferences. Is there a good reason to be using that rather
> than the traditional "\N" backref notation?
I don't see a reason to use "\gN" either. Actually after applying
attached patch, my machine is still happy with pgbench test.
Yugo?
-
code from the original patch by mistake, but
> I could not realize because the test works in my machine without any
> errors somehow.
>
> I attached a patch to fix the test as was in the original patch, where
> backreferences are used to check retry of the same query.
My machine (Ubuntu
umber of tries for transactions with
>> serialization or deadlock errors
>
> Thank you for the updated patch. I think the patches look good and now
> it's ready for commit. If there's no objection, I would like to
> commit/push the patches.
The patch Pushed. Thank you!
x27;s ready for commit. If there's no objection, I would like to
commit/push the patches.
Best reagards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
> On Sun, 20 Mar 2022 16:11:43 +0900 (JST)
> Tatsuo Ishii wrote:
>
>> > Hi Yugo,
>> >
>> > I tested with serialization error scenario by setting:
>> > default_transaction_isolation = 'repeatable read'
>> > The result was:
>&
to use the language "transaction" here
because A, B and C are different transactions. I would think it's
better to use different language instead of "transaction", something
like "cycle"? i.e.
number of cycles retried: 35 (35.000%)
Best reagards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
ot;number of
transactions retried". What does this mean?
Best reagards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
l. Do we want to use the link tag as
well?
Best reagards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
t password will be
> sniffable.
So the plaintext password is safe if used with hostssl + verify-full
(server side) and sslmode = verify-full (client side), right?
Best reagards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
d.html
"If the connection is protected by SSL encryption then password can be
used safely, though."
Best reagards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
sword shored in
pg_shadow is created as md5(password + username). But the md5 hashed
password flying over wire is using a random salt like md5(md5(password
+ username) + random_salt).
Best reagards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
ntend. In this case passwords are stored in a file and
Pgpool-II reads passwords from the file. But this is annoying for
users because they have to sync the passwords stored in PostgreSQL
with the passwords stored in the file.
So, dropping plaintext password authentication support from libpq will
make it impossible for users to use the former method.
Best reagards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
ote: each deadlock detection takes 1 second
>>
>>psql < deadlock_prep.sql
>>pgbench -t 10 -c 2 -f serializable.sql
>># very quick 50% serialization errors
>
> That works. However, it still gets hang when --max-tries = 2,
> so maybe I would no
>> So are you fine with Kawamoto-san's patch?
>
> Yes.
>
> Patch applies cleanly (hmmm, it would have been better to have it as
> an attachement). Make & make check ok. Fine with me.
Thank you for the review. Fix pushed to master branch.
Best reagards,
--
Ta
t.
So are you fine with Kawamoto-san's patch?
Best reagards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
>> I think you are right. In English there's should be no space between number
>> and "%".
>> AFAIK other parts of PostgreSQL follow the rule.
I think it's better to back-patch this to stable branches if there's
no objection. Thought?
Best reagards,
T64_FORMAT "/" INT64_FORMAT " (%.3f %%)\n",
> + printf("number of transactions above the %.1f ms latency limit:
> " INT64_FORMAT "/" INT64_FORMAT " (%.3f%%)\n",
> latency_limit / 1000.0, latency_late, ntx,
> (ntx > 0) ? 100.0 * latency_late / ntx : 0.0);
Looks good to me.
Best reagards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
ail even if no
> previous command/statement failed, right?
Right. Alvaro gave an excellent example.
Best reagards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
> Hi,
>
> On 2021-12-03 10:28:34 +0900, Tatsuo Ishii wrote:
>> It seems there are no environment variables corresponding to keepalives
>> etc. connection parameters in libpq. Is there any reason for this?
>
> PGOPTIONS='-c tcp_keepalive_*=foo' should work
It seems there are no environment variables corresponding to keepalives
etc. connection parameters in libpq. Is there any reason for this?
Best reagards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
es, which makes the review process
significantly hard. Because of this, we have to split those large
sgml files into small files, typically 4 to 5 segments for each large
sgml file.
Splitting those large sgml files in upstream woudl greatly help us
because we don't need to split the
t; Backend fetch failed
> Guru Meditation:
>
> XID: 83477623
>
> Varnish cache server
>
> Is there anything wrong with CF app?
I can access the mail archive link now. It looks like a temporary
failure.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
Varnish cache server
Is there anything wrong with CF app?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
er branch in
> early September.
I have pushed the patch to master branch.
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=06ba4a63b85e5aa47b325c3235c16c05a0b58b96
Thank you for those who gave me the valuable reviews!
Reviewed-by: Fabien COELHO, Laurenz Albe, Peter Geoghegan, Dean
? Do you think we should also change the
>> > behavior of pg13 or later? If so, should we measure disconnection delay
>> > even
>> > when -C is not specified in pg13?
>>
>> You mean "pg13 or before"?
>
> Sorry, you are right. I mean "pg13 or before".
I would think we should leave as it is for pg13 and before to not surprise
users.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
ary when -C is not specified because pgbench just
> reports "initial connection time".
Ok.
> However, what about pg13 or later? Do you think we should also change the
> behavior of pg13 or later? If so, should we measure disconnection delay even
> when -C is not specif
figure even
> at the price of a small change in an undocumented feature.
+1. The aim of -C is trying to measure connection overhead which
naturally includes disconnection overhead.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
> On Mon, 30 Aug 2021 14:22:49 +0900 (JST)
> Tatsuo Ishii wrote:
>
>> >> Anyway, I changed the status of this patch to "Waiting on Author" in CF.
>> >
>> > I returned the status to "Ready for Committer".
>> > Could you plea
>> Anyway, I changed the status of this patch to "Waiting on Author" in CF.
>
> I returned the status to "Ready for Committer".
> Could you please review this?
According to the patch tester, the patch does not apply.
--
Tatsuo Ishii
SRA OSS, Inc. Jap
74.04 s (drop tables 0.46 s, create tables 0.04 s, client-side
> generate 51.81 s, vacuum 2.11 s, primary keys 19.63 s)
>
> Nice!
>
> Regards,
> Dean
If there's no objection, I am going to commit/push to master branch in
early September.
--
Tatsuo Ishii
SRA OSS, Inc. J
ple.
> number of failed transactions: 9 (0.916%)
I don't like this and want to have the failed transactions to be 0.
Who wants a benchmark result having errors?
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
consistent, but I am
>> not
>> sure such behavioural change benefit users.
>
> The user benefit would be that if they asked for a 100s benchmark,
> pgbench does a reasonable effort not to overshot that?
Right.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
rrors, but
probably I can live with it.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
nning
benchmarking. Remember, pgbench is a tool for serious users, not for
novice users.
Or, we should terminate the last cycle of benchmark regardless it is
retrying or not if -T expires. This will make pgbench behaves much
more consistent.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
ies=0 case?
> In the sense that we don't
> terminate running transactions forcibly, this don't change the existing
> behaviour.
This statement seems to be depending on your perosnal assumption.
I still don't understand why you think that --max-tries non 0 case
will *certai
fully drop the comment, because the code is clear
> enough and the doc already says it.
I'd prefer to leave a comment. People (including me) tend to forget
things in the future, that are obvious now:-)
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.
test
before the commit was 14%. It seems the patch is still beneficial
after the commit.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
Hi Simon,
>> Hello Simon,
>>
>> Indeed.
>>
>> There is already a "ready" patch in the queue, see:
>>
>> https://commitfest.postgresql.org/33/3034/
>
> Ah, my bad. I withdraw this patch, apologies Tatsuo-san.
No problem at all.
ction finishes?
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
^~~
There is a typo in the doc (more over -> moreover).
>of all transaction tries; more over, you cannot use an unlimited number
of all transaction tries; moreover, you cannot use an unlimited number
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English:
mmands[st->command];
^~~
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
;
>
> Regards
> Takayuki Tsunakawa
Good luck, Tsunakawa-san!
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
7;s the reason why he does not see the problem
while compiling the sgml files. In his environment release-14.sgml is
encoded in UTF-8, I guess. To prevent the problem next time, it's
better to change the mime type of the attached file to
Application/Octet-Stream.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
master.diff
Description: Binary data
o what we want even with the hack "(size_t) -1" definition,
but we could easily get burnt on other tests in future.
Back-patch to all supported branches, like the previous commits.
Discussion: https://postgr.es/m/15883.1504278...@sss.pgh.pa.us
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
7.3, not 7.2? Because v3 was introduced in 7.4.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
> On Mon, May 17, 2021 at 09:33:27AM +0900, Tatsuo Ishii wrote:
>> Me too. Let's backpatch.
>
> A README is not directly user-facing, it is here for developers, so I
> would not really bother with a backpatch. Now it is not a big deal to
> do so either, so that's n
> On Mon, 17 May 2021 at 16:45, Tatsuo Ishii wrote:
>> Would you like to push the patch?
>
> Yeah, I can. I was just letting it sit for a while to see if anyone
> else had an opinion about backpatching.
Ok.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.
t; was backpatched. I'm leaning towards backpatching.
>
> Me too. Let's backpatch.
Would you like to push the patch?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
sons though maybe not is that it seems unlikely maybe people would
> not be working in master if they're developing something new. On the
> other side of the argument, 0ccebe779, which adjusts another README
> was backpatched. I'm leaning towards backpatching.
Me too. Let's
some platforms, an
>> aligned eight-byte load or store will generate two four-byte operations. If
>> you need an atomic eight-byte read or write, you must make it atomic with a
>> lock.
Yes, we'd better to fix them. Attached is a propsal for these.
Best regards,
--
Tatsuo
I think there is a typo in src/backend/storage/lmgr/README.barrier.
Attached patch should fix it.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jpdiff --git a/src/backend/storage/lmgr/README.barrier b/src/backend
gt; able to add some stats about downtime might be a good addition.
Oh I see. That makes sense.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
lover takes sometime (like a few
minutes), and it will strongly affect TPS. I think in the end it just
compares the failover time.
Or are you suggesting to ignore the time spent in failover?
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
> On Tue, Apr 13, 2021 at 5:51 PM Tatsuo Ishii wrote:
>> Currently standard pgbench scenario produces transaction serialize
>> errors "could not serialize access due to concurrent update" if
>> PostgreSQL runs in REPEATABLE READ or SERIALIZABLE level, and the
o hear your thoughts,
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
the time.
>
> The patch changes the initial state of the database with "pgbench -i",
> I think. But that's good.
Oh, ok. Thanks for the explanation!
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
efits of this patch for users that currently deliberately force
> freezing by VACUUM, just because it matters to their benchmark?
I am not sure how many people use this kind of options while running
pgbench -i but we could add yet another switch to fall back to none
FREEZE COPY if you want.
Best
> On Mon, Mar 22, 2021 at 1:11 PM Tatsuo Ishii wrote:
>> It seems only logical replication launcher exited with exit code 1
>> when it received shutdown request. Why?
>
> FWIW here's an earlier discussion of that topic:
>
> https://www.postg
es 0.01 s, client-side generate
9.68 s, vacuum 0.23 s, primary keys 3.27 s).
This time current pgbench performs much faster than I wrote (15.47 s
vs. 70.78 s). I don't why.
Anyway, this time total pgbench time is reduced by 14% over all
here. I hope people agree that the patch is worth the ga
ted with exit code 1
11802 2021-03-22 07:28:20 JST LOG: shutting down
11799 2021-03-22 07:28:20 JST LOG: database system is shut down
It seems only logical replication launcher exited with exit code 1
when it received shutdown request. Why?
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc.
> pgbench uses the FREEZE option with 14 or later
> version of PostgreSQL to speed up
> subsequent VACUUM, unless partitions are enabled.
Thanks for pointing it out. Also I think that in "with 14 or later
version", "version" should be "versions"
ould not use COPY
FREEZE. Attached v4 patch does this.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml
index 50cf22ba6b..0f6a6babc2 100644
---
> FREEZE" in the sentence.
>>>
>>> Ok. The section is needed to be modified.
>>
>> This is also addressed in the patch.
>
> V3 works for me and looks ok. I changed it to ready in the CF app.
Thank you for your review!
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
s.
>> The "g" item in the section describing initialization steps
>> (i.e. option -I). I'd suggest just to replace "COPY" with "COPY
>> FREEZE" in the sentence.
>
> Ok. The section is needed to be modified.
This is also address
"g"? I am not sure what
>> you mean.
>
> The "g" item in the section describing initialization steps
> (i.e. option -I). I'd suggest just to replace "COPY" with "COPY
> FREEZE" in the sentence.
Ok. The section is needed to be modified.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
benefit to continue after pqserverversion returns 0?
>
>> Question: should there be a word about copy using the freeze option?
>> I'd say yes, in the section describing "g".
>
> Can you elaborate about "section describing "g"? I am not sure what
&g
are likely fail
too. What's a benefit to continue after pqserverversion returns 0?
> Question: should there be a word about copy using the freeze option?
> I'd say yes, in the section describing "g".
Can you elaborate about "section describing "g"? I am not su
> "PQserverVersion() >= 14" I think. Attached is the patch doing
> what you suggest.
I have created a CommitFest entry for this.
https://commitfest.postgresql.org/33/3034/
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
he old syntax will be desupported some day.
Agreed.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
e205e4d2b045bf2
which was there only in the master branch as of Jan 17, 2021.
So I think adding "freeze" to the copy statement should only happen in
PostgreSQL 14 or later. Probably the test should be
"PQserverVersion() >= 14" I think. Attached is the patch doing
what y
s one line patch for this.
Best regards,
--
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/pgbench/pgbench.c b/src/bin/pgbench/pgbench.c
index f1d98be2d2..eea96bc53b 100644
--- a/src/bin/pgbench/pgbench.c
+++
>> On Thu, 2021-03-04 at 10:42 +0900, Tatsuo Ishii wrote:
>> > Is there any formal specification for the "a protocol common and very
>> > light weight in proxies"?
>>
>> See
>>
>> https://www.haproxy.org/download/1.8/doc/proxy-protoco
d it in your patch.
Also we need a regression test for this feature.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
> Pushed. Thanks everyone for the effort put into this patch. The first
> version was sent in 2015, so it took quite a bit of time.
Great news. Thanks everyone who have been working on this.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_
hazards for docs fixes.
Yeah, simple grep showed that there are almost 1k lines using
. I agree that the pain caused by fixing all of them is much
larger than the benefit to standardize the usage of .
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
In doc/src/sgml/func.sgml description of SHOW command use
"SQL", while SET command description the same
section does not use "". Shouldn't the description of SET use
"" for "SQL" as well? Patch attached.
Best regards,
--
Tatsuo Ishii
SRA OSS
tps = 102.990159 (including connections establishing)
>
> [In the latest version (v20 with weaker lock)]
> - latency average = 17.576 ms
> - tps = 455.159644 (including connections establishing)
>
> There is still substantial overhead, but we can see that the effect
> of
st nuke the feature altogether.
By Googling I found an instance which is using CREATE CONVERSION
(Japanese article).
http://grep.blog49.fc2.com/blog-entry-87.html
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
thout
incremental materialized view defined? If it's around 141 then we
could surely confirm that the major bottle neck is locking contention.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
crosoft for their products.
Probably we should call our "EUC-JP" something like "EUC-JP-MS" or
whatever to differentiate from true EUC-JP.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
:
>
> postgres=# select convert('\xe28892', 'utf-8', 'sjis');
> convert
> -
> \x817c
> (1 row)
>
> Please note that the byte sequence (81-7c) in SJIS represents MINUS
> SIGN in SJIS which means the MINUS SIGN in UTF8 got converted to the
> MINUS SIGN in SJIS and that is what we expect. Isn't it?
Agreed.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
/*
+* vmbuffer should be already pinned by
RelationGetBufferForTuple.
+* Though, it's fine if it is not. all_frozen is just
an optimization.
+*/
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
Engli
work
difficult. So I personally think we should commit the patch as it is,
then enhance IVM to support user defined and other aggregates in later
version of PostgreSQL.
However, if supporting user defined and other aggregates is quite
important for certain users, then we should rethink
Are you proposing to bump up the protocol version (either major or
minor)? I am asking because it seems you are going to introduce some
new message types.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
> I want
> On Thu, Sep 17, 2020 at 09:42:45AM +0900, Tatsuo Ishii wrote:
>> I am asking because these patch sets are now getting closer to
>> committable state in my opinion, and if there's someting wrong, it
>> should be fixed soon so that these patches are getting into the
ure has been long awaited by users and merging the
patches should be a benefit for them.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
From: Yugo NAGATA
Subject: Re: Implementing Incremental View Maintenance
Date: Fri, 21 Aug 2020 17:23:20 +0900
Message-ID: <20200821172320.a2506577d5244b6066f69...@sraoss.co.jp>
> On Wed, 19 Aug 2020 10:02:42 +0900 (JST)
> Tatsuo Ishii wrote:
>
>> I have looked into thi
27;t be
"Check if the given aggregate function is supporting IVM"?
+ * check_aggregate_supports_ivm
+ *
+ * Check if the given aggregate function is supporting
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
It seems I cannot access to pgsql-hackers archives.
https://www.postgresql.org/list/pgsql-hackers/2020-07/
Error 503 Backend fetch failed
Backend fetch failed
Guru Meditation:
XID: 68609318
Varnish cache server
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
is only supported
-- subquery is not supported with outer join
CREATE INCREMENTAL MATERIALIZED VIEW mv(a,b) AS SELECT a.i, b.i FROM mv_base_a
a LEFT JOIN (SELECT * FROM mv_base_b) b ON a.i=b.i;
ERROR: this query is not allowed on incrementally maintainable materialized
view
HINT:
. This indicates that the atomic
visibility are kept.
On the other hand Pgpool-II which does not implement Pangea showed
differences in those files.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
data
> inconsistency but atomic commit and atomic visibility eliminate
> different possibilities. We can eliminate all possibilities of data
> inconsistency only after we support 2PC and globally MVCC.
IMO any permanent data inconsistency is a serious problem for users no
matter what the technical reasons are.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
n1';
PREPARE TRANSACTION
S2/N2: PREPARE TRANSACTION 's2n2';
PREPARE TRANSACTION
S1/N2: COMMIT PREPARED 's1n2';
COMMIT PREPARED
S2/N1: COMMIT PREPARED 's2n1';
COMMIT PREPARED
S2/N2: COMMIT PREPARED 's2n2';
COMMIT PREPARED
S2/N1: SELECT * FROM t1;
i
---
(0 row
ACTION 's1n2';
PREPARE TRANSACTION
S2/N1: PREPARE TRANSACTION 's2n1';
PREPARE TRANSACTION
S1/N1: COMMIT PREPARED 's1n1';
COMMIT PREPARED
S1/N2: COMMIT PREPARED 's1n2';
COMMIT PREPARED
S2/N1: COMMIT PREPARED 's2n1';
COMMIT PREPARED
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
1 row)
S2/N2: SELECT * FROM t1; -- doesn't see the row
i
---
(0 rows)
S1/N2: COMMIT PREPARED 's1n2';
COMMIT PREPARED
S2/N1: COMMIT PREPARED 's2n1';
COMMIT PREPARED
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
, a middleware called "Pangea" was proposed). Also we need to
limit the transaction isolation level to REPEATABLE READ.
[1] http://www.vldb.org/pvldb/vol2/vldb09-694.pdf
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
ing data from TPC-DS data set.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
olumn "avg" specified more than once
Attached are the queries IVM are successfully applied.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
IVM_sucessfull_queries.tar.gz
Description: Binary data
ion and
rows formatting errors are ignored. Malformed rows will rise
warnings, while constraint violating rows will be returned back
to the caller unless any error is raised; i.e. if any error is
raised due to error_limit exceeds, no rows will be returned back
to
eady exists.
CONTEXT: COPY t1, line 2: "2 2"
So if the number of errors raised exceeds error_limit, no constaraint
violating rows (in this case i=1, j=1) are returned.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
201 - 300 of 488 matches
Mail list logo
