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
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
>> 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
> 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:
>> >>
>
> 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
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
--
;>
>> 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
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
> 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
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
> 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
> 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
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
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
> 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
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
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
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
> 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
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
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
> 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
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
> 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
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
> 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
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
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
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:
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.
?
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
> 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
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
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.
> 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
> 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
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
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
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
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
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.
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
> 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
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
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
;. 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
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
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
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
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
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/
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
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.
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
>> 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
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
> * 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
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
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
> (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
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
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
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
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
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
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
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
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
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
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
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
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
> 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
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.
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
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
> 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
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
> 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
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
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
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
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
> 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
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
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
;.
>
> 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
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
. 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
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
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
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
: 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
> 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
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
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
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
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
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
> 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
301 - 400 of 1697 matches
Mail list logo