t the existence of the trigger file immdiately after
it's created?
Regards,
--
Fujii Masao
NTT DATA CORPORATION
Advanced Platform Technology Group
Research and Development Headquarters
On 2020/04/01 3:42, Julien Rouhaud wrote:
On Wed, Apr 01, 2020 at 02:43:10AM +0900, Fujii Masao wrote:
On 2020/03/31 16:33, Julien Rouhaud wrote:
v12 attached!
Thanks for updating the patch! The patch looks good to me.
I applied minor and cosmetic changes into the patch. Attached is
the paused state. It might be problematic to end the paused
state silently? So, to make the situation less confusing, what about
emitting a log message when ending the paused state because of
the promotion?
Regards,
--
Fujii Masao
NTT DATA CORPORATION
Advanced Platform Technology Group
Research and Development Headquarters
g thst every WAL file might be ok. I'm not sure
if this is really improvement or not, though...
Regards,
--
Fujii Masao
NTT DATA CORPORATION
Advanced Platform Technology Group
Research and Development Headquarters
On 2020/04/01 19:37, Fujii Masao wrote:
On 2020/04/01 18:56, movead...@highgo.ca wrote:
>This happens because the startup process detects the trigger file
after pg_wal_replay_pause() succeeds, and then make the recovery
get out of the paused state.
Yes that is.
>It mi
On 2020/03/30 20:10, Masahiko Sawada wrote:
On Fri, 27 Mar 2020 at 17:54, Fujii Masao wrote:
On 2020/03/04 14:31, Masahiko Sawada wrote:
On Wed, 4 Mar 2020 at 13:48, Fujii Masao wrote:
On 2020/03/04 13:27, Michael Paquier wrote:
On Wed, Mar 04, 2020 at 01:13:19PM +0900, Masahiko
#x27;t this indent look strange? IMO no indent for buffer usage is
necessary when the format is either json, xml, and yaml. This looks
better at least for me. OTOH, in text format, it seems better to indent
the buffer usage for more readability. Thought?
The patch changes the code so that "es-&g
On 2020/04/01 18:19, Fujii Masao wrote:
On 2020/04/01 3:42, Julien Rouhaud wrote:
On Wed, Apr 01, 2020 at 02:43:10AM +0900, Fujii Masao wrote:
On 2020/03/31 16:33, Julien Rouhaud wrote:
v12 attached!
Thanks for updating the patch! The patch looks good to me.
I applied minor and
On 2020/04/02 3:47, Julien Rouhaud wrote:
On Wed, Apr 1, 2020 at 7:51 PM Fujii Masao wrote:
On 2020/03/31 10:31, Justin Pryzby wrote:
On Wed, Jan 29, 2020 at 12:15:59PM +0100, Julien Rouhaud wrote:
Rebase due to conflict with 3ec20c7091e97.
This is failing to apply probably since
On 2020/04/02 14:25, Masahiko Sawada wrote:
On Wed, 1 Apr 2020 at 22:32, Fujii Masao wrote:
On 2020/03/30 20:10, Masahiko Sawada wrote:
On Fri, 27 Mar 2020 at 17:54, Fujii Masao wrote:
On 2020/03/04 14:31, Masahiko Sawada wrote:
On Wed, 4 Mar 2020 at 13:48, Fujii Masao wrote
On 2020/04/02 15:01, Julien Rouhaud wrote:
On Thu, Apr 02, 2020 at 01:05:56PM +0900, Fujii Masao wrote:
On 2020/04/02 3:47, Julien Rouhaud wrote:
On Wed, Apr 1, 2020 at 7:51 PM Fujii Masao wrote:
On 2020/03/31 10:31, Justin Pryzby wrote:
On Wed, Jan 29, 2020 at 12:15:59PM +0100
On 2020/04/02 15:54, Masahiko Sawada wrote:
On Thu, 2 Apr 2020 at 15:34, Fujii Masao wrote:
On 2020/04/02 14:25, Masahiko Sawada wrote:
On Wed, 1 Apr 2020 at 22:32, Fujii Masao wrote:
On 2020/03/30 20:10, Masahiko Sawada wrote:
On Fri, 27 Mar 2020 at 17:54, Fujii Masao wrote
On 2020/04/02 15:52, Fujii Masao wrote:
On 2020/04/02 15:01, Julien Rouhaud wrote:
On Thu, Apr 02, 2020 at 01:05:56PM +0900, Fujii Masao wrote:
On 2020/04/02 3:47, Julien Rouhaud wrote:
On Wed, Apr 1, 2020 at 7:51 PM Fujii Masao wrote:
On 2020/03/31 10:31, Justin Pryzby wrote:
On
On 2020/04/02 16:12, Fujii Masao wrote:
On 2020/04/02 15:54, Masahiko Sawada wrote:
On Thu, 2 Apr 2020 at 15:34, Fujii Masao wrote:
On 2020/04/02 14:25, Masahiko Sawada wrote:
On Wed, 1 Apr 2020 at 22:32, Fujii Masao wrote:
On 2020/03/30 20:10, Masahiko Sawada wrote:
On Fri, 27
will be merged to one of the next minor releases?
This doesn't seem a bug, so I'm thinking to merge this to next *major*
version release, i.e., v13.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
diff --git a/src
about
removing it?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
on when:
* new GUC is >= 0, and
This can cause the timeout to be enabled even when no remote transaction is
started?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
of auxiliary process like
archiver is specified, probably the function always reports the same result,
doesn't it? Because, for example, the archiver always logs its backtrace in
HandlePgArchInterrupts().
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Dev
ng OS commands but
allow them to create/drop roles. Does the proposed patch fix also this issue?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
ul to investigate where
each remote transactions came from. Thought?
Patch attached.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATIONdiff --git a/contrib/postgres_fdw/option.c b/contrib/postgres_fdw/option.c
index fc3ce
x27;d with LOG level instead of LOG_SERVER_ONLY. Is this a bug, and shouldn't
we use LOG_SERVER_ONLY level to log that message? Patch attached.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATIONdiff --git a/src/backend/utils/
On 2022/01/26 14:27, Bharath Rupireddy wrote:
On Wed, Jan 26, 2022 at 10:46 AM Bharath Rupireddy
wrote:
On Wed, Jan 26, 2022 at 9:48 AM Fujii Masao wrote:
Hi,
pg_log_backend_memory_contexts() should be designed not to send the messages about the
memory contexts to the client
On 2022/01/26 14:28, torikoshia wrote:
On 2022-01-26 13:17, Fujii Masao wrote:
Hi,
pg_log_backend_memory_contexts() should be designed not to send the
messages about the memory contexts to the client regardless of
client_min_messages. But I found that the message "logging memory
contex
On 2022/01/27 17:10, Kyotaro Horiguchi wrote:
At Tue, 25 Jan 2022 16:02:39 +0900, Fujii Masao
wrote in
Hi,
Commit 6e0cb3dec1 allowed postgres_fdw.application_name to include
escape sequences %a (application name), %d (database name), %u (user
name) and %p (pid). In addition to them, I&#
. So how
about something like the following messages?
LOG: could not log the query plan
DETAIL: query plan cannot be logged while page level lock is being held
HINT: Try pg_log_query_plan() after a few
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2022/01/27 12:45, Fujii Masao wrote:
Thanks for the review! So barring any objection, I will commit the patch and
backport it to v14 where pg_log_backend_memory_contexts() is added.
Pushed. Thanks!
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development
mit exceeded" error.
To avoid this, shouldn't we make ProcessLogQueryPlanInterrupt() do nothing and return
immediately, if it's called during another ProcessLogQueryPlanInterrupt()?
pg_log_backend_memory_contexts() also might have the same issue.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
d earlierly in the log
message? Since ordinally users would be more interested in the information
about I/O by checkpoint, the information for LSN should be placed later? Sorry
if this was already discussed.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2022/02/01 13:01, Bharath Rupireddy wrote:
On Tue, Feb 1, 2022 at 9:10 AM Fujii Masao wrote:
The order of arguments for LSN seems wrong.
LSN_FORMAT_ARGS(ControlFile->checkPoint) should be specified ahead of
LSN_FORMAT_ARGS(ControlFile->checkPointCopy.redo)?
Thanks. Cor
ork there).
I agree to the discussion. Can't we use other mechanism here to get
rid of the Lockpage()?
I have no good idea for that yet, but I agree it's better to get rid of page
level lock.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Developm
return it. Is this assumption valid for
all the FDW?
How about making FDW trigger a query cancel interrupt by signaling SIGINT to
the backend, instead?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
ilar idea was proposed at [1] before, but seems
"location" was left as it was.
[1]
https://postgr.es/m/20487.1494514...@sss.pgh.pa.us
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2022/02/02 23:46, Bharath Rupireddy wrote:
On Tue, Feb 1, 2022 at 9:39 PM Fujii Masao wrote:
I found that CreateRestartPoint() already reported the redo lsn as follows
after emitting the restartpoint log message. To avoid duplicated logging of the
same information, we should update
parameter already dropped, from the
comment. OTOH, I found CheckIndexCompatible() now has "oldId" parameter but there is no
comment about it though there are comments about other parameters. Isn't it better to add the
comment about "oldId"?
Regards,
--
Fujii Masao
A
have not found
that yet.
If we update checkpoint and REDO LSN at pg_control in that case, we also need
to update min recovery point at pg_control? Otherwise the min recovery point at
pg_control still indicates the old LSN that previous restart point set.
Regards,
--
Fujii Masao
Advanced Compu
ACTIONID((U64FromFullTransactionId(fxid1) <
U64FromFullTransactionId(fxid2)) ? fxid1 : fxid2);
Shouldn't we use FullTransactionIdPrecedes() to compare those two fxid values
here, instead?
Could you add the regression tests for those min() and max() functions for xid8?
Regards,
--
Fujii Masao
Ad
neither minimum nor maximum xid8 ones, for example, '42'::xid8.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
ill start from that
redo location, for example, ISTM that we can safely delete old WAL files prior to the redo location
as the "remaining tasks". Thought?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
sequences %c
and %C.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATIONdiff --git a/contrib/postgres_fdw/option.c b/contrib/postgres_fdw/option.c
index fc3ce6a53a..af38e956e7 100644
--- a/contrib/postgres_fdw/option.c
+++ b
then
return 30;
end;
$$ language plpgsql;
select pg_sleep(test());
-CREATE ROLE regress_log_memory;
+CREATE ROLE regress_log;
Isn't this name too generic? How about regress_log_function, for example?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
n parallel_commit is enabled, since there can be a time window
between
* sending query and receiving result, we can expect data is already
available
* from the socket. In this case we try to consume it at first
Otherwise..
*/
if (consumeInput && !PQconsumeInp
0x000107ae20d9 main + 809
23 libdyld.dylib 0x7fff2045cf3d start + 1
24 ??? 0x0003 0x0 + 3
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
NULL, NULL);
+ else if ((wakeEvents & WL_POSTMASTER_DEATH) && IsUnderPostmaster)
+ AddWaitEventToSet(set, WL_POSTMASTER_DEATH, PGINVALID_SOCKET,
+
+1
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
, ('-1'::xid8);
Since "::xid8" is not necessary here, I got rid of it from the above query.
I also merged this xid8_tab and the existing xid8_t1 table, to reduce the
number of table creation.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Developm
On 2022/02/08 18:43, Ken Kato wrote:
On 2022-02-08 15:34, Fujii Masao wrote:
Thanks for updating the patch! It basically looks good to me. I
applied the following small changes to the patch. Updated version of
the patch attached. Could you review this version?
Thank you for the patch!
It
On 2022/02/09 8:49, Ken Kato wrote:
On 2022-02-08 23:16, Fujii Masao wrote:
If you want to avoid the line longer than 80 columns, you should break
it into two or more rather than remove the test code, I think. What to
test is more important than formatting.
Also the following descriptions
On 2022/02/09 13:04, Kyotaro Horiguchi wrote:
At Wed, 09 Feb 2022 12:04:51 +0900 (JST), Kyotaro Horiguchi
wrote in
At Wed, 9 Feb 2022 11:01:57 +0900, Fujii Masao
wrote in
Agreed. So barring any objection, I will commit that patch.
Sorry for being late, but I don't like the fun
sequences.
Attached is the updated version of the patch.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATIONdiff --git a/contrib/postgres_fdw/expected/postgres_fdw.out
b/contrib/postgres_fdw/expected/postgres_fdw.out
index b2e02caefe
nd as far as I tested, currently LockBufferForCleanup() is not called in
critical section. Right?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
fixing the bug all the branches
at first, then apply this patch in the master to improve the code?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
ions opened on a foreign server in a local
+ (sub)transaction in parallel when the local (sub)transaction commits.
"a foreign server" should be "foreign servers"?
"in a local (sub)transaction" part seems not to be necessary.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2022/02/15 8:52, r.takahash...@fujitsu.com wrote:
Hi Fujii san,
Thank you for updating the patch.
I have no additional comments.
Thanks for the review! Pushed.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2022/02/07 19:14, Yugo NAGATA wrote:
Agreed. I updated the patch to add a comment about 'oldId'.
Thanks for updating the patch! I slightly modified the patch and pushed it.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarter
of an overhead that many FDW registers timeout
and call setitimer() many times. Is it too overcautious?
Isn't it a very special case where many FDWs use their own user timeouts? Could
you tell me the assumption that you're thinking, especially how many FDWs are
working?
Regards,
--
Fujii
ke to drop that before release
like we agree to drop unused TRUNCATE_REL_CONTEXT_CASCADING.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
TITY should not work since foreign tables
don't have an identity-sequence. However, this we might be able to
push down the options since it affects only the target table.
+1
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2021/04/16 9:15, Bharath Rupireddy wrote:
On Thu, Apr 15, 2021 at 8:19 PM Fujii Masao wrote:
On 2021/04/14 12:54, Bharath Rupireddy wrote:
IMHO, we can push all the TRUNCATE options (ONLY, RESTRICTED, CASCADE,
RESTART/CONTINUE IDENTITY), because it doesn't have any major
chal
On 2021/04/19 8:36, Justin Pryzby wrote:
Reviewing this change which was committed last year as
321fa6a4a26c9b649a0fbec9fc8b019f19e62289
On Fri, Jul 03, 2020 at 03:57:38PM +0900, Fujii Masao wrote:
On 2020/07/03 13:05, Pavel Stehule wrote:
pá 3. 7. 2020 v 4:39 odesílatel Fujii Masao
mary is low,
pg_basebackup may need to wait a long time for all WAL files required for
the backup to be archived. It may be useful to run pg_switch_wal
on the primary in order to trigger an immediate WAL file switch and archiving.
---
Regards,
--
Fujii Masao
Advanced Compu
quot; at the above because
"similar" sounds a bit unclear in this case?
It's better to use "entries" rather than "entry" at the above?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2021/04/16 14:20, Kyotaro Horiguchi wrote:
At Fri, 16 Apr 2021 11:54:16 +0900, Fujii Masao
wrote in
On 2021/04/16 9:15, Bharath Rupireddy wrote:
On Thu, Apr 15, 2021 at 8:19 PM Fujii Masao
wrote:
On 2021/04/14 12:54, Bharath Rupireddy wrote:
IMHO, we can push all the TRUNCATE
On 2021/04/16 15:13, Bharath Rupireddy wrote:
On Fri, Apr 16, 2021 at 8:24 AM Fujii Masao wrote:
We are still discussing whether RESTRICT option should be pushed down to
a foreign data wrapper. But ISTM at least we could reach the consensus about
the drop of extra information for each
. But what about using "identical" instead of "similar"
because pg_stat_statements docs already uses "identical" in some places?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
pg_stat_statements docs. The following
description in the docs should be updated so that toplevel is included?
This view contains one row for each distinct database ID, user ID and query ID
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
primary.
--
pg_basebackup cannot force the standby to switch to
a new WAL file at the end of backup.
--
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
diff --git a/doc/src/sgml/ref
On 2021/04/22 11:19, Kyotaro Horiguchi wrote:
At Thu, 22 Apr 2021 10:56:10 +0900, Fujii Masao
wrote in
On 2021/04/22 9:25, Kyotaro Horiguchi wrote:
What about the following description?
---
When you are using -X none, if write activity on the primary is low
RUNCATE ONLY tru_ftable;-- truncate both parent and child
SELECT count(*) FROM tru_ftable; -- 0
I added the comment.
Could you review the attached patches?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
diff --git a/
type for those counters. Thought?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2021/04/23 9:26, Masahiro Ikeda wrote:
On 2021/04/23 0:36, Andres Freund wrote:
Hi
On Thu, Apr 22, 2021, at 06:42, Fujii Masao wrote:
On 2021/04/21 18:31, Masahiro Ikeda wrote:
BTW, is it better to change PgStat_Counter from int64 to uint64 because> there
aren't any count
On 2021/04/22 13:25, Kyotaro Horiguchi wrote:
At Thu, 22 Apr 2021 13:06:50 +0900, Fujii Masao
wrote in
Either works for me. I didn't add "()" because I just used the same
description
as that in func.sgml.
it may be useful to run pg_switch_wal on the
prim
On 2021/04/22 18:23, Julien Rouhaud wrote:
On Thu, Apr 22, 2021 at 12:28:11AM +0900, Fujii Masao wrote:
I found another small issue in pg_stat_statements docs. The following
description in the docs should be updated so that toplevel is included?
This view contains one row for each
On 2021/04/23 10:25, Andres Freund wrote:
Hi,
On 2021-04-23 09:26:17 +0900, Masahiro Ikeda wrote:
On 2021/04/23 0:36, Andres Freund wrote:
On Thu, Apr 22, 2021, at 06:42, Fujii Masao wrote:
On 2021/04/21 18:31, Masahiro Ikeda wrote:
BTW, is it better to change PgStat_Counter from int64
On 2021/04/22 17:56, Justin Pryzby wrote:
On Thu, Apr 22, 2021 at 03:36:25PM +0900, Fujii Masao wrote:
diff --git a/doc/src/sgml/fdwhandler.sgml b/doc/src/sgml/fdwhandler.sgml
index 553524553b..69aa66e73e 100644
--- a/doc/src/sgml/fdwhandler.sgml
+++ b/doc/src/sgml/fdwhandler.sgml
On 2021/04/22 20:27, Bharath Rupireddy wrote:
On Thu, Apr 22, 2021 at 12:06 PM Fujii Masao
wrote:
On 2021/04/22 9:39, Bharath Rupireddy wrote:
One comment on truncate_foreign_table_docs_v1.patch:
1) I think it is "to be truncated"
+ rels is a list of Relation
+ data stru
On 2021/04/23 18:46, Magnus Hagander wrote:
On Fri, Apr 23, 2021 at 9:10 AM Fujii Masao wrote:
On 2021/04/22 18:23, Julien Rouhaud wrote:
On Thu, Apr 22, 2021 at 12:28:11AM +0900, Fujii Masao wrote:
I found another small issue in pg_stat_statements docs. The following
description in
On 2021/04/23 19:11, Magnus Hagander wrote:
On Fri, Apr 23, 2021 at 12:04 PM Fujii Masao
wrote:
On 2021/04/23 18:46, Magnus Hagander wrote:
On Fri, Apr 23, 2021 at 9:10 AM Fujii Masao wrote:
On 2021/04/22 18:23, Julien Rouhaud wrote:
On Thu, Apr 22, 2021 at 12:28:11AM +0900, Fujii
On 2021/04/23 19:56, Bharath Rupireddy wrote:
On Fri, Apr 23, 2021 at 1:39 PM Fujii Masao wrote:
+
+ Note that information about ONLY options specified
+ in the original TRUNCATE command is not passed to
I think it is not "information about", no? We just don't p
uch performance risk. Otherwise
we should adopt the latter approach. Or you have the better idea?
Thought?
[1]
https://postgr.es/m/1953aec168224b95b0c962a622bef0794da6ff40.ca...@moonset.ru
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2021/04/26 13:52, Bharath Rupireddy wrote:
On Fri, Apr 23, 2021 at 9:50 PM Fujii Masao wrote:
Thanks for the review! I fixed this.
Thanks for the updated patches.
In docs v4 patch, I think we can combine below two lines into a single line:
+ supported by the foreign data wrapper
On 2021/04/27 15:02, Bharath Rupireddy wrote:
On Tue, Apr 27, 2021 at 11:19 AM Fujii Masao
wrote:
In docs v4 patch, I think we can combine below two lines into a single line:
+ supported by the foreign data wrapper,
see .
You mean "supported by the foreign data wrapper &quo
On 2021/04/26 10:11, Masahiro Ikeda wrote:
On 2021/04/23 16:30, Fujii Masao wrote:
On 2021/04/23 10:25, Andres Freund wrote:
Hi,
On 2021-04-23 09:26:17 +0900, Masahiro Ikeda wrote:
On 2021/04/23 0:36, Andres Freund wrote:
On Thu, Apr 22, 2021, at 06:42, Fujii Masao wrote:
On 2021/04
change only to the master? Even if we should do the back-patch,
we would need to wait until upcoming minor release is done before doing that.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
it be possible to move to a resolution by beta1? The consensus
I can get from the thread is that we should have a tri-value state to
track an extra "auto" for the query ID computation, as proposed by
Alvaro here:
https://www.postgresql.org/message-id/20210426174331.GA19401@alvherre.pgsql
On 2021/04/28 9:10, Masahiro Ikeda wrote:
On 2021/04/27 21:56, Fujii Masao wrote:
On 2021/04/26 10:11, Masahiro Ikeda wrote:
First patch has only the changes for pg_stat_wal view.
("v6-0001-performance-improvements-of-reporting-wal-stats-without-introducing-a-new-variable.
ill review the patch later. I'm ok to discuss that in this thread.
Thanks!
0002 patch looks good to me.
I think we can commit this at first. Barring any objection, I will do that.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
another flag like query_id_wanted
instead of overwriting compute_query_id? If we do this, query id computation is necessary when
"compute_query_id == COMPUTE_QUERY_ID_ON || (compute_query_id == COMPUTE_QUERY_ID_AUTO
&& query_id_wanted)".
Regards,
--
Fujii Masao
Advanced Computing T
On 2021/05/11 18:46, Masahiro Ikeda wrote:
On 2021/05/11 16:44, Fujii Masao wrote:
On 2021/04/28 9:10, Masahiro Ikeda wrote:
On 2021/04/27 21:56, Fujii Masao wrote:
On 2021/04/26 10:11, Masahiro Ikeda wrote:
First patch has only the changes for pg_stat_wal view.
("v6
gh.
If we do this, compute_query_id=auto seems to be similar to huge_pages=try.
When huge_pages=try, whether huge pages is actually used is defined depending
outside PostgreSQL (i.e, OS setting in this case). Neither pg_settings.setting
nor
souce are not changed in that case.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
ry ids are not computed and no queries are tracked by pg_stat_statements.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
he time
when the server process *started* waiting for the lock.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
+ *
+ * The reason the counters are accumulated values is to avoid unexpected
+ * reset because many callers may use them.
Aren't the following comments better?
These counters keep being incremented infinitely, i.e., must never be reset to
zero, so that we can calculate how much the counters are incremented in an
arbitrary period.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
paused' when standby promotion is triggered.
Thought?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
diff --git a/src/backend/access/transam/xlog.c
b/src/backend/access/transam/xlog.c
index 8d163f190f..441a9124cd 100644
On 2021/05/18 9:58, Kyotaro Horiguchi wrote:
At Mon, 17 May 2021 23:29:18 +0900, Fujii Masao
wrote in
If a promotion is triggered while recovery is paused, the paused state
ends
and promotion continues. But currently pg_get_wal_replay_pause_state()
returns 'paused' in that case.
On 2021/05/18 14:53, Dilip Kumar wrote:
On Mon, May 17, 2021 at 7:59 PM Fujii Masao wrote:
If a promotion is triggered while recovery is paused, the paused state ends
and promotion continues. But currently pg_get_wal_replay_pause_state()
returns 'paused' in that case. Isn&#x
.g., "fetch_size '123.456'".
OTOH, since batch_size was added in v14, it has no such issue.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2021/05/18 9:57, Masahiro Ikeda wrote:
On 2021/05/17 22:34, Fujii Masao wrote:
On 2021/05/17 16:39, Masahiro Ikeda wrote:
Thanks for your comments!
+ * is executed, wal records aren't nomally generated (although HOT makes
nomally -> normally?
Yes, fixed.
+ *
On 2021/05/19 11:36, Kyotaro Horiguchi wrote:
At Tue, 18 May 2021 19:46:39 +0530, Bharath Rupireddy
wrote in
On Tue, May 18, 2021 at 7:19 PM Tom Lane wrote:
Fujii Masao writes:
On 2021/05/17 18:58, Bharath Rupireddy wrote:
It looks like the values such as '123.456',
On 2021/05/18 15:46, Michael Paquier wrote:
On Tue, May 18, 2021 at 12:48:38PM +0900, Fujii Masao wrote:
Currently a promotion causes all available WAL to be replayed before
a standby becomes a primary whether it was in paused state or not.
OTOH, something like immediate promotion (i.e
On 2021/05/19 9:53, Kyotaro Horiguchi wrote:
At Tue, 18 May 2021 12:48:38 +0900, Fujii Masao
wrote in
Currently a promotion causes all available WAL to be replayed before
a standby becomes a primary whether it was in paused state or not.
OTOH, something like immediate promotion (i.e
On 2021/05/19 15:25, Kyotaro Horiguchi wrote:
At Wed, 19 May 2021 11:19:13 +0530, Dilip Kumar wrote in
On Wed, May 19, 2021 at 10:16 AM Fujii Masao
wrote:
On 2021/05/18 15:46, Michael Paquier wrote:
On Tue, May 18, 2021 at 12:48:38PM +0900, Fujii Masao wrote:
Currently a promotion
801 - 900 of 1908 matches
Mail list logo
