Re: [HACKERS] ERRCODE_T_R_DEADLOCK_DETECTED

of 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

[HACKERS] ERRCODE_T_R_DEADLOCK_DETECTED

be confused IMO. I am not sure sharing the same error code is the best idea here. 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 chan

Re: [HACKERS] Strange debug message of walreciver?

>> On Sun, Mar 8, 2015 at 8:13 PM, Tatsuo Ishii wrote: >>> >>> > On Sat, Mar 7, 2015 at 10:18 PM, Tatsuo Ishii >> wrote: >>> >> >>> >> When I set log_min_messages to debug5 and looked into walreciver log, >>> >> I sa

Re: [HACKERS] Strange debug message of walreciver?

> On Sun, Mar 8, 2015 at 8:13 PM, Tatsuo Ishii wrote: >> >> > On Sat, Mar 7, 2015 at 10:18 PM, Tatsuo Ishii > wrote: >> >> >> >> When I set log_min_messages to debug5 and looked into walreciver log, >> >> I saw this: >> >> >

Re: [HACKERS] Strange debug message of walreciver?

> On Sat, Mar 7, 2015 at 10:18 PM, Tatsuo Ishii wrote: >> >> When I set log_min_messages to debug5 and looked into walreciver log, >> I saw this: >> >> 3600 2015-03-08 09:47:38 JST DEBUG: sendtime 2015-03-08 > 09:47:38.31493+09 receipttime 2015-03-08 09:47:38

[HACKERS] Strange debug message of walreciver?

delay -1945478837 ms" part looks strange because the delay is below 0. The number is formatted as %d in elog call, and I suspect this is kind of integer overflow. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp --

Re: [HACKERS] Logical decoding document

;> >> I cannot parse the sentence above. Maybe logical decoding does not >> decode a table if it is an unloged table or a temporary table? > > It basically is saying that you won't see changes made to temporary > and/or unlogged tables. But the begin/commit callback

[HACKERS] Logical decoding document

t decode a table if it is an unloged table or a temporary table? 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] Typo in logicaldecoding.sgml

> Do you want to push this yourself or have me do it? If ok, could you please push 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.org) To m

[HACKERS] Typo in logicaldecoding.sgml

be used to control -logical decoding over a streaming replication connection. (It is uses +logical decoding over a streaming replication connection. (It is using these commands internally.) Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp

Re: [HACKERS] pgbench -f and vacuum

> On Tue, Feb 10, 2015 at 5:03 PM, Tatsuo Ishii wrote: >>> - The documentation misses some markups for pgbench and VACUUM and did >>> not respect the 80-character limit. >> >> I didn't realize that there's such a style guide. Although I think >> it

Re: [HACKERS] pgbench -f and vacuum

> On Mon, Feb 9, 2015 at 2:54 PM, Tatsuo Ishii wrote: >> Agreed. Here is the patch to implement the idea: -f just implies -n. > > Some small comments: > - is_no_vacuum, as well as is_init_mode, are defined as an integers > but their use imply that they are boolean swit

Re: [HACKERS] pgbench -f and vacuum

we could simply document to run a > VACUUM on them. Agreed. Here is the patch to implement the idea: -f just implies -n. 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/contrib/pgbench/pgbench.c

[HACKERS] Performance difference between kernel 3.10 and 3.12

it seems the performance difference is dominated by the kernel version difference (3.10 vs. 3.12). Does anybody know the cause? Note that kernel parameter "sched_autogroup" (which is available only with 3.10 kernel) did not give much difference. Best regards, -- Tatsuo Ishii SRA OSS

Re: [HACKERS] Fixing memory leak in pg_upgrade

> On Fri, Jan 9, 2015 at 9:23 PM, Tatsuo Ishii wrote: >> This is because gen_db_file_maps() allocates memory even if n_maps == 0. > Purely cosmetic: the initialization n_maps = 0 before the call of > gen_db_file_maps is unnecessary ;) Of course. n_maps is written by calling g

[HACKERS] Fixing memory leak in pg_upgrade

ings, n_maps, old_tablespace); pg_free(mappings); } -> leaks "mappings" } return; } This is because gen_db_file_maps() allocates memory even if n_maps == 0. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English

Re: [HACKERS] List of table names of a DB

from PostgreSQL. pgpool-II is an open source project, so you could get some idea to implement your own tool. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp > Sorry, it's not about querying. I am implementing an

Re: [HACKERS] Coverity and pgbench

ontact to one of admins (Stephen, Peter or Magnus). ...Or I could email you the pgbench report part if you wish. 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@po

Re: [HACKERS] Coverity and pgbench

> Anybody looks into problems in pgbench pointed out by Coverity? If no, > I would like to work on fixing them because I need to write patches > for "-f option" related issues anyway. Done. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss

[HACKERS] Coverity and pgbench

Hi, Anybody looks into problems in pgbench pointed out by Coverity? If no, I would like to work on fixing them because I need to write patches for "-f option" related issues anyway. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Jap

Re: [HACKERS] pgbench -f and vacuum

o care about it any more." So my questions are: 1) Which approach is better "IF EXISTS" or "-f implies -n"? 2) If latter is better, do we need to add "-k" option? Or it's not worth the trouble? -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss

Re: [HACKERS] pgbench -f and vacuum

> Hi, > > On 21.12.2014 15:58, Tatsuo Ishii wrote: >>> On Sun, Dec 14, 2014 at 11:43 AM, Tatsuo Ishii wrote: >>>>> If we care enough about that case to attempt the vacuum anyway >>>>> then we need to do something about the error message; either &g

Re: [HACKERS] pgbench -f and vacuum

rn false;/* table does not exist */ > +} > > To simplify isn't better this way? > > if (result == NULL || *result == 't') > { > PQclear(res); > return false; /* table does not exists */ > } Thanks for pointing it out. Best regards, -- Tats

Re: [HACKERS] pgbench -f and vacuum

> On Sun, Dec 14, 2014 at 11:43 AM, Tatsuo Ishii wrote: >>> If we care enough about that case to attempt the vacuum anyway then we >>> need to do something about the error message; either squelch it or >>> check for the existence of the tables before attempting to &g

Re: [HACKERS] pgbench -f and vacuum

gt; checking for the table is the right answer. Fair enough. I will come up with "checking for table before vacuum" approach. 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-hacke

Re: [HACKERS] pgbench -f and vacuum

> On 14 December 2014 at 04:39, Tom Lane wrote: >> >> Tatsuo Ishii writes: >> > Currently pgbench -f (run custom script) executes vacuum against >> > pgbench_* tables before stating bench marking if -n (or --no-vacuum) >> > is not specified. If th

[HACKERS] pgbench -f and vacuum

sed: 10/10 latency average: 0.000 ms tps = 5977.286312 (including connections establishing) tps = 15822.784810 (excluding connections establishing) 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/contrib/pgben

Re: [HACKERS] [pgsql-packagers] Palle Girgensohn's ICU patch

8 database encoding.) +1. Forcing only Unicode collation is totally unacceptable. 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] Let's drop two obsolete features which are bear-traps for novices

eliminating money as well as give other uses a big win. Of > course, how to do that and not break pg_upgrade is a huge question... Just out of curiosity, why is Oracle's NUMBER (I assume you are talking about this) so fast? Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English:

Re: [HACKERS] pg_dump/pg_restore seem broken on hamerkop

analysis was Oct 12. The commit 0eea804 > was made on Oct 14. So let's see what new coverity scan reports... The latest coverity scan report did not include paticular defects related to pg_dump/pg_restore... Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.

[HACKERS] Comment in outfunc.c

? 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] pg_dump/pg_restore seem broken on hamerkop

> the issue is only showing up on this one animal. I guess one of possibilities is there's garbage in memory which is related to restore the process. If so, coverity may be able to find something. The last coverity analysis was Oct 12. The commit 0eea804 was made on Oct 14. So let's see w

Re: [HACKERS] Optimizer on sort aggregate

sort" because cost estimations for sort step in each plan are exactly same (137519.84..140019.84). However I am not sure if we should fix the planner or should fix our sort machinery since it is possible that the sort machinery should not expose such a big difference in the two sort me

Re: [HACKERS] Collations and Replication; Next Steps

ation. In my understanding PostgreSQL's manual MUST include the ICU license term (this is not a problem). What I am not so sure is, any software uses PostgreSQL also MUST include the ICU license or not. If yes, I think this is surely a problem. Best regards, -- Tatsuo Ishii SRA OSS, Inc.

Re: [HACKERS] Collations and Replication; Next Steps

> On Wed, Sep 17, 2014 at 3:47 PM, Tatsuo Ishii wrote: >> I don't think we cannot achieve that because even MySQL accomplishes:-) > > We've always considered it an advantage that we're consistent with the > collations in the rest of the system. Generally

Re: [HACKERS] Collations and Replication; Next Steps

> On 9/17/14 10:47 AM, Tatsuo Ishii wrote: >> Why don't we have our collation data? It seems MySQL has already done this. > > Where would you get the source data from? How would you maintain it? Don't know. However seeing that that MySQL manages it, it should be possi

Re: [HACKERS] Collations and Replication; Next Steps

Why don't we have our collation data? It seems MySQL has already done this. http://dev.mysql.com/doc/refman/5.0/en/charset-collation-implementations.html I don't think we cannot achieve that because even MySQL accomplishes:-) Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan Eng

Re: [HACKERS] Dense index?

est 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] Dense index?

ndex tuples by using INTALIGN rather than MAXALIGN? I feel like this had been discussed before but I couldn't find the discussion. 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 ma

[HACKERS] Btree internal node data?

Offset: 3640 (0x0e38) Flags: NORMAL - BTree Index Section: Flags: 0x () Blocks: Previous (0) Next (289) Level (1) CycleId (0) 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] Question about coding of free space map

is 4+4=8 byte, which is same as 64 bit pointer. Still I think it's better to use pointer to the struct because someday we may want to add new member to the struct. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.

Re: [HACKERS] Enhancing pgbench parameter checking

commit the patch. I have committed the patch. Thanks! 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: h

Re: [HACKERS] Function to know last log write timestamp

> On Mon, Aug 11, 2014 at 9:23 AM, Tatsuo Ishii wrote: >> We can know the LSN of last committed WAL record on primary by using >> pg_current_xlog_location(). It seems there's no API to know the time >> when the WAL record was created. I would like to know

[HACKERS] Function to know last log write timestamp

a API, it would be useful to invent usch an API IMO. 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] Enhancing pgbench parameter checking

s your purpose. > > > Find attached a patch which adds these changes to your current > version. Thank you for the review and patch. Looks good. I changed the status to "Ready for Committer". I will wait for a fewd days and if there's no objection, I will commit the p

Re: [HACKERS] Enhancing pgbench parameter checking

;. I would > suggest "benchmarking_option_set"? Ok, I will replace the variable name as you suggested. > Also, to be consistent, maybe it should check that no initialization-specific > option are set when benchmarking. Good suggesition. Here is the v2 patch. Best regards, -- Tatsuo

[HACKERS] Enhancing pgbench parameter checking

time. Why don't we check the case? Included is the patch to enhance the behavior of pgbench in this regard IMO. Here is a sample session after patching: $ ./pgbench -c 10 -T 300 -S -i test some parameters cannot be used in initialize mode Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan En

Re: [HACKERS] subquery in CHECK constraint

t; I imagine that you have a very specific case in mind, though. Perhaps > you can share the details. No I don't have a specific case. I am just wondering because it's defined in the standard. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index

[HACKERS] subquery in CHECK constraint

Hi, Has anybody tried to implement subquery in CHECK constaint? If so, what are issues to implement it? Or the feature is not worth the effort? Comments and/or opinions are welcome. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http

[HACKERS] Interesting behavior change of psql

Vondendriesch) Previously, these functions treated zero-length string values as defaults only in some cases. It's not very clear that username is affected by this change here. I just want to remind hackers before you get inquries on this from PostgreSQL us

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

shared mem fixes the 9.3 performance problem. 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/port/sysv_shmem.c b/src/backend/port/sysv_shmem.c index f746c81..e82054a 100644 --- a/

Re: [HACKERS] lo_create(oid, bytea) breaks every extant release of libpq

s for large data which does not fit in a tuple, I am afraid that the query string could become extremely big one. 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@po

Re: [HACKERS] 9.4 release notes

t;error-free" is too strong wording because these functions are not actualy error free. test=# select to_regclass('a.b.c.d'); ERROR: improper relation name (too many dotted names): a.b.c.d STATEMENT: select to_regclass('a.b.c.d'); Best regards, -- Tatsuo Ishii SRA OSS, Inc.

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

he audience able to understand it is rather > limited now :) Yeah, once I proposed a translation of the documents by professional translators to the organization. Their decision was "no". The main reason was cost. The document is huge and the translation work could cost tremendous

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

>> Can you isolate the sysv-vs-mmap patch and see what happens with just >> that change..? > > Unfortunately I don't have an access to the machine at this moment. Where is the patch? I would like to test it on a smaller machine for now. Best regards, -- Tatsuo Ishii SRA

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

like collaborating I'd be glad to hear from them (The web site > is programmed in perl + TemplateToolkit, but even that's not > immutable. I'm open to using, say, node.js plus one of its templating > engines. gnuplot? (the graph I attached was created by gnuplt). Best reg

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

> * Tatsuo Ishii (is...@postgresql.org) wrote: >> I observe performance degradation with PostgreSQL 9.3 vs 9.2 on Linux >> as well. The hardware is HP DL980G7, 80 cores, 2TB mem, RHEL 6, >> pgbench is used (read only query), scale factor is 1,000 (DB size >> 15GB). &g

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

pgecons.org/downloads/43). I see up to 14% degration (at 128 concurrent users) comparing with 9.2. 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

Re: [HACKERS] Proposal: variant of regclass

patch for that. Looks good to me except duplicate oids. Included is a patch to fix that. 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/func.sgml b/doc/src/sgml/func.sgml index 0809a6d..db8

Re: [HACKERS] psql blows up on BOM character sequence

> (And I seem to recall somebody even proposing that finding a BOM > be cause to switch the client_encoding to UTF8.) This is a bad idea. ISO 8859-1 uses 0xfe and 0xff (BOM) for some characters. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/inde

Re: [HACKERS] psql blows up on BOM character sequence

he > “Byte Order Mark” subsection in Section 16.8, Specials, for more information. Right. I think unconditionally adding BOM to a file is evil. 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-ha

Re: [HACKERS] Standby server won't start

oldata showed the old max_connections at #7. So I guess XLOG_PARAMETER_CHANGE has not been sent for some reason. Will look into 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 m

Re: [HACKERS] Standby server won't start

fore So the particular WAL record was not sent to standby? I'm going to test again... 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 mak

Re: [HACKERS] Standby server won't start

dby were 4. Maybe we could enhance it something like this: 1) When standby starts, it get max_connections info from primary and updates pg_control file if it's different. 2) Then standby restarts itself if max_connections has been changed in #1. Best regards, -- Tatsuo Ishii SRA OS

[HACKERS] Standby server won't start

st 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] logical decoding doc

r example: postgres=# -- Again you can also peek ahead in the change stream without consuming changes 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] Inconsistency between pg_stat_activity and log_duration

or putting it into the normal control flow. Pgpool-II issues "flush" of course. 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] Inconsistency between pg_stat_activity and log_duration

alance. After such internal queries are sent to master, which will remain "active" for long time because "sync" is not issued. I got many inquries from pgpool-II users "Hey, when I looked at pg_stat_activity, I noticed querys is running for so long time. why?". Best re

Re: [HACKERS] Inconsistency between pg_stat_activity and log_duration

quot;active" state in pg_stat_actviity view. So why cann't we call pgstat_report_activity(STATE_IDLE) here. Somebody might claim that "idle" is a transaction state term. In the case, I propose to add new state name, say "finished". So above proposal would cal

[HACKERS] Inconsistency between pg_stat_activity and log_duration

ed. The reason why pg_stat_activity thinks that the query in question is, "sync" message has not been sent to the backend yet (at least from what I read from postgres.c). I think this inconsistency is not very intutive to users... Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan

Re: [HACKERS] Proposal: variant of regclass

27;::regclass could return 0, >> but not NULL. On the other hand, toregclass('pg_klass') *could* >> return NULL, which seems conceptually cleaner. Not sure. There's already at least one counter example: pg_my_temp_schema() oid OID of session's temporary schem

Re: [HACKERS] Proposal: variant of regclass

WHEN p.prorettype = 'pg_catalog.trigger'::pg_catalog.regtype THEN 'trigger' ELSE 'normal' END as "Type" FROM pg_catalog.pg_proc p LEFT JOIN pg_catalog.pg_namespace n ON n.oid = p.pronamespace WHERE p.proname ~ '^(sum)$' AND pg_catalog.pg

Re: [HACKERS] Portal suddenly disappears?

> I don't have it at this moment. I requested the user to give the > log_min_messages setting. It turned out that it is set to default: notice. 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] Portal suddenly disappears?

setting. >> According to the user, PostgreSQL version is 8.1.23. Could it be a >> source of problem? > > However, it's pretty hard to get excited about debugging something > that happened in a release branch that's been out of support for > more than three years.

[HACKERS] Portal suddenly disappears?

ment) then subsequent exec_bind_message failed to find the portal. Could it ever happen? According to the user, PostgreSQL version is 8.1.23. Could it be a source of problem? Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.srao

Re: [HACKERS] Proposal: variant of regclass

blem is, in order to add to commit fest, patch's URL is needed in the first place. And the URL is not defined until a posting is made. 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-hacker

Re: [HACKERS] Proposal: variant of regclass

> On 12/31/2013 02:38 AM, Tatsuo Ishii wrote: >> Before proceeding the work, I would like to make sure that followings >> are complete list of new functions. Inside parentheses are >> corresponding original functions. >> >> toregproc (regproc) >> tore

Re: [HACKERS] Proposal: variant of regclass

regoperator, regconfig, pg_ts_config and regdictionary. However I don't see much use case/users for new functions corresponding to them. Opinions? 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] ALTER SYSTEM SET command to change postgresql.conf parameters

> I found that the psql tab-completion for ALTER SYSTEM SET has not been > implemented yet. > Attached patch does that. Barring any objections, I will commit this patch. Good catch! Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japan

Re: [HACKERS] ALTER SYSTEM SET command to change postgresql.conf parameters

LTER >> SYSTEM command. \n"); > > You are right, I have changed code as per your suggestion. Confirmed. >> 3) initdb.c >> >> It seems the memory allocated for autoconflines[0] and >> autoconflines[1] by pg_strdup is never freed. > > I think, it get

Re: [HACKERS] Proposal: variant of regclass

patch. I'm going to post a concrete patch and register it to 2014-01 Commit Fest. 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/utils/adt/regproc.c b/src/backend/utils/adt/regproc.c in

Re: [HACKERS] ALTER SYSTEM SET command to change postgresql.conf parameters

simply change to this: + autoconflines[0] = pg_strdup("# Do not edit this file manually! \n"); + autoconflines[1] = pg_strdup("# It will be overwritten by the ALTER SYSTEM command. \n"); 3) initdb.c It seems the memory allocated for autoconflines[0] and autocon

Re: [HACKERS] Proposal: variant of regclass

to > prevent weird syntax problems from throwing errors. For the pgpool-II use case, I'm happy to follow you because pgpool-II always does a grammatical check (using raw parser) on a query first and such syntax problem will be pointed out, thus never reaches to the state where call

Re: [HACKERS] Proposal: variant of regclass

> Tatsuo Ishii writes: >> Can I make sure that we want to keep the current behavior: > >> test=# SELECT 'pg_klass'::regclass; >> ERROR: relation "pg_klass" does not exist > > Yeah, I think the consensus is to not change the behavior of the in

Re: [HACKERS] encoding name "SHIFT_JIS" is absent in chklocale.c

gt; This is because the encoding map (encoding_match_list) in chklocale.c > is lacking the definition for SHIFT_JIS. Included is a proposed > patch. If there's no objection, I will commit it. Done. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp

[HACKERS] encoding name "SHIFT_JIS" is absent in chklocale.c

in chklocale.c is lacking the definition for SHIFT_JIS. Included is a proposed patch. If there's no objection, I will commit it. 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/port/chklocale

Re: [HACKERS] pgbench with large scale factor

;. > > Assuming you are talking about "remaining sec" part, I agree. Here is > the revised patch. 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

Re: [HACKERS] pgbench with large scale factor

about "remaining sec" part, I agree. Here is the revised patch. 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/contrib/pgbench/pgbench.c b/contrib/pgbench/pgbench.c index 2c96fae..00374d8 1006

Re: [HACKERS] pgbench with large scale factor

. If there's no objection, I will commit it. 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/contrib/pgbench/pgbench.c b/contrib/pgbench/pgbench.c index 2c96fae..28ab52f 100644 --- a/contrib/pgbench/pgb

Re: [HACKERS] pgbench with large scale factor

9.3 pgbench. Sorry for noise. BTW, I saw this with 9.3.2's pgbench: 23930 of 38 tuples (-48%) done (elapsed 226.86 s, remaining -696.10 s). -48% does not seem to be quite correct to me... Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_e

Re: [HACKERS] pgbench with large scale factor

ry for noise. 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] pgbench with large scale factor

I noticed that "pgbench -s scale_factor" where scale_factor is larger than 20,000 (SCALE_32BIT_THRESHOLD) creates pgbench_accounts table containing 0 row without any complain. Is there any reason for this? Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sr

Re: [HACKERS] Proposal: variant of regclass

: relation "pg_klass" does not exist LINE 1: SELECT 'pg_klass'::regclass; ^ Or do we want the SELECT to return 0 in the case above? I'm asking because of this: >> So 'pg_klass'::regclass could return 0, >> but not NULL. In the

Re: [HACKERS] Proposal: variant of regclass

> Tatsuo Ishii writes: >> I would like to add a variant of regclass, which is exactly same as >> current regclass except it does not raise an error when the target >> table is not found. Instead it returns InvalidOid (0). > > I've sometimes thought we sho

[HACKERS] Proposal: variant of regclass

EnterpriseDB, VMWare, SRA OSS and so on. IMO this small enhancement will benefit many PostgreSQL users by small changes to PostgreSQL. -- 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

Re: [HACKERS] Why we are going to have to go DirectIO

work very well anyway. In my understanding, the problem is, even if there's enough memory, the kernel's cache does not work as expected. -- 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 ma

Re: [HACKERS] Why we are going to have to go DirectIO

scaffolding to be sure that *their* version never has performance > regressions? (Well, no, they won't, because no such thing will ever be > built. But we do need better test scaffolding for real problems.) Can we avoid the Linux kernel problem by simply increasing our share

Re: [HACKERS] Data corruption issues using streaming replication on 9.0.14/9.2.5/9.3.1

a community to have > such a testing framework in place, otherwise we really need to halt all > work on replication until we have such a thing. Agreed. I think this is very critical for us. -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://ww

Re: [HACKERS] Can we trust fsync?

why we have the "fsync" param to > control different sync modes. Just concerned it's even more variable > than I thought. So on linux, we don't have any safe option for wal_sync_method? -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanes

Re: [HACKERS] tcp_keepalives_idle

> Tatsuo Ishii writes: >> I am struggling to understand what following phrase says: > >> tcp_keepalives_idle (integer) >> Specifies the number of seconds before sending a keepalive packet >> on an otherwise idle connection. > > It means "th

<    1   2   3   4   5   6   7   8   9   10   >