On Thu, Jan 25, 2024 at 4:40 AM Nathan Bossart wrote:
>
> On Wed, Jan 24, 2024 at 07:30:17PM +0530, Bharath Rupireddy wrote:
> > On Wed, Jan 24, 2024 at 5:50 PM Fujii Masao wrote:
> >> Because of commit 1bdd54e662, the code of HandleWalWriterInterrupts()
On Thu, Jan 25, 2024 at 5:45 AM Noah Misch wrote:
>
> On Thu, Jan 25, 2024 at 04:23:39AM +0900, Fujii Masao wrote:
> > I found that this patch was committed at d3c5f37dd5 and changed the
> > error message in postgres_fdw slightly. Here's an example:
> >
> > #1. B
ls pqWait(), detecting the invalid socket
and appending "invalid socket" to the error message.
I think the "invalid socket" message is unsuitable in this scenario,
and PQgetResult() should not be called after PQconsumeInput() returns
0. Thought?
Regards,
--
Fujii Masao
On Wed, Jan 24, 2024 at 8:29 PM Fujii Masao wrote:
>
> On Tue, Jan 23, 2024 at 6:43 PM Heikki Linnakangas wrote:
> > There's an existing AmWalReceiverProcess() macro too. Let's use that.
>
> +1
>
> > Hmm, but doesn't bgworker_die() have that problem with exit(1)in
.
Regards,
--
Fujii Masao
v1-0001-Remove-redundant-HandleWalWriterInterrupts.patch
Description: Binary data
request
only when no other checkpoint is in progress because initiating a shutdown
checkpoint while another checkpoint is running could lead to issues.
Also I just wonder if even walreceiver can exit safely at any random
CHECK_FOR_INTERRUPTS()...
Regards,
--
Fujii Masao
ShutdownRequest); /* request shutdown */
+ pqsignal(SIGTERM, WalRcvShutdownSignalHandler); /* request shutdown */
Can't we just use die(), instead?
Regards,
--
Fujii Masao
pected delays in failover times.
Regards,
--
Fujii Masao
still use Kuwamura-san's patch
even after the one you posted on the thread gets accepted. BTW, I was able to
reproduce the assertion failure Kuwamura-san reported, even after applying
your latest patch from the thread.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research
the intended behavior?
I'm not sure how the function should work in this case, though.
Though I don't understand the purpose of this option fully yet,
is flushing the WAL sufficient? Are there scenarios where the function
should ensure that the WAL is not only flushed but also replicated
to the sta
, similar to idle_in_transaction_session_timeout.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
b, --clean-backup-history clean up files including backup
history files\n"));
Shouldn't -b option be placed in alphabetical order?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2023/06/08 0:53, Fujii Masao wrote:
On 2023/06/07 23:25, Mehmet Emin KARAKAŞ wrote:
Fixed typo in SQL.
Current: ALTER FOREIGN TABLE myschema.distributors OPTIONS (ADD opt1 'value',
SET opt2 'value2', DROP opt3 'value3');
Fixed: ALTER FOREIGN TABLE myschema.distributors OPTIONS (ADD
that that sounds reasonable, particularly
in case #1. If the postmaster dies, we are going to die too, so it
probably doesn't matter much. But I think an error is certainly also
correct in that case.
+1
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
);
Drop options do not get a value.
Thanks for the report! I agree with your findings and the patch looks good to
me.
I will commit the patch barring any objection.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
meter doesn't always indicate
the current superuser status of the role."?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
cel request: %s",
errbuf)));
PQfreeCancel(cancel);
return false;
}
----
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
omit this row from the view? Additionally, I noticed that
the view also includes a row with backend_type=startup and
context=bulkread / bulkwrite. Do these operations actually occur
during startup process?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development
, but when
initdb
is run with a non-default segment size, the value in postgresql.conf is changed
to five times the new segment size? This will help users better understand
the behavior of the setting and how it is affected by changes made during
initdb.
Regards,
--
Fujii Masao
Advanced Computing
hich caused the
warning message. Then, they would need to check the setting of the "keepalives" option and correct
it if necessary.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
ugh the primary message is the same, the supplemental message provides
additional context that can help distinguish which function is reporting the
message. Therefore, I'm fine with the current primary message in the 0001
patch. However, I'm open to any better message ideas.
Regards,
--
Fujii
ify the cause of the problem (such as
setting an overly large value for the keepalives parameter).
Although I view it as an internal error, I agree with emitting some
error messages in that situation.
Ok.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Developm
the feature freeze date,
I'm thinking to commit this change at the next CommitFest.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2023/04/12 12:00, Kyotaro Horiguchi wrote:
At Wed, 12 Apr 2023 03:36:01 +0900, Fujii Masao
wrote in
Attached patch fixes this issue. It ensures that postgres_fdw only
waits
for a reply if a cancel request is actually issued. Additionally,
it improves PQgetCancel() to set error messages
message when PQgetCancel()
returns NULL, explaining the reason for the NULL value.
Thought?
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATIONFrom 26293ade92ce6fa0bbafac4a95f634e485f4aab6 Mon Sep 17 00:00:00 2001
From: Fujii Masao
Date
On 2023/04/08 23:53, Joseph Koshakow wrote:
On Mon, Apr 3, 2023 at 10:47 AM Fujii Masao mailto:masao.fu...@oss.nttdata.com>> wrote:
> Yes, the patch has not been committed yet because of lack of review
comments.
> Do you have any review comments on this patch?
>
ure in v16.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
don't see this update
Yes, the patch has not been committed yet because of lack of review comments.
Do you have any review comments on this patch?
Or you think it's ready for committer?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA
and
return -1 if either of those bits is set?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
such ctags really exist?
I fixed the above issues and refactored the code.
Attached is the updated version of the patch. Thought?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATIONdiff --git a/src/tools/make_ctags b/src/tools/m
e_etags). Isn't this confusing?
$ ./src/tools/make_etags -a
Usage: /.../make_ctags [-e][-n]
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
the commit and
make make_etags work with that ctags? Or, we should support
only Exuberant-type ctags (btw, I'm ok with this) and get rid of
something like the above code?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
be beyond refactoring,
though.
Isn't it useful to react the interrupts (e.g., shutdown requests)
soon even during waiting for the result of DEALLOCATE ALL?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2022/10/07 18:43, bt22nakamorit wrote:
2022-10-07 16:59 Fujii Masao wrote:
s/subscriber/publisher ?
I did not understand what this means.
Sorry for confusing wording... I was just trying to say that walsender
is connected to a database of the publisher instead of subscriber
On 2022/09/30 16:54, bt22nakamorit wrote:
2022-09-21 11:45 に Fujii Masao wrote:
We can execute the shell commands via psql in various ways
other than \! meta-command. For example,
* `command`
* \g | command
* \gx | command
* \o | command
* \w | command
* \copy ... program 'command
!
-
+ printf("fork child process\n");
+ printf(" am_walsender: %d\n", am_walsender);
+ printf(" am_db_walsender: %d\n", am_db_walsender);
The patch seems to include the debug code accidentally.
Except this, the patch looks good to
mmitdiff;h=249b0409b181311bb1c375311e43eb767b5c3bdd
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATIONFrom 74a89cac092969208067143d25743b40ddbfbfb0 Mon Sep 17 00:00:00 2001
From: Fujii Masao
Date: Sat, 1 Oct 2022 12:51:45 +0900
Subject: [PATCH] U
pfree(backup_state);
+ backup_state = NULL;
It's harmless to set tablespace_map and backup_state to NULL after pfree(),
but it's also unnecessary at least here.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2022/09/21 14:40, Fujii Masao wrote:
On 2022/09/21 12:01, Japin Li wrote:
Hi hackers,
In 6c2003f8a1bbc7c192a2e83ec51581c018aa162f, we change the snapshot name
when exporting snapshot, however, there is one place we missed update the
snapshot name in documentation. Attach a patch
!PGSS_HANDLED_UTILITY(query->utilityStmt))
"pgss_track_utility" should be
"pgss_track_utility || FORCE_TRACK_UTILITY(parsetree)" theoretically?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
ter checking its length?
Seems this can simplify the code very much.
If so, ISTM that we can replace allocate_backup_state() and
reset_backup_state() with just palloc0() and MemSet(), respectively.
Also we can remove fill_backup_label_name().
Regards,
--
Fujii Masao
Advanced Computing Technology
to me.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
"AS", MatchAny, "USING", MatchAny,
"AS", MatchAny, "ON"))
+ COMPLETE_WITH_ATTR(prev8_wd);
+ else if (TailMatches("INTO", MatchAny, MatchAny, "USING", MatchAny,
MatchAny, "ON"))
+ CO
(same as the current
behavior)
* on or sql - stop only whensql fails (same as the current behavior)
* shell - stop only when shell fails
* all - stop when either sql or shell fails
Thought?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
ormation
that's carried across various functions.
In v7 patch, since pg_backup_stop() calls build_backup_content(),
backup_label and history_file seem not to be carried from do_pg_backup_stop()
to pg_backup_stop(). This makes me still think that it's better not to include
them in BackupState...
R
docs? I applied this change to the patch.
Attached is the updated version of the patch.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATIONdiff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 700914684d
-completed with just after "EXPLAIN" or "EXPLAIN ANALYZE", etc.
Since "INTO" always follows "MERGE", it's better to complete with "MERGE INTO"
there. I replaced "MERGE" with "MERGE INTO" in those tab-completions.
Regards,
--
Fujii Masao
hat's not acceptable
and they should be performed outside signal handler. No?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
that. This makes me think that it's better to get rid of the call to
build_backup_content() from do_pg_backup_stop(). Instead its callers,
perform_base_backup() and pg_backup_stop() should call that.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA
nfused. For example, they may fail
to
find the pgss entry for RESET command they ran and just wonder why the command
was
not recorded. To avoid such confusion, how about appending stmt->kind to the
jumble?
Thought?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
scans by one
vacuum run, the number of cancellation of vacuum because of
lock conflicts, etc. If so, when these global counters are high or
increasing, we can think that it may worth tuning maintenance_work_mem.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development
posing seems to add new function pgfdw_finish_abort_cleanup()
with the similar structure as the function added by 0003 patch.
So probably it's helpful for us to consider this together :)
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
quot;,
MatchAny) ||
+TailMatches("USING", MatchAny, "AS", MatchAny, "ON", MatchAny,
MatchAnyExcept("When"), MatchAnyExcept("When")) ||
+TailMatches("USING", MatchAny, MatchAny, "ON",
MatchAny) ||
+TailMatches("USING", MatchAny, MatchAny, "ON", MatchAny,
MatchAnyExcept("When"), MatchAnyExcept("When")))
"When" should be "WHEN"?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
y SET SESSION AUTHORIZATION */
{"session_authorization", PGC_USERSET, UNGROUPED,
If we don't document session_authorization and do expect that
it's usually used by SET/SHOW SESSION AUTHORIZATION,
this comment doesn't need to be removed, I think.
Could you register this
ate
src/test/regress/expected/guc.out.
IS_SUPERUSER
True if the current role has superuser privileges.
I found that the docs of SET command has the above description about
is_superuser.
This description seems useless if we document the is_superuser GUC itself. So
On 2022/07/27 10:36, Kyotaro Horiguchi wrote:
At Tue, 26 Jul 2022 18:33:04 +0900, Fujii Masao
wrote in
I'm not sure the two are similar with each other. The new function
pgfdw_exec_pre_commit() looks like a merger of two isolated code paths
intended to share a seven-line codelet. I feel
On 2022/07/27 1:29, Zhang Mingli wrote:
Thanks!
Pushed. Thanks!
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2022/07/26 19:26, Etsuro Fujita wrote:
Thanks for working on this! I'd like to review this after the end of
the current CF.
Thanks!
Could you add this to the next CF?
Yes.
https://commitfest.postgresql.org/39/3782/
Regards,
--
Fujii Masao
Advanced Computing Technology Center
e function are the toplevel-dedicated stuff.
Same as above.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
nformation commented on
the top of basic_archive.c.
Anyway, since the patches look good to me, I pushed them. Thanks a lot!
If necessary, we can keep improving the docs later.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
;
Fix the annotations for less confusion.
Thanks for the patch! LGTM. I will commit it.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2022/07/26 9:42, Kyotaro Horiguchi wrote:
At Sun, 24 Jul 2022 22:40:16 -0400, Tom Lane wrote in
Fujii Masao writes:
On 2022/07/22 17:31, Kyotaro Horiguchi wrote:
I believed that it is recommended to move to the style not having the
outmost parens. That style has been introduced
() and
pgfdw_finish_pre_subcommit_cleanup()
are no longer necessary and 0003 patch removes them.
[1] https://commitfest.postgresql.org/38/3392/
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATIONFrom aa115d03880968c2e5bab68415e06e17a337a45b Mon Sep
the existing calls to errmsg(). Removing extra
parens can interfere with back-patching of the changes around those errmsg(),
can't it?
Anyway, at first I pushed the 0001 patch that removes useless arguments in
ReadCheckpointRecord().
Regards,
--
Fujii Masao
Advanced Computing Technology Center
On 2022/07/21 23:41, Japin Li wrote:
On Thu, 21 Jul 2022 at 22:22, Fujii Masao wrote:
Hi,
I found that fetch_more_data_begin() in postgres_fdw reports an error when
PQsendQuery() returns the value less than 0 as follows though PQsendQuery() can
return only 1 or 0. I think this is a bug
On 2022/07/21 14:54, Kyotaro Horiguchi wrote:
I agree to removing the two parameters. And agree to let
ReadCheckpointRecord not conscious of the location source.
Thanks for the review!
At Thu, 21 Jul 2022 11:45:23 +0900, Fujii Masao
wrote in
Agreed. Attached is the updated version
execution was
supported in postgres_fdw.
if (PQsendQuery(fsstate->conn, sql) < 0)
pgfdw_report_error(ERROR, NULL, fsstate->conn, false,
fsstate->query);
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquart
s, corruption, etc. That is, I'm concerned
about that some users might quickly run pg_resetwal because hint message says
that, without reading the docs nor understanding those risks.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORAT
On 2022/07/21 10:13, Masahiko Sawada wrote:
Hi,
I realized that standby_desc_running_xacts() in standbydesc.c doesn't
describe subtransaction XIDs. I've attached the patch to improve the
description.
+1
The patch looks good to me.
Regards,
--
Fujii Masao
Advanced Computing Technology
and
sounds confusing because, as far as I recall correctly, we removed the concept of primary
and secondary checkpoints before.
Therefore I think that it's better to remove "whichChkpt" argument in
ReadCheckpointRecord().
Patch attached. Thought?
Regards,
--
Fujii Masao
Advanced Computing T
ne by me.
I pushed these bugfix patches at first. Thanks!
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2022/07/15 16:52, Fujii Masao wrote:
On 2022/07/08 17:03, Etsuro Fujita wrote:
Rather than doing so, I'd vote for adding a test case to file_fdw, as
proposed in the patch, because that would be much simpler and much
less expensive.
So ISTM that most agreed to push Nagata-san's patch
.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
table with file_fdw. So barring any objection, I will
commit the patch.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2022/07/14 17:00, Michael Paquier wrote:
On Fri, Jul 08, 2022 at 08:56:14AM -0400, Robert Haas wrote:
On Thu, Jul 7, 2022 at 10:58 AM Fujii Masao wrote:
But if many think that it's worth adding the test, I will give a
try. But even in that case, I think it's better to commit the
proposed
. Thanks for the clarification!
So I pushed the v2 patch that Yugo-san posted. Thanks!
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
M.
Barring any objection, I will commit the patch.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
ackup_label function. No tests nor docs
have been added yet, but if we can successfully reach the consensus for adding
the function, I will update the patch.
Thought?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATIONdiff --git
On 2022/07/08 0:33, Tom Lane wrote:
Fujii Masao writes:
On 2022/06/30 10:48, Yugo NAGATA wrote:
When a foreign table has handler but doesn't support TRUNCATE,
an error "cannot truncate foreign table xxx" occurs. So, what
about adding a test this message output? We can add
to me except the following thing.
TRUNCATE
- Tables
+ Tables and foreign tables
You added "foreign tables" for BEFORE statement-level trigger as the above, but
ISTM that you also needs to do that for AFTER statement-level trigger. No?
Regards,
--
Fujii Masa
-committer,
and will commit it barring any objeciton.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2022/07/07 9:09, Michael Paquier wrote:
On Wed, Jul 06, 2022 at 11:27:58PM +0900, Fujii Masao wrote:
For the test, BASE_BACKUP needs to be canceled after it finishes
do_pg_backup_start(), i.e., checkpointing, and before it calls
do_pg_backup_stop(). So the timing to cancel that seems more
it.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
not always updator of them? No?
Excluding initialization, (I believe) checkpointer is really the only
updator of the variables/members. But I'm fine with the addition.
Ok, so I modified the patch slightly and pushed it. Thanks!
Regards,
--
Fujii Masao
Advanced Computing Technology Cente
+* updator of these variables.
Isn't it better to add "at this time" or something at the end of the comment
because only we're not always updator of them? No?
Barring any objection, I'm thinking to apply the above small change and commit
the patch.
Regards,
On 2022/07/01 15:41, Michael Paquier wrote:
On Fri, Jul 01, 2022 at 03:32:50PM +0900, Fujii Masao wrote:
Sounds good idea to me. I updated the patch in that way. Attached.
Skimming quickly through the thread, this failure requires a
termination of a backend running BASE_BACKUP
gress in this session")));
I think we can move it to the beginning of SendBaseBackup() so we can
avoid bbsink initialization and cleanup in the error case.
Sounds good idea to me. I updated the patch in that way. Attached.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and D
On 2022/06/30 18:57, Alvaro Herrera wrote:
On 2022-Jun-30, Fujii Masao wrote:
Hi,
I found that there is no index item for MERGE command, in the docs.
Attached is the patch that adds the indexterm for MERGE to merge.sgml.
+1 LGTM, thanks.
Thanks for the review! Pushed.
Regards
inking that the patch I posted is simpler and enough.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
Hi,
I found that there is no index item for MERGE command, in the docs.
Attached is the patch that adds the indexterm for MERGE to merge.sgml.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATIONdiff --git a/doc/src/sgml/ref
ackup is already in progress in the *same* session
as we already do this for pg_backup_start(). Thought? I included
the code to disallow that in the attached patch.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATIONdiff --git a/src
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 Headquarters
NTT DATA
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
, 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
.
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,
--
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 Computing
WNED_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
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
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 Masao
Advanced
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 Headquarters
NTT DATA
1 - 100 of 1476 matches
Mail list logo
