Re: [HACKERS] proposal: schema variables

2017-10-26 Thread Tatsuo Ishii
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

Re: [HACKERS] [PATCH] Lockable views

2017-10-16 Thread Tatsuo Ishii
e 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

Re: [HACKERS] [PATCH] Lockable views

2017-10-15 Thread Tatsuo Ishii
gt; 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 V, th

Re: [HACKERS] [PATCH] Lockable views

2017-10-11 Thread Tatsuo Ishii
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

Re: [HACKERS] [PATCH] Lockable views

2017-10-11 Thread Tatsuo Ishii
> 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 where i in (select i

Re: [HACKERS] list of credits for release notes

2017-10-03 Thread Tatsuo Ishii
> On Mon, Oct 2, 2017 at 5:09 PM, Tatsuo Ishii <is...@sraoss.co.jp> 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. >

Re: [HACKERS] Conversion error

2017-10-02 Thread Tatsuo Ishii
> Tatsuo Ishii <is...@sraoss.co.jp> 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. >

Re: [HACKERS] Conversion error

2017-10-02 Thread Tatsuo Ishii
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

[HACKERS] Conversion error

2017-10-02 Thread Tatsuo Ishii
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

Re: [HACKERS] list of credits for release notes

2017-10-02 Thread Tatsuo Ishii
a bit trickier, as his email 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

Re: [HACKERS] Statement timeout behavior in extended queries

2017-09-18 Thread Tatsuo Ishii
> 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! -- Tatsuo Ish

Re: [HACKERS] More efficient truncation of pg_stat_activity query strings

2017-09-12 Thread Tatsuo Ishii
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/index_

Re: [HACKERS] More efficient truncation of pg_stat_activity query strings

2017-09-12 Thread Tatsuo Ishii
> 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.sraoss

Re: [HACKERS] Statement timeout behavior in extended queries

2017-09-10 Thread Tatsuo Ishii
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 >> protocol, so I'

Re: [HACKERS] Statement timeout behavior in extended queries

2017-09-04 Thread Tatsuo Ishii
er 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/postgres.c

Re: [HACKERS] pgbench: faster version of tpcb-like transaction

2017-08-27 Thread Tatsuo Ishii
> 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://www.sraoss

Re: [HACKERS] pgbench: faster version of tpcb-like transaction

2017-08-27 Thread Tatsuo Ishii
e master DB 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_

Re: [HACKERS] [BUGS] Replication to Postgres 10 on Windows is broken

2017-08-16 Thread Tatsuo Ishii
> On Thu, Aug 17, 2017 at 9:15 AM, Tatsuo Ishii <is...@sraoss.co.jp> 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 doe

Re: [HACKERS] [BUGS] Replication to Postgres 10 on Windows is broken

2017-08-16 Thread Tatsuo Ishii
> 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://www.sra

Re: [HACKERS] [BUGS] Replication to Postgres 10 on Windows is broken

2017-08-16 Thread Tatsuo Ishii
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://www.sraoss.co.jp/index

Re: [HACKERS] [BUGS] Replication to Postgres 10 on Windows is broken

2017-08-16 Thread Tatsuo Ishii
primary 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

Re: [HACKERS] Confusing error message in pgbench

2017-08-02 Thread Tatsuo Ishii
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-hackers

Re: [HACKERS] Confusing error message in pgbench

2017-08-02 Thread Tatsuo Ishii
> 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

Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization

2017-08-02 Thread Tatsuo Ishii
voking 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-hackers@postgresql.org) To make chang

[HACKERS] Confusing error message in pgbench

2017-08-01 Thread Tatsuo Ishii
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. Japan

Re: [HACKERS] Incorrect comment of XLByteToSeg() and XLByteToPrevSeg()

2017-07-31 Thread Tatsuo Ishii
> 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 mailin

Re: [HACKERS] Missing comment for max_logical_replication_workers in postgresql.conf.sample

2017-07-30 Thread Tatsuo Ishii
ch 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) To ma

Re: [HACKERS] Missing comment for max_logical_replication_workers in postgresql.conf.sample

2017-07-28 Thread Tatsuo Ishii
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, Inc

Re: [HACKERS] Incorrect comment of XLByteToSeg() and XLByteToPrevSeg()

2017-07-27 Thread Tatsuo Ishii
good to me. I will commit/push into 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

[HACKERS] More optimization effort?

2017-07-20 Thread Tatsuo Ishii
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

Re: [HACKERS] Dealing with logical replication

2017-07-20 Thread Tatsuo Ishii
> On 19 July 2017 at 16:34, Tatsuo Ishii <is...@sraoss.co.jp> 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 repli

[HACKERS] Dealing with logical replication

2017-07-19 Thread Tatsuo Ishii
? Or are 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 your

Re: [HACKERS] SCRAM auth and Pgpool-II

2017-07-13 Thread Tatsuo Ishii
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 OSS, Inc. Japan

Re: [HACKERS] SCRAM auth and Pgpool-II

2017-07-13 Thread Tatsuo Ishii
rberos > 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 Japanese:http://www.sraoss

Re: [HACKERS] SCRAM auth and Pgpool-II

2017-07-13 Thread Tatsuo Ishii
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 encrypted

Re: [HACKERS] SCRAM auth and Pgpool-II

2017-07-08 Thread Tatsuo Ishii
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 regards, -- Tat

Re: [HACKERS] SCRAM auth and Pgpool-II

2017-07-07 Thread Tatsuo Ishii
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-hackers@postgresql.org) To make c

Re: [HACKERS] SCRAM auth and Pgpool-II

2017-07-07 Thread Tatsuo Ishii
t 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 the link a

Re: [HACKERS] SCRAM auth and Pgpool-II

2017-07-07 Thread Tatsuo Ishii
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 Japanese:h

Re: [HACKERS] SCRAM auth and Pgpool-II

2017-07-05 Thread Tatsuo Ishii
ng 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 OSS, Inc. Ja

[HACKERS] SCRAM auth and Pgpool-II

2017-07-05 Thread Tatsuo Ishii
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.

Re: [HACKERS] REPLICA IDENTITY FULL

2017-06-24 Thread Tatsuo Ishii
> 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

Re: [HACKERS] shift_sjis_2004 related autority files are remaining

2017-06-24 Thread Tatsuo Ishii
t.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/index_en.php Japa

Re: [HACKERS] shift_sjis_2004 related autority files are remaining

2017-06-23 Thread Tatsuo Ishii
st 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.sraoss.co.

Re: [HACKERS] shift_sjis_2004 related autority files are remaining

2017-06-22 Thread Tatsuo Ishii
hat >> 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. Maybe, but I don

Re: [HACKERS] shift_sjis_2004 related autority files are remaining

2017-06-22 Thread Tatsuo Ishii
e 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-hackers@postgr

Re: [HACKERS] shift_sjis_2004 related autority files are remaining

2017-06-22 Thread Tatsuo Ishii
> 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:

Re: [HACKERS] REPLICA IDENTITY FULL

2017-06-19 Thread Tatsuo Ishii
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, -- T

Re: [HACKERS] REPLICA IDENTITY FULL

2017-06-19 Thread Tatsuo Ishii
nsists 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.php Japanese

Re: [HACKERS] REPLICA IDENTITY FULL

2017-06-19 Thread Tatsuo Ishii
pending 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-hackers@postgresql.o

Re: [HACKERS] REPLICA IDENTITY FULL

2017-06-19 Thread Tatsuo Ishii
roblem. 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

[HACKERS] REPLICA IDENTITY FULL

2017-06-18 Thread Tatsuo Ishii
-p 11002 -c delete from t4 where i = 'b'; test delete from t4 where i = 'b'; DELETE 2 + psql -e -p 11003 -c select * from t4; test select * from t4; i | j ---+--- a | a b | b b | b (3 rows) Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php

Re: [HACKERS] improve release-note for pg_current_logfile()

2017-06-18 Thread Tatsuo Ishii
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 -- Sent via pg

Re: [HACKERS] Restrictions of logical replication

2017-06-16 Thread Tatsuo Ishii
o 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

Re: [HACKERS] Restrictions of logical replication

2017-06-16 Thread Tatsuo Ishii
> 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.

Re: [HACKERS] Restrictions of logical replication

2017-06-16 Thread Tatsuo Ishii
> 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 log

[HACKERS] Restrictions of logical replication

2017-06-16 Thread Tatsuo Ishii
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

Re: [HACKERS] WIP: Data at rest encryption

2017-06-15 Thread Tatsuo Ishii
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

Re: [HACKERS] improve release-note for pg_current_logfile()

2017-06-14 Thread Tatsuo Ishii
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) To make changes

Re: [HACKERS] type of release note of PG10

2017-06-14 Thread Tatsuo Ishii
> 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

Re: [HACKERS] Document bug regarding read only transactions

2017-06-14 Thread Tatsuo Ishii
> 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

Re: [HACKERS] Document bug regarding read only transactions

2017-06-13 Thread Tatsuo Ishii
that 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 Ishii SRA OSS,

[HACKERS] Document bug regarding read only transactions

2017-06-13 Thread Tatsuo Ishii
('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/sgml/high

Re: [HACKERS] documentation typo in ALTER TABLE example

2017-06-11 Thread Tatsuo Ishii
>> 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 pushed the

Re: [HACKERS] documentation typo in ALTER TABLE example

2017-06-11 Thread Tatsuo Ishii
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://www.

Re: [HACKERS] pgbench - allow to store select results into variables

2017-04-20 Thread Tatsuo Ishii
scanslash.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 -- Sent vi

Re: [HACKERS] pgbench - allow to store select results into variables

2017-04-17 Thread Tatsuo Ishii
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 and psqlsc

Re: [HACKERS] pgbench - allow to store select results into variables

2017-04-09 Thread Tatsuo Ishii
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() as

Re: [HACKERS] [PATCH] Warn users about duplicate configuration parameters

2017-04-07 Thread Tatsuo Ishii
l.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@postgresql.or

[HACKERS] pg_export_snapshot doc

2017-04-07 Thread Tatsuo Ishii
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 diff

Re: [HACKERS] pgbench - allow to store select results into variables

2017-04-07 Thread Tatsuo Ishii
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 to y

Re: [HACKERS] pgbench - allow to store select results into variables

2017-04-06 Thread Tatsuo Ishii
eed 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 list (pgsql-hackers@pos

Re: [HACKERS] pgbench - allow to store select results into variables

2017-04-05 Thread Tatsuo Ishii
he 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 need to be > adding more uncertainty. Ok, I will move the pat

Re: [HACKERS] pgbench - allow to store select results into variables

2017-04-05 Thread Tatsuo Ishii
ocumenting 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://www.sr

Re: [HACKERS] Statement timeout behavior in extended queries

2017-04-05 Thread Tatsuo Ishii
"" 0 > > # Execute statement which takes 2 seconds (statement timeout expected). > 'E' "S2"0 > -> timeout error occurred, T1 aborted Right. The automatically started transaction is aborted and the effect of the set statement is canceled. In summar

Re: [HACKERS] Statement timeout behavior in extended queries

2017-04-05 Thread Tatsuo Ishii
> 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 secon

Re: [HACKERS] Statement timeout behavior in extended queries

2017-04-04 Thread Tatsuo Ishii
>> 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

Re: [HACKERS] Statement timeout behavior in extended queries

2017-04-04 Thread Tatsuo Ishii
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 > protocol, so I'd appreciate if you cou

Re: [HACKERS] Statement timeout behavior in extended queries

2017-04-04 Thread Tatsuo Ishii
ut 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.co.jp -- Se

Re: [HACKERS] Statement timeout behavior in extended queries

2017-04-04 Thread Tatsuo Ishii
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://www.sraoss.co.jp -- Sent via

Re: [HACKERS] pgbench - allow to store select results into variables

2017-04-04 Thread Tatsuo Ishii
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) To m

Re: [HACKERS] Statement timeout behavior in extended queries

2017-04-04 Thread Tatsuo Ishii
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 to work on thi

Re: [HACKERS] Statement timeout behavior in extended queries

2017-04-04 Thread Tatsuo Ishii
'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://www.sraoss.co.jp/index_e

Re: [HACKERS] Statement timeout behavior in extended queries

2017-04-03 Thread Tatsuo Ishii
> 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

Re: [HACKERS] Statement timeout behavior in extended queries

2017-04-03 Thread Tatsuo Ishii
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) To

Re: [HACKERS] Statement timeout behavior in extended queries

2017-04-03 Thread Tatsuo Ishii
> 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

Re: [HACKERS] Statement timeout behavior in extended queries

2017-04-03 Thread Tatsuo Ishii
ed 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 patch attached. -- Tatsuo Ishii SRA

Re: [HACKERS] [BUGS] Bug in Physical Replication Slots (at least 9.5)?

2017-03-29 Thread Tatsuo Ishii
> On Thu, Mar 30, 2017 at 9:12 AM, Tatsuo Ishii <is...@sraoss.co.jp> 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

Re: [HACKERS] [BUGS] Bug in Physical Replication Slots (at least 9.5)?

2017-03-29 Thread Tatsuo Ishii
: patch failed: src/backend/replication/walsender.c:210 >> 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 n

Re: [HACKERS] [POC] hash partitioning

2017-03-27 Thread Tatsuo Ishii
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://www.

Re: [HACKERS] Statement timeout behavior in extended queries

2017-02-26 Thread Tatsuo Ishii
> 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-ishi

[HACKERS] Statement timeout behavior in extended queries

2017-02-21 Thread Tatsuo Ishii
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

[HACKERS] Sync message

2017-02-14 Thread Tatsuo Ishii
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 to your subscrip

Re: [HACKERS] Fix a comment in feelist.c

2017-01-23 Thread Tatsuo Ishii
Freund <and...@anarazel.de> >> 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,

Re: [HACKERS] Fix a comment in feelist.c

2017-01-22 Thread Tatsuo Ishii
de> > 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. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http:

[HACKERS] Questionable tag usage

2017-01-04 Thread Tatsuo Ishii
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 regards,

Re: [HACKERS] Questions regarding signal handler of postmaster

2016-12-26 Thread Tatsuo Ishii
t'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 your sub

Re: [HACKERS] Questions regarding signal handler of postmaster

2016-12-26 Thread Tatsuo Ishii
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.sraoss.co.jp

[HACKERS] Questions regarding signal handler of postmaster

2016-12-26 Thread Tatsuo Ishii
57 in 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.

Re: [HACKERS] Back-patch use of unnamed POSIX semaphores for Linux?

2016-12-06 Thread Tatsuo Ishii
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   2   3   4   5   6   7   8   9   10   >