Hello, moved to pgsql-hackers.
This is the revased and revised version of the previous patch.
At Thu, 13 Jul 2017 13:42:49 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20170713.134249.97825982.horiguchi.kyot...@lab.ntt.co.jp>
> At Tue, 11 Jul 2017 15:39:14 -0400, Tom La
At Wed, 12 Jul 2017 17:11:12 +0300, Heikki Linnakangas wrote
in
> On 07/11/2017 10:34 AM, Kyotaro HORIGUCHI wrote:
> > I noticed that a comment above StandbyAcquireAccessExclusiveLock
> > in backend/storage/ipc/standby.c using wrong names of a variable
> > and a type.
>
and
fix_typo_of_standby_c_96_and_before.patch for 9.6 and before.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
*** a/src/backend/storage/ipc/standby.c
--- b/src/backend/storage/ipc/standby.c
***
*** 587,596 StandbyLockTimeoutHandler(void)
* one transaction on
At Mon, 10 Jul 2017 18:37:34 +0530, Amit Kapila wrote
in
> On Mon, Jul 10, 2017 at 3:27 PM, Kyotaro HORIGUCHI
> wrote:
> > Hi,
> >
> > At Mon, 10 Jul 2017 14:58:13 +0530, Amit Kapila
> > wrote in
> >
> >
> >> I am also not 100% comfortable
Hi,
At Mon, 10 Jul 2017 14:58:13 +0530, Amit Kapila wrote
in
> On Mon, Jul 10, 2017 at 10:39 AM, Kyotaro HORIGUCHI
> wrote:
> > At Sat, 8 Jul 2017 16:41:27 +0530, Amit Kapila
> > wrote in
> >
> >> On Sat, Jul 8, 2017 at 9:08 AM, Robert Haas wrote:
>
(IS_DUMMY_REL(rel))
+ set_dummy_rel_pathlist(childrel);
This is equivalent of just returning before looking over
append_rel_list when rel is a dummy. It doesn't seem to me to add
marked-as-dummy children to a dummy parent. (I understand that is
the objective of this patch.)
At Sat, 8 Jul 2017 16:41:27 +0530, Amit Kapila wrote
in
> On Sat, Jul 8, 2017 at 9:06 AM, Amit Kapila wrote:
> > On Sat, Jul 8, 2017 at 8:52 AM, Robert Haas wrote:
> >> On Thu, Jul 6, 2017 at 5:54 AM, Kyotaro HORIGUCHI
> >> wrote:
> >>> Check for INIT_F
FWIW..
At Thu, 06 Jul 2017 18:54:47 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20170706.185447.256482539.horiguchi.kyot...@lab.ntt.co.jp>
> > > + /*
> > > +* Force the on-disk state of init forks to always be in sync
> > > with the
tions, which
| * is OK, because we only use it during XLOG replay. If in the future we
| * want to use it on temporary or unlogged relations, we could pass additional
| * parameters.
and does
| return ReadBuffer_common(smgr, RELPERSISTENCE_PERMANENT, forkNum, blockNum,
Thank you for the thought.
This is at PoC level so I'd be grateful for this kind of
fundamental comments.
At Wed, 28 Jun 2017 20:22:24 +0200, Antonin Houska wrote in
<392.1498674144@localhost>
> Kyotaro HORIGUCHI wrote:
>
> > The patch got conflicted. This is a new
Hi, I've returned.
At Thu, 29 Jun 2017 14:08:27 +0900, Amit Langote
wrote in
<63a5a01c-2967-83e0-8bbf-c981404f5...@lab.ntt.co.jp>
> Hi,
>
> On 2017/06/29 13:45, Kyotaro HORIGUCHI wrote:
> > Thank you for looking this.
> >
> > At Wed, 28 Jun 2017 10:23:54
Thank you for looking this.
At Wed, 28 Jun 2017 10:23:54 +0200, Antonin Houska wrote in
<4579.1498638234@localhost>
> Kyotaro HORIGUCHI wrote:
>
> > The patch got conflicted. This is a new version just rebased to
> > the current master. Furtuer amendment will be t
Hello,
At Mon, 26 Jun 2017 18:16:42 +0900, Amit Langote
wrote in
<7f5fe522-f328-3c40-565f-5e1ce3745...@lab.ntt.co.jp>
> Hello,
>
> On 2017/06/26 17:46, Kyotaro HORIGUCHI wrote:
> > Hello.
> >
> > I had a case of unexpected error caused by ALTER TABLE NO
>
oving them if someone strongly
wants to preserve them, since their existence don't harm
anything.
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
e latter has a larger impact on the current behavior and
we already treat "DROP TABLE child" case in the similar way, I
suppose that the first approach would be preferable.
Any comments or thoughts?
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
diff --git a/src/backen
w how to deal with them.
Except for detecting changes, as mentioned upthread, in case of
necessity of authority files (why?) after losing the autority, we
can regenerate a linear mapping from a .map file. But I believe
that further change (that we should follow) will hardly come.
regards,
--
At Thu, 22 Jun 2017 09:13:56 -0400, Peter Eisentraut
wrote in
<08678a07-3967-8567-59e5-b9bcced7f...@2ndquadrant.com>
> On 6/22/17 07:09, Kyotaro HORIGUCHI wrote:
> > What makes us have both TRUE/true or FALSE/false as constants of
> > bool?
>
> Historical reasons, pr
At Thu, 22 Jun 2017 15:35:13 +0300, Alexander Korotkov
wrote in
> On Thu, Jun 22, 2017 at 2:09 PM, Kyotaro HORIGUCHI <
> horiguchi.kyot...@lab.ntt.co.jp> wrote:
>
> > Hello, I have a maybe-silly question.
> >
> > What makes us have both TRUE/true or FAL
Hello, I have a maybe-silly question.
What makes us have both TRUE/true or FALSE/false as constants of
bool?
The following definitions in c.h didn't mess anything up.
#define TRUEtrue
#define FALSE false
# NIL seems causing similar mess.
regards,
--
Kyotaro Horiguchi
NTT Open S
g
> > else stays the same.
>
> The alternative is that we use the LockSharedObject() approach that was
> already alluded to, like in the attached patch. Both approaches would
> work equally fine AFAICT.
However I haven't seen this deeply, just making
SetSubscriptionRelStat
Kyotaro Horiguchi
NTT Open Source Software Center
>From 32d5c143a679bcccee9ff29fe3807dfd8deae458 Mon Sep 17 00:00:00 2001
From: Kyotaro Horiguchi
Date: Wed, 22 Feb 2017 09:07:49 +0900
Subject: [PATCH 1/4] Allow wait event set to be registered to resource owner
WaitEventSet needs to be re
ot a part of this patch, but in ruleutils.c, the error
for unknown paritioning strategy is emitted as following.
> elog(ERROR, "unrecognized partition strategy: %d",
>(int) strategy);
The cast is added because the strategy is a char. I suppose
this is because strategy ca
der with its
defintion. Initializing needreload is quite natural from its
definition. (Still it is possible that an extra reload happens if
a reload is requested just after the initialization...)
> > Basically, I don't think this patch is ready to commit. We have
> > neither eviden
Hello.
It is annoying that only staext_dependencies_load is prefixed
with "staext" (two t's) among several similar names prefixed by
"statext"(three t's).
Should we rename it to have the same prefix?
regards,
--
Kyotaro Horiguchi
NTT Open Source Software C
Hello, I noticed that src/include/statistics is not installed by
make install.
The commit 7b504eb282ca2f5104b5c00b4f05a forgot to do that.
master and 10 beta 1 is affected.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
>From 9b871ac36a0867e106200c66179ce593a25988c2 Mon Sep
wn by the check,
timeout would be usable. Attached patch does almost the same
thing with your patch but without busy time check.
What do you think about this?
# I saw that SIGQUIT doens't work for active publisher, which I
# think mention in another thread.
regards,
--
Kyotaro Horiguch
At Mon, 22 May 2017 13:12:14 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20170522.131214.20936668.horiguchi.kyot...@lab.ntt.co.jp>
> > The attached patch is rebased on the current master, but no
> > substantial changes other than disallowing partitioned tabl
Hello.
At Tue, 04 Apr 2017 19:25:39 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20170404.192539.29699823.horiguchi.kyot...@lab.ntt.co.jp>
> The attached patch is rebased on the current master, but no
> substantial changes other than disallowing partitioned tables o
resolving this is preventing blocking of workers
caused by DROP SUBSCRIPTION. So Sadasan's patch immediately
released the lock on pg_subscrption and uses another lock for
exclusion. My patch just give up to read the catalog when not
available.
regards,
--
Kyotaro Horiguchi
NTT Open Source S
Hello, thank you for the reply.
At Thu, 18 May 2017 20:48:44 -0400, Peter Eisentraut
wrote in
<343d4cdb-e25d-867d-2830-6502eca4d...@2ndquadrant.com>
> On 5/10/17 04:38, Kyotaro HORIGUCHI wrote:
> > Hi. While I read the documentation I found the following
> > description
teach libpq to error out with EINTR with
some additional reasons. PQsetEINTRcallback() or something?
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 Mon, 15 May 2017 14:35:20 +0900, Michael Paquier
wrote in
> On Thu, May 11, 2017 at 1:09 PM, Kyotaro HORIGUCHI
> wrote:
> > If we can accept multiple server versions share a tablespace
> > directory, pg_basebackup also can allow that situation. The
> >
in normal operation apply worker
> >> should only exit/restart if subscription has changed or has been
> >> dropped/disabled and I think sync workers want to exit/restart in that
> >> situation as well.
> >
> > I agree that sync workers are tied to the app
ed the same amendment
since the code is a parallel to that of wal receiver.
Or, if we were too sensitive to such locks for nothing, we could
use double-checked locking but I don't think we are so here.
In short, +1 too and walreceiver needs the same amendment.
regards,
--
Kyotaro Horiguchi
NTT
epts
existing catver directory if it is empty.
Anyway, I think it's better that ReceiveAndUnpackTarFile()
doesn't accept any existing direcotry.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To ma
t is not clear that
> why the directory emptiness rule was introduced in first place. Any insight
> on that will be useful.
Originally (before 9.0) files in a tablespace is directly placed
in the "location" and it is reasonable at that time.
> Regards,
> Neha
>
> [1]htt
n the background
writer' (This seems a bit verbose.).
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Centerhas
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ion. This can be a
> host name, an IP address, or a directory path if the connection
> is via Unix socket. (The path case can be distinguished because
> it will always be an absolute path, beginning with /.)
I don't think more strict definition is required but the above
should desc
At Mon, 1 May 2017 11:34:41 -0400, Robert Haas wrote in
> On Fri, Apr 28, 2017 at 3:54 AM, Kyotaro HORIGUCHI
> wrote:
> > But the above also leaves a bug so I sent another patch to fix
> > it. The attched patch restores the 9.6's beavior of looking up
> > .pgpass f
if (table_states != NIL && !last_start_times)
===
- else if (!table_states && last_start_times)
+ else if (table_states == NIL && last_start_times)
reagrds,
--
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, 28 Apr 2017 06:43:19 +0900, Fujii Masao wrote
in
> On Thu, Apr 27, 2017 at 6:32 PM, Kyotaro HORIGUCHI
> wrote:
> > At Thu, 27 Apr 2017 00:51:03 +0900, Fujii Masao
> > wrote in
> >
> >> On Wed, Apr 26, 2017 at 4:03 PM, Kyotaro HORIGUCHI
> >>
's beavior of looking up
.pgpass file in the same manner to the aother patch.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
*** a/src/interfaces/libpq/fe-connect.c
--- b/src/interfaces/libpq/fe-connect.c
***
*** 978,986 connectOptions2(PGconn *conn)
gres"
6. PQhost = localhost <= "host=localhost hostaddr=127.0.0.1 port=5432
dbname=postgres"
7. PQhost = hoge <= "host=hoge hostaddr=127.0.0.1 port=5432 dbname=postgres"
The third case is somewhat confusing but it would be the user's
fault.
regards,
--
At Thu, 27 Apr 2017 00:51:03 +0900, Fujii Masao wrote
in
> On Wed, Apr 26, 2017 at 4:03 PM, Kyotaro HORIGUCHI
> wrote:
> > At Tue, 25 Apr 2017 14:45:03 -0400, Peter Eisentraut
> > wrote in
> > <3d6a1bd0-08ce-301d-3336-ec9f623a3...@2ndquadrant.com>
> >
At Tue, 25 Apr 2017 21:21:29 +0900, Masahiko Sawada
wrote in
> On Tue, Apr 25, 2017 at 8:07 PM, Amit Kapila wrote:
> > On Tue, Apr 25, 2017 at 2:09 PM, Kyotaro HORIGUCHI
> > wrote:
> >>
> >> I'm not good at composition, so I cannot insist on my
> &
At Tue, 25 Apr 2017 11:00:16 -0400, Robert Haas wrote
in
> On Mon, Apr 24, 2017 at 3:55 AM, Kyotaro HORIGUCHI
> wrote:
> > While I looked into dynahash.c, I found that the following
> > sentense became outdated by 5dfc198. The commit removed the only
> > usage of hash_f
At Tue, 25 Apr 2017 15:43:59 +0530, Ashutosh Bapat
wrote in
> On Tue, Apr 25, 2017 at 1:31 PM, Kyotaro HORIGUCHI
> wrote:
> >>
> >> The logs above show that 34 seconds elapsed between starting to abort
> >> the transaction and knowing that the foreign server i
At Tue, 25 Apr 2017 14:45:03 -0400, Peter Eisentraut
wrote in
<3d6a1bd0-08ce-301d-3336-ec9f623a3...@2ndquadrant.com>
> On 4/6/17 08:24, Kyotaro HORIGUCHI wrote:
> > The attached patch wakes up launcher when a subscription is
> > enabled. This fails when a subscription i
ng maximum nap time of apply launcher user-configurable
> and document it.
> But if we can deal with it by minimum changes like attached your patch I
> agree.
This change looks reasonable to me, +1 from me to this.
The patch reads on_commit_launcher_wakeup directly then updates
it via ApplyALuncherWakeupAtCommit() but it's too much to add a
function for the sake of this.
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
uot;hashtable" and "hash table" appear there but hash_freeze
uses the former. I followed that.
> s/leavs/leaves/
> s/freezed/frozen/
> s/rurn/run/
Thanks! But the "rurn" was a typo of "turn".
> On Tue, Apr 25, 2017 at 1:42 AM, Petr Jelinek
>
> >
> > Okay, so our consensus is to always set the priorities of sync standbys
> > to 1 in quorum-based syncrep case. Attached patch does this change.
> > Barrying any objection, I will commit this.
>
> +1
Ok, +1 from me.
regards,
--
Kyotaro Horiguchi
NTT Open Source
At Tue, 25 Apr 2017 01:13:12 +0900, Fujii Masao wrote
in
> On Mon, Apr 24, 2017 at 2:55 PM, Masahiko Sawada
> wrote:
> > On Thu, Apr 20, 2017 at 9:31 AM, Kyotaro HORIGUCHI
> > wrote:
> >> Ok, I got the point.
> >>
> >> At Wed, 19 Apr 2017
At Tue, 25 Apr 2017 10:11:06 +0900, Masahiko Sawada
wrote in
> On Mon, Apr 24, 2017 at 7:57 PM, Kyotaro HORIGUCHI
> wrote:
> > Hello,
> >
> > At Mon, 24 Apr 2017 11:18:32 +0900, Masahiko Sawada
> > wrote in
> >
> >> >> BEGIN;
> >
see how can we provide that information to pgfdw_xact_callback().
Expiration of statement_timeout doesn't mean a stall of foreign
connections. If we are to keep connections by, for example, a
cancel request from client, we also should keep them on
statememt_timeout because it is not necessariry triggered by a
stall of
using two-paase
commmit, but I think it shouldn't happen silently.
How about providing AtPrepare_ApplyLauncher(void) like the
follows and calling it in PrepareTransaction?
void
AtPrepare_ApplyLauncher(void)
{
if (on_commit_launcher_wakeup)
ereport(WARNING,
(errmsg ("
Hello,
At Fri, 21 Apr 2017 10:15:20 -0400, Peter Eisentraut
wrote in
<77f75a90-a495-6661-68df-e4993bfac...@2ndquadrant.com>
> On 4/6/17 08:24, Kyotaro HORIGUCHI wrote:
> > Hello. I found dubious behavior while playing with logical
> > replication.
> >
> &g
begins with "This is used
by..".
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
diff --git a/src/backend/utils/hash/dynahash.c b/src/backend/utils/hash/dynahash.c
index 12b1658..1adc5841 100644
--- a/src/backend/utils/hash/dynahash.c
+++ b/src/backend/utils/hash
Hello,
At Sun, 23 Apr 2017 00:51:52 +0900, Masahiko Sawada
wrote in
> On Fri, Apr 21, 2017 at 11:19 PM, Masahiko Sawada
> wrote:
> > On Fri, Apr 21, 2017 at 5:33 PM, Kyotaro HORIGUCHI
> > wrote:
> >> Hello,
> >>
> >> At Thu, 20 Apr 2017 13
; On 19/04/17 14:42, Masahiko Sawada wrote:
> >>>> On Wed, Apr 19, 2017 at 5:12 PM, Kyotaro HORIGUCHI
> >>>> wrote:
> >>>>> At Tue, 18 Apr 2017 18:40:56 +0200, Petr Jelinek
> >>>>> wrote in
> >>>>>
> >>>>
that some people want to report NULL priority, some people
> >> > want to
> >> > report a constant 1 priority, and nobody wants the current behavior. Is
> >> > that
> >> > an accurate summary?
> >>
> >> Yes, I think that's correct.
> >
> > Okay, but ...
> >
> >> FWIW the reason of current behavior is that it would be useful for the
> >> user who is willing to switch from ANY to FIRST. They can know which
> >> standbys will become sync or potential.
> >
> > ... does this mean you personally want to keep the current behavior? If
> > not,
> > has some other person stated a wish to keep the current behavior?
>
> No, I want to change the current behavior. IMO it's better to set
> priority 1 to all standbys in quorum set. I guess there is no longer
> person who supports the current behavior.
+1 for the latter. For the former, I'd like to distinguish
standbys in sync and not in the field or something if we can
allow the additional complexity.
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 Wed, 19 Apr 2017 10:59:00 +0200, Petr Jelinek
wrote in <3ef9c831-0508-51a9-5ded-c2e31e958...@2ndquadrant.com>
> On 19/04/17 10:45, Kyotaro HORIGUCHI wrote:
> > At Wed, 19 Apr 2017 17:43:17 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
> > wrote in
> >
Ok, I got the point.
At Wed, 19 Apr 2017 17:39:01 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20170419.173901.16598616.horiguchi.kyot...@lab.ntt.co.jp>
> > >> |
> > >> | Quorum-based synchronous replication is basically more
> > >&g
At Wed, 19 Apr 2017 17:43:17 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20170419.174317.114509231.horiguchi.kyot...@lab.ntt.co.jp>
> At Wed, 19 Apr 2017 10:33:29 +0200, Petr Jelinek
> wrote in
>
> > > Commit has been moved from after to before of the
. Of course this is rather unrealistic,
though.
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 Wed, 19 Apr 2017 03:03:38 +0900, Fujii Masao wrote
in
> On Tue, Apr 18, 2017 at 7:02 PM, Masahiko Sawada
> wrote:
> > On Tue, Apr 18, 2017 at 6:40 PM, Kyotaro HORIGUCHI
> > wrote:
> >> At Tue, 18 Apr 2017 14:58:50 +0900, Masahiko Sawada
> >> wrote in
ter, Kyotaro
>
> I vote for "location" -> "lsn". I would expect complains about the
> current inconsistency at some point, and the function names have been
> already changed for this release..
I won't stick on "location" except that "pg_wal_lsn_diff&
ificant problem that
> >>>>>>> potentially-throwable function is called within the mutex
> >>>>>>> region. It potentially causes a kind of dead lock. (That said,
> >>>>>>> theoretically dosn't occur and I'm
we'll not try to start the
> worker again.
Considering the anticipated complexity when many subscriptions
exist in the list, and complexity to remove stale entries in the
hash, I'm inclining toward poroposing just to add 'worker_start'
in pg_subscription_rel. We already have
; > This description looks misleading. A quorum-based sync rep is basically
> > more efficient when there are multiple standbys in s_s_names and you want
> > to replicate the transactions to some of them synchronously. I think that
> > this assumption should be documented explicit
CAH%3Dt1kqwCBF7J1bP0RjgsTcp-SaJaHrF4Yhb1iiQZMe3W-FX2w%40mail.gmail.com
>
> --
> Keith Fiske
> Database Administrator
> OmniTI Computer Consulting, Inc.
> http://www.keithf4.com
Good luck!
--
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 Tue, 18 Apr 2017 09:12:07 +0530, Ashutosh Bapat
wrote in
> On Tue, Apr 18, 2017 at 8:12 AM, Kyotaro HORIGUCHI
> wrote:
> > At Mon, 17 Apr 2017 17:50:58 +0530, Ashutosh Bapat
> > wrote in
> >
> >> On Mon, Apr 17, 2017 at 1:53 PM, Kyotaro HORIGUCHI
> &
Hi,
Thank you for the revised version.
At Mon, 17 Apr 2017 23:29:28 +0900, Masahiko Sawada
wrote in
> On Mon, Apr 17, 2017 at 9:13 PM, Masahiko Sawada
> wrote:
> > On Mon, Apr 17, 2017 at 7:39 PM, Kyotaro HORIGUCHI
> > wrote:
> >> At Mon, 17 Apr 2017 18:0
At Mon, 17 Apr 2017 17:50:58 +0530, Ashutosh Bapat
wrote in
> On Mon, Apr 17, 2017 at 1:53 PM, Kyotaro HORIGUCHI
> wrote:
> > At Thu, 13 Apr 2017 13:04:12 -0400, Robert Haas
> > wrote in
> >
> >> On Thu, Apr 21, 2016 at 10:53 AM, Robert Haas
> >&g
alled while spinlock is being held.
> >
>
> One option is adding new LWLock for the relation state change but this
> lock is used at many locations where the operation actually doesn't
> take time. I think that the discussion would be needed to get
> consensus, so patch for
n the case.
If we are not willing to pay such high penalty, maybe we are to
manage busy-idle time of each connection and trying graceful
abort if it is short enough, maybe having a shoft timeout.
Furthermore, if most or all of the hundreds of connections get
stuck, such timeout will accumulate up like a mountain...
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
oyance is the historical function pg_xlog_location_diff(),
which is currently just an alias of pg_lsn_mi. It is
substantially an operator, but 'pg_wal_lsn_diff()' is so far from
the historical name that it becomes totally useless.
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, 14 Apr 2017 18:26:37 -0400, Peter Eisentraut
wrote in
<052f4ce0-159a-1666-f136-91977d326...@2ndquadrant.com>
> On 4/14/17 04:28, Kyotaro HORIGUCHI wrote:
> > =# select distinct attname from pg_attribute where attname like '%lsn%&
x27;%lsn%';
attname
-
confirmed_flush_lsn
latest_end_lsn
local_lsn
receive_start_lsn
received_lsn
remote_lsn
restart_lsn
srsublsn
(8 rows)
Feature is already frozen, but this seems inconsistent a bit..
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
ority | sync_state
-++---+---
sby1 | 0/700140 | 1 | sync
sby4 | 0/700100 | 1 | sync
sby2 | 0/700080 | 1 | sync
sby3 | 0/6FFF3e | 2 |
.. yes, sorry for the noise.
--
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
Ouch! I replied to wrong mail.
At Thu, 13 Apr 2017 19:55:04 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20170413.195504.89348773.horiguchi.kyot...@lab.ntt.co.jp>
> I confused sync and apply workers.
> sync worker failure at start causes immediate retries.
>
> A
problem but, if I understand correctly, the
many pallocs in process_syncing_tables_for_apply() is working on
ApplyContext and the context is reset before the next visit here
(in LogicalRepApplyLoop).
Although this is not a problem of this patch, this is a problem
generally.
regards,
--
Kyotaro Horiguchi
N
At Thu, 13 Apr 2017 13:52:40 +0900, Michael Paquier
wrote in
> On Tue, Apr 11, 2017 at 5:38 PM, Kyotaro HORIGUCHI
> wrote:
> > Sorry, what I have just sent was broken.
>
> You can use PROVE_TESTS when running make check to select a subset of
> tests you want to run. I
orum-based sync replication
since the value is useless."
Or, or, or.. something other.
This part,
+if (SyncRepConfig &&
+SyncRepConfig->syncrep_method == SYNC_REP_QUORUM)
+nulls[9] = true;
+else
+values[9] = Int32GetDatum(priority);
I looked on how
Sorry for the too-brief reply.
At Tue, 11 Apr 2017 20:08:46 +0300, Konstantin Knizhnik
wrote in
<94c8692a-f299-b72b-6227-270b8a9ed...@postgrespro.ru>
>
> On 04.04.2017 13:29, Kyotaro HORIGUCHI wrote:
> > Hi,
> >
> > At Sun, 02 Apr 2017 16:30:24 +0300, Kon
I'd like to put a supplimentary explanation.
At Tue, 11 Apr 2017 17:38:12 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20170411.173812.133964522.horiguchi.kyot...@lab.ntt.co.jp>
> Sorry, what I have just sent was broken.
>
> At Tue, 11 Apr 2017 17:33:41 +0900
Sorry, what I have just sent was broken.
At Tue, 11 Apr 2017 17:33:41 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20170411.173341.257028732.horiguchi.kyot...@lab.ntt.co.jp>
> At Tue, 11 Apr 2017 09:56:06 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
&g
At Tue, 11 Apr 2017 09:56:06 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20170411.095606.245908357.horiguchi.kyot...@lab.ntt.co.jp>
> Hello, thank you for looking this.
>
> At Fri, 07 Apr 2017 20:38:35 -0400, Tom Lane wrote in
> <27309.1491611...@sss.
ved me that it can store
transient values. But I came up with another thought.
The reason I proposed it was I thought that hash_search for every
buffer is not good. Instead, like pg_stat_info, we can link the
pending-sync hash entry to Relation. This greately reduces the
frequency of hash-searching.
I&
f => $fname,
>l => $.
> };
Of course this is utterly harmless but wrong.
The attached patch fixes this following other perl files around.
No similar mistake is not found there.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
diff --git a
teps.
$ cd src/backend/utils/mb/Unicode
$ git rm *.txt
$ git commit
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
>From 59c069baaee7a4125fe7071e999c9b2a9d0e40d2 Mon Sep 17 00:00:00 2001
From: Kyotaro Horiguchi
Date: Fri, 7 Apr 2017 14:33:56 +0900
Subject: [PATCH 1/2] Fi
At Thu, 6 Apr 2017 18:42:37 +0200, Petr Jelinek
wrote in <8c7afb37-be73-c6bd-80bc-e87522f04...@2ndquadrant.com>
> On 06/04/17 16:44, Masahiko Sawada wrote:
> > On Thu, Apr 6, 2017 at 9:06 PM, Kyotaro HORIGUCHI
> > wrote:
> >>> I prefer subscription option t
f ', "\if(n/un)def
' and other '\if_blah_blah's.
Otherwise we could introduce pseudo-functions instead, but this
is unnecessarily complex for this case.
| \if defined() && execute('select version()')) ~= / 10 devel/
# Ugh.
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, Pierre.
Maybe you're the winner:p
At Thu, 06 Apr 2017 12:34:09 +0200, Pierre Ducroquet
wrote in <1714428.BHRm6e8A2D@peanuts2>
> On Thursday, April 6, 2017 2:00:55 PM CEST Kyotaro HORIGUCHI wrote:
> > https://www.postgresql.org/docs/9.6/static/manage-ag-tablespaces
At Thu, 6 Apr 2017 14:43:56 -0400, Peter Eisentraut
wrote in
<330a093a-d155-c866-cbf2-8f36fdf51...@2ndquadrant.com>
> On 4/6/17 11:47, Peter Eisentraut wrote:
> > On 4/5/17 21:32, Kyotaro HORIGUCHI wrote:
> >> At Wed, 5 Apr 2017 11:33:51 -0400, Peter Eisentraut
> &
I don't mean that this is the only or best way to go.
I apologize for the possible lack of explanation.
At Thu, 06 Apr 2017 12:03:51 -0400, Tom Lane wrote in
<21084.1491494...@sss.pgh.pa.us>
> Kyotaro HORIGUCHI writes:
> > I noticed by the following report, PostgreSQ
worst
case. (DEFAULT_NAPTIME_PER_CYCLE)
The attached patch wakes up launcher when a subscription is
enabled. This fails when a subscription is enabled immedaitely
after disabling but it won't be a matter.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
diff --git a/src/backen
At Thu, 06 Apr 2017 17:02:14 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20170406.170214.263553093.horiguchi.kyot...@lab.ntt.co.jp>
> At Thu, 6 Apr 2017 16:15:33 +0900, Masahiko Sawada
> wrote in
> > On Thu, Apr 6, 2017 at 3:45 PM, Kyotaro HORIGUCHI
>
At Thu, 6 Apr 2017 21:55:43 +1200, David Rowley
wrote in
> On 6 April 2017 at 19:50, Kyotaro HORIGUCHI
> wrote:
> > At Thu, 6 Apr 2017 18:59:35 +1200, David Rowley
> > wrote in
> >
> >> On 6 April 2017 at 18:03, Kyotaro HORIGUCHI
> >> wrote:
>
At Thu, 6 Apr 2017 16:15:33 +0900, Masahiko Sawada
wrote in
> On Thu, Apr 6, 2017 at 3:45 PM, Kyotaro HORIGUCHI
> wrote:
> > I was thinking the same.
> >
> > At Thu, 6 Apr 2017 11:33:22 +0900, Masahiko Sawada
> > wrote in
> >
> >> Hi all,
101 - 200 of 1270 matches
Mail list logo
