>> On 2018-Dec-03, Tatsuo Ishii wrote:
>>
>>> To:
>>> ---
>>> -M querymode
>>> --protocol=querymode
>>>
>>> Protocol to use for submitting queries
> From: Tatsuo Ishii [mailto:is...@sraoss.co.jp]
>> But pg_is_in_recovery() returns true even for a promoting standby. So
>> you have to wait and retry to send pg_is_in_recovery() until it
>> finishes the promotion to find out it is now a primary. I am not sure
>> if ba
> On 2018-Dec-03, Tatsuo Ishii wrote:
>
>> To:
>> ---
>> -M querymode
>> --protocol=querymode
>>
>> Protocol to use for submitting queries to the server:
>>
>> simp
ntil it
finishes the promotion to find out it is now a primary. I am not sure
if backend out to be responsible for this process. If not, libpq would
need to handle it but I doubt it would be possible.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
>> On Sat, Jan 5, 2019 at 1:35 AM Tatsuo Ishii wrote:
>>> PostgreSQL includes an implementation of the
>>> standard btree (multi-way binary tree) index data
>>> structure.
>>>
>>> I think the term "btree" here means "multi-wa
> On Sat, Jan 5, 2019 at 1:35 AM Tatsuo Ishii wrote:
>> PostgreSQL includes an implementation of the
>> standard btree (multi-way binary tree) index data
>> structure.
>>
>> I think the term "btree" here means "multi-way balanced tree", r
hard to do it with an
eager approach if want to MV is always consistent with base tables.
On the other hand, a lazy approach allows to implement IVM
incrementally because we could always let full MV build from scratch
if operations on MV include queries we do not support.
Best regards,
--
Tatsuo Ish
tree, there could be
more than one key in a node. 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/src/sgml/btree.sgml b/doc/src/sgml/btree.sgml
index c16825e2ea..996932e35d 100644
--- a
t; ability to read any file on the server which the database can read and
>> that those reads bypass all in-database privilege checks.
>
> Thanks. I will commit this.
Done.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
he EXECUTE privilege on
> pg_read_file(), or related functions, allows them
> the
> ability to read any file on the server which the database can read and
> that those reads bypass all in-database privilege checks.
Thanks. I will commit this.
Best regards,
--
Tatsuo Is
and
that those reads bypass all in-database privilege checks.
It seems there's an extra comma between "related" and "functions". Am I correct?
Patch attached.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sra
u think some of the implementations may not be appropriate if
they behave like that discussed in this thread? If so, maybe it is
worth to add a warning to the backend.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
> Curious what client is this that is violating the protocol.
I heard it was a Java program.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
> Tatsuo>responses of a simple query do not include CloseComplete
>
> Tatsuo, where do you get the logs from?
As I said, pgproto.
https://github.com/tatsuo-ishii/pgproto
> I guess you are just confused by the PRINTED order of the messages in the
> log.
> Note: w
> Tatsuo Ishii writes:
>> While looking into an issue of Pgpool-II, I found an interesting
>> behavior of a PostgreSQL client.
>> Below is a trace from pgproto to reproduce the client's behavior.
>
>> It starts a transacton.
>
>> FE=> Parse(stmt=
h series of extended-query messages, the frontend
should issue a Sync message."
:
"In addition to these fundamental, required operations, there are
several optional operations that can be used with extended-query
protocol."
:
"The Close message closes an existing prepared statement or portal and
releases resources"
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
an enhancement, not a bug fix, I think no back patching
> is necessary.
Done.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
ug fix, I think no back patching
is necessary.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
ul to get:
>
> ERROR: "public.foo" is a partitioned table
> DETAIL: Partitioned tables are not supported as logical replication targets
>
> Thoughts?
+1.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
se extended query protocol.
prepared: use extended query protocol with prepared statements.
Because in "prepared" mode pgbench reuses the parse analysis
result for the second and subsequent query iteration, pgbench runs
faster in the prepared mode than in other modes.
--
me on this point.
> Are you planning to change other similar messages?
No, because this is the only message related to an explicit
transaction. Other messages are not related to explicit transactions,
so current messages look ok to me.
>>BTW, would you like to be added to the CF item as a reviewer?
> Yeah, I've already added myself as a review.
Thanks.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
command_supports_reload in config.sgml.
Attached is a patch to fix them in config.sgml.
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/config.sgml b/doc/src/sgml/config.sgml
index 2e5a5cd331..fc4f17
from a file, for example.
I thought we prefer "on/off" rather than "true/false" for boolean
parameter values in postgresql.conf. Should we change them to "on/off"?
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
Hi,
> Hello.
>
> At Thu, 29 Nov 2018 09:16:01 +0900 (JST), Tatsuo Ishii
> wrote in <20181129.091601.830026250066724330.t-is...@sraoss.co.jp>
>> >>> Hi, it makes sense to me. One can submit transaction again same as
>> >>> other cases you me
n is alive after connection is terminated.
>>
>> In this case you could change the comment issued by other errors mentioned
>> while you're at it.
>>
>> Regards,
>> Takeshi Ideriha
>
> I have added this to the next CF (2019-01).
Please find attached
action" seems more accurate. People might
> think
> only the command they hit is not sent but transaction is still alive though
> it's of course unnatural
> that transaction is alive after connection is terminated.
>
> In this case you could change the comment issued by ot
g of the error (transaction aborted)
cleaner and might give a better suggestion 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
idle-in-transaction timeout error closed the session. I think in this
case the error message should give a hint something like other errors
(for example ERRCODE_CRASH_SHUTDOWN or
ERRCODE_T_R_SERIALIZATION_FAILURE) to ask users to reconnect.
Attached patch does that.
Best regards,
--
Tatsuo Ishii
> Andres Freund writes:
>> On 2018-11-03 10:12:14 +0900, Tatsuo Ishii wrote:
>>> One of my colleagues actually believed that if both "-M extended" and
>>> "-M prepared" were specified, pgbench runs in mixture of those
>>> modes. So I felt a
> 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 other
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
escribe 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/doc/
> 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
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
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
quot;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 least
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 protocol&qu
> 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
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 English
his 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..54b7
>>> 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. Japan
En
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
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.
Best regards,
--
Tats
>> 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
m Thomas'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
hanged 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
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
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.co.jp/
; 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.
hat 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 by Andres Freund
>> Reviewed-By: Takayuki Tsunakawa,
e latter two could 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,
imitation 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
> n
ase, 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 other
us
ase.
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 <is...@sraoss.co.jp> 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, thoug
> 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 wo
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
SRA OSS, Inc
nother 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
ntly 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
ch 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
t; 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 to external
> 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 fixe
ling 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 Ishii
SRA OSS, Inc. Japa
ew 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 v3 as sele
andby") 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
>> 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://www.
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
but the 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 <is...@sraoss.co.jp> wrote:
>
>> >> I found the previous patch was broken and this can't handle
>> >> views that has subqueries as bellow;
>> >>
>> >> 　CREATE VIEW lock_view6
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
an 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
;
> I fixed this 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
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
nqualified 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(nspname, '%s');
Best reg
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 <is...@sraoss.co.jp> 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
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 <is...@sraoss.co.jp> 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
> 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_
301 - 400 of 427 matches
Mail list logo
