> Tatsuo Ishii writes:
>> While playing with pgbench, I found multiple "-M query_mode" can be
>> set more than once. For example,
>
> I think that's true of just about every option in all of our programs.
> Why is this one instance so much worse than
is sloppy because we cannot actually choose different -M at the same
time.
Attached is a patch to detect such an error.
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/pgb
em, I prefer "reused" since it more explicitly stats the
difference between "-M extended" and "-M prepared".
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
(parse, bind, describe and execute).
This is not a fault of pgbench, rather of libpq (the sync message is
issued inside libpq). This is a serious problem because libpq can be
used by other language APIs as well, and those languages are also
affected by the slowness of libpq. Probably we should redesign (or
add) better APIs for extended queries someday.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
information to users.
I think this should be changed to:
prepared: use extended query protocol with named prepared statements.
Patch attached.
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/s
> I'm not opposed to simplifying the instructions, however.
Ok, attached is a proposal to simplify the instructions.
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/runtime.sgml b
> It will in fact be in the certificate:
Oh, ok. That makes sense. Thanks for the explanation.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
ext -days 3650 \
> -config /etc/ssl/openssl.cnf -extensions v3_ca \
> -out root.crt -keyout root.key -subj "/CN=root.yourdomain.com"
I wonder if this is normal or not.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http
minimum, I think.
So +1 to remove the unused argument.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
BTW, I think the patch should apply to master and REL_11_STABLE
> branches at least. But should this be applied to other back branches
> as well?
I have marked 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
of "terminating line", and "termination line" looks correct. The
former refers to concrete example thus uses "the", while the latter
refers to more general case thus uses "an".
BTW, I think the patch should apply to master and REL_11_STABLE
branches at
nice English (I learned "holdover"), it occurs to me
> that references to the protocol version lacks homogeneity.
>
> Should it use v, V or version?
>
> I'd suggest to keep "the vX.0 protocol" for a short version, and "the
> version X.0 protoc
> On 2018-08-25, Tatsuo Ishii wrote to the pgsql-docs mailing list ...
>> Hi Bradley,
>> Thank you for your follow up. Your patch looks good to me.
>> Can you please re-send your message in pgsql-hackers attaching to this
>> thread ...
>> CommitFest app does not a
nt to call PQendcopy after
>
> "It is now sufficient ..."?
Well, I did not intend to enhance libpq.sgml but maybe your points is
valid (I cannot judge because I am not an native English speaker).
So I am include your point to the patch and wait for feed back from
(possibly) native En
hackers. This is usually fine. However if people want to
contribute document *only* patches and send it to pgsql-docs then
tries to register it into CF, the CF app does not recognize it. I am
not sure if this is intended behavior or not.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
frontend/backend protocol
should be able to focus on protocol.sgml. Attached is a 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.jpdiff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml
> Tatsuo Ishii writes:
>> While populating pgbench_account table by using COPY FROM STDIN,
>> pgbench sends out "\." at the end of the copy data. However this is
>> only necessary in the version 2 of frontend/backend protocol (i.e. the
>> version 3 proto
or not, but I doubt it's necessary.
Comments?
(patch to remove the unneccessary code attached)
--
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 41b756c.
>>> Does this test doc building?
>>
>> Good question. Thomas?
>
> Yes. You can't see the resulting HTML or anything... but it does fail
> if you break the documentation build.
Great! Thanks for the explanation.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Jap
> apply or don't build/test cleanly in travis or appveyor.
Does this test doc building?
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
ions, but wouldn't all translations also
> need to switch from SGML to XML for back branches? That would be a lot
> of work.
Regarding Japanese translations, we only do translations for the
latest stable branch (for now 10.x). I don't know about other language
translations though.
B
>> Thanks for finding these accidental duplications, and to Ishii-san for
>> committing the fix. Oops.
>>
>> +1 for this refactoring.
>
> Thanks for confirming. I will go ahead commit/push the patch.
Done.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
En
Hi Thomas,
> On Fri, Jun 15, 2018 at 8:42 PM, Antonin Houska wrote:
>> Tatsuo Ishii wrote:
>>
>>> The changes were made by this commit to add infrastructure for sharing
>>> temporary files between backends, according to the author (Thomas
>>> Mun
homas's
opinion as well.
Thomas?
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
BufFile*file;
> charsegment_name[MAXPGPATH];
> Sizecapacity = 16;
> - File *files = palloc(sizeof(File) * capacity);
> + File *files;
> int nfiles = 0;
>
> file = (BufF
7;s changed is expected to be minimal, unlike the manual translation
works.
One concern is, who checks for the correctness of the translations. I
think committers could do the job since there are good number of
non-English native speakers in the group.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
> The core team is pleased to announce the appointment of seven
> new Postgres committers:
>
> Etsuro Fujita
> Peter Geoghegan
> Amit Kapila
> Alexander Korotkov
> Thomas Munro
> Michael Paquier
> Tomas Vondra
>
> Congratulations to all!
Conjurations!
--
Tats
gt;> format makes sense because a lot of users are used to it, so that's
>> where they're going to go look first.
>
> +1
Sounds good to me 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
ge of
11 to the users.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
There's a small typo.
> Add support for with huge(large) pages on Windows (Takayuki Tsunakawa, Thomas
> Munro)
I think a space between "huge" and "(large)" is needed.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.c
; to match the pg_stat_activity.backend_type labels Eisentraut)
Seems good to me.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
res [local] idle". Do we want to mention this?
For example "Change the ps process display labels to match the
pg_stat_activity.backend_type labels except client backend (Peter
Eisentraut)"
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
>> Can you please add Andres Freund to the author? He made extensive
>> changes to the original patch to improve it.
>
> Done.
Thanks!
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
gt;
> In the Extended Query
> Protocol, have statement_timeout apply
> to each Execute message, not to all commands
> before Sync (Tatsuo Ishii)
Can you please add Andres Freund to the author? He made extensive
changes to the original patch to improve it.
ssue Sync messages when preparing, and adding
>> timeout rearming to both is fairly expensive for the common parse /
>> bind / execute sequence.
>>
>> Author: Tatsuo Ishii, editorialized by Andres Freund
>> Reviewed-By: Takayuki Tsunakawa, Andres Freu
still
cause undesirable timeouts. But a survey of protocol implementations
shows that all drivers issue Sync messages when preparing, and adding
timeout rearming to both is fairly expensive for the common parse /
bind / execute sequence.
Author: Tatsuo Ishii, editorialized b
have the limitation because it
would have a full access to system catalogs and wal.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
> On 11.05.2018 18:01, Tatsuo Ishii wrote:
>> Plus checking username is neccessary (otherwise any user could
>> retrieve a cache for a table lookup which is not permitted by other
>> users).
>
> as the tables a cached query operated on is known anyway -- it's
&
database, protocol version,
> and character
> set/collation settings of the client session, asl all these may have
> an influence on the actual result values, too ...
Plus checking username is neccessary (otherwise any user could
retrieve a cache for a table lookup which is not permitted by oth
hat case.
I think in-core query cache could deal with the case (probably as
Michael suggested).
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
Pgpool-II's in memory query cache)
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
ry string (or its hash) as the
index of the query cache.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
> On 07/05/18 05:47, Tom Lane wrote:
>> Tatsuo Ishii writes:
>>> Does anybody think having in-memory query result cache in core is a
>>> good idea?
>> No.
>
> Agreed.
>
> You could probably write an extension for that, though. I think the
&g
> On 07.05.2018 05:32, Tatsuo Ishii wrote:
>> Does anybody think having in-memory query result cache in core is a
>> good idea? From the experience of implementing the feature in
>> Pgpool-II, I would think this is not terribly hard job. But first of
>> all I'm w
Does anybody think having in-memory query result cache in core is a
good idea? From the experience of implementing the feature in
Pgpool-II, I would think this is not terribly hard job. But first of
all I'm wondering if there's a demand for the feature.
Best regards,
--
Tatsuo Ishii
SR
7;s another major version away):
>
> 1. Make pg_rewind work over the replication protocol so it doesn't require
> db superuser
> 2. Unify, to the extent possible, the code base with pg_basebackup.
Interesting idea.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
aparently uses the port), the rewound
server won't start up.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
postgresql.conf on the target
cluster being overwritten by pg_rewind is annoying. I believe there
are some use cases where different port numbers are used among
PostgreSQL database clusters in the real world.
Comments?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
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
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
> 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
> 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
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
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
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
>> 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.
>> 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:/
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
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
> 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
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
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
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
uld we update the manual? There are bunch of
places where example queries are shown without schema qualifications.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
of unqualified operators.
>
> So this should go something like this?
>
> select pg_catalog.count(*) from pg_catalog.pg_namespace where nameeq(nspname,
> '%s');
Oops. I meant:
select pg_catalog.count(*) from pg_catalog.pg_namespace where
pg_catalog.nameeq(nspna
fied operators.
So this should go something like this?
select pg_catalog.count(*) from pg_catalog.pg_namespace where nameeq(nspname,
'%s');
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
> Tatsuo Ishii writes:
>> Would you like to do this yourself? Or shall I do this?
>
> Go ahead, I have a bunch of other stuff to do ...
Done. Once my editing is confirmed ok, I will delete the item.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.
Patrick,
>> Sure, although leaving a commit message with a pointer to the fix in git
>> would document this better.
>
> Right. We should always do that.
Would you like to do this yourself? Or shall I do this?
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http:
> Sure, although leaving a commit message with a pointer to the fix in git
> would document this better.
Right. We should always do that.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
he entry
> immediately.
I would prefer to mark it done then remove the item just for leaving
an editing history.
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, Feb 26, 2018 at 4:54 PM, Tatsuo Ishii wrote:
>>> It appears this was fixed back in 2014 with 750c5ee. I propose for it
>>> to be removed from the TODO list.
>>
>> Yes, I confirmed it by using Ubuntu + libedit. I have not tested it on
>>
> It appears this was fixed back in 2014 with 750c5ee. I propose for it
> to be removed from the TODO list.
Yes, I confirmed it by using Ubuntu + libedit. I have not tested it on
Mac OS X yet though.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_
> On Fri, Feb 23, 2018 at 09:51:02AM +0900, Tatsuo Ishii wrote:
>> I'm not working on message translations. Hotta-san is actively
>> working on the translations here:
>>
>> https://github.com/hotta/pg-nls-ja
>
> If you need help here, feel free to ping me.
> Michael Paquier wrote:
>> On Fri, Feb 23, 2018 at 09:51:02AM +0900, Tatsuo Ishii wrote:
>> > I'm not working on message translations. Hotta-san is actively
>> > working on the translations here:
>> >
>> > https://github.com/hotta/pg-nls-ja
>
y of us take
> for granted.
>
> Can more be gained with user-friendly, probably web-based, translation
> tools to make translation updating more accessible?
Do you have any recommendation for such tools?
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.s
e how the translations are maintained but I think I can help.
> Ishii-san, Thom, may I take some (or all?) of the files?
I'm not working on message translations. Hotta-san is actively
working on the translations here:
https://github.com/hotta/pg-nls-ja
Best regards,
--
T
0) and I didn't have spare time
to work on the Japanese message translations.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
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
.
"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
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
ected?
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
> 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
> 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?
>
>
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
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
tables.
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
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
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
> 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
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
> 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
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
Your patch fixes only instr(string varchar, string_to_search varchar, beg_index
integer).
However in the doc there is another instr(string varchar, string_to_search
varchar, beg_index integer, occur_index integer).
Shouldn't this be fixed as well?
Best regards,
--
Tatsuo Ishii
SRA OSS, In
>> Attached is a patch to implement a feature to get the current function
>> name by GET DIAGNOSTICS in PL/pgSQL function.
>
> Could you add it to the nexf CF, I have not seen it there? Maybe the
> deadline is tonight...
I have added this to the next CF.
Best regards,
--
aises an error when the forth argument value is less than
>> zero, but the sample code returns zero. This patch fixes this.
>
> Do we need treat this as a bug fix? If so, do we need to back patch as
> well?
I have added this to CF 2018-01.
Best regards,
--
Tatsuo Ishii
SRA
rgument value is less than
> zero, but the sample code returns zero. This patch fixes this.
Do we need treat this as a bug fix? If so, do we need to back patch 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
+ Automatically updatable views (see )
+ that do not have INSTEAD OF triggers or INSTEAD
+ rules are also lockable. When a view is locked, its base relations are
+ also locked recursively with the same lock mode.
does not mention about the point:
>> >> > 1) Leave as it is (ignore tables appearing in a subquery)
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
le() as a wrapper of this
> function.
> I also made view_query_is_lockable() that returns a other message than
> view_query_is_auto_updatable().
>
>> On Tue, 17 Oct 2017 11:59:05 +0900 (JST)
>> Tatsuo Ishii wrote:
>> > 1) Leave as it is (ignore tables appe
401 - 500 of 503 matches
Mail list logo
