d and put this one
> out there. I believe there are other people thinking about these
> topics as well, including Andres Freund, Kyotaro Horiguchi, and
> probably some folks at 2ndQuadrant (but I don't know exactly who). To
> make a long story short, I think there are several d
Hello,
At Wed, 27 Apr 2016 18:05:26 -0400, Tom Lane wrote in
<3167.1461794...@sss.pgh.pa.us>
> Kyotaro HORIGUCHI writes:
> > Sorry, I have attached an empty patch. This is another one that should
> > be with content.
>
> I pushed this after whacking it around some,
On Wed, Apr 27, 2016 at 10:14 AM, Kyotaro HORIGUCHI
wrote:
> I just added a comment in the v9.
Sorry, I have attached an empty patch. This is another one that should
be with content.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
fix_sync_rep_update_conf_v9.patch
Descript
ving. I don't think
that leaving them is a problem on both of the cases and there's
no point freeing only it among those (if any) allocated in the
generated code by bison and flex... I suppose.
I just added a comment in the v9.
| * No further need for syncrep_parse_result. The memory blocks are
| * released along with the deletion of the current context.
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
that would work fine in text
> format.
I haven't considered much about the usefulness of this
restriction, but receiving into an array of a different type
easily leads to a crash.
# However, false matching of type oids also would do so.
I suppose that we should reconsider here if removing the checks.
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, attached is the new version v8.
At Tue, 26 Apr 2016 11:02:25 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20160426.110225.35506931.horiguchi.kyot...@lab.ntt.co.jp>
> At Sat, 23 Apr 2016 10:12:03 -0400, Tom Lane wrote in
> <476.1461420...@sss.pgh.pa.us&g
much as guc.c can keep track of for an
> "extra" value.
Ok, I'll post the v8 with the blob solution sooner.
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
Hi,
At Fri, 22 Apr 2016 17:27:07 +0900, Amit Langote
wrote in <5719e05b.4030...@lab.ntt.co.jp>
>
> Horiguchi-san,
>
> On 2016/04/22 14:21, Kyotaro HORIGUCHI wrote:
> > I came to think that both of you are misunderstanding how
> > synchronous standbys are choo
Hello, thank you for understanding.
At Mon, 25 Apr 2016 10:26:49 -0400, Robert Haas wrote
in
> On Thu, Apr 21, 2016 at 9:47 PM, Kyotaro HORIGUCHI
> wrote:
> > A lock was already held in BackendPidGetProc(). Is it also
> > needless? If so, we should use BackendPidGetPro
I came to think that both of you are misunderstanding how
synchronous standbys are choosed so I'd like to clarify the
behavior.
At Fri, 22 Apr 2016 11:09:28 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20160422.110928.18809311.horiguchi.kyot...@lab.ntt.co.jp>
>
5(name1, name2, name3)'
and the following standbys
(name1, name1, name2, name2, name3, name3)
The following standbys are choosed as synchronous.
(name1, name1, name2, name2, name3)
# However, 5 for three names causes a warning..
Am I still wrong?
regards,
--
Kyotaro Horiguch
only thing we need to do is to prevent the value from being read
> > twice, and we already have precedent for how to prevent that in
> > freelist.c.
However, I don't have objections for the patch applied.
> That was intended to say "a hideously expensive way".
Thank
At Wed, 20 Apr 2016 23:07:41 -0400, Robert Haas wrote
in
> On Sun, Apr 17, 2016 at 11:56 PM, Kyotaro HORIGUCHI
> wrote:
> > Hello, now the synchronous_standby_names can teach to ensure more
> > then one synchronous standbys. But the doc for it seems assuming
> > only
between weit_event and query,
or beentry itself but preventing it would need to have local
copies of wait_event_info of all corresponding entries in
procarray, which will be overdone.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
diff --git a/src/backend/postmaster/pgstat.c b/src/b
reaming is just the same with
that for psql.
| FATAL: terminating connection due to administrator command
| server closed the connection unexpectedly
| This probably means the server terminated abnormally
| before or while processing the request.
Or, we should provide another c
At Wed, 20 Apr 2016 11:51:09 +0900, Masahiko Sawada
wrote in
> On Mon, Apr 18, 2016 at 2:15 PM, Kyotaro HORIGUCHI
> wrote:
> > At Fri, 15 Apr 2016 17:36:57 +0900, Masahiko Sawada
> > wrote in
> >
> >> How about if check_hook just parses parameter
ne function.
>
> -void
> -SyncRepFreeConfig(SyncRepConfigData *config)
> +SyncRepConfigData *
> +SyncRepCopyConfig(SyncRepConfigData *oldconfig, MemoryContext targetcxt)
>
> I'm not sure targetcxt argument is necessary.
Yes, these are just for signalling so removal doesn&#x
At Sat, 16 Apr 2016 12:50:30 +0530, Amit Kapila wrote
in
> On Fri, Apr 15, 2016 at 11:30 AM, Kyotaro HORIGUCHI <
> horiguchi.kyot...@lab.ntt.co.jp> wrote:
> >
> > At Fri, 15 Apr 2016 08:52:56 +0530, Amit Kapila
> wrote :
> > >
> > > How about if we
terminate way.
Is this makes sense?
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index f9ba148..7b2edbe 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -3028,9 +3028,9 @@ include_dir 'co
ial serial mode
> parallel parallel mode
This looks good to me but since is optional, some
description about default behavior would be needed.
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, 15 Apr 2016 08:52:56 +0530, Amit Kapila wrote
in
> On Thu, Apr 14, 2016 at 1:10 PM, Masahiko Sawada
> wrote:
> >
> > On Thu, Apr 14, 2016 at 1:11 PM, Kyotaro HORIGUCHI
> > wrote:
> > > At Thu, 14 Apr 2016 12:42:06 +0900, Fujii Masao
> wrote in
fine.
Hmm. I got an error that dmake is not found for the first time
but I could successfully install it this time. Thank you for
letting me retry.
I confirmed that fix_sync_rep_update_conf_v4.patch doesn't make
nothing to be broken in vcregress recoverycheck. And I will be
able to recheck
At Thu, 14 Apr 2016 17:25:39 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20160414.172539.34325458.horiguchi.kyot...@lab.ntt.co.jp>
> Hello,
>
> At Thu, 14 Apr 2016 13:24:34 +0900, Michael Paquier
> wrote in
>
> > On Thu, Apr 14, 2016 at 11:45
,6 @@ sub usage
{
print STDERR
"Usage: vcregress.pl ",
-"
[schedule]\n";
+"
[schedule]\n";
exit(1);
}
=
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql
int*. It might have been
confused with pgwin32_accept.
The attached patch fixes this.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
diff --git a/src/backend/port/win32/socket.c b/src/backend/port/win32/socket.c
index ea4fb55..56a13e5 100644
--- a/src/backend/port/win32/socke
ory leak on all postgres processes.
It might be better if the parser works on the current memory
context and the caller copies the result on the malloc'ed
memory. But some list-creation functions using palloc.. Changing
SyncRepConfigData.members to be char** would be messier..
Any idea?
regar
he patch assumes that one check_s_s_names is
followed by exactly one assign_s_s_names. I suppose that myextra
should be handled without such assumption.
Plus, the name myextra should be any saner name..
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
Hi,
At Tue, 5 Apr 2016 19:46:04 +0900, Amit Langote
wrote in <5703976c.30...@lab.ntt.co.jp>
> On 2016/04/05 18:44, Kyotaro HORIGUCHI wrote:
> > At Tue, 5 Apr 2016 14:24:52 +0900, Amit Langote wrote:
> > With this patch, making any change on foreign servers or user
> >
Sorry, my code was wrong in the case that the total numer of
synchronous standby exceeds required number and the wansender is
at priority 1.
Sorry for the noise.
At Wed, 06 Apr 2016 17:01:51 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20160406.170151.246853881.horiguchi.k
= next)
! {
...
! if (this_priority == priority)
! {
! result = lappend_int(result, i);
! if (am_sync != NULL && walsnd == MyWalSnd)
! *a
At Tue, 5 Apr 2016 20:17:21 +0900, Fujii Masao wrote in
> >> list_member_int() performs the loop internally. So I'm not sure how much
> >> adding extra list_member_int() here can optimize this processing.
> >> Another idea is to make SyncRepGetSyncStandby() check whether I'm sync
> >> standby or
parentheses.
If the 'another kind of parehtheses' is a pair of brackets, an
application_name 'tokyo[A]', for example, is currently allowed to
occur unquoted in the list but will become disallowed by the
syntax change.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Cen
At Tue, 5 Apr 2016 18:08:20 +0900, Fujii Masao wrote in
> On Mon, Apr 4, 2016 at 10:00 PM, Masahiko Sawada
> wrote:
> > On Mon, Apr 4, 2016 at 6:03 PM, Kyotaro HORIGUCHI
> > wrote:
> >> Hello, thank you for testing.
> >>
> >> At Sat, 2 Apr 2016
e moved in to core, with the following
API like this.
reoutine->NotifyObjectModification(ObjectAccessType access,
Oid classId, Oid objId);
- using object access hook (which is put by the core itself) is not bad?
- If ok, the API above looks bad. Any better
s
> would fail to get the word about needing to do this.
If the "recording" means recoding oids to CachedPlanSource like
relationOids, it seems to be able to be recorded automatically by
the core, not by fdw side, we already know the server id for
foreign tables.
I'm mis
st_concat(result, pending);
>
> The cells from 'pending' will be attached to 'result', and 'result'
> will be freed by the caller. But won't the List header object from
> 'pending' be leaked?
>
> + result = lappend_int(result, i);
> + if (li
ake was found in
the following syntaxes. CREATE SEQENCE had one more mistake.
"CREATE [UNIQUE] INDEX"
"CREATE [TEMP] SEQUENCE"
"CREATE [TEMP..] TABLE"
It is arguable that it is proper to suggest existing object for
CREATE statement, but most of the statement is suggest
h
ADDLISTn() expression.
At Fri, 01 Apr 2016 11:52:03 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20160401.115203.98896697.horiguchi.kyot...@lab.ntt.co.jp>
> > > > I found new warning
> > > >
> > > > tab-complete.c:1438:87: warni
At Thu, 31 Mar 2016 11:22:20 +0200, Pavel Stehule
wrote in
> 2016-03-30 10:34 GMT+02:00 Kyotaro HORIGUCHI <
> horiguchi.kyot...@lab.ntt.co.jp>:
>
> > Hi,
> >
> > At Wed, 30 Mar 2016 09:23:49 +0200, Pavel Stehule
> > wrote in <
> >
At Thu, 31 Mar 2016 14:51:02 -0400, Tom Lane wrote in
<19589.1459450...@sss.pgh.pa.us>
> Kyotaro HORIGUCHI writes:
> > Thank you for the comment. The new version is attached.
>
> Committed with rather heavy editorialization and a batch of re
t; > repeated failures to update comments only a few lines away from a
> > change.
I'll recheck that and fix in the next version.
> Kyotaro,
>
> I may look into fixing those issues early next week, but that's fairly
> close to the freeze. Also, I'll have
ng condition to
> > decline ripping index predicates from base restrictinfo without
> > understanding the reason to do so.
>
> U, I'm a bit confused. Which condition?
I sent the messages incomplete. The "condition" mentioned above
is the following.
| rel->relid ==
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
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
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
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
> > &
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
> > addressed.
> >
>
> ok, probably my mistake. I am sorry.
>
>
> >
> > > > drop user mapping
> >
> > "drop user" was not completed with "mapping". I added it then
> > addressed th
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
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.
> >
>
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,
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
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
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
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 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
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
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
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 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
; 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
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
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
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
> >
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
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
>
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
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
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
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
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
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
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.
>
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
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
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
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
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 ==
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
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
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
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
ms
> ::table_privileges ::trigger
> ::tables::triggered_update_columns
> ::text ::triggers
> ::tid ::tsm_handler
> ::time ::tsquery
> ::timestamp ::tsrange
> ::time_stamp::t
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
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
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
> &
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
#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
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
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
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, 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
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
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
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
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
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, 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
> >
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
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
501 - 600 of 1270 matches
Mail list logo
