ach can reduce WAL volume than other approach?
In the PoC patch, to reduce WAL volume more, it might be better to make
nextval_internal() update XactLastRecEnd and assign XID rather than emitting
new WAL record, when SyncRepNeedsWait() returns true.
Regards,
--
Fujii Masao
Advanced Co
back, I'm fine with not having a NULL check since anyway it
bumps into SEGV immediately. In short I'm fine with #3 here.
Yep, let's use #3 approach.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
eloption to 0. OTOH, those who prefer the current
behavior in spite of the risk we're discussing at this thread can set the
reloption to 32 like it is for now, for example.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
7;s better to just provide the convertion
function.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
to call process_pgfdw_appname() in that case.
Right. I removed too much.
Thanks for the check! So I kept the check "*(values[i]) != '\0'" as it is
and pushed the patch. Thanks!
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
42.horikyota@gmail.com
But anyway I want to say thank you for your contribution!
Thanks!
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/postg
the patch. It uses
current_setting('max_identifier_length').
BTW it seems confusing that pg_control_init() (also pg_controldata) and GUC
report different values as max_identifier_length. Probably they should return
the same value such as NAMEDATALEN - 1. But this change might be overkill...
uence page LSN, and flushing
up to that position.
Sounds great, thanks!
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
ng-running
transaction?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
x27;t it enough to
replace the existing int32 option with int64 one? Or how about using
string-type option for very large number like 64-bit XID, like it's done for
recovery_target_xid?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
rverLoop at postmaster.c:1802:7
frame #34: 0x0001103e9e29 postgres`PostmasterMain(argc=3,
argv=0x7fe567405e70) at postmaster.c:1474:11
frame #35: 0x0001102c8b69 postgres`main(argc=3,
argv=0x7fe567405e70) at main.c:198:3
frame #36: 0x7fff2045cf3d libdyld.dylib`start + 1
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
ackendId = proc->backendId;
else
proc = AuxiliaryPidGetProc(pid);
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
nds as an error" in the definition of
MaxBackends?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2022/01/08 1:50, Bharath Rupireddy wrote:
PSA v7 patch.
Thanks for updating the patch!
I applied some cosmetic changes and pushed the patch. Thanks!
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2022/01/06 17:29, Etsuro Fujita wrote:
On Fri, Dec 3, 2021 at 6:07 PM Fujii Masao wrote:
On 2021/11/16 18:55, Etsuro Fujita wrote:
I changed my mind; I’ll update the patch to ignore the error as
before, because 1) as far as I know, there are no reports from the
field concerning that we
they are not
directly related to the improvement of tab-completion.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
applications that don't want to
increase the cache size for some reasons. So IMO it's better to provide the
option to enable/disable that page-lsn approach.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
it is good name. Because that's not
"unsafe" exit. No? Even after this signal handler is triggered, the server is
still running normally and a process that exits will be restarted later. What
about SignalHandlerForNonCrashExit or SignalHandlerForNonFatalExit?
Regards,
--
Fujii Masao
ots of log messages.
I'm going to add documentation and regression tests.
Thanks!
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2021/03/17 12:02, Thomas Munro wrote:
On Tue, Mar 16, 2021 at 9:10 PM Fujii Masao wrote:
Thanks for the patch!
+When set to fsync, which is the default,
+PostgreSQL will recursively open and fsync
+all files in the data directory before crash recovery begins
On 2021/03/17 12:45, Thomas Munro wrote:
On Tue, Mar 16, 2021 at 9:29 PM Fujii Masao wrote:
On 2021/03/16 8:15, Thomas Munro wrote:
I don't want to add a hypothetical sync_after_crash=none, because it
seems like generally a bad idea. We already have a
running-with-scissors mode you
ook the lock on the relation B.
3. backend 1 tries to take the lock on the relation B and is waiting for
the lock to be released.
4. backend 2 accidentally executes pg_wait_for_backend_termination() with
the pid of backend 1, and then is waiting for backend 1 to be terminated.
Regards,
--
Fujii
can be
returned by atoi().
Yes, you're right. I removed that check from the patch.
Attached 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/bin/pgbench/pgbench
ENT_WAL_SENDER_WAIT_WAL should be moved to in Activity.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
%m"?
I confirmed that no error was reported when crash recovery started with
syncfs, in old Linux. I should also confirm that no error is reported in that
case in Linux 5.8+, but I don't have that environement. So I've not tested
this feature in Linux 5.8+
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
the beginning of recovery) without changing the name.
I'm not sure if such cases actually exist, though.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
r them rather than elog()? For example,
ereport(LOG,
(errcode_for_file_access(),
errmsg("could not open \"%s\": %m", path)))
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2021/03/16 18:27, Fujii Masao wrote:
Thanks for the path! LGTM. Barring any objection, I will push the patch.
Pushed. Thanks!
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2021/03/19 11:22, Fujii Masao wrote:
On 2021/03/19 10:37, Thomas Munro wrote:
On Fri, Mar 19, 2021 at 2:16 PM Thomas Munro wrote:
PS: For illustration/discussion, I've also attached a "none" patch. I
also couldn't resist rebasing my "wal" mode patch, wh
be called at subsequent
startup of the stats collector instead of calling it in the handler
at the end? BTW, I found bgworker calls FreeWaitEventSet() via
ShutdownLatchSupport() at its startup. But I'm also not sure if this
is really necessary at the startup...
Regards,
--
Fujii Masao
Adva
On 2021/03/18 18:48, Fujii Masao wrote:
WAIT_EVENT_WAL_RECEIVER_WAIT_START is waiting for waiting for starup
process to kick me. So it may be either IPC or Activity. Since
walreceiver hasn't sent anything to startup, so it's activity, rather
than IPC. However, the behavior can be
t void *" instead of "char *" for *buf?
Regarding 0005 patch, I will review it later.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2021/03/19 14:28, Thomas Munro wrote:
On Fri, Mar 19, 2021 at 3:23 PM Fujii Masao wrote:
Thanks for updating the patch! It looks good to me!
I have one minor comment for the patch.
+ elog(LOG, "could not open %s: %m", path);
+ return;
+ }
riguchi-san,
Do you have updated version of that bug-fix patch?
Or you started another thread for that issue?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2021/03/19 18:27, Fujii Masao wrote:
On 2021/03/19 15:06, shinya11.k...@nttdata.com wrote:
But 0 value maybe looks strange, so in current version I show it like >below:
Type N (%) Record size (%) FPI size (%) Combined s
On 2021/03/19 10:43, Fujii Masao wrote:
On 2021/03/19 10:02, kuroda.hay...@fujitsu.com wrote:
Dear Fujii-san,
I confirmed your patch and some parse functions, and I agree
the check condition in evaluateSleep() is correct.
No problem is found.
Thanks for reviewing the patch!
Barring any
like the 1 above,
wait_client case should be distinctive from the _MAIN event.
+1. What about the attached patch (WalSenderWaitForWAL.patch)?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
diff --git a/doc/src/sgml/monitor
On 2021/03/22 14:03, shinya11.k...@nttdata.com wrote:
Barring any objection, I will commit this.
I think it's good except for a typo "thoes four bits"
Thanks for the review! Attached is the updated version of the patch.
Regards,
--
Fujii Masao
Advanced Computing Te
this flag for walreceiver,
I guess. But even without the argument, walreceiver seems to work expectedly.
So, what about the attached patch? I applied some cosmetic changes to the patch.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORAT
ld
call ShutdownRecoveryTransactionEnvironment() at its exit.
Attached is the POC patch that changes the startup process that way.
I've not tested the patch enough yet..
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
diff
he promotion. IMO this is why you got that FATAL error.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
before exiting too?
Yes if which could cause actual issue. Otherwise I don't have strong
reason to do that for now..
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2021/03/19 23:35, James Coleman wrote:
Here's an updated patch; I think I've gotten what Alvaro suggested.
Thanks for updating the patch! But I was thinking that our consensus is
something like the attached patch. Could you check this patch?
Regards,
--
Fujii Masao
Advanced
On 2021/03/23 3:25, James Coleman wrote:
On Mon, Mar 22, 2021 at 1:49 PM Fujii Masao wrote:
On 2021/03/19 23:35, James Coleman wrote:
Here's an updated patch; I think I've gotten what Alvaro suggested.
Thanks for updating the patch! But I was thinking that our consensus is
On 2021/03/22 17:49, Kyotaro Horiguchi wrote:
At Mon, 22 Mar 2021 14:07:43 +0900, Fujii Masao
wrote in
On 2021/03/22 14:03, shinya11.k...@nttdata.com wrote:
Barring any objection, I will commit this.
I think it's good except for a typo "thoes four bits"
Thanks
On 2021/03/22 13:59, Fujii Masao wrote:
Ok, so barring any objection, I will commit the patch that I posted upthread.
Pushed!
I'm waiting for other two patches to be reviewed :)
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT
n de829ddf23, and which added new
wait event WalrcvExit. This name seems not consistent with other wait
events. I'm thinking it's better to rename it to WalReceiverExit. Thought?
Patch attached.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarte
GTERM. If we do this, TerminateChildren(SIGTERM)
cannot terminate the stats collector. Thought?
If we adopt this idea, the detail comment about why SIGUSR2 is used for that
needs to be added.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT
nsus is what message
should be logged at PM_STARTUP. I'm thinking it's better to log
"the database system is starting up" in that case because of the reasons
that I explained upthread.
Thought?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2021/03/23 10:52, Thomas Munro wrote:
On Tue, Mar 23, 2021 at 2:44 PM Fujii Masao wrote:
I found 0001 patch was committed in de829ddf23, and which added new
wait event WalrcvExit. This name seems not consistent with other wait
events. I'm thinking it's better to re
ked before
PMSIGNAL_BEGIN_HOT_STANDBY is sent.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
se we cannnot collect the statistics about WAL writing by walreceiver
in that case.
[1]
https://postgr.es/m/e5a982a5-8bb4-5a10-cf9a-40dd1921b...@oss.nttdata.com
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2021/03/24 1:20, Alvaro Herrera wrote:
On 2021-Mar-23, James Coleman wrote:
On Tue, Mar 23, 2021 at 1:46 AM Fujii Masao wrote:
Therefore for now what we've not reached the consensus is what message
should be logged at PM_STARTUP. I'm thinking it's better to log
"
On 2021/03/23 14:49, Fujii Masao wrote:
On 2021/03/23 10:52, Thomas Munro wrote:
On Tue, Mar 23, 2021 at 2:44 PM Fujii Masao wrote:
I found 0001 patch was committed in de829ddf23, and which added new
wait event WalrcvExit. This name seems not consistent with other wait
events. I&#
e database system is starting up" seems enough to me.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
sults.
Should we put this patch to CF?
Yes. Since this is a bug, we can review and commit the patch
without waiting for next CF. But I agree that it's better to
add the patch to next CF so that we don't forget the patch.
Regards,
--
Fujii Masao
Advanced Computing Technology Cent
On 2021/03/23 15:50, Fujii Masao wrote:
+ * The statistics collector is started by the postmaster as soon as the
+ * startup subprocess finishes.
This comment needs to be updated? Because the stats collector can
be invoked when the startup process sends PMSIGNAL_BEGIN_HOT_STANDBY
signal.
I
On 2021/03/24 3:51, Andres Freund wrote:
Hi,
On 2021-03-23 15:50:46 +0900, Fujii Masao wrote:
This fact makes me wonder that if we collect the statistics about WAL writing
from walreceiver as we discussed in other thread, the stats collector should
be invoked at more earlier stage. IIUC
On 2021/03/24 16:59, Alvaro Herrera wrote:
On 2021-Mar-24, Fujii Masao wrote:
On 2021/03/24 5:59, Tom Lane wrote:
Alvaro Herrera writes:
FATAL: the database system is starting up
DETAIL: WAL is being applied to recover from a system crash.
or
DETAIL: The system is applying WAL to
bles can be truncated
before any actual truncation operations. For example, we can easily
do that by truncate foreign tables before local ones. Thought?
XLOG_HEAP_TRUNCATE record is written even for the truncation of
a foreign table. Why is this necessary?
Regards,
--
Fujii Masao
Advanced Co
On 2021/03/24 22:06, James Coleman wrote:
That looks good to me. Thanks for working on this.
Thanks! I pushed the patch.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
there is the case where a backend generates no WAL records,
but just writes them because it needs to do write-ahead-logging
when flush the table data? If yes, "pgWalUsage.wal_records > 0" is not enough.
Probably other fields also need to be checked.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2021/03/25 9:31, Masahiro Ikeda wrote:
On 2021/03/24 18:36, Fujii Masao wrote:
On 2021/03/24 3:51, Andres Freund wrote:
Hi,
On 2021-03-23 15:50:46 +0900, Fujii Masao wrote:
This fact makes me wonder that if we collect the statistics about WAL writing
from walreceiver as we
On 2021/03/25 9:58, Andres Freund wrote:
Hi,
On 2021-03-24 18:36:14 +0900, Fujii Masao wrote:
Barring any objection, I'm thinking to commit this patch.
To which branches?
I was thinking to push the patch to the master branch
because this is not a bug fix.
I am *strongly* oppos
mmon.mk:39: utils-recursive] Error 2
make[1]: *** [Makefile:42: all-backend-recurse] Error 2
make: *** [GNUmakefile:11: all-src-recurse] Error 2
https://cirrus-ci.com/task/4621477321375744
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2021/03/25 11:50, Masahiro Ikeda wrote:
On 2021/03/23 16:10, Fujii Masao wrote:
On 2021/03/22 20:25, ikedamsh wrote:
Agreed. Users can know whether the stats is for walreceiver or not. The
pg_stat_wal view in standby server shows for the walreceiver, and in primary
server it shows
On 2021/03/23 16:32, torikoshia wrote:
On 2021-03-05 17:47, Fujii Masao wrote:
Thanks for your comments!
Thanks for updating the patch!
PostgreSQL Patch Tester reported that the patched version failed to be compiled
at Windows. Could you fix this issue?
https://ci.appveyor.com/project
On 2021/03/26 9:25, Masahiro Ikeda wrote:
On 2021/03/25 21:23, Fujii Masao wrote:
On 2021/03/25 9:58, Andres Freund wrote:
Outside of very
narrow circumstances a normal exit shouldn't use _exit(1). Neither 1 no
_exit() (as opposed to exit()) seem appropriate. This seems like a bad
. OTOH I'm afraid it increases
a bit the risk that users get unstartable database, i.e., lose whole database.
But maybe I'm concerned about rare case and my opinion is minority one.
So I'd like to hear more opinions about this patch.
Regards,
--
Fujii Masao
Advanced Computing Technol
On 2021/03/26 10:08, Kyotaro Horiguchi wrote:
At Thu, 25 Mar 2021 19:01:23 +0900, Fujii Masao
wrote in
On 2021/03/25 16:37, Kyotaro Horiguchi wrote:
pgWalUsage was used without resetting and we (I) thought that that
behavior should be preserved. On second thought, as Andres suggested,
we
feel
like about the behavior.
I think that it's confusing to merge two different features into one function.
Isn't it better to leave pg_get_backend_memory_contexts() as it is, and
make the log-memory-contexts feature as separate function, e.g.,
pg_log_backend_memory_contexts()?
R
On 2021/03/26 12:26, Fujii Masao wrote:
On 2021/03/26 12:01, Kyotaro Horiguchi wrote:
At Thu, 25 Mar 2021 23:45:17 +0900, torikoshia
wrote in
Attached new one.
Regarding the argument max_children, isn't it better to set its default value,
e.g., 100 like MemoryContextStats()
pace/nblocks?
This may be an improvement, but makes us modify MemoryContextStatsInternal()
very much. I'm afraid that it's too late to do that at this stage...
What about leaving the output order as it is at the first version?
Regards,
--
Fujii Masao
Advanced Computing Technology C
On 2021/03/26 0:33, torikoshia wrote:
On 2021-03-25 22:14, Fujii Masao wrote:
On 2021/03/23 16:32, torikoshia wrote:
On 2021-03-05 17:47, Fujii Masao wrote:
Thanks for your comments!
Thanks for updating the patch!
PostgreSQL Patch Tester reported that the patched version failed to be
, their changes are WAL-logged in a publisher
side,
e.g., for logical replication? If not, it seems strange to allow only TRUNCATE
on foreign tables to be WAL-logged in a publisher side...
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA
On 2021/03/29 11:59, torikoshia wrote:
On 2021-03-26 14:08, Kyotaro Horiguchi wrote:
At Fri, 26 Mar 2021 14:02:49 +0900, Fujii Masao
wrote in
On 2021/03/26 13:28, Kyotaro Horiguchi wrote:
>> "some contexts are omitted"
>> "n child contexts: total_bytes = ..
olved, checking permissions and otherwise
verifying that the relation is OK for truncation
Finally all the relations are truncated and reindexed.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2021/03/29 13:55, Michael Paquier wrote:
On Mon, Mar 29, 2021 at 10:53:14AM +0900, Fujii Masao wrote:
I understand the motivation of this. But the other DMLs like UPDATE also
do the same thing for foreign tables? That is, when those DML commands
are executed on foreign tables, their
truncate ft, test" works fine, but "truncate test, ft" causes
an error though they should work in the same way basically.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2021/03/30 10:11, Kohei KaiGai wrote:
2021年3月30日(火) 3:45 Fujii Masao :
On 2021/03/28 2:37, Kazutaka Onishi wrote:
Fujii-san,
Thank you for your review!
Now I prepare v5 patch and I'll answer to your each comment. please
check this again.
m(_ _)m
1. In postgres-fdw.sgml,
On 2021/03/26 22:14, David Steele wrote:
On 3/25/21 9:23 PM, Fujii Masao wrote:
On 2021/03/25 23:21, David Steele wrote:
On 1/25/21 3:55 AM, Laurenz Albe wrote:
On Mon, 2021-01-25 at 08:19 +, osumi.takami...@fujitsu.com wrote:
I think you should pst another patch where the second
version?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index fbf6062d0a..aa9080bddc 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -24917,6
ning the record about the change of wal_level
(to minimal) is archived, so that the subsequent archive recovery
will be able to replay it.
By the way, when I build postgres with this patch and enable-coverage option,
the results of RT becomes unstable. Does someone know the reason ?
When i
n't cause any actual bugs. So if you think the current order is better,
I'm ok with that for now. In this case, the comments for ExecuteTruncate()
should be updated.
BTW, the latest patch doesn't seem to be applied cleanly to the master
because of commit 27e1f14563. Could you rebase
e target.
Or just using "logged" is enough?
Also I'd like to document that one message for each memory context is logged.
So what about the following?
One message for each memory context will be logged. For example,
+1 from me. It looks like more compliant with the standa
?
+1 to add more comments into ShutdownRecoveryTransactionEnvironment().
I did that. What about the attached patch?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
diff --git a/src/backend/postmaster/startup.c b/src/backend
On 2021/02/22 14:55, Bharath Rupireddy wrote:
On Thu, Feb 4, 2021 at 9:36 AM Bharath Rupireddy
wrote:
On Wed, Feb 3, 2021 at 4:22 PM Fujii Masao wrote:
Maybe my explanation in the previous email was unclear. What I think is; If the
server-level option is explicitly specified, its setting
On 2021/04/02 1:13, Bharath Rupireddy wrote:
On Thu, Apr 1, 2021 at 8:56 PM Fujii Masao wrote:
Attaching v21 patch set, rebased onto the latest master.
I agree to add the server-level option. But I'm still not sure if it's good
idea to also expose that option as GUC. Isn&#x
e pass int64 variables to the function but the function
prototype uses int type. I I felt the function parameters should be
int64. Attached patch fixes the same.
Isn't it better to use PgStat_Counter instead of int64?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
R
truncation
of regular tables.
LGTM.
BTW, the latest patch doesn't seem to be applied cleanly to the master
because of commit 27e1f14563. Could you rebase it?
Onishi-san, go ahead. :-)
+1
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarter
unted including new pages.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2021/04/02 15:02, Masahiko Sawada wrote:
Hi all,
I found typos in verify_heapam.c.
s/comitted/committed/
Please find an attached patch.
Thanks for the report and patch! Pushed.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT
On 2021/04/02 11:20, vignesh C wrote:
On Thu, Apr 1, 2021 at 11:18 PM Fujii Masao wrote:
On 2021/04/02 2:18, Jeevan Ladhe wrote:
On Thu, Apr 1, 2021 at 10:20 PM vignesh C mailto:vignes...@gmail.com>> wrote:
Hi,
While I was reviewing replication slot statistics c
ports so this would need a backpatch down to 12.
Yes.
I have not looked
in details and have not looked at the patch yet, though. Fujii-san,
are you planning to take care of that?
Yes, I will. Thanks for the consideration!
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Researc
On 2021/04/02 2:22, Fujii Masao wrote:
Thanks a lot! Barring any objection, I will commit this version.
Pushed. Thanks!
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2021/04/02 18:19, shinya11.k...@nttdata.com wrote:
Thanks for your review!
I updated the patch, and attached it.
Thanks for updating the patch! Pushed.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
this issue or not?
If it still causes, could you check which part (the change of xlog.c or
the addition of regression test) caused the issue?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
diff --git a/src/backend/access/tra
comment that I added wrongly. So the comment should be
"This is just a warning so a loop-through-resultset will not abort
if one backend terminated on its own during the run.",
like pg_signal_backend(). Thought?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and D
On 2021/04/05 16:13, Kyotaro Horiguchi wrote:
At Mon, 5 Apr 2021 12:34:53 +0900, Fujii Masao
wrote in
On 2021/04/04 11:58, osumi.takami...@fujitsu.com wrote:
IMO it's better to comment why this server restart is necessary.
As far as I understand correctly, this is necessary to e
301 - 400 of 1905 matches
Mail list logo
