PARALLEL_INDVAC_STATUS_COMPLETED.
BTW, currently we don't need a lock for touching index status since
each worker touches different indexes. But after this patch, the
leader will touch all index status, do we need a lock for that?
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
On Mon, May 2, 2022 at 11:32 AM Amit Kapila wrote:
>
> On Mon, May 2, 2022 at 7:33 AM Masahiko Sawada wrote:
> > On Thu, Apr 28, 2022 at 7:01 PM houzj.f...@fujitsu.com
> > wrote:
> > >
> > > Hi Sawada-san, Wang
> > >
> > > I was looking
On Thu, Apr 28, 2022 at 7:01 PM houzj.f...@fujitsu.com
wrote:
>
> On Wednesday, April 20, 2022 3:21 PM Masahiko Sawada
> wrote:
> >
> > BTW the changes in
> > REL_14_v1-0001-Fix-the-logical-replication-timeout-during-large-.patch,
> > adding end_xact to Logical
On Thu, Apr 21, 2022 at 11:19 AM Amit Kapila wrote:
>
> On Wed, Apr 20, 2022 at 6:22 PM Masahiko Sawada wrote:
> >
> > On Wed, Apr 20, 2022 at 7:12 PM Amit Kapila wrote:
> > >
> >
> > > I think it would
> > > be then better to have it in the
On Wed, Apr 20, 2022 at 7:12 PM Amit Kapila wrote:
>
> On Wed, Apr 20, 2022 at 2:38 PM Amit Kapila wrote:
> >
> > On Wed, Apr 20, 2022 at 12:51 PM Masahiko Sawada
> > wrote:
> > >
> > > On Wed, Apr 20, 2022 at 11:46 AM wangw.f...@fujitsu.com
> >
ter to put it after fast_forward where the
new field should fall within the padding space.
BTW the changes in
REL_14_v1-0001-Fix-the-logical-replication-timeout-during-large-.patch,
adding end_xact to LogicalDecodingContext, seems good to me and it
might be better than the approach of v17 patch from plugin developers’
perspective? This is because they won’t need to pass true/false to
end_xact of OutputPluginUpdateProgress(). Furthermore, if we do what
we do in update_replication_progress() in
OutputPluginUpdateProgress(), what plugins need to do will be just to
call OutputPluginUpdate() in every callback and they don't need to
have the CHANGES_THRESHOLD logic. What do you think?
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
;
> Perhaps the latter is more future-proof.
Copying only xmin-related flags in this way also makes sense to me and
there is no problem at least for now. A note would be that when we
introduce a new flag that needs to be copied in the future, we need to
make sure to add it to PROC_XMIN_FLAGS so it is copied. Otherwise a
similar issue we fixed by 0f0cfb494004befb0f6e could happen again.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
On Mon, Apr 18, 2022 at 3:16 PM wangw.f...@fujitsu.com
wrote:
>
> On Mon, Apr 18, 2022 at 00:35 PM Masahiko Sawada
> wrote:
> > On Mon, Apr 18, 2022 at 1:01 PM Amit Kapila wrote:
> > >
> > > On Thu, Apr 14, 2022 at 5:50 PM Masahiko Sawada
> > wrote:
&g
On Mon, Apr 18, 2022 at 8:04 PM Amit Kapila wrote:
>
> On Thu, Apr 14, 2022 at 9:09 AM Amit Kapila wrote:
> >
> > On Thu, Apr 14, 2022 at 8:32 AM Masahiko Sawada
> > wrote:
> > > >
> > > > The other part of the puzzle is the below check in the c
On Mon, Apr 18, 2022 at 1:01 PM Amit Kapila wrote:
>
> On Thu, Apr 14, 2022 at 5:50 PM Masahiko Sawada wrote:
> >
> > On Wed, Apr 13, 2022 at 7:45 PM Amit Kapila wrote:
> > >
> > > On Mon, Apr 11, 2022 at 12:09 PM wangw.f...@fujitsu.com
> > >
On Mon, Apr 18, 2022 at 12:22 PM Noah Misch wrote:
>
> On Mon, Apr 18, 2022 at 10:45:50AM +0900, Masahiko Sawada wrote:
> > On Fri, Apr 15, 2022 at 4:26 PM Noah Misch wrote:
> > > On Thu, Apr 07, 2022 at 08:39:58PM +0900, Masahiko Sawada wrote:
> > > > On Thu, A
On Fri, Apr 15, 2022 at 4:26 PM Noah Misch wrote:
>
> On Thu, Apr 07, 2022 at 08:39:58PM +0900, Masahiko Sawada wrote:
> > On Thu, Apr 7, 2022 at 7:28 PM Amit Kapila wrote:
> > > On Thu, Apr 7, 2022 at 8:25 AM Amit Kapila
> > > wrote:
> > > > I'll ta
{
+OutputPluginUpdateProgress(ctx, skipped_xact, end_xact);
+changes_count = 0;
+}
Can we merge two if branches since we do the same things? Or did you
separate them for better readability?
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
(
On Wed, Apr 13, 2022 at 6:45 PM Amit Kapila wrote:
>
> On Wed, Apr 13, 2022 at 1:41 PM Masahiko Sawada wrote:
> >
> > I've looked at this issue and had the same analysis. Also, I could
> > reproduce this issue with the steps shared by Amit.
> >
> >
value from
wait_for_worker_state_change() seems a bug to me. So my initial
thought of the solution is that we can have the tablesync worker check
the return value and exit if it's false. That way, the apply worker
can restart and request to launch the tablesync worker again. What do
you think?
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
On Wed, Apr 13, 2022 at 2:39 PM Amit Kapila wrote:
>
> On Tue, Apr 12, 2022 at 6:16 AM Masahiko Sawada wrote:
> >
> > Hi,
> >
> > On Thu, Apr 7, 2022 at 4:37 PM Andres Freund wrote:
> > >
> > > Hi,
> > >
> > > On 2022-
cription (and
exits if there is parameter change) and then requests to launch
tablesync workers accordingly. Also, the fact that we don't check the
return value of wiat_for_worker_state_change() is not a new thing; we
have been living with this behavior since v10. So I'm not really sure
why this problem appeared recently if my hypothesis is correct.
Regards,
[1]
https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=grassquit=2022-04-08%2014%3A13%3A27=subscription-check
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
... SKIP).
Thank you for the patch! I've looked at 0012 patch. Regarding the
following part:
pg_replication_origin_advance() function
- transaction. Before using this function, the subscription needs
to be disabled
+ XXX? transaction. Before using this function, the subscription
needs to be disabled
temporarily either by ALTER SUBSCRIPTION ...
DISABLE or, the
we can remove "transaction", it seems a typo. The rest looks good to me.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
hanged the definition of pg_stat_statements, so I have added two
> extra queries for those upgrade paths in oldextversions.sql.
Thank you for committing both patches. Agreed with these changes.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
ambulkdelete and amvacuumcleanup so that the
leader can do that periodically, e.g., every 1000 blocks, while
vacuuming an index.
Regards,
[1]
https://www.postgresql.org/message-id/CAD21AoBW6SMJ96CNoMeu%2Bf_BR4jmatPcfVA016FdD2hkLDsaTA%40mail.gmail.com
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
On Thu, Apr 7, 2022 at 5:52 PM Masahiko Sawada wrote:
>
> On Thu, Apr 7, 2022 at 4:55 PM Julien Rouhaud wrote:
> >
> > On Thu, Apr 07, 2022 at 04:24:54PM +0900, Michael Paquier wrote:
> > > On Thu, Apr 07, 2022 at 03:14:01PM +0800, Julien Rouhaud wrote:
> > >
>
> Pushed.
Thanks!
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
ench, 4 clients (I have 4 cores) for 30 seconds, 3 times.
>
> Comparing master and this patch with track_io_timing activated, I see a 0.95%
> overhead, with a 2.6% noise level.
I've done the same test with a larger data set (10M tuples) on my
machine (MacOS):
HEAD: 5418.869 ms
Patched: 5367.234 ms
I can see about 1% overhead.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
On Wed, Apr 6, 2022 at 12:21 PM Noah Misch wrote:
>
> On Tue, Apr 05, 2022 at 04:41:28PM +0900, Masahiko Sawada wrote:
> > On Tue, Apr 5, 2022 at 4:08 PM Noah Misch wrote:
> > > On Tue, Apr 05, 2022 at 03:05:10PM +0900, Masahiko Sawada wrote:
> > > > I've att
On Tue, Apr 5, 2022 at 4:08 PM Noah Misch wrote:
>
> On Tue, Apr 05, 2022 at 03:05:10PM +0900, Masahiko Sawada wrote:
> > I've attached an updated patch. The patch includes a regression test
> > to detect the new violation as we discussed. I've confirmed that
> > Cirr
On Tue, Apr 5, 2022 at 12:38 PM Masahiko Sawada wrote:
>
> On Tue, Apr 5, 2022 at 10:46 AM Noah Misch wrote:
> >
> > On Tue, Apr 05, 2022 at 10:13:06AM +0900, Masahiko Sawada wrote:
> > > On Tue, Apr 5, 2022 at 9:21 AM Noah Misch wrote:
> > > > On Mon, Apr
On Tue, Apr 5, 2022 at 10:46 AM Noah Misch wrote:
>
> On Tue, Apr 05, 2022 at 10:13:06AM +0900, Masahiko Sawada wrote:
> > On Tue, Apr 5, 2022 at 9:21 AM Noah Misch wrote:
> > > On Mon, Apr 04, 2022 at 06:55:45PM +0900, Masahiko Sawada wrote:
> > > > On Mon,
On Tue, Apr 5, 2022 at 1:31 AM Julien Rouhaud wrote:
>
> On Tue, Apr 05, 2022 at 12:51:12AM +0900, Masahiko Sawada wrote:
> > On Mon, Apr 4, 2022 at 1:30 PM Julien Rouhaud wrote:
> > >
> > > Hmm, but AFAICS the json format would be stable as the counters are always
On Tue, Apr 5, 2022 at 9:21 AM Noah Misch wrote:
>
> On Mon, Apr 04, 2022 at 06:55:45PM +0900, Masahiko Sawada wrote:
> > On Mon, Apr 4, 2022 at 3:26 PM Noah Misch wrote:
> > > On Mon, Apr 04, 2022 at 08:20:08AM +0530, Amit Kapila wrote:
> > > > How about a comm
On Mon, Apr 4, 2022 at 1:30 PM Julien Rouhaud wrote:
>
> Hi,
>
> On Tue, Mar 01, 2022 at 11:35:32AM +0900, Masahiko Sawada wrote:
> > On Wed, Jan 19, 2022 at 5:52 PM Julien Rouhaud wrote:
> > >
> > > It seems that the regression tests aren't entirely sta
On Mon, Apr 4, 2022 at 3:26 PM Noah Misch wrote:
>
> On Mon, Apr 04, 2022 at 08:20:08AM +0530, Amit Kapila wrote:
> > On Mon, Apr 4, 2022 at 8:01 AM Noah Misch wrote:
> > > On Mon, Apr 04, 2022 at 10:28:30AM +0900, Masahiko Sawada wrote:
> > > > On Sun, Apr 3,
ecoding changes in transactions that create
> >> the sequence and add it to a publication. I think the agreement was that
> >> this behavior was incorrect, we should not decode changes until the
> >> subscription is refreshed. Doesn't that mean can't be any CREATE case,
> >> just ALTER?
> >>
> >
> > Yeah, but how will we distinguish them. Aren't they using the same
> > kind of WAL record?
> >
>
> Same WAL record, but the "created" flag which should distinguish these
> two cases, IIRC.
Since the "created" flag indicates that we created a new relfilenode
so it's true when both CREATE and ALTER.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
On Mon, Apr 4, 2022 at 11:50 AM Amit Kapila wrote:
>
> On Mon, Apr 4, 2022 at 8:01 AM Noah Misch wrote:
> >
> > On Mon, Apr 04, 2022 at 10:28:30AM +0900, Masahiko Sawada wrote:
> > > On Sun, Apr 3, 2022 at 9:45 AM Noah Misch wrote:
> > > > On Sat, Apr
On Sun, Apr 3, 2022 at 9:45 AM Noah Misch wrote:
>
> On Sat, Apr 02, 2022 at 08:44:45PM +0900, Masahiko Sawada wrote:
> > On Sat, Apr 2, 2022 at 7:04 PM Amit Kapila wrote:
> > > On Sat, Apr 2, 2022 at 1:43 PM Noah Misch wrote:
> > > > Some options:
> >
On Sat, Apr 2, 2022 at 7:04 PM Amit Kapila wrote:
>
> On Sat, Apr 2, 2022 at 1:43 PM Noah Misch wrote:
> >
> > On Sat, Apr 02, 2022 at 04:33:44PM +0900, Masahiko Sawada wrote:
> > > It seems that 0/B0706F72 is not a random value. Two subscriber logs
> > >
wrong when we read the
subskiplsn value by like "sub->skiplsn = subform->subskiplsn;".
Is it possible to run the test again with the attached patch?
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
add_logs_v2.patch
Description: Binary data
On Fri, Apr 1, 2022 at 5:10 PM Masahiko Sawada wrote:
>
> On Fri, Apr 1, 2022 at 4:44 PM Noah Misch wrote:
> >
> > On Tue, Mar 29, 2022 at 10:43:00AM +0530, Amit Kapila wrote:
> > > On Mon, Mar 21, 2022 at 5:51 PM Euler Taveira wrote:
> > > > On Mon, Mar 2
s://drive.google.com/file/d/16NkyNIV07o0o8WM7GwcaAYFQDPTkULkR/view?usp=sharing
Thank you for the report. I'm investigating this issue.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
hat until the transaction commits.
> >>
> >> So I guess that's correct, and the current behavior is a bug.
> >>
> >
> > Yes, I also think that is a bug.
> >
>
> OK
I also think that this is a bug. Given this behavior is a bug and
newly-added sequence data should be replicated only after ALTER
SUBSCRIPTION ... REFRESH PUBLICATION, is there any case where the
sequence message applied on the subscriber is transactional?
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
a good design, and adding a new callback introduces complexity.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
t.
> Attach the new version patch with this change.
>
Thank you for updating the patch. Looks good to me.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
the reloading has taken effect.
+$log_location = -s $node_subscriber->logfile;
+
+$node_publisher->safe_psql('postgres', "INSERT INTO tab_notrep VALUES (11)");
+
+$node_publisher->wait_for_catchup('tap_sub');
+
+$logfile = slurp_file($node_publisher->logfile, $log_location);
I think we should get the log location of the publisher node, not
subscriber node.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
On Fri, Mar 25, 2022 at 5:33 PM Amit Kapila wrote:
>
> On Fri, Mar 25, 2022 at 11:49 AM Masahiko Sawada
> wrote:
> >
> > On Fri, Mar 25, 2022 at 2:23 PM wangw.f...@fujitsu.com
> > wrote:
> >
> > Since commit 75b1521 added decoding of sequence to logical
&
pg_stat_get_subscription_stats(NULL) I found to
> also be wrong upthread.
Right. But it seems like we cannot simply add PG_ARGISNULL () to
PG_GETARG_DATUM(). There are some codes such as array_remove() and
array_replace() that call PG_GETARG_DATUM() and PG_ARGISNULL() and
pass these values to
the above concerns you mentioned such as introducing
additional complexity and a possible lag of progress updates. So if we
go with the current approach, I think we need to make sure enough (and
not too many) hash table entries.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
s_option_given = true;
+
+data->sequences = defGetBoolean(defel);
+}
But as far as I read changes, there is no use of this option, and this
code is not tested. Can we remove it or is it for upcoming changes?
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
tab_completion.patch
Description: Binary data
ed comments in the code.
> >
> > Do let me know what you think of the attached?
> It looks good to me. Just rebase it because the change in header(75b1521).
> I tested it and the result looks good to me.
Since commit 75b1521 added decoding of sequence to logical
replication, the patch need
more demand for this.
Marking as Returned with feedback makes sense to me.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
lel vacuums.
>
Can the leader pass a callback that checks PVIndStats to ambulkdelete
an amvacuumcleanup callbacks? I think that in the passed callback, the
leader checks if the number of processed indexes and updates its
progress information if the current progress needs to be updated.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
esults/vacuum.out
2022-03-22 03:28:09.813377179 +0100
@@ -181,7 +181,7 @@
SELECT pg_relation_size('vac_truncate_test') = 0;
?column?
--
- t
+ f
(1 row)
VACUUM (TRUNCATE FALSE, FULL TRUE) vac_truncate_test;
=== EOF ===
not ok 2 - regression tests pass
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
and the leader
deallocating the hash table entry.
BTW have we discussed another idea I mentioned before that we have the
leader process periodically check the number of completed indexes and
advertise it in its progress information? I'm not sure which one is
better but this idea would require only changes of vacuum code and
probably simpler than the current idea.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
On Thu, Mar 17, 2022 at 3:03 PM Amit Kapila wrote:
>
> On Wed, Mar 16, 2022 at 1:53 PM Masahiko Sawada wrote:
> >
> > I've attached an updated version patch.
> >
>
> The patch LGTM. I have made minor changes in comments and docs in the
> attached patch.
On Thu, Mar 17, 2022 at 7:14 PM Amit Kapila wrote:
>
> On Thu, Mar 17, 2022 at 12:27 PM Amit Kapila wrote:
> >
> > On Wed, Mar 16, 2022 at 7:38 PM Masahiko Sawada
> > wrote:
> > >
> > > After more thought, can we check only w
On Thu, Mar 17, 2022 at 5:52 PM Amit Kapila wrote:
>
> On Thu, Mar 17, 2022 at 12:39 PM osumi.takami...@fujitsu.com
> wrote:
> >
> > On Thursday, March 17, 2022 3:04 PM Amit Kapila
> > wrote:
> > > On Wed, Mar 16, 2022 at 1:53 PM Masahiko Sawada
> &g
On Wed, Mar 16, 2022 at 8:51 PM Amit Kapila wrote:
>
> On Tue, Mar 15, 2022 at 10:09 AM Masahiko Sawada
> wrote:
> >
> > On Tue, Mar 15, 2022 at 3:34 AM Melanie Plageman
> > wrote:
> > >
> > > On Mon, Mar 14, 2022 at 4:02 AM Masahiko Sawada
>
On Wed, Mar 16, 2022 at 11:57 AM wangw.f...@fujitsu.com
wrote:
>
> On Wed, Mar 9, 2022 at 2:45 PM Masahiko Sawada wrote:
> >
> Thanks for your comments.
>
> > On Wed, Mar 9, 2022 at 10:26 AM I wrote:
> > > On Tue, Mar 8, 2022 at 3:52 PM Masahiko Sawad
On Wed, Mar 16, 2022 at 1:20 PM Amit Kapila wrote:
>
> On Wed, Mar 16, 2022 at 7:58 AM Amit Kapila wrote:
> >
> > On Wed, Mar 16, 2022 at 6:03 AM Masahiko Sawada
> > wrote:
> > >
> > > On Tue, Mar 15, 2022 at 7:18 PM Amit Kapila
> > > wrot
On Wed, Mar 16, 2022 at 11:28 AM Amit Kapila wrote:
>
> On Wed, Mar 16, 2022 at 6:03 AM Masahiko Sawada wrote:
> >
> > On Tue, Mar 15, 2022 at 7:18 PM Amit Kapila wrote:
> > >
> > > On Tue, Mar 15, 2022 at 11:43 AM Masahiko Sawada
> > > wrote:
&g
On Tue, Mar 15, 2022 at 7:18 PM Amit Kapila wrote:
>
> On Tue, Mar 15, 2022 at 11:43 AM Masahiko Sawada
> wrote:
> >
> > I've attached an updated version patch.
> >
>
> Review:
> ===
Thank you for the comments.
> 1.
> +++ b/doc/src/sgml/log
On Tue, Mar 15, 2022 at 7:18 PM Amit Kapila wrote:
>
> On Tue, Mar 15, 2022 at 11:43 AM Masahiko Sawada
> wrote:
> >
>
> 6.
> @@ -1583,7 +1649,8 @@ apply_handle_insert(StringInfo s)
> TupleTableSlot *remoteslot;
> MemoryContext oldctx;
>
&g
Hi,
On Fri, Mar 11, 2022 at 8:37 PM osumi.takami...@fujitsu.com
wrote:
>
> On Friday, March 11, 2022 5:20 PM Masahiko Sawada
> wrote:
> > I've attached an updated version patch. This patch can be applied on top of
> > the
> > latest disable_on_error patch[1].
&g
On Tue, Mar 15, 2022 at 3:34 AM Melanie Plageman
wrote:
>
> On Mon, Mar 14, 2022 at 4:02 AM Masahiko Sawada wrote:
> >
> > On Mon, Mar 14, 2022 at 2:05 AM Melanie Plageman
> > wrote:
> > >
> > > On Sat, Mar 12, 2022 at 3:15 PM Andres Freund wrote:
>
On Mon, Mar 14, 2022 at 6:50 PM shiy.f...@fujitsu.com
wrote:
>
> On Fri, Mar 11, 2022 4:20 PM Masahiko Sawada wrote:
> >
> > I've attached an updated version patch. This patch can be applied on
> > top of the latest disable_on_error patch[1].
> >
>
> Thanks fo
e message for creating the
subscription at the end of CRAETE SUBSCRIPTION which basically
resolves them. A caveat is that if CREATE SUBSCRIPTION (that doesn't
involve replication slot creation) is rolled back, the first problem
still occurs. But it should not practically matter as a similar thing
is
Since we raise an error in case of out of memory, I think we can use
HASH_ENTER instead of HASH_ENTER_NULL. Or do we want to emit a
detailed error message here?
---
+ VacuumWorkerProgressHash = NULL;
This line is not necessary.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
On Thu, Mar 10, 2022 at 9:02 PM Amit Kapila wrote:
>
> On Tue, Mar 1, 2022 at 8:31 PM Masahiko Sawada wrote:
> >
> > I've attached an updated patch along with two patches for cfbot tests
> > since the main patch (0003) depends on the other two patches. Both
> > 0001
On Thu, Mar 10, 2022 at 2:10 PM osumi.takami...@fujitsu.com
wrote:
>
> On Wednesday, March 2, 2022 12:01 AM Masahiko Sawada
> wrote:
> > I've attached an updated patch along with two patches for cfbot tests since
> > the
> > main patch (0003) depends on the other
on_error is
changed? It doesn't affect the remote connection at all. I think it
can be changed without restarting like synchronous_commit option.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
On Wed, Mar 9, 2022 at 11:26 AM wangw.f...@fujitsu.com
wrote:
>
> On Tue, Mar 8, 2022 at 3:52 PM Masahiko Sawada wrote:
> > I've looked at the patch and have a question:
> Thanks for your review and comments.
>
> > +void
> > +SendKeepaliveIfNecessary(LogicalDeco
On Wed, Mar 9, 2022 at 12:37 PM Amit Kapila wrote:
>
> On Wed, Mar 9, 2022 at 6:29 AM Masahiko Sawada wrote:
> >
> > ---
> > It might have already been discussed but the worker disables the
> > subscription on an error but doesn't work for a fatal. Is that
&g
red the callback in the index AM's bulkdelete and
> vacuumcleanup, but I can imagine this is not possible since a leader could be
> busy vacuuming rather than updating counters, but I may be misunderstanding
> the suggestion.
Checking PVIndStats.status values is cheap. Probably the leader can
check it every 1GB index block, for example.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
ea I come up with is that the parallel vacuum leader checks
PVIndStats.status and updates how many indexes are processed to its
progress information. The leader can check it and update the progress
information before and after index vacuuming. And possibly we can add
a callback to the main loop of index AM's bulkdelete and vacuumcleanup
so that the leader can periodically make it up-to-date.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
doesn't work for a fatal. Is that
expected or should we handle that too?
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
On Tue, Mar 8, 2022 at 7:56 PM Amit Kapila wrote:
>
> On Mon, Mar 7, 2022 at 10:06 AM Amit Kapila wrote:
> >
> > On Mon, Mar 7, 2022 at 6:36 AM Masahiko Sawada
> > wrote:
> > >
> > > Thank you for the comment. +1.
> > >
> > > I've at
anges_count = 0;
+}
+}
Since we send a keepalive after continuously skipping 1 changes,
the originally reported issue can still occur if skipping 1
changes took more than the timeout and the walsender didn't send any
change while that, is that right?
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
_BLOBS);
+}
It seems to me that creating a shmem hash with max_table_size entries
for parallel vacuum process tracking is too much. IIRC an old patch
had parallel vacuum workers advertise its progress and changed the
pg_stat_progress_vacuum view so that it aggregates the results
including workers' stats. I think it’s better than the current one.
Why did you change that?
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
instructions.
Thank you for the comment. +1.
I've attached updated patches.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
v5-0002-Add-the-origin-name-and-remote-commit-LSN-to-logi.patch
Description: Binary data
v5-0001-Use-complete-sentences-in-logical-replication-wor.patch
Description: Binary data
On Fri, Mar 4, 2022 at 2:55 PM Amit Kapila wrote:
>
> On Fri, Mar 4, 2022 at 6:40 AM Masahiko Sawada wrote:
> >
> > Attached updated version patches.
> >
>
> The patch looks mostly good to me. Few minor comments:
Thank you for the comments!
> 1. I think
On Wed, Mar 2, 2022 at 6:38 PM osumi.takami...@fujitsu.com
wrote:
>
> On Wednesday, March 2, 2022 12:47 PM Masahiko Sawada
> wrote:
> > After more thoughts, should we do both AbortOutOfAnyTransaction() and error
> > message handling while holding interrupts? That is,
&g
On Fri, Mar 4, 2022 at 11:27 AM osumi.takami...@fujitsu.com
wrote:
>
> On Friday, March 4, 2022 10:09 AM Masahiko Sawada
> wrote:
> > On Thu, Mar 3, 2022 at 10:02 PM Masahiko Sawada
> > wrote:
> > >
> > >
> > > I'm updating the patches and wi
On Thu, Mar 3, 2022 at 10:02 PM Masahiko Sawada wrote:
>
>
> I'm updating the patches and will submit them.
Attached updated version patches.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
v3-0002-Add-the-origin-name-and-remote-commit-LSN-to-logi.patch
Descriptio
On Thu, Mar 3, 2022 at 3:37 PM Amit Kapila wrote:
>
> On Wed, Mar 2, 2022 at 1:05 PM Masahiko Sawada wrote:
> >
> > On Wed, Mar 2, 2022 at 4:14 PM Amit Kapila wrote:
> >
> > I've attached updated patches.
> >
>
> The first patch LGTM. Some comment
On Wed, Mar 2, 2022 at 4:07 PM Kyotaro Horiguchi
wrote:
>
> At Wed, 2 Mar 2022 14:39:54 +0900, Masahiko Sawada
> wrote in
> > On Wed, Mar 2, 2022 at 11:55 AM Amit Kapila wrote:
> > >
> > > On Mon, Feb 28, 2022 at 5:46 PM Masahiko Sawada
> > > wrote:
On Wed, Mar 2, 2022 at 4:14 PM Amit Kapila wrote:
>
> On Wed, Mar 2, 2022 at 9:33 AM Masahiko Sawada wrote:
> >
> > On Wed, Mar 2, 2022 at 12:21 PM Amit Kapila wrote:
> > >
> > > On Wed, Mar 2, 2022 at 8:25 AM Peter Smith wrote:
> > > >
> >
On Wed, Mar 2, 2022 at 11:55 AM Amit Kapila wrote:
>
> On Mon, Feb 28, 2022 at 5:46 PM Masahiko Sawada wrote:
> >
> > I've attached two patches: the first one changes
> > apply_error_callback() so that it uses complete sentences with if-else
> > blocks in or
.h? worker_internal.h
is the header file shared by logical replication workers such as apply
worker, tablesync worker, and launcher. So it might not be advisable
to include it in pgstat.c.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
On Wed, Mar 2, 2022 at 12:21 PM Amit Kapila wrote:
>
> On Wed, Mar 2, 2022 at 8:25 AM Peter Smith wrote:
> >
> > On Mon, Feb 28, 2022 at 11:16 PM Masahiko Sawada
> > wrote:
> > >
> > > The errcontext message would become like follows:
> > &
+$cmd = qq(DROP INDEX tbl_unique);
+$node_subscriber->safe_psql('postgres', $cmd);
In the newly added tap tests, all queries are consistently assigned to
$cmd and executed even when the query is used only once. It seems a
different style from the one in other tap tests. Is there any reason
why we do this style for all queries in the tap tests?
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
tps://www.postgresql.org/message-id/20220125063131.4cmvsxbz2tdg6g65%40alap3.anarazel.de
[2]
https://www.postgresql.org/message-id/CAD21AoBarBf2oTF71ig2g_o%3D3Z_Dt6_sOpMQma1kFgbnA5OZ_w%40mail.gmail.com
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
v12-0003-Add-ALTER-SUBSCRIPTION-.-SKIP-to-s
On Wed, Jan 19, 2022 at 5:52 PM Julien Rouhaud wrote:
>
> Hi,
>
> On Tue, Nov 16, 2021 at 04:37:44PM +0900, Masahiko Sawada wrote:
> >
> > I've attached an updated patch. Please review it.
>
> It seems that the regression tests aren't entirely stable, per cfbot:
Hi,
Sorry for the late reply.
On Fri, Nov 19, 2021 at 7:24 AM Melanie Plageman
wrote:
>
> On Sun, Aug 22, 2021 at 9:47 PM Masahiko Sawada wrote:
> >
> > On Thu, Aug 19, 2021 at 10:52 PM Ranier Vilela wrote:
> > >
> > > Em qui., 19 de ago. de 2021 às 09:
else
blocks in order to have a translation work, the second patch adds the
origin name and commit-LSN to the errcontext message.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
From dc6d97c71394c7c216920b9aa1d55bf33c5ac472 Mon Sep 17 00:00:00 2001
From: Masahiko Sawada
Date: Thu, 24 Feb 2
On Mon, Feb 28, 2022 at 11:52 AM Amit Kapila wrote:
>
> On Mon, Feb 28, 2022 at 8:17 AM Masahiko Sawada wrote:
> >
> > On Mon, Feb 28, 2022 at 11:33 AM Amit Kapila
> > wrote:
> > >
> > > >
> > > > (2) doc/src/sgml/monitoring.sgm
statistics for all
> > +subscriptions.
> >
> >
> > I felt we could improve the first sentence.
> >
> > From:
> > Resets statistics for a single subscription shown in the..
> >
> > To(idea1):
> > Resets statistics for a single subscription defined by the argument to zero.
> >
>
> Okay, I can use this one.
Are you going to remove the part "shown in the
pg_stat_subsctiption_stats view"? I think it's better to keep it in
order to make it clear which statistics the function resets as we have
pg_stat_subscription and pg_stat_subscription_stats.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
On Sat, Feb 26, 2022 at 11:51 AM Amit Kapila wrote:
>
> On Thu, Feb 24, 2022 at 9:20 PM Masahiko Sawada wrote:
> >
>
> I have reviewed the latest version and made a few changes along with
> fixing some of the pending comments by Peter Smith.
Thank you for updating the
Hi,
Thank you for the comments!
On Thu, Feb 24, 2022 at 4:20 PM tanghy.f...@fujitsu.com
wrote:
>
> On Thu, Feb 24, 2022 9:33 AM Masahiko Sawada wrote:
> >
> > Thank you for the comments! I've attached the latest version patch
> > that incorporated all comments I got so
On Thu, Feb 24, 2022 at 8:08 PM Amit Kapila wrote:
>
> On Thu, Feb 24, 2022 at 1:20 PM Masahiko Sawada wrote:
> >
> > Here are some comments:
> >
> > Why do we need SyncTableStartWrapper() and ApplyLoopWrapper()?
> >
>
> I have given this comment to mov
On Thu, Feb 24, 2022 at 9:23 PM Peter Eisentraut
wrote:
>
>
> On 24.02.22 12:46, Masahiko Sawada wrote:
> >> We have a view called pg_stat_activity, which is very well known. From
> >> that perspective, "activity" means what is happening right now or
g tests for stats for each and every case as it
> is not reliable in nature (the message can be lost). If we can find a
> reliable way then it is okay.
Yeah, the messages can even be out-of-order. Particularly, in this
test, the apply worker and table sync worker keep reporting the
messages, it's quite possible that the test becomes unstable. I
remember we removed unstable tests of resetting statistics before
(e.g., see fc6950913).
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
On Thu, Feb 24, 2022 at 6:53 PM Peter Eisentraut
wrote:
>
> On 24.02.22 02:32, Masahiko Sawada wrote:
> > On Wed, Feb 23, 2022 at 12:08 PM Peter Smith wrote:
> >>
> >> Hi. Below are my review comments for the v1 patch.
> >
> > Thank you for the commen
801 - 900 of 2763 matches
Mail list logo
