On 2022/02/21 14:45, Etsuro Fujita wrote:
On Fri, Feb 18, 2022 at 1:46 AM Fujii Masao wrote:
I reviewed 0001 patch. It looks good to me except the following minor things.
If these are addressed, I think that the 001 patch can be marked as ready for
committer.
OK
+* Also
ate = DB_SHUTDOWNED_IN_RECOVERY;
Same as above. IMO it's safer and better to always update the state (whether
the state is DB_IN_ARCHIVE_RECOVERY or not) if CHECKPOINT_IS_SHUTDOWN flag is
passed.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
yDesc
should NOT be reset to save_ActiveQueryDesc in this case, should it?
OTOH, in your example, ActiveQueryDesc set by the second call to ExecutorRun()
should be reset in AbortSubTransaction(). Then ActiveQueryDesc set by the first
call should be valid.
Regards,
--
Fujii Masao
Advanced Comp
.
Thoughts?
This information seems not so helpful because only "in production" and "archive
recovery" can be reported during normal running and recovery, respectively. No? In the state
other than them, we cannot connect to the server and execute pg_control_system().
Regards,
--
ion() does, can't we use PQserverVersion() instead of
implementing new function GetServerVersion()?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2022/02/22 11:53, kuroda.hay...@fujitsu.com wrote:
How do you think?
Thanks for updating the patches! I will read them.
cfbot is reporting that the 0002 patch fails to be applied cleanly. Could you
update the patch?
http://cfbot.cputube.org/patch_37_3388.log
Regards,
--
Fujii Masao
ed and
detected the closed connection. Then when I executed COMMIT command, I got the
following WARNING message. Is this a bug?
WARNING: leaked hash_seq_search scan for hash table 0x7fd2ca878f20
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development H
On 2020/11/26 16:07, Masahiro Ikeda wrote:
On 2020-11-25 20:19, Fujii Masao wrote:
On 2020/11/19 16:31, Masahiro Ikeda wrote:
On 2020-11-17 11:46, Fujii Masao wrote:
On 2020/11/16 16:35, Masahiro Ikeda wrote:
On 2020-11-12 14:58, Fujii Masao wrote:
On 2020/11/06 10:25, Masahiro Ikeda
mit 9bae7e4cde provided?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2020/12/01 16:23, Masahiko Sawada wrote:
On Tue, Dec 1, 2020 at 1:48 PM Kasahara Tatsuhito
wrote:
Hi,
On Mon, Nov 30, 2020 at 8:59 PM Fujii Masao wrote:
On 2020/11/30 10:43, Masahiko Sawada wrote:
On Sun, Nov 29, 2020 at 10:34 PM Kasahara Tatsuhito
wrote:
Hi, Thanks for you
On 2020/11/27 12:05, Kyotaro Horiguchi wrote:
At Fri, 27 Nov 2020 09:48:25 +0900, Fujii Masao
wrote in
On 2020/11/27 9:30, Kyotaro Horiguchi wrote:
At Thu, 26 Nov 2020 22:43:48 +0900, Fujii Masao
wrote in
On 2020/11/12 4:38, Sergei Kornilov wrote:
Hello
Anyway, for now I think
On 2020/12/01 14:01, Fujii Masao wrote:
On 2020/11/26 16:07, Masahiro Ikeda wrote:
On 2020-11-25 20:19, Fujii Masao wrote:
On 2020/11/19 16:31, Masahiro Ikeda wrote:
On 2020-11-17 11:46, Fujii Masao wrote:
On 2020/11/16 16:35, Masahiro Ikeda wrote:
On 2020-11-12 14:58, Fujii Masao
On 2020/12/02 12:53, Masahiko Sawada wrote:
On Tue, Dec 1, 2020 at 5:31 PM Masahiko Sawada wrote:
On Tue, Dec 1, 2020 at 4:32 PM Fujii Masao wrote:
On 2020/12/01 16:23, Masahiko Sawada wrote:
On Tue, Dec 1, 2020 at 1:48 PM Kasahara Tatsuhito
wrote:
Hi,
On Mon, Nov 30, 2020 at 8
t about
counting the number of times when the statement is executed
in toplevel, and also in nested level?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
tion keeps waiting infinity. Is this a bug?
Probably we should exclude non-backend proceses from the target
processes to dump? Sorry if this was already discussed.
SELECT pg_get_backend_memory_contexts(pid) FROM pg_stat_activity;
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Re
Fujii/pg_fallback_utf8_to_euc_jp
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
pdate pg_conversion.condefault directly so that we can
use custom encoding when I registered it. The direct update of
pg_conversion is of course not good thing. So I was wondering
if we should have something like ALTER CONVERSION SET DEFAULT.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Researc
On 2020/12/03 13:07, Tom Lane wrote:
Fujii Masao writes:
On 2020/12/03 1:04, Heikki Linnakangas wrote:
We never use non-default conversions for anything. All code that performs
encoding conversions only cares about the default ones.
Yes. I had to update pg_conversion.condefault
On 2020/12/03 11:46, Kasahara Tatsuhito wrote:
On Wed, Dec 2, 2020 at 7:11 PM Masahiko Sawada wrote:
On Wed, Dec 2, 2020 at 3:33 PM Fujii Masao wrote:
On 2020/12/02 12:53, Masahiko Sawada wrote:
On Tue, Dec 1, 2020 at 5:31 PM Masahiko Sawada wrote:
On Tue, Dec 1, 2020 at 4:32 PM
:25 AM Alvaro Herrera wrote:
On 2020-Dec-01, Fujii Masao wrote:
+ if (proc)
+ {
+ if (nprocs == 0)
+ appendStringInfo(&buf, "%d", proc->pid);
+
On 2020/12/04 9:28, Masahiko Sawada wrote:
On Fri, Dec 4, 2020 at 2:54 AM Fujii Masao wrote:
On 2020/12/01 17:29, Drouvot, Bertrand wrote:
Hi,
On 12/1/20 12:35 AM, Masahiko Sawada wrote:
CAUTION: This email originated from outside of the organization. Do not click
links or open
te lots of memory. No? For example, when
plan_cache_mode=force_custom_plan, the memory used for the columns
for generic plans is not used.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
ink_get_connections(),
together with 0001 patch? Otherwise it's not easy for users to
see how many cached connections are and determine whether to
disconnect them or not. Sorry if this was already discussed before.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
erformance of walreceiver.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2020/12/04 12:21, Kasahara Tatsuhito wrote:
Hi,
On Thu, Dec 3, 2020 at 9:09 PM Fujii Masao wrote:
On 2020/12/03 11:46, Kasahara Tatsuhito wrote:
On Wed, Dec 2, 2020 at 7:11 PM Masahiko Sawada wrote:
On Wed, Dec 2, 2020 at 3:33 PM Fujii Masao wrote:
On 2020/12/02 12:53
n as wait
event in pg_stat_activity, instead?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2020/12/04 20:15, Bharath Rupireddy wrote:
On Fri, Dec 4, 2020 at 1:46 PM Bharath Rupireddy
wrote:
On Fri, Dec 4, 2020 at 11:49 AM Fujii Masao wrote:
Attaching the v2 patch set. Please review it further.
Regarding the 0001 patch, we should add the function that returns
the
On 2020/12/09 20:42, Li Japin wrote:
Hi,
On Dec 9, 2020, at 6:37 PM, Seino Yuki mailto:sein...@oss.nttdata.com>> wrote:
2020-12-01 01:04 に Fujii Masao さんは書きました:
On 2020/11/30 23:05, Seino Yuki wrote:
2020-11-30 15:02 に Fujii Masao さんは書きました:
On 2020/11/30 12:08, Seino Yuki wrote:
of server or user mapping will not be closed even by the subsequent access
to the foreign server and will remain until the backend exits. Right? If so,
this seems like a connection-leak bug, at least for me Thought?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2020/12/10 10:44, Bharath Rupireddy wrote:
On Wed, Dec 9, 2020 at 4:49 PM Fujii Masao wrote:
I started reviewing 0001 patch.
Thanks!
IMO the 0001 patch should be self-contained so that we can commit it at first.
That is, I think that it's better to move the documents and test
On 2020/12/12 3:01, Bharath Rupireddy wrote:
On Fri, Dec 11, 2020 at 11:01 PM Fujii Masao
wrote:
On 2020/12/11 19:16, Bharath Rupireddy wrote:
On Thu, Dec 10, 2020 at 7:14 AM Bharath Rupireddy
wrote:
+ /* We only look for active and open remote connections
On 2020/12/12 15:05, Bharath Rupireddy wrote:
On Sat, Dec 12, 2020 at 12:19 AM Fujii Masao mailto:masao.fu...@oss.nttdata.com>> wrote:
> I was thinking that in the case of drop of user mapping or server,
hash_search(ConnnectionHash) in GetConnection() cannot find the cached connect
On 2020/12/05 12:38, Masahiko Sawada wrote:
On Fri, Dec 4, 2020 at 7:22 PM Drouvot, Bertrand wrote:
Hi,
On 12/4/20 2:21 AM, Fujii Masao wrote:
On 2020/12/04 9:28, Masahiko Sawada wrote:
On Fri, Dec 4, 2020 at 2:54 AM Fujii Masao
wrote:
On 2020/12/01 17:29, Drouvot, Bertrand wrote
On 2020/12/14 18:17, Seino Yuki wrote:
2020-12-09 21:14 に Fujii Masao さんは書きました:
On 2020/12/09 20:42, Li Japin wrote:
Hi,
On Dec 9, 2020, at 6:37 PM, Seino Yuki mailto:sein...@oss.nttdata.com>> wrote:
2020-12-01 01:04 に Fujii Masao さんは書きました:
On 2020/11/30 23:05, Seino Yuki wrote:
2
On 2020/12/14 14:36, Bharath Rupireddy wrote:
On Mon, Dec 14, 2020 at 9:38 AM Fujii Masao mailto:masao.fu...@oss.nttdata.com>> wrote:
> On 2020/12/12 15:05, Bharath Rupireddy wrote:
> > On Sat, Dec 12, 2020 at 12:19 AM Fujii Masao mailto:masao.fu...@oss.nttdata.com>
On 2020/12/14 21:31, Fujii Masao wrote:
On 2020/12/05 12:38, Masahiko Sawada wrote:
On Fri, Dec 4, 2020 at 7:22 PM Drouvot, Bertrand wrote:
Hi,
On 12/4/20 2:21 AM, Fujii Masao wrote:
On 2020/12/04 9:28, Masahiko Sawada wrote:
On Fri, Dec 4, 2020 at 2:54 AM Fujii Masao
wrote:
On
On 2020/12/15 0:49, Drouvot, Bertrand wrote:
Hi,
On 12/14/20 4:20 PM, Fujii Masao wrote:
CAUTION: This email originated from outside of the organization. Do not click
links or open attachments unless you can confirm the sender and know the
content is safe.
On 2020/12/14 21:31, Fujii
On 2020/12/15 1:40, Bharath Rupireddy wrote:
On Mon, Dec 14, 2020, 9:47 PM Bharath Rupireddy
wrote:
On Mon, Dec 14, 2020 at 8:03 PM Fujii Masao wrote:
We will not output if the invalidated entry has no active connection[2], so if we
fix the connection leak issue with the above discussed
On 2020/12/15 12:04, Kyotaro Horiguchi wrote:
At Tue, 15 Dec 2020 02:00:21 +0900, Fujii Masao
wrote in
Thanks for the review! I'm thinking to wait half a day before
commiting
the patch just in the case someone may object the patch.
Sorry for coming late. I have looked only the l
On 2020/12/15 15:40, Fujii Masao wrote:
On 2020/12/15 12:04, Kyotaro Horiguchi wrote:
At Tue, 15 Dec 2020 02:00:21 +0900, Fujii Masao
wrote in
Thanks for the review! I'm thinking to wait half a day before
commiting
the patch just in the case someone may object the patch.
Sorr
On 2020/11/04 18:06, Fujii Masao wrote:
On 2020/10/29 15:21, Fujii Masao wrote:
On 2020/10/07 11:30, Bharath Rupireddy wrote:
On Tue, Oct 6, 2020 at 11:41 AM Bharath Rupireddy
wrote:
On Tue, Oct 6, 2020 at 11:20 AM Fujii Masao wrote:
+1 Or it's also ok to make each
On 2020/12/16 16:24, Kyotaro Horiguchi wrote:
At Tue, 15 Dec 2020 23:10:28 +0900, Fujii Masao
wrote in
I pushed the following two patches.
- v1-use-standard-SIGHUP-hanlder-in-syslogger-process.patch
- v1-use-MyLatch-and-standard-SIGHUP-handler-in-startup-process.patch
As I told in other
patch implimenting this.
Thought?
Regards,
[1] https://postgr.es/m/9a60178c-a853-1440-2cdc-c3af916cf...@amazon.com
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
diff --git a/src/backend/storage/ipc/standby.c
b/src/backend/storag
:49, Fujii Masao mailto:masao.fu...@oss.nttdata.com>>:
After doing this procedure, you can see the startup process and backend
wait for the table lock each other, i.e., deadlock. But this deadlock
remains
even after deadlock_timeout passes.
This seems a bug to me
ls to interrupt that wait. Also a signal sent by this timeout
doesn't interrupt poll() used in ProcWaitForSignal(), on all platforms.
So I think that StandbyLockTimeoutHandler() should do SetLatch(MyLatch)
so that the timeout can interrupt ProcWaitForSignal() even in those cases.
Thought?
Regards,
On 2020/12/16 18:12, Fujii Masao wrote:
On 2020/12/16 16:24, Kyotaro Horiguchi wrote:
At Tue, 15 Dec 2020 23:10:28 +0900, Fujii Masao
wrote in
I pushed the following two patches.
- v1-use-standard-SIGHUP-hanlder-in-syslogger-process.patch
- v1-use-MyLatch-and-standard-SIGHUP-handler-in
On 2020/12/17 11:04, Fujii Masao wrote:
Hi,
When the startup process needs to wait for recovery conflict on lock,
STANDBY_LOCK_TIMEOUT is enabled to interrupt ProcWaitForSignal()
if necessary. If this timeout happens, StandbyLockTimeoutHandler() is
called and this function does nothing as
On 2020/12/17 22:59, Seino Yuki wrote:
2020-12-14 23:01 に Fujii Masao さんは書きました:
On 2020/12/14 18:17, Seino Yuki wrote:
2020-12-09 21:14 に Fujii Masao さんは書きました:
On 2020/12/09 20:42, Li Japin wrote:
Hi,
On Dec 9, 2020, at 6:37 PM, Seino Yuki mailto:sein...@oss.nttdata.com>> wrote:
On 2020/12/17 18:45, Fujii Masao wrote:
On 2020/12/17 11:04, Fujii Masao wrote:
Hi,
When the startup process needs to wait for recovery conflict on lock,
STANDBY_LOCK_TIMEOUT is enabled to interrupt ProcWaitForSignal()
if necessary. If this timeout happens, StandbyLockTimeoutHandler() is
On 2020/12/17 2:15, Fujii Masao wrote:
On 2020/12/16 23:28, Drouvot, Bertrand wrote:
Hi,
On 12/16/20 2:36 PM, Victor Yegorov wrote:
*CAUTION*: This email originated from outside of the organization. Do not click
links or open attachments unless you can confirm the sender and know the
On 2020/12/19 1:43, Drouvot, Bertrand wrote:
Hi,
On 12/18/20 10:35 AM, Fujii Masao wrote:
CAUTION: This email originated from outside of the organization. Do not click
links or open attachments unless you can confirm the sender and know the
content is safe.
On 2020/12/17 2:15, Fujii
On 2020/12/22 10:25, Masahiko Sawada wrote:
On Fri, Dec 18, 2020 at 6:36 PM Fujii Masao wrote:
On 2020/12/17 2:15, Fujii Masao wrote:
On 2020/12/16 23:28, Drouvot, Bertrand wrote:
Hi,
On 12/16/20 2:36 PM, Victor Yegorov wrote:
*CAUTION*: This email originated from outside of the
On 2020/12/22 20:42, Fujii Masao wrote:
On 2020/12/22 10:25, Masahiko Sawada wrote:
On Fri, Dec 18, 2020 at 6:36 PM Fujii Masao wrote:
On 2020/12/17 2:15, Fujii Masao wrote:
On 2020/12/16 23:28, Drouvot, Bertrand wrote:
Hi,
On 12/16/20 2:36 PM, Victor Yegorov wrote:
*CAUTION
rontend (F) and a backend (B)" into the description about each message
format for START_REPLICATION.
[1]
https://www.postgresql.org/docs/devel/protocol-message-formats.html
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2020/12/23 11:08, Li Japin wrote:
On Dec 22, 2020, at 11:13 PM, Fujii Masao mailto:masao.fu...@oss.nttdata.com>> wrote:
‘B’ means a backend and ‘F’ means a frontend. Maybe as [1] does, we should
add the note like "Each is marked to indicate that it can be sent by
a fronten
On 2020/12/23 19:28, Masahiko Sawada wrote:
On Tue, Dec 22, 2020 at 11:58 PM Fujii Masao
wrote:
On 2020/12/22 20:42, Fujii Masao wrote:
On 2020/12/22 10:25, Masahiko Sawada wrote:
On Fri, Dec 18, 2020 at 6:36 PM Fujii Masao wrote:
On 2020/12/17 2:15, Fujii Masao wrote:
On 2020
necessary
scan of the hashtable during COMMIT of transaction not accessing to
foreign servers. Attached is the POC patch that I'm thinking. Thought?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
diff --git a/contrib/
On 2020/12/23 23:40, Bharath Rupireddy wrote:
On Wed, Dec 23, 2020 at 7:31 PM Fujii Masao wrote:
I agree to make pgfdw_xact_callback() close the connection when
entry->invalidated == true. But I think that it's better to get rid of
have_invalid_connections flag and make pgfdw_inval_
Error 1
make[1]: *** [check-recovery-recurse] Error 2
make[1]: *** Waiting for unfinished jobs
t/070_dropuser.pl ..... ok
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2020/12/24 15:42, Bharath Rupireddy wrote:
On Thu, Dec 24, 2020 at 7:21 AM Fujii Masao wrote:
On 2020/12/23 23:40, Bharath Rupireddy wrote:
On Wed, Dec 23, 2020 at 7:31 PM Fujii Masao wrote:
I agree to make pgfdw_xact_callback() close the connection when
entry->invalidated == t
On 2020/12/24 23:30, Bharath Rupireddy wrote:
On Thu, Dec 24, 2020 at 7:43 PM Fujii Masao wrote:
Even when we're in the midst of transaction, if that transaction has not used
the cached connections yet, we close them immediately. So, to make the
comment more precise, what about updatin
On 2020/12/25 12:03, Kyotaro Horiguchi wrote:
Thank you for looking this.
At Thu, 24 Dec 2020 15:33:04 +0900, Fujii Masao
wrote in
When I applied two patches in the master branch and
ran "make check-world", I got the following error.
== creating database "con
On 2020/12/24 23:45, Fujii Masao wrote:
On 2020/12/24 23:30, Bharath Rupireddy wrote:
On Thu, Dec 24, 2020 at 7:43 PM Fujii Masao wrote:
Even when we're in the midst of transaction, if that transaction has not used
the cached connections yet, we close them immediately. So, to mak
On 2021/01/04 12:06, Kyotaro Horiguchi wrote:
At Sat, 26 Dec 2020 02:15:06 +0900, Fujii Masao
wrote in
On 2020/12/25 12:03, Kyotaro Horiguchi wrote:
Thank you for looking this.
At Thu, 24 Dec 2020 15:33:04 +0900, Fujii Masao
wrote in
When I applied two patches in the master branch and
On 2020/12/25 13:16, Kyotaro Horiguchi wrote:
At Wed, 23 Dec 2020 21:42:47 +0900, Fujii Masao
wrote in
you. Attached
is the updated of the patch. What about this version?
The patch contains a hunk in the following structure.
+ if (got_standby_lock_timeout)
+ goto
ith a list of cursors and one of ABSOLUTE,
BACKWARD, FORWARD, RELATIVE, ALL,
+* NEXT, PRIOR, FIRST, LAST, FROM, IN
*/
Maybe I think the commend should say:
+* Complete FETCH with one of ABSOLUTE, BACKWARD, FORWARD,
RELATIVE, ALL,
+* NEXT, PRIOR, FIRST, LAST, FROM, IN, and a list
wal.html#GUC-RECOVERY-TARGET-TIMELINE>.
You cannot recover into timelines that branched off earlier than the base backup." [1][2]
Here is an attempt to fix that.
Thanks for the patch! This looks good to me. Barring any objection, I will
commit it.
Regards,
--
Fujii Masao
Advanced Comp
On 2021/01/06 11:13, Masahiko Sawada wrote:
On Tue, Jan 5, 2021 at 6:08 PM Fujii Masao wrote:
+ COMPLETE_WITH_QUERY(Query_for_list_of_cursors
+ " UNION SELECT
On 2021/01/06 3:01, Fujii Masao wrote:
On 2021/01/05 20:18, Benoit Lobréau wrote:
Hi,
It seems like this part of the documentation was not updated after changing the
default value of recovery_target_timeline to latest in v12.
"The default behavior of recovery is to recover alon
On 2021/01/06 11:48, Masahiko Sawada wrote:
On Tue, Jan 5, 2021 at 3:26 PM Fujii Masao wrote:
On 2020/12/25 13:16, Kyotaro Horiguchi wrote:
At Wed, 23 Dec 2020 21:42:47 +0900, Fujii Masao
wrote in
you. Attached
is the updated of the patch. What about this version?
The patch
On 2020/12/15 0:20, Fujii Masao wrote:
On 2020/12/14 21:31, Fujii Masao wrote:
On 2020/12/05 12:38, Masahiko Sawada wrote:
On Fri, Dec 4, 2020 at 7:22 PM Drouvot, Bertrand wrote:
Hi,
On 12/4/20 2:21 AM, Fujii Masao wrote:
On 2020/12/04 9:28, Masahiko Sawada wrote:
On Fri, Dec 4
URSOR");
+ /*
+* Complete DECLARE with one of BINARY, INSENSITIVE, SCROLL,
+* NO SCROLL, and CURSOR. The tail doesn't match any keywords for
+* DECLARE, assume we want options.
+*/
+ else if (HeadMatches("DECLARE", MatchAny, "*") &&
+TailMatches(MatchAnyExcept("CURSOR|WITH|WITHOUT|HOLD|FOR")))
+ COMPLETE_WITH("BINARY", "INSENSITIVE", "SCROLL", "NO SCROLL",
+ "CURSOR");
This change seems to cause "DECLARE ... CURSOR FOR SELECT " to
unexpectedly output BINARY, INSENSITIVE, etc.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2021/01/05 17:26, Kyotaro Horiguchi wrote:
At Mon, 4 Jan 2021 19:00:21 +0900, Fujii Masao
wrote in
On 2021/01/04 12:06, Kyotaro Horiguchi wrote:
At Sat, 26 Dec 2020 02:15:06 +0900, Fujii Masao
wrote in
On 2020/12/25 12:03, Kyotaro Horiguchi wrote:
The attached is the fixed
r function dblink_get_connections() does that. But
isn't it more convenient to make that return the set of records?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2021/01/07 12:42, Masahiko Sawada wrote:
On Thu, Jan 7, 2021 at 10:59 AM Fujii Masao wrote:
On 2021/01/07 10:01, Masahiko Sawada wrote:
On Wed, Jan 6, 2021 at 3:37 PM wrote:
+#define Query_for_list_of_cursors \
+" SELECT name FROM pg_cursors"\
This query should be the
On 2021/01/07 17:28, shinya11.k...@nttdata.com wrote:
On Thu, Jan 7, 2021 at 1:30 PM Fujii Masao
wrote:
On 2021/01/07 12:42, Masahiko Sawada wrote:
On Thu, Jan 7, 2021 at 10:59 AM Fujii Masao
wrote:
On 2021/01/07 10:01, Masahiko Sawada wrote:
On Wed, Jan 6, 2021 at 3:37 PM wrote
On 2021/01/07 22:39, Drouvot, Bertrand wrote:
Hi,
On 1/6/21 6:31 PM, Fujii Masao wrote:
CAUTION: This email originated from outside of the organization. Do not click
links or open attachments unless you can confirm the sender and know the
content is safe.
On 2020/12/15 0:20, Fujii
On 2020/12/15 2:00, Fujii Masao wrote:
On 2020/12/15 0:49, Drouvot, Bertrand wrote:
Hi,
On 12/14/20 4:20 PM, Fujii Masao wrote:
CAUTION: This email originated from outside of the organization. Do not click
links or open attachments unless you can confirm the sender and know the
content
On 2021/01/07 17:21, Bharath Rupireddy wrote:
On Thu, Jan 7, 2021 at 9:49 AM Fujii Masao wrote:
On 2021/01/05 16:56, Bharath Rupireddy wrote:
Attaching v8 patch set. Hopefully, cf bot will be happy with v8.
Please consider the v8 patch set for further review.
-DATA = postgres_fdw--1.0
On 2021/01/08 11:17, Kyotaro Horiguchi wrote:
At Fri, 8 Jan 2021 01:32:11 +0900, Fujii Masao
wrote in
Attached is the updated version of the patch. This can be applied to
current master.
With the patch, for example, if the startup process waited longer than
deadlock_timeout for the
On 2021/01/08 14:02, Drouvot, Bertrand wrote:
Hi,
On 1/7/21 4:51 PM, Fujii Masao wrote:
Thanks for the review! I pushed the latest patch.
Thanks all of you for your precious help on this patch!
The original idea behind this thread has been split into 3 pieces.
Pieces 1
rming the commit time and doing the commit
on each node.
I don't intend to offend Clock-SI and any activities based on that. OTOH,
I'm now wondering if it's worth considering another approach for global
transaction support, while I'm still interested in Clock-SI technically.
On 2021/02/10 10:43, Fujii Masao wrote:
On 2021/02/09 23:31, torikoshia wrote:
On 2021-02-09 22:54, Fujii Masao wrote:
On 2021/02/09 19:11, Fujii Masao wrote:
On 2021/02/09 18:13, Fujii Masao wrote:
On 2021/02/09 17:48, torikoshia wrote:
On 2021-02-05 18:49, Fujii Masao wrote:
On
be problematic? If so, the variable
needs to be initialized in WalRcvShmemInit(), instead.
BTW, the recent commit 46d6e5f567 has the similar issue. The variable
that commit added is initialized in InitProcess(), but maybe should be done
in InitProcGlobal() or elsewhere.
Regards,
--
Fujii Masao
is the updated version of the patch.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
diff --git a/src/backend/replication/walreceiver.c
b/src/backend/replication/walreceiver.c
index 723f513d8b..316640c275 100644
--- a/src/bac
On 2021/02/15 15:17, Fujii Masao wrote:
On 2021/02/10 10:43, Fujii Masao wrote:
On 2021/02/09 23:31, torikoshia wrote:
On 2021-02-09 22:54, Fujii Masao wrote:
On 2021/02/09 19:11, Fujii Masao wrote:
On 2021/02/09 18:13, Fujii Masao wrote:
On 2021/02/09 17:48, torikoshia wrote:
On
On 2021/02/16 15:50, Michael Paquier wrote:
On Tue, Feb 16, 2021 at 12:43:42PM +0900, Fujii Masao wrote:
On 2021/02/16 6:28, Andres Freund wrote:
So what? It's just about free to initialize a spinlock, whether it's
using the fallback implementation or not. Initializing upon walsend
On 2021/02/17 13:52, Michael Paquier wrote:
On Tue, Feb 16, 2021 at 11:47:52PM +0900, Fujii Masao wrote:
On 2021/02/16 15:50, Michael Paquier wrote:
+ /*
+* Read "writtenUpto" without holding a spinlock. So it may not be
+* consistent with other WAL receiver's s
On 2021/02/18 16:26, torikoshia wrote:
On 2021-02-16 16:59, Fujii Masao wrote:
On 2021/02/15 15:17, Fujii Masao wrote:
On 2021/02/10 10:43, Fujii Masao wrote:
On 2021/02/09 23:31, torikoshia wrote:
On 2021-02-09 22:54, Fujii Masao wrote:
On 2021/02/09 19:11, Fujii Masao wrote:
On
.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
iver process running
at that moment. IOW, it seems strange that some values show dynamic
stats and the others show collected stats, even though they are in
the same view pg_stat_wal_receiver. Thought?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2021/02/24 12:59, Fujii Masao wrote:
On 2021/02/23 1:44, Muhammad Usama wrote:
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation
ws.
We can replace this part with "user", I think.
Good catch!
fprintf(output, _(" -U, --username=USERNAME database user name (default:
\"%s\")\n"), env);
We can simplify the code more and remove "env = user"
by just using "user" inste
On 2021/03/03 14:33, Masahiro Ikeda wrote:
On 2021-02-24 16:14, Fujii Masao wrote:
On 2021/02/15 11:59, Masahiro Ikeda wrote:
On 2021-02-10 00:51, David G. Johnston wrote:
On Thu, Feb 4, 2021 at 4:45 PM Masahiro Ikeda
wrote:
I pgindented the patches.
... XLogWrite, which is invoked
On 2021/03/03 12:27, miyake_kouta wrote:
2021-03-03 00:09, Fujii Masao wrote:
We can simplify the code more and remove "env = user"
by just using "user" instead of "env" in the above?
Thank you for your comment.
I updated my patch and replaced "env"
og_page() may cause those functions to get
the same issue.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
as changed very much?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
pshot() call just
above where you're ressetting ThisTimeLineID also write a WAL record
with incorrect timeline?
Agreed.
Right.
On Wed, Mar 3, 2021 at 1:04 AM Fujii Masao wrote:
Even better, can we avoid setting ThisTimeLineID in XlogReadTwoPhaseData() in
the first place?
Or isn&#
On 2021/03/03 17:05, Nitin Jadhav wrote:
Hi,
I have reviewed the patch and it looks good to me.
Thanks! Pushed.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2021/03/04 16:14, Masahiro Ikeda wrote:
On 2021-03-03 20:27, Masahiro Ikeda wrote:
On 2021-03-03 16:30, Fujii Masao wrote:
On 2021/03/03 14:33, Masahiro Ikeda wrote:
On 2021-02-24 16:14, Fujii Masao wrote:
On 2021/02/15 11:59, Masahiro Ikeda wrote:
On 2021-02-10 00:51, David G
1 - 100 of 1694 matches
Mail list logo
