N)
>
> SELECT varname;
>
> The SEARCH_PATH is used, when varname is located. The variables can be used
> everywhere where query parameters are allowed.
>
> I hope so this proposal is good enough and simple.
>
> Comments, notes?
Just q quick follow up. Looks like a
g in the TLE
as far as the view locking concerns.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ere
> are no subquery, deadlock can occur in the current patch.
>
> For example, lock a table T in Session1, and then lock a view V
> whose base relation is T in Session2. Session2 will wait for
> Session1 to release the lock on T. After this, when Session1 try to
> lock view
t2 as well?
Current the patch ignores t2 in the case above.
So we have options below:
- Leave as it is (ignore tables appearing in a subquery)
- Lock all tables including in a subquery
- Check subquery in the view definition. If there are some tables
involved, emit an error and abort.
The first
=# BEGIN;
> BEGIN
> test=# LOCK TABLE v1;
> ERROR: cannot lock view "v1"
> DETAIL: views that have an INSTEAD OF trigger are not lockable
> test=# END;
> ROLLBACK
I wonder if we should lock tables in a subquery as well. For example,
create view v1 as select * from t1 w
> On Mon, Oct 2, 2017 at 5:09 PM, Tatsuo Ishii wrote:
>> Michael is correct.
>>
>> Sometimes people choose family name first in the emails. However I am
>> sure "Fujii" is the family name and "Masao" is the firstname.
>
> But I don'
> Tatsuo Ishii writes:
>> I saw this while restoring 9.6 database to 10.0 database.
>> \connect: FATAL: conversion between UTF8 and MULE_INTERNAL is not supported
>> Is this expected? I saw nothing releated to this in the release notes.
>
> Don't think that
feature.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
I saw this while restoring 9.6 database to 10.0 database.
\connect: FATAL: conversion between UTF8 and MULE_INTERNAL is not supported
Is this expected? I saw nothing releated to this in the release notes.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp
name has changed over time.
Michael is correct about Kaigai too.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> On 2017-09-10 17:12:19 -0700, Andres Freund wrote:
>> On 2017-09-11 09:10:49 +0900, Tatsuo Ishii wrote:
>> > If you don't mind, can you please commit/push the patch?
>>
>> Ok, will do so.
>
> And, done. Thanks for patch and reminder!
Thanks!
--
Tatsu
the reason you said.
However, if we could have variants of mblen functions with additional
parameter: input string length, then we could remove this inconstancy.
I don't know if this is overkill or not, though.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/
> read side. I think that should work because all *server side* encodings
> store character lengths in the *first* byte of a multibyte character
What do you mean? I don't see such data in a multibyte string.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.s
Andres,
If you don't mind, can you please commit/push the patch?
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
>> What do you think? I've not really tested this with the extended
>> proto
tched
master branch. All looks 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
diff --git a/src/backend/tcop/postgres.c b/src/backend/tcop/postgres.c
index 8d3fecf..6c53b9c 100644
--- a/src/backend/tcop/p
> Don't think anybody is proposing to remove the existing way to run
> pgbench, so I'm not sure what your point is?
I know. I just wanted to point out that the proposal is not good for
cluster environment tests.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://
node and read queries to
standby nodes to distribute loads among DB nodes.
With the proposed implementation it is not possible to do that kind of
test anymore since everything is packed into a function.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.ph
> On Thu, Aug 17, 2017 at 9:15 AM, Tatsuo Ishii wrote:
>>> He meant logical replication,
>>
>> Oh I could not find he meant logical replication in the original
>> report.
>
> The second message of the thread says so, but the first does not
> mention logi
> He meant logical replication,
Oh I could not find he meant logical replication in the original
report.
> but the code in question here is the same
> for streaming replication, or whatever it's called.
Yes.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://ww
ndency
> of textual index sort ordering on non-C locale definitions. But that
> wouldn't show up in a quick smoke test of replication ... and if you
> really wanted, you could use C locale on both ends.
Of course.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://ww
mary and standbys are same platform (in my
understanding this means the same hardware architecture and OS) in
streaming replication.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailin
about whether to
> extract parameters from the SQL commands. Proposed patch attached.
Great. Patch looks 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
--
Sent via pgsql-hackers mailing list (pgsql-ha
> Not really objecting, but an even better fix might be to remove the
> restriction on the order in which the options can be specified.
+100 :-)
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
--
Sent via
this could be addressed by invoking a
> customized script instead of complicating pgbench's option set.
+1.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-ha
citly
introduces a built in script for -S. To eliminate the confusion, I
think the error message should be fixed like this:
query mode (-M) should be specified before transaction type (-S or -N) or any
transaction scripts (-f or -b)
Patch attached.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc.
> Thanks for the patch. Looks good to me. I will commit/push into all
> supported branches if there's no objection.
Done.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
--
Sent via pgsql-hackers m
Each fix were pushed in separate commit because the version
needed to back patch are differ.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
Attached patch looks good except the excessive tab stops:
+
# (change requires restart)
I will commit/push this with removing the excessive tab stops if
there's no objection.
Best regards,
--
Tatsuo Ishii
SRA OSS
all
supported branches if there's no objection.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
h=97)
Index Cond: (aid < 100)
(2 rows)
Is it worth to make our optimizer a little bit smarter to convert the
the first query into the second form?
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
--
Sent via pgsq
> On 19 July 2017 at 16:34, Tatsuo Ishii wrote:
>
>> Now that we are going to have logical replication in PostgreSQL 10, I
>> have started thinking how Pgpool-II can deal with it. For example, the
>> logical replication does not replicate DDLs. Isn't it con
they against the design philosophy of the logical replication?
Comments are welcome.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
t; Should that be reworded to eliminate "md5"? I'd consider "scram-sha-256"
> suitable over a clear channel, but I've never recommended "md5" for that.
I don't think so unless clear text password is superior than md5.
Best regards,
--
Tatsuo Ishii
SRA O
we have Kerberos
> but it's disappointing when they can't use Kerberos with either
> connection poolers or with FDWs.
I would add supporting Kerberos to the Pgpool-II todo list.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japane
hat would
> matter is the TLS finish (for tls-unique) or the hash server
> certificate between Postgres and pgpool, not between the client and
> pgpool. But that's actually the point you are raising here:
Using a clear text password would not be acceptable for users even
through an
; current SET ROLE.
>
> From a SCRAM protocol perspective, this is very simple, just an extra
> attribute. Part b) may need more discussion.
>
> I believe this could be of help to your case and other middleware.
That's ambitious. Thank you for the info!
Best
r email.
Thank your for your comment. Probably now is the time to give up
to support SCRAM in Pgpool-II.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hac
s different from what pgpool needs.
Yeah, I wish I could use libpq in Pgpool-II. Unfortunately libpq does
not provide necessary features what Pgpool-II needs.
> In short I would think that pgpool needs first to un-cheat its
> handling with MD5, which is likely here to simplify its code.
See
binding is going to figure that out and
> fail the authentication. So unless I'm misunderstanding, the solution
> you are proposing figures to have a very limited shelf life.
Check...
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japan
estion along
with the SCRAM code in PostgreSQL whether it could be possible in
Pgpool-II.
Regarding your question on md5 auth handling in Pgpool-II, please look
into:
https://pgpool.net/mediawiki/index.php/FAQ#How_does_pgpool-II_handle_md5_authentication.3F
Best regards,
--
Tatsuo Ishii
SRA OS
would be appreciated. Thanks in advance.
[1] https://pgpool.net
[2] https://tools.ietf.org/html/rfc5802#section-3
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
> Thanks for the feedback. I have committed it after removing the
> datumIsEqual() call.
Thanks for the patch! I confirmed my examples now work.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
--
Sent via
/ssl.icu-project.org/. I do not know what licenses those files
use (maybe Apache).
Regarding euc-jis-2004-std.txt and sjis-0213-2004-std.txt are from
http://x0213.org. The license are described in the files.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/in
he rest even without the restriction.
So are you saying that if n/m of authority files are not kept because
of license issue, then m-n authority files should not be kept as well?
What's the benefit for us by doing so?
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.
he future. If that
>> happens, we will lose track data how we create the map files.
>
> There are other problems then as there are 3 sites in use to fetch the data:
> - GB2312.TXT comes from greenstone.org.
> - Some from icu-project.org.
> - The rest is from unicode.org.
M
ct the
original txt files from the map files, I doubt it's worth the
trouble to create such tools however.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hack
> Hi, I happned to notice that backend/utils/mb/Unicode directory
> contains two encoding authority files, which I believe are not to
> be there.
>
> euc-jis-2004-std.txt
> sjis-0213-2004-std.txt
Why do you believe so?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http:
t's just a bug, nothing else.
If my understanding is correct, it would not be easy to fix, no?
> We might be able to refine that, but there is a general problem that
> without an index and an operator class, we are just doing our random
> best to match the values.
Best regards,
e table consists of only INT types, REPLICA IDENTITY
FULL works with UPDATE/DELETE (i.e. replicated), but if some of them
are TEXT types, then UPDATE/DELETE does not work.
See up thread for more details.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.ph
y or may not
work depending on the data types of columns, probably I will not
recommend users/my customers to use it.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hac
the problem.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
x27; where i = 'b' and j = 'b';
UPDATE 2
+ psql -e -p 11003 -c select * from t4; test
select * from t4;
i | j
---+---
a | a
b | b
b | b
(3 rows)
+ psql -e -p 11002 -c delete from t4 where i = 'b'; test
delete from t4 where i = 'b';
DELETE 2
+ psql
s current stderr
> and csvlog output file names (Gilles Darold)
>
> Looks reasonable fix to me. If there's no objection, 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
red to be supported.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> Docs stated "Publications can choose to limit the changes they produce to
> any combination of INSERT, UPDATE, and DELETE". It is clear that only those
> DMLs are supported.
What about COPY?
> However, we should mention that large objects are not
> supported.
Right.
> On 6/16/17 03:00, Tatsuo Ishii wrote:
>> Maybe I am missing something, but I could not find any description
>> that logical replication does not support large objects and TRUNCATE
>> in the doc. Do we want to add them to the doc as the restrictions of
>> the logica
Maybe I am missing something, but I could not find any description
that logical replication does not support large objects and TRUNCATE
in the doc. Do we want to add them to the doc as the restrictions of
the logical replication?
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http
this feature only with the expensive enterprise
edition. And people actually buy it. I guess the feature is pretty
important for some users.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
--
Sent via pgsql-hackers
Gilles Darold)
Looks reasonable fix to me. If there's no objection, I will commit
this.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
T
> Hi,
>
> I found a typo in the PG10 release note and attached is a patch
> to fix it.
Fix committed. Thanks!
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@po
> It used to be true. Tom changed it in commit
> 05d8a561ff85db1545f5768fe8d8dc9d99ad2ef7, back in 2010.
Thank you for the info. For a record, I will add it to the commit
message.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanes
t they can be executed in read only
transaction but not in standby servers. I'm not sure it's worth the
trouble. Moreover, that will create maintenance headache once we
decide to remove some of the restrictions, because we need to update
multiple places in the doc.
--
Tatsuo Ishi
('t1_i_seq');
ERROR: cannot execute nextval() in a read-only transaction
test=# \q
Attached is the patch against master branch.
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
>> Amit Langote, which one was your intention?
>
> I wanted to show DETACH PARTITION command's usage with a range partitioned
> table (detaching the "oldest" partition).
>
> So, we should apply Nagata-san's patch.
Thank you for the confirmation. I have p
LTER TABLE cities
Detach a partition from partitioned table:
ALTER TABLE cities
-DETACH PARTITION measurement_y2015m12;
+DETACH PARTITION cities_ab;
Amit Langote, which one was your intention?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http:/
l and psqlscanslash.l.
>
> Here is a v3 with a more precise comment.
Looks good to me. I have marked the patch status 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
--
S
you need to fix parseVariable() as well.
>
> Indeed. Here is v2.
I think you'd better to change the following comments because there's
no psqlscan.l or psqlscanslash.l in pgbench source tree.
+ * underscore. Keep this in sync with the definition of variable_char in
+ * psqlscan.l
ged, wrong patch suffix... Here it is with the right
> suffix.
Thank you for the patch. I tested a little bit and found that it does
not allow value replacement against non ascii variables in given SQL
statements . Is it intentional? If not, I think you need to fix
parseVariable
gresql.auto.conf it's even more
> common to override parameters.
-1 from me too by the same reason Andres said.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@pos
pg_export_snapshot() cannot be used during recovery (i.e. on standby
servers), but it's not documented. IMO this is a bug and should be
fixed. 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
ause the new feature relies on
existing pgbench variable infrastructure.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
ted, we don't need to be
>> adding more uncertainty.
>
> Ok, I will move the patch to the next cf.
Done.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing lis
> Having said all that, I think we're at the point in the commitfest
> where if there's any design question at all about a patch, it should
> get booted to the next cycle. We are going to have more than enough
> to do to stabilize what's already committed, we don't
documenting the limitation.
(the patch looks good to me except the issue above)
2) move it to next cf hoping that someone starts the implementation to
eliminate the limitation of none ascii variable names.
Comments?
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://w
quot; "" 0 0 0
> 'E' "" 0
>
> # Execute statement which takes 2 seconds (statement timeout expected).
> 'E' "S2"0
> -> timeout error occurred, T1 aborted
Right. The automatically started transac
> From: pgsql-hackers-ow...@postgresql.org
>> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tatsuo Ishii
>> I have done tests using pgproto. One thing I noticed a strange behavior.
>> Below is an output of pgproto. The test first set the timeout to 3 seconds,
>> What do you think? I've not really tested this with the extended protocol,
>> so I'd appreciate if you could rerun your test from the older thread.
>
> The patch looks good and cleaner. It looks like the code works as expected.
> As before, I ran one INSERT statement with PgJDBC, with gdb's
the
> timeout in the most common cases, that seems to make more sense to
> me. In your version we'd have called enable_statement_timeout() twice
> consecutively (which behaviourally is harmless).
>
> What do you think? I've not really tested this with the extended
> pro
/stop the timeout in exec_execute_message()
only. This could avoid the problem above. Also this is more consistent
with log_duration/log_min_duration_statement behavior than now.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss
s, without syncs?
What's your point of the question? What kind of problem do you expect
if the timeout starts only once at the first parse meesage out of
bunch of parse messages?
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http
the feature reveals the undocumented limitation, we
should document the limitation of \gset at least.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
t;>
>> Tatsuo-san, do you want to change those, and push? I can otherwise.
>
> Andres,
>
> If you don't mind, could you please fix the comments and push it.
I have changed the comments as you suggested. If it's ok, I can push
the patch myself (today I have time
es,
If you don't mind, could you please fix the comments and push it.
> Unfortunately I can't move the patch back to the current CF, but I guess
> we can just mark it as committed in the next.
That will be great.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http:/
> The patch doesn't seem to behave like that. The Parse message calls
> start_xact_command() -> enable_statement_timeout() -> enable_timeout(), and
> set stmt_timer_started to true. Subsequent Bind and Execute messages call
> enable_statement_timeout(), but enable_statement_timeout() doesn't c
imer
stop timer
Bind(statement1, portal1)
Execute(portal1)
start timer
stop timer
:
:
Sync
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
> That seems like it could represent quite a lot of added overhead,
> on machines where gettimeofday() is slow ... which is still a lot
> of them, unfortunately.
Maybe. I think we could eliminate restarting the timer for parse and
bind.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japa
eout() is
> used only at limited places in postgres.c, so I don't see the chance of
> misuse.
I'd suggest leave it as it is. Because it might be possible that the
function is used in different place in the future. Or at least we
should document the pre-condition as a comment.
revised p
> On Thu, Mar 30, 2017 at 9:12 AM, Tatsuo Ishii wrote:
>> Committers will not apply patches which has trailing whitespace
>> issues. So the patch submitter needs to fix them anyway.
>
> I cannot comment on that point (committers are free to pick up things
> the way they w
>> error: src/backend/replication/walsender.c: patch does not apply
>
> git apply and git am can be very picky sometimes, so you may want to
> fallback to patch -p1 if things don't work. In this case it does.
Committers will not apply patches which has trailing whitespace
issues
marked as "Returned with Feedback". I don't know why.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http:/
> On Wed, Feb 22, 2017 at 11:50:44AM +0900, Tatsuo Ishii wrote:
>> Last year I have proposed an enhancement regarding behavior of the
>> statement timeout in extended queries.
>>
>> https://www.postgresql.org/message-id/20160528.220442.1489791680347556026.t-ishii%40
ot;, which
can issue arbitrary sequence of frontend/backend message, reading from a
text file.
https://github.com/tatsuo-ishii/pgproto
(to build the program, you need C compiler and libpq)
A test data is here:
--
#
# Test case for statement tim
API
which needs to handle frontend/backend protocol in the future.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes t
es Freund
>> Date: Thu Dec 25 18:24:20 2014 +0100
>>
>> Lockless StrategyGetBuffer clock sweep hot path.
>
> Looks good to me. I will commit/push the patch if there's no
> objection.
Committed/pushed to all supported branches.
Best regards,
--
Tatsu
Thu Dec 25 18:24:20 2014 +0100
>
> Lockless StrategyGetBuffer clock sweep hot path.
Looks good to me. I will commit/push the patch if there's no
objection.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.srao
GML coding:
Specifies the configuration file for
user name mapping
(customarily called pg_ident.conf).
This parameter can only be set at server start.
Shouldn't we use a link tag instead of the xref tag here? Attached is
a patch to fix this.
Best reg
s broken.
Ok, there seems no better solution than always blocking signals.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to you
n, as well as ensuring that crash recovery can proceed if
> some child processes have become “stuck”.
Looks wild to me:-) I hope there exists better way to solve the problem...
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.srao
n die (sig=2) at protocol/child.c:925
#12
#13 _int_malloc (av=0x7f67fe546760 , bytes=4176) at malloc.c:3302
#14 0x7f67fe20a6c0 in __GI___libc_malloc (bytes=4176) at malloc.c:2891
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.
tching could bring disasters, but in that case
packagers could turn off the switch and ship updated version of
packages.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-h
1 - 100 of 1697 matches
Mail list logo
