On Tue, May 7, 2019 at 5:33 PM Masahiko Sawada wrote:
>
> On Mon, Apr 8, 2019 at 7:29 PM Masahiko Sawada wrote:
> >
> > On Mon, Apr 8, 2019 at 7:22 PM Fujii Masao wrote:
> > >
> > > On Mon, Apr 8, 2019 at 5:30 PM Masahiko Sawada
> > > wrote:
&
On Mon, Apr 8, 2019 at 8:15 PM Julien Rouhaud wrote:
>
> On Mon, Apr 8, 2019 at 12:22 PM Fujii Masao wrote:
> >
> > On Mon, Apr 8, 2019 at 5:30 PM Masahiko Sawada
> > wrote:
> > >
> > > On Mon, Apr 8, 2019 at 5:15 PM Fujii Masao wrote:
> > &
Hi,
vacuumdb command supports the corresponding options to
any VACUUM parameters except INDEX_CLEANUP and TRUNCATE
that were added recently. Should vacuumdb also support those
new parameters, i.e., add --index-cleanup and --truncate options
to the command?
Regards,
--
Fujii Masao
On Fri, Apr 26, 2019 at 10:52 AM Matsumura, Ryo
wrote:
>
> On Wed. Apr. 24, 2019 at 11:40 PM Masao, Fujii
> wrote:
>
> Thank you for the comment.
> I understand about REPLICATION privilege and notice my unecessary words.
> I update the patch.
Thanks! Pushed.
Regards,
--
Fujii Masao
On Wed, May 8, 2019 at 9:32 AM Masahiko Sawada wrote:
>
> On Wed, May 8, 2019 at 2:41 AM Fujii Masao wrote:
> >
> > Hi,
> >
> > vacuumdb command supports the corresponding options to
> > any VACUUM parameters except INDEX_CLEANUP and TRUNCATE
> > that
adds such NumericOnly. The bug exists only in 12dev.
Barring any objection, I will commit the patch.
Regards,
--
Fujii Masao
vacuum_numeric_as_boolean.patch
Description: Binary data
we received many
complaints about "--index-cleanup=BOOLEAN" from users. So this week,
I'd like to review Sawada's patch and commit it if that's ok.
Regards,
--
Fujii Masao
On Thu, May 9, 2019 at 8:20 PM Masahiko Sawada wrote:
>
> On Thu, May 9, 2019 at 10:01 AM Michael Paquier wrote:
> >
> > On Wed, May 08, 2019 at 06:21:09PM -0300, Euler Taveira wrote:
> > > Em qua, 8 de mai de 2019 às 14:19, Fujii Masao
> > > escreveu:
>
On Wed, May 15, 2019 at 2:52 AM Andres Freund wrote:
>
> Hi,
>
> On 2019-05-15 02:45:21 +0900, Fujii Masao wrote:
> > VACUUM fails to parse 0 and 1 as boolean value
> >
> > The document for VACUUM explains
> >
> > boolean
> > Specifies wh
t do you think?
I'm ok to drop this from open items for v12 because this is not a bug.
Let's work on this next CommitFest.
Regards,
--
Fujii Masao
t's not good to
rush the partial refactoring code into v12 before beta.
I'm ok to apply the first patch and focus on the bugfix at this moment.
Regards,
--
Fujii Masao
On Mon, May 20, 2019 at 11:04 PM Antonin Houska wrote:
>
> Someone probably forgot to update the comment when changing the arguments.
Thanks for the patch! Committed.
Regards,
--
Fujii Masao
On Fri, May 17, 2019 at 10:21 AM Kyotaro HORIGUCHI
wrote:
>
> We now have several syntax elements seemingly the same but behave
> different way.
>
> At Thu, 16 May 2019 15:29:36 -0400, Robert Haas wrote
> in
> > On Thu, May 16, 2019 at 2:56 PM Fujii Masao wrote:
&
On Tue, May 21, 2019 at 11:47 AM Masahiko Sawada wrote:
>
> On Tue, May 21, 2019 at 2:10 AM Fujii Masao wrote:
> >
> > On Fri, May 17, 2019 at 10:21 AM Kyotaro HORIGUCHI
> > wrote:
> > >
> > > We now have several syntax elements seemingly the same but
On Wed, May 22, 2019 at 4:47 PM Michael Paquier wrote:
>
> On Wed, May 22, 2019 at 04:32:38AM +0900, Fujii Masao wrote:
> > I found that tab-completion also needs to be updated for ANALYZE
> > boolean options. I added that change for tab-completion into
> > the patch and
On Fri, Feb 2, 2018 at 2:06 PM, Michael Paquier
wrote:
> On Fri, Feb 02, 2018 at 12:47:26AM +0900, Fujii Masao wrote:
>> The patch basically looks good to me. Here are some small comments.
>>
>>
>> The backup history file is not created in the dat
ptions.
Thanks for the patch! Committed.
Regards,
--
Fujii Masao
On Fri, Mar 2, 2018 at 1:07 PM, Michael Paquier wrote:
> On Fri, Mar 02, 2018 at 02:29:13AM +0900, Fujii Masao wrote:
>> + * write a backup history file with the same name.
>>
>> So more than one backup history files with the same name
>> but the diffferent content
On Fri, Mar 2, 2018 at 12:26 PM, Andres Freund wrote:
> Hi!
>
> On 2018-03-02 02:29:13 +0900, Fujii Masao wrote:
>> On Fri, Feb 2, 2018 at 2:06 PM, Michael Paquier
>> wrote:
>> > On Fri, Feb 02, 2018 at 12:47:26AM +0900, Fujii Masao wrote:
>> >> The
, but as long as we are on it..
>
> Done, thanks again for marking the CF entry.
Thanks for the patch! Pushed.
Regards,
--
Fujii Masao
On Mon, Mar 5, 2018 at 11:01 PM, David Steele wrote:
> On 3/5/18 1:06 AM, Michael Paquier wrote:
>> On Fri, Mar 02, 2018 at 03:41:57PM -0500, David Steele wrote:
>>> On 3/2/18 1:03 PM, Fujii Masao wrote:
>>>> On Fri, Mar 2, 2018 at 1:07 PM, Michael Paquier
>>
oesn't need to wait for
RemoveNonParentXlogFiles() to end. Instead, RemoveNonParentXlogFiles()
seems to have to complete before the checkpointer calls RemoveOldXlogFiles()
and creates .ready files for the "garbage" WAL files on the old timeline.
So it seems natual to leave that WAL recycle task to the checkpointer.
Regards,
--
Fujii Masao
pected delays in failover times.
Regards,
--
Fujii Masao
ignalHandlerForShutdownRequest); /* request shutdown */
+ pqsignal(SIGTERM, WalRcvShutdownSignalHandler); /* request shutdown */
Can't we just use die(), instead?
Regards,
--
Fujii Masao
want to handle a shutdown 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
ached.
Regards,
--
Fujii Masao
v1-0001-Remove-redundant-HandleWalWriterInterrupts.patch
Description: Binary data
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
gt;socket as invalid.
Subsequent PQgetResult() calls 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 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:
> >
> >
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()
&g
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 Headquarter
clude this feature in v16.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
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?
>
to report a warning 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
Fro
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
d 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
ation
can help them identify 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 Cen
Although 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.
Reg
on, which 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
, 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
ouldn't we 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
("could not send cancel request: %s",
errbuf)));
PQfreeCancel(cancel);
return false;
}
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
a timeout, similar to idle_in_transaction_session_timeout.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
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
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
Researc
On 2020/03/10 11:36, Fujii Masao wrote:
On 2020/03/09 14:21, Magnus Hagander wrote:
On Sun, Mar 8, 2020 at 10:13 PM Kyotaro Horiguchi
wrote:
At Fri, 6 Mar 2020 09:54:09 -0800, Magnus Hagander wrote
in
On Fri, Mar 6, 2020 at 1:51 AM Fujii Masao wrote:
I believe that the time required
On 2020/03/10 22:43, Amit Langote wrote:
On Tue, Mar 10, 2020 at 6:09 PM Fujii Masao wrote:
So, I will make the patch adding support for --no-estimate-size option
in pg_basebackup.
Patch attached.
Like the idea and the patch looks mostly good.
Thanks for reviewing the patch
On 2020/03/11 13:44, Amit Langote wrote:
On Wed, Mar 11, 2020 at 3:39 AM Magnus Hagander wrote:
On Tue, Mar 10, 2020 at 6:19 PM Fujii Masao wrote:
Attached is the updated version of the patch.
Would it perhaps be better to return NULL instead of 0 in the
statistics view if there is no
On 2020/03/11 3:39, Magnus Hagander wrote:
On Tue, Mar 10, 2020 at 6:19 PM Fujii Masao wrote:
On 2020/03/10 22:43, Amit Langote wrote:
On Tue, Mar 10, 2020 at 6:09 PM Fujii Masao wrote:
So, I will make the patch adding support for --no-estimate-size option
in pg_basebackup.
Patch
On 2020/03/10 13:54, Masahiko Sawada wrote:
On Tue, 10 Mar 2020 at 00:57, Fujii Masao wrote:
On 2020/03/09 14:10, Masahiko Sawada wrote:
On Mon, 9 Mar 2020 at 13:24, Fujii Masao wrote:
On 2020/03/08 13:52, Masahiko Sawada wrote:
On Thu, 5 Mar 2020 at 20:16, Fujii Masao wrote
to me.
I will commit it.
Regards,
--
Fujii Masao
NTT DATA CORPORATION
Advanced Platform Technology Group
Research and Development Headquarters
INDEX for the consistency.
Attached a patch.
Any thought?
Thanks for the patch! It basically looks good to me.
-buffering
+buffering (string)
Isn't it better to use "enum" rather than "string"?
In the docs about enum GUC parameters, "enum" is used t
dw.sgml so that
pglog table in the doc should include backend_type column.
Regards,
--
Fujii Masao
NTT DATA CORPORATION
Advanced Platform Technology Group
Research and Development Headquarters
On 2020/03/15 0:06, Atsushi Torikoshi wrote:
On 2020/02/19 21:46 Fujii Masao mailto:masao.fu...@oss.nttdata.com>>:
>> I agree to the former, I think RecoveryWalInterval works well enough.
>RecoveryWalInterval sounds confusing to me...
IMHO as a user, I prefer RecoveryRetrie
On 2020/03/16 11:08, Fujii Masao wrote:
On 2020/03/16 10:57, Atsushi Torikoshi wrote:
Hi,
It seems the comments on SharedHotStandbyActive and SharedRecoveryInProgress
are the same in XLogCtlData.
How about modifying the comment on SharedHotStandbyActive?
Attached a patch.
Thanks for
tches that you posted in this thread. Thanks!
Regards,
--
Fujii Masao
NTT DATA CORPORATION
Advanced Platform Technology Group
Research and Development Headquarters
On 2020/03/18 17:56, Atsushi Torikoshi wrote:
On Tue, Mar 17, 2020 at 11:55 AM Fujii Masao mailto:masao.fu...@oss.nttdata.com>> wrote:
> > Waiting when WAL data is not available from any kind of sources
> > (local, archive or stream) before trying aga
On 2020/03/19 0:37, Magnus Hagander wrote:
On Wed, Mar 11, 2020 at 5:53 AM Fujii Masao wrote:
On 2020/03/11 3:39, Magnus Hagander wrote:
On Tue, Mar 10, 2020 at 6:19 PM Fujii Masao wrote:
On 2020/03/10 22:43, Amit Langote wrote:
On Tue, Mar 10, 2020 at 6:09 PM Fujii Masao wrote
On 2020/03/19 1:22, Magnus Hagander wrote:
On Wed, Mar 18, 2020 at 5:14 PM Fujii Masao wrote:
On 2020/03/19 0:37, Magnus Hagander wrote:
On Wed, Mar 11, 2020 at 5:53 AM Fujii Masao wrote:
On 2020/03/11 3:39, Magnus Hagander wrote:
On Tue, Mar 10, 2020 at 6:19 PM Fujii Masao wrote
is not so bad idea.
Regards,
--
Fujii Masao
NTT DATA CORPORATION
Advanced Platform Technology Group
Research and Development Headquarters
On 2020/03/18 22:37, Atsushi Torikoshi wrote:
On Wed, Mar 18, 2020 at 6:59 PM Fujii Masao mailto:masao.fu...@oss.nttdata.com>> wrote:
I meant the following part in the doc.
-
At startup, the standby begins by restoring all WAL available in the a
On 2020/03/19 1:13, Fujii Masao wrote:
On 2020/03/19 0:37, Magnus Hagander wrote:
On Wed, Mar 11, 2020 at 5:53 AM Fujii Masao wrote:
On 2020/03/11 3:39, Magnus Hagander wrote:
On Tue, Mar 10, 2020 at 6:19 PM Fujii Masao wrote:
On 2020/03/10 22:43, Amit Langote wrote:
On Tue
On 2020/03/19 12:02, Amit Langote wrote:
On Thu, Mar 19, 2020 at 11:45 AM Fujii Masao
wrote:
On 2020/03/19 11:32, Amit Langote wrote:
On Thu, Mar 19, 2020 at 11:24 AM Alvaro Herrera
wrote:
On 2020-Mar-19, Amit Langote wrote:
Magnus' idea of checking the valu
rmation, instead, to see how much each vacuum activity
generates the WAL? Sorry if this discussion has already been done
upthread.
Regards,
--
Fujii Masao
NTT DATA CORPORATION
Advanced Platform Technology Group
Research and Development Headquarters
On 2020/03/20 15:22, Atsushi Torikoshi wrote:
On Fri, Mar 6, 2020 at 10:18 PM Fujii Masao mailto:masao.fu...@oss.nttdata.com>> wrote:
OK, so patch attached.
This patch causes, if a promotion is triggered while recovery is paused,
the paused state to end and a promot
On 2020/03/19 19:39, Atsushi Torikoshi wrote:
On Wed, Feb 26, 2020 at 9:19 PM Fujii Masao mailto:masao.fu...@oss.nttdata.com>> wrote:
I have no idea about this. But I wonder how much that change
is helpful to reduce the power consumption because waiting
for WAL archive
On 2020/03/20 3:39, Andres Freund wrote:
Hi,
On 2020-03-19 17:21:38 +0900, Fujii Masao wrote:
Pushed! Thanks!
FWIW, I'm a bit doubtful that incuring the overhead of this by default
on everybody is a nice thing. On filesystems with high latency and with
a lot of small relation
s variable
rather than long?
+ shm_toc_insert(pcxt->toc, PARALLEL_KEY_WAL_USAGE, bufusage_space);
bufusage_space should be walusage_space here?
/*
* Finish parallel execution. We wait for parallel workers to finish, and
* accumulate their buffer usage.
*/
There are some comments
On 2020/03/23 21:01, Fujii Masao wrote:
On 2020/03/23 7:32, Kirill Bychik wrote:
I'm attaching a v5 with fp records only for temp tables, so there's no risk of
instability. As I previously said I'm fine with your two patches, so unless
you have objections on the fpi test
-m fast". That is, we need to add new method into
the promotion.
Regards,
--
Fujii Masao
NTT DATA CORPORATION
Advanced Platform Technology Group
Research and Development Headquarters
On 2020/03/23 23:55, Robert Haas wrote:
On Mon, Mar 23, 2020 at 10:36 AM Fujii Masao
wrote:
If we would like to have the promotion method to finish recovery
immediately, IMO we should implement something like
"pg_ctl promote -m fast". That is, we need to add new method into
the
immediate promotion is useful, as you explained.
So, +1 to add something like "pg_ctl promote -m immediate".
But I'm afraid that now it's too late to add such feature into v13.
Probably it's an item for v14
Regards,
--
Fujii Masao
NTT DATA CORPORATION
Advanced Pla
On 2020/03/19 17:22, Fujii Masao wrote:
On 2020/03/19 12:02, Amit Langote wrote:
On Thu, Mar 19, 2020 at 11:45 AM Fujii Masao
wrote:
On 2020/03/19 11:32, Amit Langote wrote:
On Thu, Mar 19, 2020 at 11:24 AM Alvaro Herrera
wrote:
On 2020-Mar-19, Amit Langote wrote:
Magnus' id
On 2020/03/23 15:56, Fujii Masao wrote:
On 2020/03/19 19:39, Atsushi Torikoshi wrote:
On Wed, Feb 26, 2020 at 9:19 PM Fujii Masao mailto:masao.fu...@oss.nttdata.com>> wrote:
I have no idea about this. But I wonder how much that change
is helpful to reduce the power consu
On 2020/03/24 0:57, Fujii Masao wrote:
On 2020/03/24 0:17, Sergei Kornilov wrote:
Hello
You meant that the promotion request should cause the recovery
to finish immediately even if there are still outstanding WAL records,
and cause the standby to become the master?
Oh, I get your point
On 2020/03/10 2:27, Robert Haas wrote:
On Mon, Mar 9, 2020 at 12:03 PM Fujii Masao wrote:
I started the discussion about the topic very related to this.
I'm thinking to apply the change that Sergei proposes after applying
the patch I attached in this thread.
https://postgr.es/m/00c194b2
On 2020/03/05 20:16, Fujii Masao wrote:
On 2020/03/05 16:58, Masahiko Sawada wrote:
On Wed, 4 Mar 2020 at 15:21, 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
On 2020/03/10 11:47, Kyotaro Horiguchi wrote:
At Thu, 6 Feb 2020 23:23:42 +0900, Fujii Masao
wrote in
On 2020/02/06 1:10, Jeff Janes wrote:
If the restore command claims to have succeeded, but fails to have created
a file with the right name (due to typos or escaping or quoting issues
t replayed, i.e., the promotion
completes immediately. Probably we should document those two cases
explicitly to avoid the confusion about a promotion and recovery pause?
Regards,
--
Fujii Masao
NTT DATA CORPORATION
Advanced Platform Technology Group
Research and Development Headquarters
On 2020/01/28 0:24, Fujii Masao wrote:
On 2020/01/15 19:18, Paul Guo wrote:
I further fixed the last test failure (due to a small bug in the test, not in
code). Attached are the new patch series. Let's see the CI pipeline result.
Thanks for updating the patches!
I started readin
x27;s good timing to have also pg_stat_statements--1.8.sql since
the definition of pg_stat_statements() is changed. Thought?
[1]
https://postgr.es/m/CAB-hujrP8ZfUkvL5OYETipQwA=e3n7oqHFU=4zlxws_cza3...@mail.gmail.com
Regards,
--
Fujii Masao
NTT DATA CORPORATION
Advanced Platform Technology Group
Research and Development Headquarters
ements 1.8 will call pg_stat_statements_1_4. It's not confusing?
Yeah, I withdraw my comment and agree that 1_8 looks less confusing.
Regards,
--
Fujii Masao
NTT DATA CORPORATION
Advanced Platform Technology Group
Research and Development Headquarters
On 2020/03/25 22:45, Julien Rouhaud wrote:
On Wed, Mar 25, 2020 at 10:09:37PM +0900, Fujii Masao wrote:
On 2020/03/21 4:30, Julien Rouhaud wrote:
On Fri, Mar 20, 2020 at 05:09:05PM +0300, Sergei Kornilov wrote:
Hello
Yet another is missed in docs: total_time
Oh good catch! I rechecked
.
Regards,
--
Fujii Masao
NTT DATA CORPORATION
Advanced Platform Technology Group
Research and Development Headquarters
string to the planner", if you have other
use cases, or any comment regarding core architecture.
*As far as I heard*, pg_hint_plan extension uses very tricky way to
extract query string in the planner hook. So this patch would be
very helpful to make pg_hint_plan avoid using such tricky way.
On 2020/03/26 14:33, Masahiko Sawada wrote:
On Tue, 24 Mar 2020 at 17:04, Fujii Masao wrote:
On 2020/03/05 20:16, Fujii Masao wrote:
On 2020/03/05 16:58, Masahiko Sawada wrote:
On Wed, 4 Mar 2020 at 15:21, Fujii Masao wrote:
On 2020/03/04 14:31, Masahiko Sawada wrote:
On Wed, 4
ncStandbysPriority() to unexpectedly end.
Therefore, the band-aid fix seems to be to set the lowest priority to
very large number at the beginning of SyncRepGetSyncStandbysPriority().
Regards,
--
Fujii Masao
NTT DATA CORPORATION
Advanced Platform Technology Group
Research and Development Headquarters
On 2020/03/27 15:39, Masahiko Sawada wrote:
On Fri, 27 Mar 2020 at 10:32, Fujii Masao wrote:
On 2020/03/26 14:33, Masahiko Sawada wrote:
On Tue, 24 Mar 2020 at 17:04, Fujii Masao wrote:
On 2020/03/05 20:16, Fujii Masao wrote:
On 2020/03/05 16:58, Masahiko Sawada wrote:
On Wed
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 Sawada wrote:
Yeah, so 0001 patch sets existing wait events to recovery conflict
resolution. For
On 2020/03/27 19:00, Julien Rouhaud wrote:
On Thu, Mar 26, 2020 at 02:22:47PM +0100, Julien Rouhaud wrote:
On Thu, Mar 26, 2020 at 08:08:35PM +0900, Fujii Masao wrote:
Here are other comments.
- if (jstate)
+ if (kind == PGSS_JUMBLE)
Why is PGSS_JUMBLE
On 2020/03/27 19:00, Julien Rouhaud wrote:
On Thu, Mar 26, 2020 at 02:22:47PM +0100, Julien Rouhaud wrote:
On Thu, Mar 26, 2020 at 08:08:35PM +0900, Fujii Masao wrote:
Here are other comments.
- if (jstate)
+ if (kind == PGSS_JUMBLE)
Why is PGSS_JUMBLE
On 2020/03/29 15:15, Julien Rouhaud wrote:
On Fri, Mar 27, 2020 at 03:42:50PM +0100, Julien Rouhaud wrote:
On Fri, Mar 27, 2020 at 2:01 PM Fujii Masao wrote:
So what I'd like to say is that the information that users are interested
in would vary on each situation and case. At leas
On 2020/03/30 17:03, Julien Rouhaud wrote:
On Mon, Mar 30, 2020 at 01:56:43PM +0900, Fujii Masao wrote:
On 2020/03/29 15:15, Julien Rouhaud wrote:
On Fri, Mar 27, 2020 at 03:42:50PM +0100, Julien Rouhaud wrote:
On Fri, Mar 27, 2020 at 2:01 PM Fujii Masao wrote:
So what I'd li
On 2020/03/31 3:10, Andres Freund wrote:
Hi,
On 2020-03-30 19:41:43 +0900, Fujii Masao wrote:
On 2020/03/30 16:58, Peter Eisentraut wrote:
Improve handling of parameter differences in physical replication
When certain parameters are changed on a physical replication primary,
this is
On 2020/03/31 3:16, Julien Rouhaud wrote:
On Mon, Mar 30, 2020 at 6:36 PM Fujii Masao wrote:
On 2020/03/30 17:03, Julien Rouhaud wrote:
On Mon, Mar 30, 2020 at 01:56:43PM +0900, Fujii Masao wrote:
On 2020/03/29 15:15, Julien Rouhaud wrote:
On Fri, Mar 27, 2020 at 03:42:50PM +0100
On 2020/03/31 15:03, Julien Rouhaud wrote:
On Tue, Mar 31, 2020 at 12:21:43PM +0900, Fujii Masao wrote:
On 2020/03/31 3:16, Julien Rouhaud wrote:
On Mon, Mar 30, 2020 at 6:36 PM Fujii Masao wrote:
While testing the patched pgss, I found that the patched version
may track the statements
his commit, only changing the
lines in the logs.
Yes. What's your opinion about the latest patch based on Robert's idea?
Barring any ojection, I'd like to commit that.
Regards,
--
Fujii Masao
NTT DATA CORPORATION
Advanced Platform Technology Group
Research and Development Headquarters
On 2020/03/31 16:33, Julien Rouhaud wrote:
On Tue, Mar 31, 2020 at 04:10:47PM +0900, Fujii Masao wrote:
On 2020/03/31 15:03, Julien Rouhaud wrote:
On Tue, Mar 31, 2020 at 12:21:43PM +0900, Fujii Masao wrote:
On 2020/03/31 3:16, Julien Rouhaud wrote:
On Mon, Mar 30, 2020 at 6:36 PM Fujii
h, sorry. Looks good and solves my issue
Thanks for reviewing the patch! Pushed!
Regards,
--
Fujii Masao
NTT DATA CORPORATION
Advanced Platform Technology Group
Research and Development Headquarters
cking the trigger file and set the flag in the shmem
if promotion is triggered. Then other processes like backend know
whether promotion is ongoing or not from the shmem. So basically
the backend doesn't need to check the trigger file itself.
Regards,
--
Fujii Masao
NTT DATA CORPORATION
701 - 800 of 1911 matches
Mail list logo