d error as well in your patch. I sugges you change
the error message something like:
"thread progress delay (-P) must be positive number (%s)\n",
--
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
positive number (%s)\n",
>
> Please find attached a new version with an updated message.
Thanks. I've been testing on Linux now. Starting from coming Tuesday
(Monday is a national holiday in Japan) I will test on Mac OS X and
Windows.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
Eng
such as Shift Jis.
There are lots of discussion on this. Here is the one from Microsoft:
http://support.microsoft.com/kb/170559/EN-US
--
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
d why you need UTF-16 support as a database
encoding because UTF-8 and UTF-16 are logically equivalent, they are
just different represention (encoding) of Unicode. That means if we
already support UTF-8 (I'm sure we already do), there's no particular
reason we need to add UTF-16 support.
read it
/bin/tar: postgresql-9.4devel/src/bin/pg_resetxlog/pg_crc.c: File removed
before we read it
/bin/tar: postgresql-9.4devel/src/backend/tcop/.#postgres.c: File removed
before we read it
make: *** [postgresql-9.4devel.tar] Error 1
make: *** Deleting file `postgresql-9.4devel.tar'
--
Tatsuo
> To clarify what state this is all in: Fabien's latest
> pgbench-throttle-v15.patch is the ready for a committer version. The
> last two revisions are just tweaking the comments at this point, and
> his version is more correct than my last one.
Got it. I will take care of this
l
>
> It looks like your source directory isn't completely clean. Before I
> did this I did:
>
>git clean -dfx
Oh, I didn't know that "make dist" requires git clean. Thanks.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en
this be treated as if -R is not specified? Actually in the program:
/*
* When threads are throttled to a given rate limit, this is the target delay
* to reach that rate in usec. 0 is the default and means no throttling.
*/
int64 throttle_delay = 0;
So it seems treating "-R 0
rs, but
> the internal variable is in usec which is more useful for scheduling,
> and is the inverse of the other.
>
> So -R 0 would mean zero tps, that is an infinite delay, but a 0 delay
> would require an infinite tps. As requiring 0 tps does not make sense,
> I decided to disable th
510640 = 459.2 seconds, which is longer than 300 seconds
(specified by -T). Am I missing something?
--
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
number of transactions actually processed: 29840
average rate limit lag: 0.089 ms (max 27.301 ms)
tps = 2983.707895 (including connections establishing)
tps = 2991.919611 (excluding connections establishing)
0.089 ms * 29840 = 2.66 seconds. Not too bad compared with 10
seconds. On Linux maybe the ove
nning on the same box as the server, and with more clients &
> server than available cores, there is a lot of competition between
> processes, and between clients that share a unique thread, and a log
> context switching whoch will result in a measured lag.
Hmm... I would like to hav
the lag
which pgbench calculates and the expected one will be growing if a lag
happens eariler. I guess why my Linux box shows bigger lag than Mac OS
X is, the first transaction or early transactions run slowly than the
ones run later.
Of course this conclusion depends on the definition of the "
ws.
I have done the test on Mac OS X. Windows testing was done by my
coleague, Yugo Nagata. The results were very positive and I committed
--progress patches.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
--
Sent via pgsq
> On 7/17/13 9:16 PM, Tatsuo Ishii wrote:
>> Now suppose we have 3 transactions and each has following values:
>>
>> d(0) = 10
>> d(1) = 20
>> d(2) = 30
>>
>> t(0) = 100
>> t(1) = 110
>> t(2) = 120
>>
>> That says pgbench
ject the idea. We would need to make
> sure that doesn't break some part of the design too.
I would like to hear from Fabien about the issue too.
--
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
>> lag definition you're looking for. That's fine to me too, if Fabien
>> doesn't have a good reason to reject the idea. We would need to make
>> sure that doesn't break some part of the design too.
>
> I would like to hear from Fabien about th
easurement means is clearly described in
the doc as a committer. I think current measurement method will give
enough confusion if it's not provided with detailed explanation. Could
you please provide doc updatation?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japan
d further.
I'm not a native English speaker either... Greg, could you please
review the document?
--
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
kes.
Have you done it?
--
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
pace in "--progress= sec" in the doc, which is
probably mistakenly added by previous commit.
--
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
>> 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
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
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
idual error code. But then error
> handling gets too complex.
I think the solution for this is assigning a unique id to each
message. This is already done in some commercial databases. They are
pretty usefull for tech supports.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: h
sometimes the file name)
change with version to version.
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
SyncRepWakeQueue (src/backend/replication/syncrep.c) is not used
anywhere except in the file. If there's no good reason for it, I think
it should be declared as a static function. Included patch does so.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.
unction.
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
cosmetic change or not. I thought declaring
to-be-static function as extern is against our coding
standard. Moreover, if someone wants to change near the place in the
source code in the future, changes made to head may not be easily back
patched or cherry-picked to older branches if I do not back
any WAL that gets lost on the master.
*/
This one says walsender sends WAL records as long as there are
fsync'd.
Am I missing something?
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
> On 31/03/15 12:45, Tatsuo Ishii wrote:
>> In the doc:
>>
>> 25.2.5. Streaming Replication
>> :
>> The standby connects to the primary, which streams WAL records to the
>> standby as they're generated, without waiting for the WAL file to be
>>
This patch does not apply cleanly due to the moving of pgbench (patch
to filelist.sgml failed).
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
> Attached is the v7 pg_audit patch.
>
> I've tried to a
LECT * FROM vtest2;
NOTICE: AUDIT: OBJECT,1,1,READ,SELECT,TABLE,public.test2,SELECT * FROM vtest2;
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.or
lker)
is very stable. As a result, the workforce for rewriting rarely needs
to be modified.
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
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.
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
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
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
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
> 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
> 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
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.
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
> 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
?
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
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.
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:
In the above you seem to disable the conversion from 0x96 of win1250
to ISO-8859-2 by using the Unicode mapping files in
src/backend/utils/mb/Unicode. But the corresponding mapping file
(iso8859_2_to_utf8.amp) does include following entry:
{0x0096, 0xc296},
How do you know 0x96 should be
> I wrote:
>> I have not attempted to reverify the files in utils/mb/Unicode against the
>> original Unicode Consortium data, but maybe we ought to do that before
>> taking any further steps here.
>
> I downloaded the mapping files from unicode.org and attempted to verify
> that the Unicode/*.map
to
This adds to "disabled index list". The disabled index
list let the planner to disregard the indexes in the list.
SET enabled_index to
This removes from the disabled index list.
SHOW disabled_index
This shows the content of the disabled index list.
Best regards,
--
Tatsuo Ish
> On 12/11/2015 06:25 PM, Tatsuo Ishii wrote:
>
>> What about inventing a new SET command something like:
>>
>> SET disabled_index to
>>
>> This adds to "disabled index list". The disabled index
>> list let the planner to disregard the indexes
> Tatsuo Ishii wrote:
>>> Wouldn't something like:
>>>
>>> ALTER INDEX foo SET DISABLED;
>>>
>>> See more in line with our grammar?
>>
>> But this will affect other sessions, no?
>
> Not if it is used in a transaction that en
ll try out them.
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
ity.
> +1 for ALTER INDEX foo SET DISABLED
-1 for the reason I mentioned in the up thread. Also I dislike this
because this does not work with standby servers.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
16 (100%), rather
than:
number of transactions skipped: 0 (0.000 %)
in this case I think.
Am I missing something?
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
Great. It would be nice if brin.sgml has a reference to func.sgml.
I mean something like:
brin_summarize_new_pages(regclass) function,
or automatically when VACUUM processes the table.
+ See also .
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp
It seems there is a redundant word "function" in
doc/ref/create_tranform.sgml. Patch attached.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
diff --git a/doc/src/sgml/ref/create_transform.sgml b/doc/sr
are other users who have
similar use cases, since the Shift-JIS variants are still used.
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
conversions.) We could
> apply the same rules for identifying which specific conversion to use
> in convert() and siblings.
Sounds 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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
I confirmed the problem. Also I confirmed your patch fixes the
problem. In addition to this, all the tests in test/mb and
test/regress are passed.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
> hi
>
> When i test p
psql:/home/t-ishii/sql:7: warning: possible conflict between client encoding
SJIS and input file encoding
CREATE TABLE
Comments?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
diff --git a/src/bin/psql/psqlscan.l b/src/bin/psql/psq
e now connected to database "mydb" as user "t-ishii".
CREATE SCHEMA
psql:/home/t-ishii/sql:7: warning: possible conflict between client encoding
SJIS and input file encoding
CREATE TABLE
IMO it is a benefit for users to detect such errors earlier.
--
Tatsuo Ishii
SRA OSS, In
possible cause, but this is not 100%.
--
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
er" is not precise at all because the
error was caused by each byte in the file confused PQmblen, not just
last multibyte character. However to explain those in the messgae is
too technical for users, I'm afraid. Maybe just "encoding mismatch
detected. please make sure that input file
> I confirmed the problem. Also I confirmed your patch fixes the
> problem. In addition to this, all the tests in test/mb and
> test/regress are passed.
Fix committed as you proposed(without any message I proposed). Thanks.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sra
tch. I noticed two things:
1) In the help you put '-q' option into "Common options" section. I
think this should be moved to "Initialization options" section because
the option is only applied while initializing.
2) Shouldn't a long option for '-
> On 6.1.2013 03:03, Tatsuo Ishii wrote:
>> As a committer, I have looked into the patch. I noticed two things:
>>
>> 1) In the help you put '-q' option into "Common options" section. I
>> think this should be moved to "Initialization options&
But I'm not opposing a different name, I just can't think of a
> better one.
Ok, I'm with you ("-q" and along with adding the elapsed/remaining
fields to the original logging).
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http:
ion and added the fields to the original
>>> logging. But I'm not opposing a different name, I just can't think of a
>>> better one.
>>
>> Ok, I'm with you ("-q" and along with adding the elapsed/remaining
>> fields to the original logging).
&g
Hi,
I'm looking into this as a committer. It seems that this is the
newest patch and the reviewer(Pavel) stated that it is ready for
commit. However, I noticed that this patch adds a Linux/UNIX only
feature(not available on Windows). So I would like to ask cores if
this is ok or not.
--
T
fprintf(logfile, "%d %d %.0f %d 0 0\n",
st->id, st->cnt, usec, st->use_file);
#endif
}
--
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
raid it may not fit in 9.3 if we
think about the current status of CF. So our choice would be:
1) Postpone the patch to 9.4
2) Commit the patch in 9.3 without Windows support
I personally am ok with #2. We traditionally avoid particular paltform
specific features on PostgreSQL. However I think
k?
>
> Fair enough, I was just trying to point out alternatives. We have
> committed platform-specific features before now. I hope it doesn't
> just get left like this, though.
Yeah, I hope someone pick this up and propose as a TODO item. In the
mean time, I'm going to commit
e you'd be
> distributing Visual Studio, but if we can have a script that
> auto-downloads-and-installs it as necessary we can get around that)
So if my understating is correct, 1)Tomas Vondra commits to work on
Windows support for 9.4, 2)on the assumption that one of Andrew
Dunstan, Dave Pag
> On Thu, Jan 17, 2013 at 7:43 PM, Tatsuo Ishii wrote:
>> So if my understating is correct, 1)Tomas Vondra commits to work on
>> Windows support for 9.4, 2)on the assumption that one of Andrew
>> Dunstan, Dave Page or Magnus Hagander will help him in Windows
>> developm
> On Mon, Oct 1, 2012 at 02:04:00PM +0900, Tatsuo Ishii wrote:
>> >> >> > Tatsuo Ishii writes:
>> >> >> >> From the manual:
>> >> >> >> "An unnamed portal is destroyed at the end of the transaction"
>> >>
value, not 0. Recovery from WAL archive should be the last
resort, shouldn't be?
--
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 su
ts and could use that to at least give some sort of
> consistency guarantee.
In addition to this, that will greatly help query based replication
tools such as pgpool-II. Sounds great.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.srao
ntax. This seems to be a limitation of
PostgreSQL optimizer and I would like it be removed. Comments?
BTW according to the article, Oracle execute the first SELECT(the one
PostgreSQL takes infinite time) in 10 seconds. It seems Oracle's
optimizer is sperior in this regard.
--
Tatsuo Ishii
SRA
0\5\264 \231\352"..., 16384, 0, NULL, NULL) = 13
sendto(3, "p\0\0\0(md5764161564364fab9083f39d97"..., 41, MSG_NOSIGNAL, NULL, 0)
= 41
poll([{fd=3, events=POLLIN|POLLERR}], 1, -1) = 1 ([{fd=3, revents=POLLIN}])
recvfrom(3, "R\0\0\0\10\0\0\0\0S\0\0\0\32application_name\0ps"
between 8.2.14 and 8.2.15. I couldn't find related
item in HISTORY of 8.2.15. Does anybody know if this change was
intentional? If so, 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
ructure used for message passing is
storage/ipc/procsignal.c The new message type for ProcSignalReason
is "PROCSIG_TERMNINATE_BACKEND_INTERRUPT"
3) I assign new error code 57P04 which is returned from the backend
killed by pg_terminate_backend().
#define ERRCODE_TERMINATE_BAC
tructure used for message passing is
storage/ipc/procsignal.c The new message type for ProcSignalReason
is "PROCSIG_TERMNINATE_BACKEND_INTERRUPT"
3) I assign new error code 57P04 which is returned from the backend
killed by pg_terminate_backend().
#define ERRCODE_TERMINATE_BACKEND
> Tatsuo Ishii writes:
>> Comments are welcome.
>
> This is a bad idea. It makes an already-poorly-tested code path
> significantly more fragile, in return for nothing of value.
Are you saying that procsignal.c is the already-poorly-tested one? If
so, why?
As for "
Long time ago, I propose regclass like function which does not throw
an error if the table is not found. Instead I want to let it return
InvalidOid or NULL.
>> Tatsuo Ishii writes:
>> > Is there any way to use regclass without having ERROR?
>>
>> > pgpool-II ne
> It's not generally safe to suppress errors like that. You could leak
> locks or tuple descriptors etc. And if the error is not "no scuh
> table", but e.g. out of memory, you don't want to suppress it anyway.
Thanks. I will create more "invasive" pat
> Why is any of this necessary? It sure looks like you are solving a
> problem at the wrong level.
Please read upthread.
--
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
ppropreate?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> On Sat, Jan 8, 2011 at 9:52 AM, Tatsuo Ishii wrote:
>> While looking at the backend code, I realized that error code for
>> "terminating connection due to conflict with recovery" is
>> ERRCODE_ADMIN_SHUTDOWN.
>>
>> I thought the error code is
y based replication tools like pgpool-II (I don't know any
other tools, for example Postgres XC falls in this category or
not...), we need to be able to lock sequences. Fortunately it is allowed to:
SELECT 1 FROM foo_sequece FOR UPDATE;
but LOCK foo_sequence looks more appropreate synt
> On Tue, Jan 11, 2011 at 4:46 AM, Tatsuo Ishii wrote:
>>> On Fri, Jan 7, 2011 at 6:28 PM, Florian Pflug wrote:
>>>> I forgot about sequences earlier. If we dump while someone deletes all
>>>> rows and resets the sequence the dump might contain rows and still
does not block nextval(). It just
blocks concurrent "SELECT ... FOR UPDATE" in other session. This is
enough for pgpool's use case.
--
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
And don't forget there are three places where the new error code would
> need to be added.
>
> Otherwise, +1.
Ok. Here is the patch for this. I use 40P02, instead of 40004.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sr
> On Thu, Jan 13, 2011 at 2:13 AM, Tatsuo Ishii wrote:
>> Ok. Here is the patch for this. I use 40P02, instead of 40004.
>
> Please add this to the currently open CommitFest:
>
> https://commitfest.postgresql.org/action/commitfest_view/open
Done. Comments are welcome. Unl
> Tatsuo Ishii writes:
>>> Please add this to the currently open CommitFest:
>>> https://commitfest.postgresql.org/action/commitfest_view/open
>
>> Done. Comments are welcome. Unless there's objection, I will commit it
>> this weekend.
>
> If
ways involves transaction rollback. So using T_R is ok". I'm not
sure this argument is reasonable enough though.
--
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-hacke
been always wondering why we can't use exiting WAL
transporting infrastructure for sending/receiving WAL archive
segments in streaming replication.
If my memory serves, Fujii has already proposed such an idea but was
rejected for some reason I don't understand.
--
Tatsuo Ishii
SRA OSS, In
sed was to have the master restore
> segments from the archive and stream them to clients, on request. It
> was deemed better to have the slave obtain them from the archive
> directly.
Did Fuji-san agreed on the conclusion?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.c
> On Fri, Jan 14, 2011 at 1:51 PM, Robert Haas wrote:
>> On Fri, Jan 14, 2011 at 12:29 PM, Simon Riggs wrote:
>>> This whole thing is confused. No change is appropriate here at all.
>>>
>>> We issue ERRCODE_T_R_SERIALIZATION_FAILURE almost all of the time for
>>> recovery conflicts.
>>>
>>> We is
'0','4')
>
> Comments are welcome.
Anyone has better idea? Tom dislikes my patch but I don't know how to
deal with it.
--
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
301 - 400 of 1697 matches
Mail list logo
