tely so that it won't be lost if some other internal
+* error occurs in the following code.
+*/
+ EmitErrorReport();
+ AbortOutOfAnyTransaction();
+ FlushErrorState();
Do we need to hold interrupts during cleanup here?
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
is_commit)
+MyLogicalRepWorker->commit_count++;
+else
+MyLogicalRepWorker->abort_count++;
+}
It's slightly odd and it seems unnecessary to me that we modify fields
of MyLogicalRepWorker in pgstat.c. Although this function has “report”
in its name but it just inc
initial table sync for test_tab1 to finish.
>
> IMO all these "table sync" should be changed to "tablesync", because a
> table "sync error" sounds like something completely different to a
> "tablesync error".
>
> SUGGESTIONS
> - "W
On Wed, Feb 23, 2022 at 11:14 AM Andres Freund wrote:
>
> Hi,
>
> On 2022-02-22 14:45:19 +0900, Masahiko Sawada wrote:
> > I've attached a patch that changes pg_stat_subscription_workers view.
>
> Thanks for working on this!
>
> Why are the stats stored
On Tue, Feb 22, 2022 at 9:22 PM osumi.takami...@fujitsu.com
wrote:
>
> On Tuesday, February 22, 2022 2:45 PM Masahiko Sawada
> wrote:
> > I've attached a patch that changes pg_stat_subscription_workers view.
> > It removes non-cumulative values such as error deta
On Tue, Feb 22, 2022 at 6:53 PM Amit Kapila wrote:
>
> On Tue, Feb 22, 2022 at 11:15 AM Masahiko Sawada
> wrote:
> >
> > I've attached a patch that changes pg_stat_subscription_workers view.
> > It removes non-cumulative values such as error details such as
> >
: apply_error_count
and sync_error_count. Since the new view name is under discussion I
temporarily chose pg_stat_subscription_activity.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
v1-0001-Reconsider-pg_stat_subscription_workers-view.patch
Description: Binary data
does not change the fact that we'd
> better address the second case on HEAD IMO.
>
> Thoughts?
Agreed.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
On Sun, Feb 20, 2022 at 1:02 AM Andres Freund wrote:
>
> Hi,
>
> On 2022-02-19 22:38:19 +0900, Masahiko Sawada wrote:
> > On Sat, Feb 19, 2022 at 5:32 AM Andres Freund wrote:
> > > On 2022-02-18 17:26:04 +0900, Masahiko Sawada wrote:
> > > > With th
On Sat, Feb 19, 2022 at 4:47 AM David G. Johnston
wrote:
>
> On Fri, Feb 18, 2022 at 1:26 AM Masahiko Sawada wrote:
>>
>>
>> Here is the summary of the discussion, changes, and plan.
>>
>> 1. Move some error information such as the error message to a new
>
e:
> >> >
> >> > On Fri, Feb 18, 2022 at 1:26 AM Masahiko Sawada
> >> > wrote:
> >> >>
> >> >>
> >> >> Here is the summary of the discussion, changes, and plan.
> >> >>
> >> >> 1. M
On Sat, Feb 19, 2022 at 5:32 AM Andres Freund wrote:
>
> Hi,
>
> On 2022-02-18 17:26:04 +0900, Masahiko Sawada wrote:
> > With this change, pg_stat_subscription_workers will be like:
> >
> > * subid
> > * subname
> > * subrelid
> > * error_
On Wed, Feb 16, 2022 at 8:36 PM Masahiko Sawada wrote:
>
> On Wed, Feb 16, 2022 at 5:49 PM Amit Kapila wrote:
> >
> > On Tue, Feb 15, 2022 at 11:56 PM Andres Freund wrote:
> > >
> > > On 2022-02-03 13:33:08 +0900, Masahiko Sawada wrote:
> > > > I
On Fri, Feb 18, 2022 at 1:48 PM Amit Kapila wrote:
>
> On Wed, Feb 16, 2022 at 4:56 PM Amit Kapila wrote:
> >
> > On Wed, Feb 16, 2022 at 5:57 AM Masahiko Sawada
> > wrote:
> > >
> > > While reading the code, I realized that the second sentence
able in
the list even after an error. This probably means that autovacuum
eventually succeeds to process all tables that trigger the failsafe
mode, ensuring advancing datfrozenxid, which is great.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
On Wed, Feb 16, 2022 at 5:49 PM Amit Kapila wrote:
>
> On Tue, Feb 15, 2022 at 11:56 PM Andres Freund wrote:
> >
> > On 2022-02-03 13:33:08 +0900, Masahiko Sawada wrote:
> > > I see that important information such as error-XID that can be used
> > > for ALTER
On Wed, Feb 16, 2022 at 3:22 PM Kyotaro Horiguchi
wrote:
>
> At Wed, 16 Feb 2022 14:58:23 +0900, Masahiko Sawada
> wrote in
> > Or it's possible that the process took a time to clean up the
> > temporary replication slot?
>
> Checkpointer may take ReplicationSlotCon
session until the
> > server is shut down. Even though pg_basebackup clearly finished? Uh, huh?
>
> It seems to me so, too.
>
> > I guess it's conceivable that the backend was still working through process
> > shutdown? But it doesn't seem too likely, given that several other
> > connections
> > manage to get through entire connect / disconnect cycles?
>
> Yes, but since postmaster seems thinking that process is gone.
Or it's possible that the process took a time to clean up the
temporary replication slot?
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
xit(0);
}
IIUC the apply worker normally exits here when the subscription is
disabled since we don't stop the apply worker during ALTER
SUBSCRIPTION DISABLE. I've attached a patch to remove it.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
fix_comment_in_worker.c.patch
Description: Binary data
On Thu, Feb 3, 2022 at 2:35 PM Masahiko Sawada wrote:
>
> On Thu, Feb 3, 2022 at 1:48 PM David G. Johnston
> wrote:
> >
> > On Wednesday, February 2, 2022, Masahiko Sawada
> > wrote:
> >>
> >> and have other error
> >> information in pg_st
On Tue, Feb 15, 2022 at 12:09 PM Kyotaro Horiguchi
wrote:
>
> At Mon, 14 Feb 2022 17:20:16 -0800, Andres Freund wrote
> in
> > Hi,
> >
> > On 2021-12-22 22:34:45 +0900, Masahiko Sawada wrote:
> > > I've attached an updated patch. Please review it.
So I think radix tree would be a potent candidate. I have
done the insertion and search implementation.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
On Thu, Jan 27, 2022 at 10:42 PM Peter Eisentraut
wrote:
>
> On 26.01.22 05:05, Masahiko Sawada wrote:
> >> I think it is okay to clear after the first successful application of
> >> any transaction. What I was not sure was about the idea of giving
> >>
m not sure that the overheads result in
visible negative performance impact particularly because the calling
to LockBufferForCleanup() is likely to accompany wait in the first
place. BTW I think calling to LockBufferForCleanup() in a critical
section is a bad idea for sure since it becomes uninterruptible.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
assForm->relfrozenxid));
+ Assert(!MultiXactIdIsValid(classForm->relminmxid));
+ continue;
+ }
+
+ table_xid_age = DirectFunctionCall1(xid_age,
classForm->relfrozenxid);
+ table_mxid_age = DirectFunctionCall1(mxid_age,
classForm->relminmxid);
+
I think that instead of calling xid_age and mxid_age for each
relation, we can compute the thresholds for xid and mxid once, and
then compare them to relation's relfrozenxid and relminmxid.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
On Thu, Feb 3, 2022 at 1:48 PM David G. Johnston
wrote:
>
> On Wednesday, February 2, 2022, Masahiko Sawada wrote:
>>
>> and have other error
>> information in pg_stat_subscription_workers view.
>
>
> What benefit is there to keeping the existing collector-base
be used
for ALTER SUBSCRIPTION SKIP needs to be stored in a reliable way, and
using system catalogs is a reasonable way for this purpose. But it's
still unclear to me why all error information that is currently shown
in pg_stat_subscription_workers view, including error-XID and the
error message, relation OID, action, etc., need to be stored in the
catalog. The information other than error-XID doesn't necessarily need
to be reliable compared to error-XID. I think we can have
error-XID/LSN in the pg_subscription catalog and have other error
information in pg_stat_subscription_workers view. After the user
checks the current status of logical replication by checking
error-XID/LSN, they can check pg_stat_subscription_workers for
details.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
the reasons quoted in my previous
> email [1].
I see that it's better to use a better IPC for ALTER SUBSCRIPTION SKIP
feature to pass error-XID or error-LSN information to the worker
whereas I'm also not sure of the advantages in storing all error
information in a system catalog. Since what we need to do for this
purpose is only error-XID/LSN, we can store only error-XID/LSN in the
catalog? That is, the worker stores error-XID/LSN in the catalog on an
error, and ALTER SUBSCRIPTION SKIP command enables the worker to skip
the transaction in question. The worker clears the error-XID/LSN after
successfully applying or skipping the first non-empty transaction.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
cility to run queries in single-user mode will
also be helpful for testing a new vacuum option/command that is
intended to use in emergency cases and proposed here[1].
Regards,
[1]
https://www.postgresql.org/message-id/flat/20220128012842.GZ23027%40telsasoft.com#b76c13554f90d1c8bb5532d6f3e5cbf8
--
Masah
On Wed, Jan 26, 2022 at 8:02 PM Amit Kapila wrote:
>
> On Wed, Jan 26, 2022 at 12:51 PM Masahiko Sawada
> wrote:
> >
> > On Wed, Jan 26, 2022 at 1:43 PM David G. Johnston
> > wrote:
> > >
> > > We probably should just provide an option for the user
On Wed, Jan 26, 2022 at 1:43 PM David G. Johnston
wrote:
>
> On Tue, Jan 25, 2022 at 9:16 PM Amit Kapila wrote:
>>
>> On Wed, Jan 26, 2022 at 9:36 AM Masahiko Sawada
>> wrote:
>> > On Wed, Jan 26, 2022 at 12:54 PM Amit Kapila
>> > wrote:
&
On Wed, Jan 26, 2022 at 7:05 AM David G. Johnston
wrote:
>
> On Tue, Jan 25, 2022 at 8:33 AM Masahiko Sawada wrote:
>>
>> Given that we cannot use rely on the pg_stat_subscription_workers view
>> for this purpose, we would need either a new sub-system that tracks
>
On Wed, Jan 26, 2022 at 12:54 PM Amit Kapila wrote:
>
> On Wed, Jan 26, 2022 at 8:55 AM Masahiko Sawada wrote:
> >
> > On Wed, Jan 26, 2022 at 11:51 AM Masahiko Sawada
> > wrote:
> > >
> > > On Wed, Jan 26, 2022 at 11:28 AM Amit Kapila
>
On Wed, Jan 26, 2022 at 11:51 AM Masahiko Sawada wrote:
>
> On Wed, Jan 26, 2022 at 11:28 AM Amit Kapila wrote:
> >
> > On Tue, Jan 25, 2022 at 8:39 PM Masahiko Sawada
> > wrote:
> > >
> > > On Tue, Jan 25, 2022 at 11:58 PM David G. Johnston
> >
On Wed, Jan 26, 2022 at 11:28 AM Amit Kapila wrote:
>
> On Tue, Jan 25, 2022 at 8:39 PM Masahiko Sawada wrote:
> >
> > On Tue, Jan 25, 2022 at 11:58 PM David G. Johnston
> > wrote:
> > >
> > > On Tue, Jan 25, 2022 at 7:47 AM Masahiko Sawada
> >
On Wed, Jan 26, 2022 at 12:14 AM David G. Johnston
wrote:
>
>
> On Tue, Jan 25, 2022 at 8:09 AM Masahiko Sawada wrote:
>>
>> On Tue, Jan 25, 2022 at 11:58 PM David G. Johnston
>> wrote:
>> >
>> > On Tue, Jan 25, 2022 at 7:47 AM Masahiko Sawada
>
On Tue, Jan 25, 2022 at 11:58 PM David G. Johnston
wrote:
>
> On Tue, Jan 25, 2022 at 7:47 AM Masahiko Sawada wrote:
>>
>> Yeah, I think it's a good idea to clear the subskipxid after the first
>> transaction regardless of whether the worker skipped it.
>>
>
&
> operating mode. If that first transaction xid isn't the one being specified
> to skip the worker should error with "skipping transaction failed, xid 123
> expected but 456 found".
Yeah, I think it's a good idea to clear the subskipxid after the first
transaction regardless of whether the worker skipped it.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
on the
> subscriber.
>
> This view can be extended in the future to track other xact related
> statistics like the number of xacts committed/aborted for subscription
> workers.
>
> Author: Masahiko Sawada
> Reviewed-by: Greg Nancarrow, Hou Zhijie, Tang
On Mon, Jan 24, 2022 at 5:00 PM David G. Johnston
wrote:
>
> On Sun, Jan 23, 2022 at 11:55 PM Masahiko Sawada
> wrote:
>>
> >Similarly, the same is true
> >for clearing subskipxid.
>
> I'm confused - pg_subscription is a catalog, not a stat view. Why is
plication stream; perform rollback on xid
> 4(out). update pg_stat_subscription_worker to report the failure, including
> xid of the transaction
> 5(out). wait for the user to manually restart the replication stream
Do you mean that there always is user intervention after error so the
replication stream can resume?
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
On Fri, Jan 21, 2022 at 8:55 PM Amit Kapila wrote:
>
> On Fri, Jan 21, 2022 at 10:10 AM Masahiko Sawada
> wrote:
> >
> > On Fri, Jan 21, 2022 at 1:20 PM Amit Kapila wrote:
> > >
> > > What do we want to indicate by [, ... ]? To me, it appears like
> &g
On Fri, Jan 21, 2022 at 9:13 PM Amit Kapila wrote:
>
> On Fri, Jan 21, 2022 at 5:25 PM Amit Kapila wrote:
> >
> > On Fri, Jan 21, 2022 at 10:10 AM Masahiko Sawada
> > wrote:
> > >
> >
> > Few things that I think we can improve in 028_skip
On Thu, Jan 20, 2022 at 4:14 AM John Naylor
wrote:
>
> On Wed, Jan 19, 2022 at 12:46 AM Masahiko Sawada
> wrote:
> >
> > On Fri, Jan 14, 2022 at 7:04 AM Bossart, Nathan wrote:
> > >
> > > I guess I'm ultimately imagining the new options as replacing
since the remote
LSN of the subscriber’s origin is always updated first, then the
confirm_flush_lsn of the slot on the primary is updated, and then the
confirm_flush_lsn of the slot on the standby is synchronized.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
On Fri, Jan 21, 2022 at 1:20 PM Amit Kapila wrote:
>
> On Tue, Jan 18, 2022 at 9:21 AM Masahiko Sawada wrote:
> >
> > On Tue, Jan 18, 2022 at 12:37 PM Amit Kapila
> > wrote:
> > >
> > > On Tue, Jan 18, 2022 at 8:34 AM tanghy.f...@fujitsu.com
> >
On Wed, Jan 19, 2022 at 5:58 PM Amit Kapila wrote:
>
> On Wed, Jan 19, 2022 at 12:46 PM Masahiko Sawada
> wrote:
> >
> > On Wed, Jan 19, 2022 at 12:22 PM osumi.takami...@fujitsu.com
> > wrote:
> > >
> > > (6) apply_handle
On Wed, Jan 19, 2022 at 4:14 PM Greg Nancarrow wrote:
>
> On Tue, Jan 18, 2022 at 5:05 PM Masahiko Sawada wrote:
> >
> > I've attached a rebased patch.
>
> A couple of comments for the v8 patch:
Thank you for the comments!
>
> doc/src/sgml/logical-replication.sg
that is why we have 2 possible options as
> below:
> postgres=# ALTER SUBSCRIPTION sub1 SET
> (PUBLICATION
>
> Whereas in the case of SKIP there is only one possible tab completion
> option i.e XID. We handle similarly in case of WITH option, we specify
> "WITH (" in case of tab completion for "CREATE PUBLICATION pub1"
> postgres=# CREATE PUBLICATION pub1
> FOR ALL TABLESFOR ALL TABLES IN SCHEMA FOR TABLE
>WITH (
Right. I've incorporated this comment into the latest v9 patch[1].
Regards,
[1]
https://www.postgresql.org/message-id/CAD21AoDOuNtvFUfU2wH2QgTJ6AyMXXh_vdA87qX0mUibdsrYTg%40mail.gmail.com
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
On Fri, Jan 21, 2022 at 1:18 AM Peter Eisentraut
wrote:
>
> On 18.01.22 07:05, Masahiko Sawada wrote:
> > I've attached a rebased patch.
>
> I think this is now almost done. Attached I have a small fixup patch
> with some documentation proof-reading, and removing
On Wed, Jan 19, 2022 at 12:22 PM osumi.takami...@fujitsu.com
wrote:
>
> On Tuesday, January 18, 2022 3:05 PM Masahiko Sawada
> wrote:
> > I've attached a rebased patch.
> Thank you for your rebase !
>
> Several review comments on v8.
Thank you for the comments!
>
think it might also be a good start inventing something for (1). For
instance, a selector for VACUUM statement I came up with is:
VACUUM (verbose on) TABLES WITH (min_xid_age = 16);
or
VACUUM (verbose on) TABLES WITH (min_age = failsafe_limit);
We can expand it in the future to select tables by, for example, dead
tuple ratio, size, etc.
It's a random thought but maybe worth considering.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
On Tue, Jan 18, 2022 at 2:37 PM osumi.takami...@fujitsu.com
wrote:
>
> On Tuesday, January 18, 2022 1:39 PM Masahiko Sawada
> wrote:
> > I've attached an updated patch. All comments I got so far were incorporated
> > into this patch unless I'm missing something.
>
>
On Tue, Jan 18, 2022 at 12:20 PM osumi.takami...@fujitsu.com
wrote:
>
> On Monday, January 17, 2022 9:52 PM Masahiko Sawada
> wrote:
> > Thank you for the comments!
> ..
> > > (2) Minor improvement suggestion of comment in
> > > src/backend/replication/lo
On Tue, Jan 18, 2022 at 12:04 PM tanghy.f...@fujitsu.com
wrote:
>
> On Mon, Jan 17, 2022 2:18 PM Masahiko Sawada wrote:
> >
> > I've attached an updated patch. Please review it.
> >
>
> Thanks for updating the patch. Few comments:
>
> 1)
>
On Tue, Jan 18, 2022 at 12:37 PM Amit Kapila wrote:
>
> On Tue, Jan 18, 2022 at 8:34 AM tanghy.f...@fujitsu.com
> wrote:
> >
> > On Mon, Jan 17, 2022 2:18 PM Masahiko Sawada wrote:
> > >
> >
> > 2) The following two places are not consistent in whether
On Tue, Jan 18, 2022 at 10:36 AM Greg Nancarrow wrote:
>
> On Mon, Jan 17, 2022 at 5:18 PM Masahiko Sawada wrote:
> >
> > I've attached an updated patch. Please review it.
> >
>
> Some review comments for the v6 patch:
Thank you for the comments!
>
>
>
On Mon, Jan 17, 2022 at 10:15 PM Amit Kapila wrote:
>
> On Mon, Jan 17, 2022 at 6:22 PM Masahiko Sawada wrote:
> >
> > >
> > > (5)
> > >
> > > I can miss something here but, in one of
> > > the past discussions, there seems a consensus
Again, I don't follow what you mean by full-width character in this context.
>
> (9) the header comments of clear_subscription_skip_xid
>
> +/* clear subskipxid of pg_subscription catalog */
>
> Should start with an upper letter ?
Okay, I'll change it.
>
> (10) some variable declarations and initialization of
> clear_subscription_skip_xid
>
> There's no harm in moving below codes into a condition case
> where the user didn't change the subskipxid before
> apply worker clearing it.
>
> + boolnulls[Natts_pg_subscription];
> + boolreplaces[Natts_pg_subscription];
> + Datum values[Natts_pg_subscription];
> +
> + memset(values, 0, sizeof(values));
> + memset(nulls, false, sizeof(nulls));
> + memset(replaces, false, sizeof(replaces));
>
Will move.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
On Mon, Jan 17, 2022 at 5:03 PM osumi.takami...@fujitsu.com
wrote:
>
> On Monday, January 17, 2022 3:18 PM Masahiko Sawada
> wrote:
> > I've attached an updated patch. Please review it.
> Hi, thank you for sharing a new patch.
> Few comments on the v6.
Thank you for the c
On Mon, Jan 17, 2022 at 2:48 PM Amit Kapila wrote:
>
> On Mon, Jan 17, 2022 at 9:49 AM Masahiko Sawada wrote:
> >
> > On Sat, Jan 15, 2022 at 7:24 PM Amit Kapila wrote:
> > >
> >
> > > 6.
> > > +static void
> > > +maybe_start
On Fri, Jan 14, 2022 at 9:05 PM vignesh C wrote:
>
> On Fri, Jan 14, 2022 at 7:49 AM Masahiko Sawada wrote:
> >
> > On Wed, Jan 12, 2022 at 11:10 PM vignesh C wrote:
> > >
> > > On Wed, Jan 12, 2022 at 11:32 AM Masahiko Sawada
> > > wrote:
> >
On Sat, Jan 15, 2022 at 7:24 PM Amit Kapila wrote:
>
> On Fri, Jan 14, 2022 at 7:49 AM Masahiko Sawada wrote:
> >
> > I agree with all the comments above. I've attached an updated patch.
> >
>
> Review comments
>
Thank you for the comments!
On Thu, Jan 13, 2022 at 10:07 AM tanghy.f...@fujitsu.com
wrote:
>
> On Wed, Jan 12, 2022 2:02 PM Masahiko Sawada wrote:
> >
> > I've attached an updated patch that incorporated all comments I got so far.
> >
>
> Thanks for updating the patch. Here are some comment
On Wed, Jan 12, 2022 at 11:10 PM vignesh C wrote:
>
> On Wed, Jan 12, 2022 at 11:32 AM Masahiko Sawada
> wrote:
> >
> > On Wed, Jan 12, 2022 at 12:21 PM Amit Kapila
> > wrote:
> > >
> > > On Wed, Jan 12, 2022 at 5:49 AM Masahiko Sawada
> >
inal_position column) are shown in separate views.
Also, I’m not sure how useful index_tuples_removed is; what can we
infer from this value (without a total number)?
Regards,
[1] https://en.wikipedia.org/wiki/Posting_style#Top-posting
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
nly tables whose age is older than
the given value. If the value is omitted, we vacuum only tables whose
age exceeds a threshold (say autovacuum_freeze_max_age * 0.95), which
can be used in an emergency case and output in GetNewTransactionID()
WARNINGs output. vacuumdb’s --min-xid-age and --min-mxid-age can use
this option instead of fetching the list of tables from the server.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
On Mon, Jan 10, 2022 at 6:27 PM vignesh C wrote:
>
> On Fri, Jan 7, 2022 at 11:23 AM Masahiko Sawada wrote:
> >
> > On Fri, Jan 7, 2022 at 10:04 AM Masahiko Sawada
> > wrote:
> > >
> > > On Wed, Jan 5, 2022 at 12:31 PM Amit Kapila
> > > wro
On Wed, Jan 12, 2022 at 12:21 PM Amit Kapila wrote:
>
> On Wed, Jan 12, 2022 at 5:49 AM Masahiko Sawada wrote:
> >
> > On Tue, Jan 11, 2022 at 7:08 PM Amit Kapila wrote:
> > >
> > > On Tue, Jan 11, 2022 at 1:51 PM Masahiko Sawada
> > > wrote
On Tue, Jan 11, 2022 at 7:11 PM Amit Kapila wrote:
>
> On Tue, Jan 11, 2022 at 8:52 AM Masahiko Sawada wrote:
> >
> > On Mon, Jan 10, 2022 at 8:50 PM Amit Kapila wrote:
> > >
> > >
> > > Few other comments on the latest patch:
> > > =
On Tue, Jan 11, 2022 at 7:08 PM Amit Kapila wrote:
>
> On Tue, Jan 11, 2022 at 1:51 PM Masahiko Sawada wrote:
> >
> > On Tue, Jan 11, 2022 at 3:12 PM Amit Kapila wrote:
> > >
> > > On Tue, Jan 11, 2022 at 8:52 AM Masahiko Sawada
> > > wrote:
&g
On Tue, Jan 11, 2022 at 3:12 PM Amit Kapila wrote:
>
> On Tue, Jan 11, 2022 at 8:52 AM Masahiko Sawada wrote:
> >
> > On Mon, Jan 10, 2022 at 8:50 PM Amit Kapila wrote:
> > >
> > > I was thinking what if we don't advance origin explicitly in this
> > &
awada-San or others think about this?
Agreed. The automatically setting XID would be a good idea but we can
do that in a separate patch so we can keep the first patch simple.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
On Mon, Jan 10, 2022 at 8:50 PM Amit Kapila wrote:
>
> On Thu, Dec 16, 2021 at 11:12 AM Masahiko Sawada
> wrote:
> >
> > On Thu, Dec 16, 2021 at 2:21 PM Amit Kapila wrote:
> > >
> > > >
> > > > So if skip_xid is already changed, the apply
On Fri, Jan 7, 2022 at 10:04 AM Masahiko Sawada wrote:
>
> On Wed, Jan 5, 2022 at 12:31 PM Amit Kapila wrote:
> >
> > On Mon, Dec 27, 2021 at 9:54 AM Masahiko Sawada
> > wrote:
> > >
> > > On Thu, Dec 16, 2021 at 2:42 PM Masahiko Sawada
> > &g
On Wed, Jan 5, 2022 at 12:31 PM Amit Kapila wrote:
>
> On Mon, Dec 27, 2021 at 9:54 AM Masahiko Sawada wrote:
> >
> > On Thu, Dec 16, 2021 at 2:42 PM Masahiko Sawada
> > wrote:
> > >
> > > On Thu, Dec 16, 2021 at 2:21 PM Amit Kapila
> > > w
On Tue, Jan 4, 2022 at 12:05 PM Kyotaro Horiguchi
wrote:
>
> At Wed, 29 Dec 2021 10:34:31 +0900, Masahiko Sawada
> wrote in
> > On Tue, Dec 28, 2021 at 3:29 PM Fujii Masao
> > wrote:
> > >
> > >
> > >
> > > On 2021/12/28 9:32, Masahi
e the replication slot’s two_phase is false and the
plugin’s two-phase option is on and vice versa? I think that we can
have replication slots always have two_phase_at value and remove the
two_phase field from the view.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
On Tue, Dec 28, 2021 at 3:29 PM Fujii Masao wrote:
>
>
>
> On 2021/12/28 9:32, Masahiko Sawada wrote:
> > Doesn't this query return 64? So the expression "substring(str for
> > (SELECT max_identifier_length FROM pg_control_init()))" returns the
> > first
o be 63 (NAMEDATALEN - 1) characters. It also seems to be
fine to use current_setting('max_identifier_length') instead of
max_identifier_length of pg_control_init().
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
tring in the test
> query's condition to less than NAMEDATALEN.
Good idea. But the application_name is actually truncated to 63
characters (NAMEDATALEN - 1)? If so, we need to do substring(... for
63) instead.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
On Thu, Dec 16, 2021 at 2:42 PM Masahiko Sawada wrote:
>
> On Thu, Dec 16, 2021 at 2:21 PM Amit Kapila wrote:
> >
> > On Thu, Dec 16, 2021 at 10:37 AM Masahiko Sawada
> > wrote:
> > >
> > > On Thu, Dec 16, 2021 at 11:43 AM Amit Kapila
> >
On Fri, Dec 24, 2021 at 5:30 PM Kyotaro Horiguchi
wrote:
>
> Thank you for the comment.
>
> At Fri, 24 Dec 2021 17:06:57 +0900, Masahiko Sawada
> wrote in
> > Thank you for the patch! +1 for improving the messages.
> >
> > >
> > > > LOG: termina
-
LSN_FORMAT_ARGS(restart_lsn;
+
LSN_FORMAT_ARGS(restart_lsn)),
+ errdetail("The slot
got behind the limit %X/%X determined by max_slot_wal_keep_size.",
+
LSN_FORMAT_ARGS(oldestLSN;
Isn't oldestLSN calculated not only by max_slot_wal_keep_size but also
by wal_keep_size?
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
On Fri, Dec 24, 2021 at 11:59 AM Amit Kapila wrote:
>
> On Thu, Dec 23, 2021 at 10:56 AM Masahiko Sawada
> wrote:
> >
> > On Wed, Dec 22, 2021 at 10:55 PM Amit Kapila
> > wrote:
> > >
> > > On Wed, Dec 22, 2021 at 6:22 PM Amit Kapila
> > &g
Regarding the details of the progress of index vacuum, I'm not sure
this progress information can fit for pg_stat_progress_vacuum. As
Peter already mentioned, the behavior quite varies depending on index
AM.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
> num_index_scans information; (c) there seems to be quite a few
> unnecessary includes in vacuumparallel.c which I have removed; (d)
> unnecessary error callback info was being set in ParallelVacuumState
> in leader backend; (e) changed/added comments at quite a few places.
>
> Can you please once verify the changes in the attached?
Thank you for updating the patch!
I agreed with these changes and it looks good to me.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
On Mon, Dec 13, 2021 at 12:11 PM Kyotaro Horiguchi
wrote:
>
> At Fri, 10 Dec 2021 18:13:31 +0900, Masahiko Sawada
> wrote in
> > I agreed with Andres and Horiguchi-san and attached an updated patch.
>
> Thanks for the new version.
>
> It seems fine, but I have so
xt information to errors, so we
don't need to
-* revert to the previous phase.
-*/
Why is this comment removed? ISTM this comment is still valid.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
On Tue, Dec 21, 2021 at 10:24 PM Amit Kapila wrote:
>
> On Tue, Dec 21, 2021 at 11:24 AM Masahiko Sawada
> wrote:
> >
> > On Tue, Dec 21, 2021 at 2:04 PM Amit Kapila wrote:
> > >
> >
> > Thank you for the comment. Agreed.
> >
> > I'v
enxid/relminmxid and want to manually run
vacuum on them rather than relying on autovacuums. --min-xid-age
option and --min-mxid-age option of vacuumdb command would be good
examples. So I think this new command/facility might not necessarily
need to be specific to single-user mode.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
On Tue, Dec 21, 2021 at 10:24 PM Amit Kapila wrote:
>
> On Tue, Dec 21, 2021 at 11:24 AM Masahiko Sawada
> wrote:
> >
> > On Tue, Dec 21, 2021 at 2:04 PM Amit Kapila wrote:
> > >
> >
> > Thank you for the comment. Agreed.
> >
> > I'v
On Tue, Dec 21, 2021 at 1:53 PM Peter Geoghegan wrote:
>
> On Mon, Dec 20, 2021 at 8:40 PM Masahiko Sawada wrote:
> > BTW a vacuum automatically enters failsafe mode under the situation
> > where the user has to run a vacuum in the single-user mode, right?
>
> Onl
On Tue, Dec 21, 2021 at 2:04 PM Amit Kapila wrote:
>
> On Tue, Dec 21, 2021 at 10:05 AM Masahiko Sawada
> wrote:
> >
> > On Tue, Dec 21, 2021 at 12:05 PM Amit Kapila
> > wrote:
> > >
> > > On Mon, Dec 20, 2021 at 6:29 PM Masahiko S
matically enters failsafe mode under the situation
where the user has to run a vacuum in the single-user mode, right?
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
On Tue, Dec 21, 2021 at 12:05 PM Amit Kapila wrote:
>
> On Mon, Dec 20, 2021 at 6:29 PM Masahiko Sawada wrote:
> >
> > On Mon, Dec 20, 2021 at 1:08 PM Amit Kapila wrote:
> > >
> > > > >
> > > > > 2. What is the reason for not movi
On Sat, Dec 18, 2021 at 11:29 AM Peter Geoghegan wrote:
>
> On Thu, Dec 16, 2021 at 10:46 PM Masahiko Sawada
> wrote:
> > > My emphasis here has been on making non-aggressive VACUUMs *always*
> > > advance relfrozenxid, outside of certain obvious edge cases. And so
On Mon, Dec 20, 2021 at 1:08 PM Amit Kapila wrote:
>
> On Mon, Dec 20, 2021 at 8:33 AM Masahiko Sawada wrote:
> >
> > On Sat, Dec 18, 2021 at 3:38 PM Amit Kapila wrote:
> > >
> > > Few comments:
> > > =
> > > 1.
> >
On Sat, Dec 18, 2021 at 3:38 PM Amit Kapila wrote:
>
> On Fri, Dec 17, 2021 at 10:51 AM Masahiko Sawada
> wrote:
> >
> > I've attached updated patches. The first patch just moves common
> > function for index bulk-deletion and cleanup to vacuum.c. And the
> > s
c numbers and instead use a syntax that is more
> > explicit, like SKIP (xid = NONE) or RESET SKIP or something like that.
> >
>
> +1 for using SKIP (xid = NONE) because otherwise first we need to
> introduce RESET syntax for this command.
Agreed. Thank you for the comment!
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
901 - 1000 of 2763 matches
Mail list logo
