ncgroup_gram.o is generated from
syncgroup_gram.c and syncgroup_scanner.c.
-syncgroup_gram.o: syncgroup_scanner.c
-
-syncgroup_gram.h: syncgroup_gram.c ;
+syncgroup_gram.o: syncgroup_scanner.c syncgroup_gram.c
===
In pg_stat_get_wal_senders, the num_sync looks to have a chance
to be used uninitialized but I don't know why the compiler don't
complain about it.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hello,
At Fri, 26 Feb 2016 15:43:14 -0300, Alvaro Herrera
wrote in <20160226184314.GA205945@alvherre.pgsql>
> Kyotaro HORIGUCHI wrote:
>
> > So, I'd like to propose four (or five) changes to this harness.
> >
> > - prove_check to remove all in tmp_ch
t; >> + }
> >> + }
> >>
> >> How about doing this in a separate function which takes the command id as
> >> parameter and returns an array of values and the number of values (per
> >> command id). pg_stat_get_progress_info() then creates values[] and nulls[]
> >> arrays from that and returns that as result set. It will be a cleaner
> >> separation of activities, perhaps.
> >>
> >> +1
Accessing an element out of array safely be NULL and the caller
should know the number of elements, so I prefer one integer (or
bigint?) array to be returned. Or anyway the internal array has
finite number of elements, the function may return an array
exactly reflects the internal.
Last, I found one small bug mentioned above.
+if (beentry->st_progress_param[1] != 0)
+ values[8] = Float8GetDatum(beentry->st_progress_param[2] * 100 /
beentry->st_progress_param[1]);
Float8GetDatum(int/int) cannot have decimal places.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
#x27;t seem to fit with the rest of what's in that view, and
> it wasn't reliable in my testing. I did however throw together a
> little contrib module for testing, which I attach here. I'm not sure
> we want to commit this, and at the least someone would need to write
> d
Hello,
At Tue, 1 Mar 2016 13:33:02 -0500, Robert Haas wrote in
> On Fri, Feb 26, 2016 at 12:33 AM, Kyotaro HORIGUCHI
> wrote:
> > I divided the last patch into one typo-fix patch and one
> > improvement patch. This is the former one.
>
> Committed.
Thank you.
--
Ky
Hello, thank you for the comments.
At Wed, 2 Mar 2016 10:10:55 +1300, Thomas Munro
wrote in
> On Wed, Mar 2, 2016 at 7:54 AM, Robert Haas wrote:
> > On Mon, Feb 29, 2016 at 6:32 PM, Thomas Munro
> > wrote:
> >> On Fri, Feb 26, 2016 at 6:34 PM, Kyotaro HORIGUCHI
> &
ld be
> enough heads-up for DBAs to be careful with it.
It looks to expose nothing about table contents. At lesast
anybody who can see the name of a table are safely allowable to
use this on it.
A possible usage (for me) of this would be directly couting
(un)vacuumed or (un)freezed pages in a relat
t.postgresql.org/9/545/
On the other hand, it would be in another place and needs another
method if we want a history like the current autovacuum
completion logs (at debug3..) of 100 latest invocation of
autovacuum worker. Anyway the WorkerInfoData is not enough.
What kind of information we
ms
> ::table_privileges ::trigger
> ::tables::triggered_update_columns
> ::text ::triggers
> ::tid ::tsm_handler
> ::time ::tsquery
> ::timestamp ::tsrange
> ::time_stamp::t
At Thu, 3 Mar 2016 12:15:13 +0100, Pavel Stehule
wrote in
pavel.stehule> 2016-03-03 12:06 GMT+01:00 Kyotaro HORIGUCHI <
> the requirement of space before is not good :( - It should be any different
> than operator chars. Not only space.
>
> all other is perfect :)
Yeah, I
rn seems to be the list of wansnds element. Element number is
> > useless when the SyncGroupNode nests.
> > > int
> > > SyncRepGetSyncStandbysUsingPriority(SyncGroupNode *group, volatile WalSnd
> > > **sync_list)
> > This might need to expose 'volatile Wal
reads zeroes safely even if it
reads more than what the producer side offered (unless it tries
to divide something with it).
What do you think about this?
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
on.
> >>
> >> These tweaks appear to have been universally disliked by buildfarm
> >> members.
> >
> > Crap. Wasn't careful enough, sorry. Will fix shortly.
>
> Fix pushed.
Thank you for committing this. I can see only one commit for this
in the r
LIBZ
return gzclose(fh);
#else
int ret = fclose(fh);
return ret ? Z_ERRNO : Z_OK;
#endif
}
The Z_* macros should be defined when #ifndef HAVE_LIBZ. The
caller will be like the following.
if ((result = pg_gzclose(...)) == Z_ERRNO)
exit_horribly(..., strerror(errno));
else if (result ==
Hi, Amit.
At Mon, 7 Mar 2016 16:16:30 +0900, Amit Langote
wrote in <56dd2ace.5050...@lab.ntt.co.jp>
>
> Horiguchi-san,
>
> Thanks a lot for taking a look!
>
> On 2016/03/07 13:02, Kyotaro HORIGUCHI wrote:
> > At Sat, 5 Mar 2016 16:41:29 +0900, Amit Langote wrot
but at a glance,
PD_VALID_FLAG_BITS seems should be changed to 0x0007 since
PD_ALL_FROZEN has been removed.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
contrary, I suppose it counts one index page more than
once for the cases of uncorrelated heaps. index_blks_vacuumd can
exceed RelationGetNumberOfBlocks() in extreme cases. If I'm not
missing something, it stands on a quite fragile graound.
> * I am also tempted to add num_dead_tuples and dead_tuples_vacuumed to add
> granularity to 'vacuuming heap' phase but didn't in this version. Should we?
How do you think they are to be used?
reagards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
lf as a
reviewer. I have also reviewed this for last few CFs.
So, as looking into CF app, it seems not so inconsistent with the
persons who appears in this thread for thses three CFs.
Authors: Vinayak Pokale, Rahila Syed, Amit Langote
Reviewers: Amit Langote, Kyotaro Horiguchi
Is there a
Hello, thank you for the comments. The new v8 patch is attched.
At Tue, 08 Mar 2016 18:08:55 -0500, Tom Lane wrote in
<21567.1457478...@sss.pgh.pa.us>
> Kyotaro HORIGUCHI writes:
> > Hello, This is a (maybe) committer-ready patch of a Tomas
> > Vondra's project.
>
Sorry, I should correct one point.
At Wed, 09 Mar 2016 17:29:49 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20160309.172949.8413.horiguchi.kyot...@lab.ntt.co.jp>
> Hello, thank you for the comments. The new v8 patch is attched.
>
> At Tue, 08 Mar 2016 18:08:55
ews so it is proper to show *both of
database and relation* in both of oid and name.
Thoughts?
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
back-branches had problems. See
> 369c0b09080812943a2efcebe91cf4b271bc4f86.
I understand that. Thank you for replying.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
epresents the persistency of the index to be
created. But I'm out of time now..
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
diff --git a/src/backend/access/brin/brin.c b/src/backend/access/brin/brin.c
index c740952..7f0d3f9 100644
--- a/src/backend/access/brin/brin.c
t; would be enough, or needed for some other types
such as "details". This is quite straightforward so I see no
other arguable point other than the code itself.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-h
Thank you for the comment.
I understand that this is not an issue in a hurry so don't bother
to reply.
At Tue, 15 Mar 2016 18:21:34 +0100, Michael Paquier
wrote in
> On Fri, Mar 11, 2016 at 9:32 AM, Kyotaro HORIGUCHI
> wrote:
> > At Fri, 19 Feb 2016 22:27:00 +0900
Hello,
# It seems that I have been forgotten in the recepient list..
At Tue, 15 Mar 2016 22:09:59 -0400, Peter Eisentraut wrote in
<56e8c077.2000...@gmx.net>
> On 2/5/16 3:09 AM, Kyotaro HORIGUCHI wrote:
> > I considered how to make tab-completion robust for syntactical
>
Mmm. Have I broken the entry?
At Tue, 15 Mar 2016 13:55:24 -0400, David Steele wrote in
<56e84c8c.7060...@pgmasters.net>
> On 3/15/16 1:42 PM, Robert Haas wrote:
> > On Fri, Feb 26, 2016 at 2:37 AM, Kyotaro HORIGUCHI
> > wrote:
> >> Hello, this is the new versi
gt;>> SyncRepClearStandbyGroupList is defined in syncrep.c but the
> >>>> other related functions are defined in syncgroup_gram.y. It would
> >>>> be better to place them together.
> >>>
> >>> SyncRepClearStandbyGroupList() is used by
> >
MVDependencydeps[1];/* XXX why not a pointer? */
MVDependency seems to be a pointer type.
+ if (numcols >= MVSTATS_MAX_DIMENSIONS)
+ ereport(ERROR,
and
+ Assert((attrs->dim1 >= 2) && (attrs->dim1 <=
MVSTATS_MAX_DI
Thank for changing status.
At Wed, 16 Mar 2016 12:13:07 -0400, David Steele wrote in
<56e98613.5000...@pgmasters.net>
> On 3/9/16 3:29 AM, Kyotaro HORIGUCHI wrote:
>
> > Hello, thank you for the comments. The new v8 patch is attched.
>
> As far as I can see this patch
; On Thu, Feb 18, 2016 at 6:54 AM, Kyotaro HORIGUCHI <
> horiguchi.kyot...@lab.ntt.co.jp> wrote:
>
> > It is the SQL part of old psqlscan.l but the difference between
> > them is a bit bothersome to see. I attached the diff between them
> > as "psqlscanbody.l.dif
I found that this has been commited.
Thank you for committing this, Simon.
regards,
At Tue, 15 Mar 2016 12:22:05 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20160315.122205.08265186.horiguchi.kyot...@lab.ntt.co.jp>
> Thnak you for scooping up this.
>
> At Thu, 10
e;
> if you try it in psql you get an error, so on that side it's unimplemented
> behavior rather than an actual incompatibility. Perhaps somebody will be
> motivated to fix it later, but I'm not going to spend that kind of time
> on it right now.
>
> I've not written
I said.
The parser is called for not only for SIGHUP, but also for
starting of every walsender. The latter is not necessary but it
is the matter of trade-off between simplisity and
effectiveness. The same can be said for
check_synchronous_standby_names().
regards,
--
Kyotaro Horiguchi
NTT O
I had the same problem and thought similar thing.
At Wed, 16 Mar 2016 11:48:10 -0400, Tom Lane wrote in
<16068.1458143...@sss.pgh.pa.us>
> Robert Haas writes:
> > Gee, I would have expected the DROP to be blocked until the user
> > disconnected, like we do for DROP DATABASE.
FWTW, I agree with
Hello,
At Tue, 22 Mar 2016 23:08:36 +0900, Fujii Masao wrote
in
> On Tue, Mar 22, 2016 at 9:58 PM, Kyotaro HORIGUCHI
> wrote:
> > Thank you for the revised patch.
>
> Thanks for reviewing the patch!
>
> > This version looks to focus on n-priority method. Stuff
Hi,
At Tue, 22 Mar 2016 22:47:16 -0500, Jim Nasby wrote
in <56f211c4.6010...@bluetreble.com>
> On 3/22/16 10:35 PM, Kyotaro HORIGUCHI wrote:
> >> Even if we maintained some interlock for a backend's login role
> >> identity,
> >> >I hardly thi
Hello,
At Thu, 24 Mar 2016 13:04:49 +0900, Masahiko Sawada
wrote in
> On Thu, Mar 24, 2016 at 11:34 AM, Fujii Masao wrote:
> > On Wed, Mar 23, 2016 at 5:32 PM, Kyotaro HORIGUCHI
> > wrote:
> >>> I don't think it's so difficult to extend this version
name [, ...] ]'
>
> This topic has been already discussed before but, we might want to
> change it to other characters such as < and >?
I don't mind ether but as Robert said, it is true that the
characters essentially to be used to enclose something should be
preferred to other characters. Distinguishability of glyphs has
less signinficance, perhaps.
# LISPers don't hesitate to dive into Sea of Parens.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
hema. pg_toast.
=# alter table al
ALL IN TABLESPACE alpha.aalpha.b
=# alter table alp
=# alter table alpha.
alpha.a alpha.b
This seems to me the intended behavior here.
Any comments?
regards,
--
Kyotaro Horiguchi
NTT Open Source Softwa
gt; create temp sequence
> > create sequence
DROP SEQUENCE is already completed with IF EXISTS. CREATE [TEMP]
SEQUENCE with IF NOT EXISTS is added.
> Do you have an idea of when you will have a new patch ready?
Sorry to to have been late. The attached is the revised version.
regards,
Hello,
At Mon, 28 Mar 2016 18:38:22 +0900, Masahiko Sawada
wrote in
sawada.mshk> On Mon, Mar 28, 2016 at 5:50 PM, Kyotaro HORIGUCHI
> wrote:
> > Thank you for the new patch. Sorry to have overlooked some
> > versions. I'm looking the v19 patch now.
> >
>
4:23 PM, Kyotaro HORIGUCHI
> wrote:
> > Hello,
> >
> > At Mon, 28 Mar 2016 18:38:22 +0900, Masahiko Sawada
> > wrote in
> >
> > sawada.mshk> On Mon, Mar 28, 2016 at 5:50 PM, Kyotaro HORIGUCHI
> >> wrote:
> > As mentioned in my comment, SQL
> > addressed.
> >
>
> ok, probably my mistake. I am sorry.
>
>
> >
> > > > drop user mapping
> >
> > "drop user" was not completed with "mapping". I added it then
> > addressed th
nto out of memory by
this leak, though..
Anyway, using malloc is one reason of additional complexity and
it is the main cause that I avoided dynamic memory allocation.
Thoughts?
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hello,
At Tue, 29 Mar 2016 13:12:06 +0200, Pavel Stehule
wrote in
> 2016-03-29 12:08 GMT+02:00 Kyotaro HORIGUCHI <
> > > > As mentioned before, upper-lower problem is an existing
> > > > issue. The case of the words in a query result list cannot be
> > &
decline ripping index predicates from base restrictinfo without
understanding the reason to do so.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
No one should care of this but to make shure..
At Tue, 29 Mar 2016 20:12:03 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20160329.201203.78219296.horiguchi.kyot...@lab.ntt.co.jp>
> By the way, memory blocks that readline sees are freed by it but
> blocks allocated by th
ly for "if" keyword. When I am writing "if " or "if " or "if
> exi" - then autocomplete doesn't work. But this issue is exactly same for
> other "multi words" completation like "alter foreign data wrapper". So if
> it is fix
ynchronous execution/start"
> but "asynchronous tuple-passing". As I showed before, a merge
> join on asynchronous and parallel children running sort *can* win
> over a hash join (if planner foresees that). If asynchronous
> tuple-passing is not so effective like MergeAppend, we
Hi.
At Thu, 21 Jan 2016 19:09:19 +0900, Amit Langote
wrote in <56a0ae4f.9000...@lab.ntt.co.jp>
>
> Hi!
>
> On 2016/01/21 18:26, Kyotaro HORIGUCHI wrote:
> >>> Then, suppose we add a function bool ExecStartAsync(PlanState *target,
> >>> ExecCallba
Hello, thank you for committing this.
At Sat, 16 Jan 2016 21:09:26 -0500, Peter Eisentraut wrote in
<569af7d6.9090...@gmx.net>
> On 1/12/16 9:46 PM, Peter Eisentraut wrote:
> > On 12/22/15 4:44 AM, Kyotaro HORIGUCHI wrote:
> >> 1. 0001-Fix-tab-complete-of-CREATE-INDEX
Mmm. I believed that this is on CF app..
At Tue, 19 Jan 2016 15:41:54 +0900, Michael Paquier
wrote in
> On Thu, Jan 7, 2016 at 5:36 PM, Kyotaro HORIGUCHI
> wrote:
> > Finally, PsqlScanState has four callback funcions and all pgbench
> > needs to do to use it is setting NULL
Ah, I have many candidates in "Attach thread" dialog. That would
be a temporary symptom of a kind of the CF-seaon-wise
meaintenance.
> > Maybe should I repost the patch so that the "Attach thread" can
> > find it as a "recent" email?
>
> What if you
in mechanism would be usable and needs to be
redesigned, but..
Since the destination version is fixed, the advantage of the
plugin mechanism for pg_upgade would be capability to choose a
plugin to load according to some characteristics of the source
database. What do you think the trigger characteris
lly for SEMMNI
and SEMMNS. It seems to me that they should be in the same
wording, but it is not an actual problem.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
>From 6da5ad413dff4724fee75f1ba09013b6033f76ca Mon Sep 17 00:00:00 2001
From: Kyotaro Horiguchi
Date: We
C, the attached diff will appliy on the 0001 and (fixed)
0003 patches.
It might be good to give test number to the name of temp dirs by
any automated way, but it is not included in it.
Opinions? Thoughts?
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
diff --git a/src/test/p
At Thu, 4 Feb 2016 21:43:04 +0900, Fujii Masao wrote in
> On Wed, Feb 3, 2016 at 12:51 PM, Kyotaro HORIGUCHI
> wrote:
> > Hello, I found that the formulas to calculate SEMMNI and SEMMNS
> > are incorrect in 9.2 and later.
> >
> > http://www.postgresql.org/docs/9.
t such a way of changing the semantics of s_s_names
is confising. I can be in sympathy with him. If so, do we have
another variable (named standbys_definition or likewise?) which
is to be set alternatively with s_s_names? Or take another way?
Sorry for the maybe-noise in advance.
regards,
|else if (HeadMatches2("CREATE", "SCHEMA") &&
| SHIFT_TO_LAST1("CREATE") &&
| false) {} /* FALL THROUGH */
The result of this, for the query like this,
CREATE SCHEMA foo bar baz CREATE foe fee CREATE hoge h
ructed so far */
if (!WaitOnLatchSet(&set(?))
errorr()
if (is_sock_readable[sockid]) {} /** is... would be global /
if (is_sock_writable[sockid]) {} /** is... would be global /
/* Any other types of trigger would processes elsewhere */
Although it might be slow if we have an enormous number of
so
#x27;s focus on very simple case, i.e.,
> 1-level priority list, now, then we can extend it to cover other cases.
>
> If we can commit the simple version too early and there is enough
> time before the date of feature freeze, of course I'm happy to review
> the extended version like you proposed, for 9.6.
I agree to Fujii-san. There would be many of convenient gadgets
around this and they are completely welcome, but having
fundamental functionality in 9.6 seems to be far benetifical for
most of us.
At least the extensible syntax is fixed, internal structures can
be gradually exnteded along with syntactical enhancement. Over
three levels of definition or group name are syntactically
reserved and they are allowed to be nothing for now. JSON could
be added but it is too complicated for simple cases.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hello,
At Tue, 9 Feb 2016 13:31:46 +0900, Michael Paquier
wrote in
> On Tue, Feb 9, 2016 at 1:16 PM, Kyotaro HORIGUCHI
> >> > Anyway that's not a small project, and perhaps I am over-complicating
> >> > the whole thing.
> >> >
> >> >
for(n = group->member; n != NULL; n = n->next)
group->member holds two or more items, so the name would be
better to be group->members, or member_list.
===
+ /* We already got enough synchronous standbys, return */
+ if (num == group->wait_num)
As convention for saftiness, this kind of comparison is to use
inequality operators.
> if (num >= group->wait_num)
===
At a glance, SyncRepGetSyncedLsnsPriority and
SyncRepGetSyncStandbysPriority does almost the same thing and both
runs loops over group members. Couldn't they run at once?
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
7;, to define priority standbys.
> 'N(node1, node2, ...)', to define quorum standbys.
> And current patch behaves so.
>
> Which type of parentheses should be used for this syntax to be more clarity?
> Or other character should be used such as <>, // ?
I believed tha
in sight.
I incline to pull out all the plugin stuff of pg_upgrade. We are
so prudent to make changes of file formats so this kind of events
will happen with several-years intervals. The plugin mechanism
would be valuable if we are encouriged to change file formats
more frequently and freely by provid
RCODE_SYNTAX_ERROR),
> > + errmsg_internal("%s", message)));
> > +}
> > whitespace errors here.
>
> +#define MAX_WALSENDER_NAME 8192
> +
> typedef enum WalSndState
> {
> WALSNDSTATE_STARTUP = 0,
> @@ -62,6 +64,11 @@ typedef struct WalSnd
> * SyncRepLock.
> */
> intsync_standby_priority;
> +
> +/*
> + * Corresponding standby's application_name.
> + */
> +const char name[MAX_WALSENDER_NAME];
> } WalSnd;
> NAMEDATALEN instead?
--
Kyotaro Horiguchi
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hello,
At Wed, 10 Feb 2016 18:36:43 +0900, Michael Paquier
wrote in
> On Wed, Feb 10, 2016 at 5:34 PM, Kyotaro HORIGUCHI
> wrote:
> > > > +sync_node_group:
> > > > + sync_list { $$ = create_group_node(1,
> > > > $1);
rmula in 9.3?
>
> ceil((max_connections + autovacuum_max_workers + number of
> background proceses + 5) / 16)
>
> Attached patch uses the above formula for 9.3. I'm thinking to push your
> patches to 9.2, 9.4, 9.5, master, also push the attached one to 9.3.
> Comments
Hello, thank you for reviewing this.
> On Thu, Jan 7, 2016 at 3:36 AM, Kyotaro HORIGUCHI
> wrote:
> > - 0001-Prepare-for-sharing-psqlscan-with-pgbench.patch
> >
> > This diff looks a bit large but most of them is cut'n-paste
> > work and the substantial cha
ex_pages);
> + pgstat_report_progress_update_counter(4,
> vacrelstats->num_index_scans
> + 1);
> + }
> /* Remove tuples from heap */
> lazy_vacuum_heap(onerel, vacrelstats);
> vacrelstats->num_inde
Hello,
At Tue, 16 Feb 2016 10:39:27 +0900, Amit Langote
wrote in <56c27dcf.7020...@lab.ntt.co.jp>
>
> Hello,
>
> On 2016/02/15 20:21, Kyotaro HORIGUCHI wrote:
> > At Mon, 8 Feb 2016 11:37:17 +0900, Amit Langote wrote:
> >> On 2016/02/05 17:15, poku...@pm.nttda
uggestions?
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
diff --git a/src/backend/utils/error/elog.c b/src/backend/utils/error/elog.c
index 9005b26..2d13101 100644
--- a/src/backend/utils/error/elog.c
+++ b/src/backend/utils/error/elog.c
@@ -801,6 +801,7 @@ errmsg(const
Hello, thank you for the opinions,
At Tue, 16 Feb 2016 10:57:33 +0100, Pavel Stehule
wrote in
> Hi
>
> 2016-02-16 10:47 GMT+01:00 Kyotaro HORIGUCHI <
> horiguchi.kyot...@lab.ntt.co.jp>:
>
> > Hello.
> >
> > I'm planning to change the error level
gt;}
In the above part, poll()'s event is passed the callbacks so
callbacks may have a different inplement for select().
Having a callback for sockets. The initializer could be as the
following.
> InitWaitSocketCB(wait_obj, sock, event, your_callback);
If we want to have the waiting
Hello,
At Mon, 22 Feb 2016 22:52:29 +0900, Fujii Masao wrote
in
> On Tue, Feb 16, 2016 at 4:19 PM, Masahiko Sawada
> wrote:
> > On Mon, Feb 15, 2016 at 2:54 PM, Michael Paquier
> > wrote:
> >> On Mon, Feb 15, 2016 at 2:11 PM, Kyotaro HORIGUCHI wrote:
> >
Hello,
Ok, I think we should concentrate the parser part for now.
At Tue, 23 Feb 2016 17:44:44 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20160223.17.178687579.horiguchi.kyot...@lab.ntt.co.jp>
> Hello,
>
> At Mon, 22 Feb 2016 22:52:29 +0900, Fujii Mas
Hello,
At Wed, 17 Feb 2016 09:13:01 +, Simon Riggs wrote
in
> On 17 February 2016 at 08:34, Kyotaro HORIGUCHI <
> horiguchi.kyot...@lab.ntt.co.jp> wrote:
>
> >
> > > I'm guessing this would require making the pre-translated error text
> > > ava
Hello,
At Wed, 24 Feb 2016 18:01:59 +0900, Masahiko Sawada
wrote in
> On Wed, Feb 24, 2016 at 5:37 PM, Kyotaro HORIGUCHI
> wrote:
> > Hello,
> >
> > Ok, I think we should concentrate the parser part for now.
> >
> > At Tue, 23 Feb 2016 17:44:44 +0900 (Tok
s, and now the former doesn't use its first
parameter rel. We can safely remove the useless parameter.
- match_restriction_clauses_to_index(RelOptInfo *rel, IndexOptInfo *index,
- IndexClauseSet *clauseset)
+ match_restriction_clauses_to_index(IndexOptInfo *i
the former will make '1[a,b,c]'
to fail.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
At Fri, 26 Feb 2016 10:38:22 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20160226.103822.12680005.horiguchi.kyot...@lab.ntt.co.jp>
> Hello, Thanks for the new patch.
>
>
> At Fri, 26 Feb 2016 08:52:54 +0900, Masahiko Sawada
> wrote in
> > Previou
ed. Thanks for the report and patches!
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hello, thank you for the comments.
At Mon, 15 Feb 2016 15:43:57 +0300, Artur Zakirov
wrote in <56c1c80d.7020...@postgrespro.ru>
> On 05.02.2016 11:09, Kyotaro HORIGUCHI wrote:
> > Hello,
> >
> > I considered how to make tab-completion robust for syntactical
> >
Hello,
I divided the last patch into one typo-fix patch and one
improvement patch. This is the former one.
At Fri, 06 Nov 2015 11:47:17 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20151106.114717.170526268.horiguchi.kyot...@lab.ntt.co.jp>
> > Just a m
Hello, this is the second patch plitted out. This allows
multibyte names to be completed in psql.
At Fri, 06 Nov 2015 11:47:17 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20151106.114717.170526268.horiguchi.kyot...@lab.ntt.co.jp>
> At Thu, 5 Nov 2015 18:32:59 +0900, Ami
IndexClauseSet *clauseset)
> > + match_restriction_clauses_to_index(IndexOptInfo *index,
> > + IndexClauseSet *clauseset)
> >
> > I find no other problem and have no objection to this. May I mark
> > this "Ready for committer" after fixing them?
>
> OK. Do you want me to do the fixes, or will you do that?
Ah. I will do. Please wait a minute.
regares,
--
Kyotaro Horiguchi
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
e the cost of predicate_implied_by() on all clauses of
baserectrictinfo and indpred of every IndexOptInfos. The extra
work is done in check_partial_indexes() for all index scans on
partial indexes.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
>From 97040f596e34d40f1e514c8385e
I marked this as "ready for commiter" and tried to add me as the
*second* author. But the CF app forces certain msyterious order
for listed names. Is there any means to arrange the author names
in desired order?
At Fri, 26 Feb 2016 16:06:37 +0900 (Tokyo Standard Time), Kyotaro HORIGUC
Hello, this is the new version of this patch.
At Fri, 26 Feb 2016 13:17:26 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20160226.131726.54224488.horiguchi.kyot...@lab.ntt.co.jp>
> Hello, thank you for the comments.
>
> At Mon, 15 Feb 2016 15:43:57 +0300, Artur Zakir
No, it was wrong.
At Mon, 29 Aug 2016 17:08:36 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20160829.170836.161449399.horiguchi.kyot...@lab.ntt.co.jp>
> Hello,
>
> I considered applying the async infrastructure onto nodeGather,
> but since parallel workers hard
* path must not span on multiple processes */
Since anyway I cannot find a comfortable expression for this, I
attached a patch that does the last one.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
diff --git a/src/backend/executor/nodeGather.c b/src/backend/executor/nodeGather
This is random thoughts on this patch.
At Tue, 30 Aug 2016 12:17:52 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20160830.121752.100817694.horiguchi.kyot...@lab.ntt.co.jp>
> > As the result, the attached patchset is functionally the same
> > with the last v
rocesses */
>
> OK by me.
>
> regards, tom lane
Me too, thanks.
--
Kyotaro Horiguchi
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
g because of small
requirement of additional memory and far less comparisons. Also
Big5 and other encodings including EUC-* will get benefit from
it.
Implementing radix tree code, then redefining the format of
mapping table to suppot radix tree, then modifying mapping
generator script are need
Hello,
At Sun, 4 Sep 2016 12:54:57 +0200, Pavel Stehule
wrote in
> This patch needs rebase.
Thank you. I'll rebase the following patch and repost as soon as
possible.
https://www.postgresql.org/message-id/20160407.211917.147996130.horiguchi.kyot...@lab.ntt.co.jp
regards,
--
ble, the
generating script no longer usable. If any other autority is
choosed, it is to be modified according to whatever the new
source format is.
Any suggestions? Or opinions?
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
diff --git a/src/backend/utils/mb/Unicode/utf8_to_sj
Hello,
At Tue, 6 Sep 2016 03:43:46 +, "Tsunakawa, Takayuki"
wrote in
<0A3221C70F24FB45833433255569204D1F5E66CE@G01JPEXMBYT05>
> > From: pgsql-hackers-ow...@postgresql.org
> > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Kyotaro
> > HORIGUCHI
&g
Hello,
At Wed, 07 Sep 2016 16:13:04 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20160907.161304.112519789.horiguchi.kyot...@lab.ntt.co.jp>
> > Implementing radix tree code, then redefining the format of mapping table
> > > to suppot radix tree, then modify
Hello,
At Thu, 01 Sep 2016 16:12:31 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20160901.161231.110068639.horiguchi.kyot...@lab.ntt.co.jp>
> There's perfomance degradation for non-asynchronous nodes, as
> shown as 't0' below.
>
> The patch adds
1 - 100 of 1270 matches
Mail list logo
