On 2020/09/10 18:01, tsunakawa.ta...@fujitsu.com wrote:
From: Fujii Masao
But I'm concerned about that it's really hard to say there is no patent risk
around that. I'm not sure who can judge there is no patent risk,
in the community. Maybe no one? Anyway, I was thinking that
On 2020/09/10 10:13, tsunakawa.ta...@fujitsu.com wrote:
Alexey-san, Sawada-san,
cc: Fujii-san,
From: Fujii Masao
But if we
implement 2PC as the improvement on FDW independently from PostgreSQL
sharding, I think that it's necessary to support other FDW. And this is our
direction, isn
On 2020/09/09 13:57, Masahiro Ikeda wrote:
On 2020-09-07 16:19, Fujii Masao wrote:
On 2020/09/07 9:58, Masahiro Ikeda wrote:
Thanks for the review and advice!
On 2020-09-03 16:05, Fujii Masao wrote:
On 2020/09/02 18:56, Masahiro Ikeda wrote:
+/* --
+ * Backend types
the code to issue COMMIT PREPARED command from causing an error (not sure if
that's possible, though...), probably we don't need the resolver process. Right?
But in the future, I think we can have multiple background workers per
database for better performance.
Yes, that&#
eat..)
I'm ok with such "small" view. But if this is really problem, I'm ok to expose
only functions pg_stat_get_wal_buffers_full() and pg_stat_get_wal_stat_reset_time(),
without the view, at first.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research an
. Patch attached.
Barring any objection, I will commit it and back-port to v14.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
diff --git a/src/backend/postmaster/autovacuum.c
b/src/backend/postmaster/autovacuum.c
index
orary files after the backend or auxiliary process
(except startup, syslogger and stats collector) crash.
I'm not sure if we really need this long log message.
IMO it's enough to add that information in the docs.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
d then it passes that BackendId to
SharedInvalBackendInit() in InitRecoveryTransactionEnvironment().
Maybe you need to enlarge ProcState array so that it also handles
auxiliary processes if it does not for now.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
redInvalidationState. IMO, this has to go
in a separate patch and probably in a separate thread. Thoughts?
Agreed.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
diff --git a/src/backend/postmaster/auxprocess.c
b/src/ba
that the database may hit
the error "sorry, too many clients already" soon in
SharedInvalBackendInit.
Attaching a patch to fix this issue. Thoughts?
Thanks for making the patch! LGTM.
Barring any objection, I will commit it.
Regards,
--
Fujii Masao
Advanced Computing Technology C
On 2021/10/11 14:40, Fujii Masao wrote:
On 2021/10/11 14:28, torikoshia wrote:
Thanks for the patch!
It might be self-evident, but since there are comments on other process
handlings in HandleAutoVacLauncherInterrupts like below, how about adding a
comment for the consistency?
+1
I
ested, i.e., give up using isdigit()+strtol().
OTOH, of course if the behaviors of them are the same,
I'm ok to use isdigit()+strtol(), though.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
- ERRCODE_FDW_INVALID_OPTION_NAME (file_fdw.c)
- ERRCODE_FDW_OPTION_NAME_NOT_FOUND (dblink.c)
- ERRCODE_FDW_INVALID_OPTION_NAME (postgres_fdw/option.c)
- ERRCODE_SYNTAX_ERROR (foreign.c)
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
d
d IDs for them might need to be assigned
outside SharedInvalBackendInit(). Thought?
[1]
https://postgr.es/m/CALj2ACU1nBzpacOK2q=a65s_4+oaz_rltsu1ri0gf7yumnm...@mail.gmail.com
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2021/10/13 14:00, Bharath Rupireddy wrote:
On Tue, Oct 12, 2021 at 11:11 PM Fujii Masao
wrote:
BTW, I found file_fdw.c, dblink.c, postgres_fdw/option.c and foreign.c
use different error codes for the same error message as follows.
They should use the same error code? If yes, ISTM that
On 2021/10/12 15:46, Bharath Rupireddy wrote:
On Tue, Oct 12, 2021 at 5:37 AM Fujii Masao wrote:
On 2021/10/12 4:07, Bharath Rupireddy wrote:
Hi,
While working on [1], it is found that currently the ProcState array
doesn't have entries for auxiliary processes, it does have entrie
mands like
archive_cleanup_command, restore_command and recovery_end_command?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 3173ec2566..13c7e991d0 1
at_shutdown_hook() is called
after ProcKill(), e.g., by registering pgstat_shutdown_hook() into
on_proc_exit_list (I'm not sure if this change is safe, though).
Or maybe pgstat logic for replication slot drop needs to be overhauled.
Regards,
--
Fujii Masao
Advanced Computing Technology Cente
://www.postgresql.org/message-id/os0pr01mb571621b206eeb17d8ab171f094...@os0pr01mb5716.jpnprd01.prod.outlook.com
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
iously an issue. And then we can consider what error code should be
used in FDW layer if necessary.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
t case for file_fdw? It looks like the
file_fdw contrib module doesn't have any test cases in its sql
directory. I'm not sure if the module code is being covered in
someother tests.
You can see the regression test for file_fdw,
in contrib/file_fdw/input and output directories.
Rega
y contexts.
+Only superusers can request to log the memory contexts of superuser
+backends.
The description "This function is restricted to superusers by default,
but other users can be granted EXECUTE to run the function."
should be added into the docs?
Regards,
--
Fujii Masa
On 2021/10/25 21:27, Bharath Rupireddy wrote:
On Mon, Oct 25, 2021 at 4:36 PM Fujii Masao wrote:
On 2021/10/25 16:44, Bharath Rupireddy wrote:
Yeah, let's focus on fixing the hint message here and the
alter_foreign_data_wrapper_options_v3.patch LGTM.
Thanks! But since v3 change
gards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
but a hook just for this purpose isn't a great
idea IMO.
Yes, this idea sounds overkill to me.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index
On 2021/10/22 18:32, Michael Paquier wrote:
On Thu, Oct 21, 2021 at 10:57:50PM +0900, Fujii Masao wrote:
Also how about adding wait events for other commands like
archive_cleanup_command, restore_command and recovery_end_command?
+1 to add something for all of them as we track the startup
On 2021/09/29 22:11, Fujii Masao wrote:
On 2021/09/24 11:26, Fujii Masao wrote:
On 2021/09/24 7:26, Yugo NAGATA wrote:
That makes sense. Failures of setup connection or initial connection doesn't
seem 'static problems'. I rewrote this description to explain exit status 1
On 2021/10/09 0:41, Fujii Masao wrote:
On 2021/10/01 15:27, Michael Paquier wrote:
On Wed, Sep 29, 2021 at 10:11:53PM +0900, Fujii Masao wrote:
BTW, when logfile fails to be opened, pgbench gets stuck due to commit
aeb57af8e6. So even if we decided not to back-patch those changes,
we
sn't it overkill to tab-complete this? I thought that because
I'm not sure if COMMENT command for OPERATOR CLASS or FAMILY is
usually executed via psql interactively, instead I just guess
it's executed via script. Also because there is no tab-completion
support for ALTER OPERATOR CLASS or FAMILY command. It's a bit
strange to support the tab-complete for COMMENT for OPERATOR CLASS
or FAMILY first.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
a separate "if". The preceding block is a terminal FATAL
and it seems more intuitive that way.
Agreed.
Should it include an errcode() ?
ERRCODE_INSUFFICIENT_RESOURCES ?
ERRCODE_OUT_OF_MEMORY ?
Probably errcode is not necessary here because it's a log message
not error one?
R
On 2021/10/29 16:00, Masahiko Sawada wrote:
Which is noisy. Perhaps it's better to log it only when
IsPostmasterEnvironment is true.
+1
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
test module. It provides very basic
WAL archiving feature, but (I guess) it's enough for some users.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
_name in the local server is not set? At least for me,
it's intuitive to replace it with empty string in that case,
in postgres_fdw application_name.
The patch now fails to be applied to the master. Could you rebase it?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2021/11/01 23:01, Fujii Masao wrote:
The remainings are the changes of handling of initial connection or
logfile open failures. I agree to push them at least for the master.
But I'm not sure if they should be back-patched. Without these changes,
even when those failures happen, pg
I posted other comments upthread. Could you consider
whether it's worth applying those comments to the patch?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
ould arrange to suppress that output.
+1
I didn't spot any other problems on a quick read-through.
-bool log_checkpoints = false;
+bool log_checkpoints = true;
It's better to initialize the global variable Log_autovacuum_min_duration
with 60 like the above ch
inions.
Ok, we can wait for more opinions about this to come.
But if user name and database name should NOT be NULL
in postgres_fdw, I think that it's better to add the assertion
check for those conditions and get rid of "[unknown]" part.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
committer for it. My
apologies!
No problem. Thanks for committing the patch!
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
g behavior.
It seems to me that postgres-fdw asumes a valid user id, but doesn't
make no use of databsae, server port, and process id. What I thought
here is that making it an assertion is too much. So just ignoring the
replacement is also fine to me.
That being said, if we are eager not to
On 2021/11/03 0:03, Bossart, Nathan wrote:
On 11/1/21, 9:44 PM, "Fujii Masao" wrote:
What is the main motivation of this patch? I was thinking that
it's for parallelizing WAL archiving. But as far as I read
the patch very briefly, WAL file name is still passed to
the a
On 2021/11/07 18:06, Etsuro Fujita wrote:
On Mon, Nov 1, 2021 at 3:22 PM Fujii Masao wrote:
On 2021/10/31 18:05, Etsuro Fujita wrote:
The patch is pretty simple: if a server option added
by the patch “parallel_commit” is enabled,
Could you tell me why the parameter is necessary?
Can'
On 2021/11/08 15:12, Ken Kato wrote:
Hi,
Configuration parameters for pg_stat_statements were not in the index,
so I added them just like auto_explain configuration parameters.
Thanks for the patch! LGTM.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and
On 2021/11/08 16:23, Julien Rouhaud wrote:
On Mon, Nov 8, 2021 at 3:19 PM Fujii Masao wrote:
On 2021/11/08 15:12, Ken Kato wrote:
Hi,
Configuration parameters for pg_stat_statements were not in the index,
so I added them just like auto_explain configuration parameters.
Thanks for the
ng a
tiny patch for that.
Thoughts?
I'm fine with this. Barring any objection, I will commit the patch.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2021/11/09 13:01, Michael Paquier wrote:
On Tue, Nov 09, 2021 at 12:51:39PM +0900, Fujii Masao wrote:
I'm fine with this. Barring any objection, I will commit the patch.
I have to admit that the timing is kind of odd, or strange, or both,
because I was just going through my backlog
== 0)
wait_event_info = WAIT_EVENT_RECOVERY_END_COMMAND;
else if (strcmp(commandName, "archive_command_command") == 0)
...
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
r
the opinions of people.
Yes.
IIUC I think the overheads of WaitLatchOrSocket() incurred by a series
of epoll system calls are much larger compared to the overheads of
PQconsumeInput() incurred by a recv system call in non-blocking mode
when no data is available. I didn’t do testing, though.
Understoo
e28, dbname=, username=)
I think the problem here is that secure_write() uses infinite timeout.
Is this the same issue as one reported at [1]?
[1]
https://www.postgresql.org/message-id/adce2c09-3bfc-4666-997a-c21991cb1eb1.mengjuan@alibaba-inc.com
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
uot;%s", message_primary) :
errmsg("could not obtain message string for remote
error"),
---
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
sult() does. So it might be good idea to refactor
those function to reduce the code duplication.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
return NULL. But *if* it returns NULL,
pchomp(NULL) is executed and would cause a segmentation fault.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATIONdiff --git a/contrib/postgres_fdw/connection.c
b/contrib/postgres_fdw/
the patch.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
duplicate code we save here vs the
readability or complexity that comes with the single function.
Please see the attached patch (refactor_pgfdw_get_result_v1.patch).
This is still WIP, but you can check how much the refactoring can
simplify the code.
Regards,
--
Fujii Masao
Advanced Computing
On 2021/11/20 0:19, Fujii Masao wrote:
On 2021/11/19 16:54, Michael Paquier wrote:
On Thu, Nov 18, 2021 at 10:04:57AM +0530, Bharath Rupireddy wrote:
Yeah let's not do that. I'm fine with the
wait_event_for_archive_command_v2.patch as is.
Switched the patch as RfC, then
all the cases. I'm not sure how much it's worth doing that, though..
It seems more robust to check also NULL there.
BTW, we might have to fix it in dblink_res_error too?
Yeah, that's good idea. I included that change in the patch. Attached.
Regards,
--
Fujii Masao
Advanced C
separately. Thoughts?
Yes! I will consider again if it's worth doing the refactoring,
if yes, I will start new thread for the discussion for that.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
back(path, FILE_TYPE_DIRECTORY, 0, NULL);
/* recurse to handle subdirectories */
recurse_dir(datadir, path, callback);
}
Regards,
--
Fujii Masao
t tries to skip
that directory at all. But isn't this right behavior? If that directory doesn't
exist in the target directory(though I'm not sure if this situation is really
possible), I'm thinking that pg_rewind should create that "empty" directory
in the target. No?
Regards,
--
Fujii Masao
On Tue, Mar 27, 2018 at 10:55 AM, Michael Paquier wrote:
> On Tue, Mar 27, 2018 at 01:32:41AM +0900, Fujii Masao wrote:
>> +1. It's better for us to focus on the code change of the fillter on
>> pg_rewind
>> rather than such "refactoring".
>
> (filter t
small modification in
> remove_target_file to make the code cleaner, a proposal of commit
> message and pgindent applied on the code. I am switching that as ready
> for committer.
The patch looks good to me! Barring objection, I will commit it
and back-patch to 9.5 where pg_rewind was
On Wed, Mar 28, 2018 at 11:24 AM, Michael Paquier wrote:
> On Wed, Mar 28, 2018 at 04:45:49AM +0900, Fujii Masao wrote:
>> The patch looks good to me! Barring objection, I will commit it
>> and back-patch to 9.5 where pg_rewind was added.
>
> Thanks in advance! I just eyeb
On Wed, Mar 28, 2018 at 7:54 AM, Michael Paquier wrote:
> On Wed, Mar 28, 2018 at 04:13:25AM +0900, Fujii Masao wrote:
>> This code is almost ok in practice, but using the check of
>> "strstr(path, localpath) == path" is more robust here?
>
> No problems with that e
ng in libpqrcv_get_remoteserver_info() because it's called just
after the replication connection is successfully established. But it's better to
handle also that case for robustness of the code.
Regards,
--
Fujii Masao
at 04:36, Masahiko Sawada wrote:
>>>> We're not talking about standbys, so the message is incorrect.
>>>
>>> Ah, I understood. How about "\"%s\" has now caught up with upstream
>>> server"?
>>
>> +1.
>
> upstream is what I would have suggested, so +1 here also.
>
> Will commit.
ping?
Regards,
--
Fujii Masao
tiple
relation files. Patch attached. Thought?
Regards,
--
Fujii Masao
speedup_relation_deletes_during_recovery_v1.patch
Description: Binary data
On Fri, Mar 30, 2018 at 9:34 AM, Michael Paquier wrote:
> On Fri, Mar 30, 2018 at 10:52:02AM +1100, Haribabu Kommi wrote:
>> On Fri, Mar 30, 2018 at 7:26 AM, Fujii Masao wrote:
>>> @@ -753,4 +753,6 @@ CREATE VIEW pg_stat_wal_receiver AS
>>>
On Fri, Mar 30, 2018 at 11:46 AM, Michael Paquier wrote:
> On Fri, Mar 30, 2018 at 11:19:58AM +0900, Kyotaro HORIGUCHI wrote:
>> At Fri, 30 Mar 2018 08:31:29 +0900, Fujii Masao
>> wrote in
>>> When multiple relations are deleted at the same transaction,
>>>
On Fri, Mar 30, 2018 at 12:18 PM, Tsunakawa, Takayuki
wrote:
> From: Fujii Masao [mailto:masao.fu...@gmail.com]
>> When multiple relations are deleted at the same transaction, the files of
>> those relations are deleted by one call to smgrdounlinkall(), which leads
>> to scan
lation are unnecessarily repeated,
which would decrease the performance. So, to alleviate this situation,
$SUBJECT is useful, I think.
Thought?
Regards,
--
Fujii Masao
On Wed, Apr 18, 2018 at 10:44 AM, Michael Paquier wrote:
> On Wed, Apr 18, 2018 at 12:46:58AM +0900, Fujii Masao wrote:
>> Yes, I think. And, I found that smgrdounlinkfork() is also dead code.
>> Per the discussion [1], this unused function was left intentionally.
>> But
On Wed, Apr 18, 2018 at 11:29 PM, Pavan Deolasee
wrote:
>
>
> On Tue, Apr 17, 2018 at 11:05 PM, Fujii Masao wrote:
>>
>> Hi,
>>
>> I'd like to propose to add $SUBJECT for performance improvement.
>>
>> When VACUUM tries to truncate the trai
bail out of the loop immediately in that case.
Attached is the patch for the fix.
Regards,
--
Fujii Masao
pg_promote_and_postmaster_death.patch
Description: Binary data
On Thu, Sep 5, 2019 at 10:26 AM Michael Paquier wrote:
>
> On Thu, Sep 05, 2019 at 09:46:26AM +0900, Fujii Masao wrote:
> > I found small issue in pg_promote(). If postmaster dies
> > while pg_promote() is waiting for the standby promotion to finish,
> > pg_promote() c
On Thu, Sep 5, 2019 at 11:10 AM Michael Paquier wrote:
>
> On Thu, Sep 05, 2019 at 10:53:19AM +0900, Fujii Masao wrote:
> > It's ok to use PG_RETURN_BOOL(false) instead of breaking out of the loop
> > in that case. Which would make the code simpler.
>
> Okay. I would
On Thu, Sep 5, 2019 at 4:52 PM Michael Paquier wrote:
>
> On Thu, Sep 05, 2019 at 04:03:22PM +0900, Fujii Masao wrote:
> > So, barring any objection, I will commit the attached patch.
>
> LGTM. Thanks!
Committed. Thanks!
Regards,
--
Fujii Masao
On Sat, Sep 7, 2019 at 12:06 AM Jehan-Guillaume de Rorthais
wrote:
>
> On Wed, 4 Sep 2019 00:32:03 +0900
> Fujii Masao wrote:
>
> > On Mon, Jul 29, 2019 at 7:26 PM Jehan-Guillaume de Rorthais
> > wrote:
> > >
> > > On Fri, 26 Jul 2019 18:22:25 +020
On Tue, Sep 3, 2019 at 11:04 PM Fujii Masao wrote:
>
> On Thu, Aug 22, 2019 at 3:06 PM Wang, Shenhao
> wrote:
> >
> > Hello, hackers:
> >
> > I created a patch about tab completion for command CREATE OR REPLACE in psql
> > includes:
> > CREA
On Thu, Sep 5, 2019 at 5:53 PM Jamison, Kirk wrote:
>
> On Tuesday, September 3, 2019 9:44 PM (GMT+9), Fujii Masao wrote:
> > Thanks for the patch!
>
> Thank you as well for the review!
>
> > -smgrdounlinkfork(SMgrRelation reln, ForkNumber forknum, bool isRedo)
> &g
e patch removing the smgrdounlinkfork.
Per the past discussion, some people want to keep this "dead" function
for some reasons. So, in my opinion, it's better to just enclose the function
with #if NOT_USED and #endif, to keep the function itself as it is, and then
to start new discussion on hackers about the removal of that separatedly
from this patch.
Regards,
--
Fujii Masao
On Fri, Sep 13, 2019 at 9:51 PM Alvaro Herrera wrote:
>
> On 2019-Sep-13, Fujii Masao wrote:
>
> > On Mon, Sep 9, 2019 at 3:52 PM Jamison, Kirk
> > wrote:
>
> > > > Please add a preliminary patch that removes the function. Dead code is
> > > >
On Tue, Sep 17, 2019 at 10:44 AM Jamison, Kirk wrote:
>
> On Friday, September 13, 2019 10:06 PM (GMT+9), Fujii Masao wrote:
> > On Fri, Sep 13, 2019 at 9:51 PM Alvaro Herrera
> > wrote:
> > >
> > > On 2019-Sep-13, Fujii Masao wrote:
> > >
> &g
On Tue, Sep 17, 2019 at 2:25 PM Michael Paquier wrote:
>
> On Tue, Sep 17, 2019 at 01:44:12AM +, Jamison, Kirk wrote:
> > On Friday, September 13, 2019 10:06 PM (GMT+9), Fujii Masao wrote:
> >> On Fri, Sep 13, 2019 at 9:51 PM Alvaro Herrera
> >> w
iately
after the change of primary_conninfo. If the change happens while
the startup process in paused state (e.g., by pg_wal_replay_pause(),
recovery_min_apply_delay, recovery conflict, etc), the startup
process tries to terminate walreceiver after it gets out of such state.
Shouldn't this fact be documented as a note?
Regards,
--
Fujii Masao
_label nor recovery.signal exist. Thought?
Regards,
--
Fujii Masao
On Thu, Sep 19, 2019 at 9:42 AM Jamison, Kirk wrote:
>
> On Wednesday, September 18, 2019 8:38 PM, Fujii Masao wrote:
> > On Tue, Sep 17, 2019 at 10:44 AM Jamison, Kirk
> > wrote:
> > >
> > > On Friday, September 13, 2019 10:06 PM (GMT+9), Fujii Masao wrote:
There are other log messages that
"%c" is used for such variable, in proto.c. Seems the above is
only message that "%d" is used for such variable.
Regards,
--
Fujii Masao
improve-elog-message-in-proto.patch
Description: Binary data
would be replayed on the standby, and the surrounding comments are
> clear about that.
Could you elaborate what problem adding a critical section there occurs?
Regards,
--
Fujii Masao
es RECO VERYXLOG and
RECOVERYHISTORY from exitArchiveRecovery() and performing it
just before/after RemoveNonParentXlogFiles()? Which looks simple.
Regards,
--
Fujii Masao
even when standby.signal exists.
Regards,
--
Fujii Masao
On Fri, Sep 27, 2019 at 3:36 AM David Steele wrote:
>
> On 9/24/19 1:25 AM, Fujii Masao wrote:
> >
> > When backup_label exists, the startup process enters archive recovery mode
> > even if recovery.signal file doesn't exist. In this case, the startup
> > proc
On Fri, Sep 27, 2019 at 4:07 PM Masahiko Sawada wrote:
>
> On Fri, Sep 27, 2019 at 3:36 AM David Steele wrote:
> >
> > On 9/24/19 1:25 AM, Fujii Masao wrote:
> > >
> > > When backup_label exists, the startup process enters archive recovery mode
> > &g
On Fri, Sep 27, 2019 at 5:09 PM Michael Paquier wrote:
>
> On Fri, Sep 27, 2019 at 01:51:25PM +0900, Masahiko Sawada wrote:
> > On Thu, Sep 26, 2019 at 6:23 PM Fujii Masao wrote:
> >> What about moving the logic that removes RECO VERYXLOG and
> >> RECOVERYHISTORY
On Fri, Sep 27, 2019 at 7:16 PM Michael Paquier wrote:
>
> On Fri, Sep 27, 2019 at 05:58:21PM +0900, Fujii Masao wrote:
> > So you think that it's better to remove them just after
> > writeTimeLineHistory()?
> > Per the following Sawada-san's comment, I was th
hat
it behaves in the same way as prior versions. That is,
- Stop the recovery with an error if any recovery target is set in
crash recovery
- Use recovery target settings if set even when standby mode
- Do not enter an archive recovery mode if recovery.signal is missing
Thought?
If we want new behavior in recovery, we can change the logic for v13.
Regards,
--
Fujii Masao
On Sat, Sep 28, 2019 at 2:01 AM David Steele wrote:
>
> On 9/27/19 11:58 AM, Fujii Masao wrote:
> > On Sat, Sep 28, 2019 at 12:14 AM David Steele wrote:
> >>
> >> I think, at the very least, the fact that targeted recovery proceeds in
> >> the abse
ce changing
> the recovery behavior in old versions could lead to nasty surprises.
+1 to update the documentation.
Regards,
--
Fujii Masao
On Sun, Sep 29, 2019 at 12:51 AM David Steele wrote:
>
> On 9/28/19 10:54 AM, Fujii Masao wrote:
> > On Sat, Sep 28, 2019 at 2:01 AM David Steele wrote:
> >> On 9/27/19 11:58 AM, Fujii Masao wrote:
> >>>
> >>> Yes, recovery target settings are
the assertion failure happened.
Attached patch fixes this issue by making archive recovery always ignore
recovery_min_apply_delay. This change is OK because
recovery_min_apply_delay was introduced for standby mode, I think.
This issue is not new in v12. I observed that the issue was reprod
ssing but backup_label exists. In this case,
InArchiveRecovery is set to true though ArchiveRecoveryRequested is
false because recovery.signal is missing.
With the attached patch, I checked that the steps that I described
upthread didn't reproduce the issue.
Regards,
--
Fujii Masao
ignore-reco
On Mon, Sep 30, 2019 at 6:59 AM Peter Eisentraut
wrote:
>
> On 2019-09-29 18:36, Fujii Masao wrote:
> > Yes, but ArchiveRecoveryRequested should be checked instead of
> > InArchiveRecovery, I think. Otherwise recovery targets would take effect
> > when recovery.signal is
501 - 600 of 1911 matches
Mail list logo
