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
>> 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,
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
>> 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
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
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
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
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
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
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
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
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
> 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:
>&
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
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!
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
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
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
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
>> 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
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
+++
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
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
> "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
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
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
"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
/*
+* 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
:
>
> 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
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
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
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
> 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_
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
> 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
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
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
> 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
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
---
> 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"
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.
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
> 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
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
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
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
> 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
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
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
and attached the updated version including additional tests.
This patch gives a warning while compiling:
lockcmds.c:186:1: warning: no semicolon at end of struct or union
} LockViewRecurse_context;
^
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
we can lock a table with inheritance children.
--- 118,125
lock_tbl1
lock_view6
! mvtest_tm
! (3 rows)
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
plete, and
command complete.). Currently it's not easy to recognize which
response corresponds to which message, which makes certain
applications such as Pgpool-II hard to implement and inefficient.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
> On Wed, 28 Mar 2018 15:45:09 +0900 (JST)
> Tatsuo Ishii wrote:
>
>> >> I found the previous patch was broken and this can't handle
>> >> views that has subqueries as bellow;
>> >>
>> >> CREATE VIEW lock_view6 AS SELECT * fro
feature will greatly make admin's life
easier.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
Andres,
I have just pushed the v10 patch. Yugo will reply back to your point
but I will look into your review as well.
Thanks.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
> Hi,
>
> On 2018-03-28
>> I have just pushed the v10 patch.
>
> The buildfarm is fairly unhappy, and I think it's because of this patch.
Thanks for the info. Yes, at least prion is unhappy because of the
patch. I will look into this.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http:/
>> The buildfarm is fairly unhappy, and I think it's because of this patch.
>
> Thanks for the info. Yes, at least prion is unhappy because of the
> patch. I will look into this.
Done. See if the buildarm becomes happy.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc.
reaming_standby") would be called something like:
create_streaming_standby('standby_host', 5432, '/usr/local/pgsql/data')
and it execute create_standby.sh with the arguments.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
ce view v1 as select * from v2;
>> begin;
>> lock v1;
>> abort;
>>
>> However, I found that the previous patch could not handle the following
>> situation in which the root relation itself doesn't have infinite recursion.
>>
>> create view
l-II are struggling to adopt it.
Another thing PostgreSQL can do to make external pooler's life easier
is, enhancing frontend/backend protocol so that reply messages of
prepare etc. include portal/statement info. But apparently this needs
protocol changes.
Best regards,
--
Tatsuo Ishi
> On Fri, Apr 20, 2018 at 07:58:00AM +0900, Tatsuo Ishii wrote:
>> Yeah. Since SCRAM auth is implemented, some connection poolers
>> including Pgpool-II are struggling to adopt it.
>
> Er, well. pgpool is also taking advantage of MD5 weaknesses... While
> SCRAM fixes thi
> On 20.04.2018 01:58, Tatsuo Ishii wrote:
>>> I think there's plenty things that don't really make sense solving
>>> outside of postgres:
>>> - additional added hop / context switches due to external pooler
>> This is only applied t
around me.
> 5. It doesn't matter how you manged to implement pooling outside
> Postgres: if you want to preserve session semantic, then you need to
> spawn as much backends as sessions. And number of clients is limited
> by number of backends/sessions.
Rigt. I am happy with the limitation for now.
> The primary idea and main benefit of built-in connection pooler is to
> support session semantic with limited number of backends.
I am confused. If so, why do you want to push statement based or
transaction based built-in connection pooler?
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
sion level in-core pooler,
which would be much easier than transaction level pooler to make it
transparent.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
> On 2019-Aug-06, Tatsuo Ishii wrote:
>
>> It's not mentioned below but some bugs including seg fault when
>> --enable-casser is enabled was also fixed in this patch.
>>
>> BTW, I found a bug with min/max support in this patch and I believe
>>
E i = 1;
UPDATE 1
SELECT * FROM mv1;
i | j | k | l | m | n
---++---++---+
2 | 11 | 2 | 21 | 2 | 31
1 | 15 | 1 | 20 | 1 | 30
(2 rows)
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
> Either there
tual time=3.832..6.841 rows=365 loops=1)
Filter: (d_year = 1998)
Rows Removed by Filter: 72684
Planning Time: 0.962 ms
Execution Time: 2027.758 ms
(42 rows)
BTW, in my small TPC-DS environment (2GB), only two queries were not
fini
rom t1;
ERROR: permission denied for table t1
test=> select to_regclass('t1')::oid;
to_regclass
-
1647238
(1 row)
So why can't we do the same thing for schema? For me, that way seems
to be 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
this
> schema.
> => select to_regclass('t1')::oid; -- the table is really exists.
>> to_regclass
>> -
>>
>> (1 row)
I (and Hoshiai-san) concern about following case:
# revoke usage on schema s1 from foo;
REVOKE
:
[connect as foo]
test=>
> S2:foo: commit;
> S2:foo: select to_regclass('s1.t1')::oid;
>> ERROR: permission denied for schema s1
I'm confused. How is an explicit transaction related to the topic?
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
these program names would exceed
> the value; and that tradeoff gets worse, not better, as more years
> go by. I don't foresee it happening.
+1. As one of third party PostgreSQL tool developers, I am afraid
changing names of PostgreSQL commands would give us lots of pain: for
exa
QL since it was
born, and I love the place. Forcing to install everything into
/usr/bin is distributions' policy, not PostgreSQL core project's as
far as I know. So I wonder why people don't ask the renaming request
to packagers, rather than PostgreSQL core project itself.
Best regard
tall binaries so separate directory (which some
> distros already do anyway)
>
> So to me this seems like a fairly invasive change (potentially breaking
> quite a few scripts/tools) just to address a minor inconvenience.
+1.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
name in a
cetain Linux distribution. "libmemcached" is a more geneal and non
distribution dependent term.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
ot;pgsql" is new command name and "createdb" is a sub command name
to create a database.
This way, we would be free from the command name conflict problem and
plus, we could do:
pgsql --help
which will prints subscommand names when a user is not sure what is
the sub command
re cited, such as
> serialization conflicts, where you just got unlucky due to concurrent
> events. In the case of idle-in-transaction-timeout, the fault is
> entirely your own.
Hum. Sounds like a fair argument. Ideriha-san, what do you think?
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
Englis
>>From: Tatsuo Ishii [mailto:is...@sraoss.co.jp]
>>
>>> Personally, I don't find this hint particularly necessary. The
>>> session was terminated because nothing was happening, so the real fix
>>> on the application side is probably more involved th
It's not mentioned below but some bugs including seg fault when
--enable-casser is enabled was also fixed in this patch.
BTW, I found a bug with min/max support in this patch and I believe
Yugo is working on it. Details:
https://github.com/sraoss/pgsql-ivm/issues/20
Best regards,
--
Tatsuo
et other transaction do
> anything with the read set of T1, since it is invisible to T1(use the
> transaction start time as statement timestamp).
There are some test cases and link to the paper explaining read-only
transaction anomaly in the source tree.
src/test/isolation/specs/read-only-a
touches
> documentation, we should probably call it out as a bug fix in the next
> minor release notes, since users who have adopted the functions will
> likely want to update their versions.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
> Attached is the updated patch v5 including fixing SGML and rebase to HEAD.
You need to DROP VIEW lock_view4 and lock_view5 in the regression
test as well.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
this as "ready for committer".
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, Jan 30, 2018 at 6:48 PM, Tatsuo Ishii wrote:
>> Looks good to me. If there's no objection, especially from Thomas
>> Munro, I will mark this as "ready for committer".
>
> No objection from me.
I marked this as "Ready for Committer".
Bes
ou want to lock the view
> itself, and pg_dump wants do that if only we had syntax for it.
I agree with Yugo and Alvaro. It's better to have a separate syntax
for locking views itself.
https://www.postgresql.org/message-id/20171226143407.6wjzjn42pt54qskm@alvherre.pgsql
Best regards
e're doing this based on the rewriter output, rather than the
> optimizer output, which makes it a lot less likely that we would
> decide to change anything here.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
to allow to lock all base tables in a view
definition if the view is updatable?
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
tables.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
ews that
are not automatically updatable but that kind of views are tend to
complex and IMO there's less need the automatic view locking feature.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
In
https://www.postgresql.org/about/news/1829/
URL links to both CVE-2018-1052 and CVE-2018-1053 give me a 404 error.
I am the only one who are getting the error?
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
> Greetings Tatsuo,
>
> * Tatsuo Ishii (is...@sraoss.co.jp) wrote:
>> In
>> https://www.postgresql.org/about/news/1829/
>>
>> URL links to both CVE-2018-1052 and CVE-2018-1053 give me a 404 error.
>> I am the only one who are getting the error?
>
>
> My vote would be to backport the build changes to v10, which should be
> simple enough, and wait for 9.6 to be EOL'd before doing the rename.
Me too. However my concern is the tool chain. Maybe we should notice
packagers to prepare it?
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Ja
ected?
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
o not only standard_conforming_strings, but Datestyle and TimeZone
were sent to frontend (I only changed standard_conforming_strings in
postgresql.conf).
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
.
"User was holding shared buffer pin for too long" sounds unusual to
me. Is this a bug? PostgreSQL version is 10.1 according to the user.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
if max_standby_archive_delay or
> max_standby_streaming_delay expires, whatever is blocking recovery
> gets blasted out of the way.
I didn't know that recovery conflict could happen even with buffer
pin. I should have examined the source code first. Sorry for noise.
Best regards,
--
Tatsuo Ishii
SRA OSS, I
> Hi folks
>
> I was recently surprised to notice that log_line_prefix doesn't support a
> cluster_name placeholder. I suggest adding one. If I don't hear objections
> I'll send a patch.
I think it'd be a good thing for users.
Best regards,
--
Tatsuo Ishi
oss.co.jp), Takuma
Hoshiai (hosh...@sraoss.co.jp). Adding support for EXISTS clause has
been done by Takuma.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
IVM_v7.patch.gz
Description: Binary data
following post.
>
> On Fri, 22 Nov 2019 15:29:45 +0900 (JST)
> Tatsuo Ishii wrote:
>> Up to now, IVM supports materialized views using:
>>
>> - Inner joins
>> - Some aggregate functions (count, sum, min, max, avg)
>> - GROUP BY
>> - Self joins
>>
&
> BTW, the SGML docs in the patch is very poor at this point. I am going
> to add more descriptions to the doc.
As promised, I have created the doc (CREATE MATERIALIZED VIEW manual)
patch.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index
can be maintained using IVM. Off the top of my head, we can call this
> Incrementally Maintainable Views (= IMVs), but this might cofusable with
> IVM, so I'll think about that a little more
But if we introduce IMV, IVM would be used in much less places in the
doc and source code,
1 - 100 of 566 matches
Mail list logo
