On Mon, Jun 21, 2021 at 8:48 AM osumi.takami...@fujitsu.com
wrote:
>
> On Sunday, June 20, 2021 9:50 PM I wrote:
> > On Sunday, June 20, 2021 3:23 PM Amit Kapila
> > wrote:
> > > On Sun, Jun 20, 2021 at 9:28 AM osumi.takami...@fujitsu.com
> > > wrote:
> > > > * doc/src/sgml/logicaldecoding.sgml
On Sunday, June 20, 2021 9:50 PM I wrote:
> On Sunday, June 20, 2021 3:23 PM Amit Kapila
> wrote:
> > On Sun, Jun 20, 2021 at 9:28 AM osumi.takami...@fujitsu.com
> > wrote:
> > > * doc/src/sgml/logicaldecoding.sgml
> ...
> > >
> > > Now we have the four paren supplementary descriptions, not to m
On Sunday, June 20, 2021 3:23 PM Amit Kapila wrote:
> On Sun, Jun 20, 2021 at 9:28 AM osumi.takami...@fujitsu.com
> wrote:
> > * doc/src/sgml/logicaldecoding.sgml
...
> >
> > Now we have the four paren supplementary descriptions, not to make
> > users miss any other [user] catalog tables.
> > Be
On Sun, Jun 20, 2021 at 9:28 AM osumi.takami...@fujitsu.com
wrote:
>
> On Saturday, June 19, 2021 6:51 PM Amit Kapila
> wrote:
> > On Fri, Jun 18, 2021 at 2:25 PM osumi.takami...@fujitsu.com
> > wrote:
> > >
> > > On Friday, June 18, 2021 11:41 AM osumi.takami...@fujitsu.com
> > wrote:
> >
>
On Saturday, June 19, 2021 6:51 PM Amit Kapila wrote:
> On Fri, Jun 18, 2021 at 2:25 PM osumi.takami...@fujitsu.com
> wrote:
> >
> > On Friday, June 18, 2021 11:41 AM osumi.takami...@fujitsu.com
> wrote:
>
> > > Simon, I appreciate your suggestions and yes, if the user catalog
> > > table is r
On Fri, Jun 18, 2021 at 2:25 PM osumi.takami...@fujitsu.com
wrote:
>
> On Friday, June 18, 2021 11:41 AM osumi.takami...@fujitsu.com
> wrote:
> > Simon, I appreciate your suggestions and yes, if the user catalog table is
> > referenced by the output plugin, it can be another cause of the deadl
On Friday, June 18, 2021 11:41 AM osumi.takami...@fujitsu.com
wrote:
> On Thursday, June 17, 2021 10:34 PM Simon Riggs
> wrote:
> > On Thu, Jun 17, 2021 at 12:57 PM Amit Kapila
> > wrote:
> > > On Thu, Jun 17, 2021 at 4:27 PM Amit Kapila
> > >
> > wrote:
> > > >
> > > > On Thu, Jun 17, 2021 a
On Thursday, June 17, 2021 10:34 PM Simon Riggs
wrote:
> On Thu, Jun 17, 2021 at 12:57 PM Amit Kapila
> wrote:
> > On Thu, Jun 17, 2021 at 4:27 PM Amit Kapila
> wrote:
> > >
> > > On Thu, Jun 17, 2021 at 8:41 AM osumi.takami...@fujitsu.com
> > > wrote:
> > >
> > > Pushed!
> > >
> > [Responding
On Thu, Jun 17, 2021 at 12:57 PM Amit Kapila wrote:
>
> On Thu, Jun 17, 2021 at 4:27 PM Amit Kapila wrote:
> >
> > On Thu, Jun 17, 2021 at 8:41 AM osumi.takami...@fujitsu.com
> > wrote:
> >
> > Pushed!
> >
> [Responding to Simon's comments]
>
> > If LOCK and TRUNCATE is advised against on all us
On Thu, Jun 17, 2021 at 4:27 PM Amit Kapila wrote:
>
> On Thu, Jun 17, 2021 at 8:41 AM osumi.takami...@fujitsu.com
> wrote:
>
> Pushed!
>
[Responding to Simon's comments]
> If LOCK and TRUNCATE is advised against on all user catalog tables, why would
> CLUSTER only apply to pg_class? Surely its
On Thu, Jun 17, 2021 at 8:41 AM osumi.takami...@fujitsu.com
wrote:
>
> On Wednesday, June 16, 2021 7:21 PM Amit Kapila
> wrote:
> > On Mon, Jun 14, 2021 at 5:33 PM osumi.takami...@fujitsu.com
> > wrote:
> > >
> > > On Friday, June 11, 2021 2:13 PM vignesh C
> > wrote:
> > >
> > > Attached th
On Wednesday, June 16, 2021 7:21 PM Amit Kapila wrote:
> On Mon, Jun 14, 2021 at 5:33 PM osumi.takami...@fujitsu.com
> wrote:
> >
> > On Friday, June 11, 2021 2:13 PM vignesh C
> wrote:
> >
> > Attached the patch-set that addressed those two comments.
> >
>
> Few minor comments:
> 1.
> +
On Wed, Jun 16, 2021 at 3:51 PM Amit Kapila wrote:
>
> On Mon, Jun 14, 2021 at 5:33 PM osumi.takami...@fujitsu.com
> wrote:
> >
> > On Friday, June 11, 2021 2:13 PM vignesh C wrote:
> >
> > Attached the patch-set that addressed those two comments.
> >
>
> Few minor comments:
> 1.
> +
> +
On Mon, Jun 14, 2021 at 5:33 PM osumi.takami...@fujitsu.com
wrote:
>
> On Friday, June 11, 2021 2:13 PM vignesh C wrote:
>
> Attached the patch-set that addressed those two comments.
>
Few minor comments:
1.
+
+
+Clustering pg_class in a transaction.
Can we change above t
On Tuesday, June 15, 2021 1:51 PM vignesh C wrote:
> > Attached the patch-set that addressed those two comments.
> > I also fixed the commit message a bit in the 2PC specific patch to HEAD.
> > No other changes.
> >
> > Please check.
>
> Thanks for the updated patches, the patch applies cleanly i
On Mon, Jun 14, 2021 at 5:33 PM osumi.takami...@fujitsu.com
wrote:
>
> On Friday, June 11, 2021 2:13 PM vignesh C wrote:
> > Thanks for the updated patch:
> > Few comments:
> > 1) We have used Reordering and Clustering for the same command, we could
> > rephrase similarly in both places.
> > +
On Friday, June 11, 2021 2:13 PM vignesh C wrote:
> Thanks for the updated patch:
> Few comments:
> 1) We have used Reordering and Clustering for the same command, we could
> rephrase similarly in both places.
> +
> +Reordering pg_class by
> CLUSTER
> +command in a transac
On Fri, Jun 11, 2021 at 6:57 AM osumi.takami...@fujitsu.com
wrote:
>
> On Thursday, June 10, 2021 1:30 PM I wrote:
> > On Thursday, June 10, 2021 1:14 PM vignesh C
> > > On Wed, Jun 9, 2021 at 12:03 PM osumi.takami...@fujitsu.com
> > > wrote:
> > > >
> > > > On Wednesday, June 9, 2021 12:06 PM A
On Thursday, June 10, 2021 1:30 PM I wrote:
> On Thursday, June 10, 2021 1:14 PM vignesh C
> > On Wed, Jun 9, 2021 at 12:03 PM osumi.takami...@fujitsu.com
> > wrote:
> > >
> > > On Wednesday, June 9, 2021 12:06 PM Amit Kapila
> > wrote:
> > > > On Tue, Jun 8, 2021 at 6:24 PM vignesh C
> wrote:
On Thursday, June 10, 2021 1:14 PM vignesh C
> On Wed, Jun 9, 2021 at 12:03 PM osumi.takami...@fujitsu.com
> wrote:
> >
> > On Wednesday, June 9, 2021 12:06 PM Amit Kapila
> wrote:
> > > On Tue, Jun 8, 2021 at 6:24 PM vignesh C wrote:
> > > >
> > > > Thanks for the updated patch.
> > > >
> > >
On Wed, Jun 9, 2021 at 12:03 PM osumi.takami...@fujitsu.com
wrote:
>
> On Wednesday, June 9, 2021 12:06 PM Amit Kapila
> wrote:
> > On Tue, Jun 8, 2021 at 6:24 PM vignesh C wrote:
> > >
> > > Thanks for the updated patch.
> > >
> > > I have few comments:
> > > 1) Should we list the actual syste
On Tuesday, June 8, 2021 5:04 PM I wrote:
> On Monday, June 7, 2021 6:22 PM Amit Kapila
> wrote:
> > On Mon, Jun 7, 2021 at 10:44 AM Amit Kapila
> > wrote:
> > >
> > > One more comment is that for HEAD, first just create a patch with
> > > synchronous replication-related doc changes and then writ
On Wed, Jun 9, 2021 at 12:03 PM osumi.takami...@fujitsu.com
wrote:
>
> On Wednesday, June 9, 2021 12:06 PM Amit Kapila
> wrote:
> > On Tue, Jun 8, 2021 at 6:24 PM vignesh C wrote:
>
> > > 3) Should [user] catalog tables be catalog tables or user catalog
> > > tables [user] catalog tables
> > >
On Wednesday, June 9, 2021 12:06 PM Amit Kapila wrote:
> On Tue, Jun 8, 2021 at 6:24 PM vignesh C wrote:
> >
> > Thanks for the updated patch.
> >
> > I have few comments:
> > 1) Should we list the actual system tables like pg_class,pg_trigger,
> > etc instead of any other catalog table?
> > User
On Tue, Jun 8, 2021 at 6:24 PM vignesh C wrote:
>
> Thanks for the updated patch.
>
> I have few comments:
> 1) Should we list the actual system tables like pg_class,pg_trigger,
> etc instead of any other catalog table?
> User has issued an explicit LOCK on pg_class (or any other catalog table)
>
On Tue, Jun 8, 2021 at 1:34 PM osumi.takami...@fujitsu.com
wrote:
>
> On Monday, June 7, 2021 6:22 PM Amit Kapila wrote:
> > On Mon, Jun 7, 2021 at 10:44 AM Amit Kapila
> > wrote:
> > >
> > > One more comment is that for HEAD, first just create a patch with
> > > synchronous replication-related
On Monday, June 7, 2021 6:22 PM Amit Kapila wrote:
> On Mon, Jun 7, 2021 at 10:44 AM Amit Kapila
> wrote:
> >
> > One more comment is that for HEAD, first just create a patch with
> > synchronous replication-related doc changes and then write a separate
> > patch for prepared transactions.
> >
>
On Mon, Jun 7, 2021 at 10:44 AM Amit Kapila wrote:
>
> One more comment is that for HEAD, first just create a patch with
> synchronous replication-related doc changes and then write a separate
> patch for prepared transactions.
>
I noticed that docs for "Synchronous replication support for Logica
On Mon, Jun 7, 2021 at 9:26 AM vignesh C wrote:
>
> On Mon, Jun 7, 2021 at 4:18 AM osumi.takami...@fujitsu.com
> wrote:
> >
> > On Thursday, June 3, 2021 7:07 PM Amit Kapila
> > wrote:
> > > On Thu, Jun 3, 2021 at 9:18 AM osumi.takami...@fujitsu.com
> > > wrote:
> > > > Thank you for providing
On Mon, Jun 7, 2021 at 4:18 AM osumi.takami...@fujitsu.com
wrote:
>
> On Thursday, June 3, 2021 7:07 PM Amit Kapila wrote:
> > On Thu, Jun 3, 2021 at 9:18 AM osumi.takami...@fujitsu.com
> > wrote:
> > > Thank you for providing the patch.
> > > I have updated your patch to include some other view
On Thursday, June 3, 2021 1:09 PM vignesh C wrote:
> On Thu, Jun 3, 2021 at 9:18 AM osumi.takami...@fujitsu.com
> wrote:
> > Thank you for providing the patch.
> > I have updated your patch to include some other viewpoints.
> >
> > I also included the description about TRUNCATE on user_catalog_ta
On Thursday, June 3, 2021 7:07 PM Amit Kapila wrote:
> On Thu, Jun 3, 2021 at 9:18 AM osumi.takami...@fujitsu.com
> wrote:
> > Thank you for providing the patch.
> > I have updated your patch to include some other viewpoints.
> >
>
> I suggest creating a synchronous replication part of the patch
On Thu, Jun 3, 2021 at 9:18 AM osumi.takami...@fujitsu.com
wrote:
>
> On Tuesday, June 1, 2021 4:33 PM Peter Smith
> > To: Andres Freund
> > Cc: PostgreSQL-development ; Amit Kapila
> > ; Markus Wanner
> >
> > Subject: Re: locking [user] catalog tab
On Thu, Jun 3, 2021 at 9:18 AM osumi.takami...@fujitsu.com
wrote:
>
> On Tuesday, June 1, 2021 4:33 PM Peter Smith
> > To: Andres Freund
> > Cc: PostgreSQL-development ; Amit Kapila
> > ; Markus Wanner
> >
> > Subject: Re: locking [user] catalog tab
On Tuesday, June 1, 2021 4:33 PM Peter Smith
> To: Andres Freund
> Cc: PostgreSQL-development ; Amit Kapila
> ; Markus Wanner
>
> Subject: Re: locking [user] catalog tables vs 2pc vs logical rep
>
> Hi.
>
> The attached PG docs patch about catalog deadlocks was
Hi.
The attached PG docs patch about catalog deadlocks was previously
implemented in another thread [1], but it seems more relevant to this
one.
PSA.
--
[1]
https://www.postgresql.org/message-id/CAA4eK1K%2BSeT31pxwL5iTvXq%3DJhZpG_cUJLFhiz-eD%2BJr-WAPeg%40mail.gmail.com
Kind Regards,
Peter
On Wed, May 26, 2021 at 1:53 PM Petr Jelinek
wrote:
>
> On 26 May 2021, at 05:04, Amit Kapila wrote:
> >
> > On Tue, May 25, 2021 at 12:40 PM Michael Paquier
> > wrote:
> >>
> >> It seems to me that the 2PC issues on catalog tables and the issues
> >> related to logical replication in synchonou
On Tue, May 25, 2021 at 12:40 PM Michael Paquier wrote:
>
> On Mon, May 24, 2021 at 10:03:01AM +0530, Amit Kapila wrote:
> > So, this appears to be an existing caveat of synchronous replication.
> > If that is the case, I am not sure if it is a good idea to just block
> > such ops for the prepared
On 26 May 2021, at 05:04, Amit Kapila wrote:
>
> On Tue, May 25, 2021 at 12:40 PM Michael Paquier wrote:
>>
>> On Mon, May 24, 2021 at 10:03:01AM +0530, Amit Kapila wrote:
>>> So, this appears to be an existing caveat of synchronous replication.
>>> If that is the case, I am not sure if it is a
Amit Kapila writes:
> Fair enough. But the way we were looking at them as they will also
> block (lead to deadlock) for logical replication of prepared
> transactions and also logical replication in synchonous mode without
> prepared transactions. Now, if we want to deal with the 2PC issues
> sepa
On Tue, May 25, 2021 at 12:40 PM Michael Paquier wrote:
>
> On Mon, May 24, 2021 at 10:03:01AM +0530, Amit Kapila wrote:
> > So, this appears to be an existing caveat of synchronous replication.
> > If that is the case, I am not sure if it is a good idea to just block
> > such ops for the prepared
On Tue, May 25, 2021 at 1:43 PM osumi.takami...@fujitsu.com
wrote:
>
> On Monday, May 24, 2021 1:33 PM Amit Kapila wrote:
> > On Tue, Apr 20, 2021 at 9:57 AM vignesh C wrote:
> > >
> > > This similar problem exists in case of synchronous replication setup
> > > having synchronous_standby_names r
On Monday, May 24, 2021 1:33 PM Amit Kapila wrote:
> On Tue, Apr 20, 2021 at 9:57 AM vignesh C wrote:
> >
> > This similar problem exists in case of synchronous replication setup
> > having synchronous_standby_names referring to the subscriber, when we
> > do the steps "begin;lock pg_class; inser
On Mon, May 24, 2021 at 10:03:01AM +0530, Amit Kapila wrote:
> So, this appears to be an existing caveat of synchronous replication.
> If that is the case, I am not sure if it is a good idea to just block
> such ops for the prepared transaction. Also, what about other
> operations which acquire an
On Mon, Feb 22, 2021 at 02:28:47PM -0800, Andres Freund wrote:
> Perhaps all that we need to do is to disallow 2PC prepare if [user]
> catalog tables have been locked exclusively? Similar to how we're
> disallowing preparing tables with temp table access.
At least for anything involving critical r
On Tue, Apr 20, 2021 at 9:57 AM vignesh C wrote:
>
> This similar problem exists in case of synchronous replication setup
> having synchronous_standby_names referring to the subscriber, when we
> do the steps "begin;lock pg_class; insert into test1 values(10);
> commit". In this case while decodin
On Wed, Mar 31, 2021 at 5:47 PM vignesh C wrote:
>
> On Wed, Mar 31, 2021 at 2:35 PM Ajin Cherian wrote:
> >
> > The patch applies fine on HEAD and "make check" passes fine. No major
> > comments on the patch, just a minor comment:
> >
> > If you could change the error from, " cannot PREPARE a t
On Wed, Mar 31, 2021 at 2:35 PM Ajin Cherian wrote:
>
> The patch applies fine on HEAD and "make check" passes fine. No major
> comments on the patch, just a minor comment:
>
> If you could change the error from, " cannot PREPARE a transaction that has a
> lock on user catalog/system table(s)"
>
On Tue, Mar 16, 2021 at 1:36 AM vignesh C wrote:
> On Tue, Feb 23, 2021 at 3:59 AM Andres Freund wrote:
> >
> > Hi,
> >
> > The 2pc decoding added in
> >
> > commit a271a1b50e9bec07e2ef3a05e38e7285113e4ce6
> > Author: Amit Kapila
> > Date: 2021-01-04 08:34:50 +0530
> >
> > Allow decoding
On Tue, Feb 23, 2021 at 3:59 AM Andres Freund wrote:
>
> Hi,
>
> The 2pc decoding added in
>
> commit a271a1b50e9bec07e2ef3a05e38e7285113e4ce6
> Author: Amit Kapila
> Date: 2021-01-04 08:34:50 +0530
>
> Allow decoding at prepare time in ReorderBuffer.
>
> has a deadlock danger when used in
On Tue, Feb 23, 2021 at 12:00 PM Amit Kapila wrote:
>
> On Tue, Feb 23, 2021 at 9:33 AM Andres Freund wrote:
> >
> > On 2021-02-23 09:24:18 +0530, Amit Kapila wrote:
> > > Okay, so is it sufficient to add comments in code, or do we want to
> > > add something in docs? I am not completely sure if
On Tue, Feb 23, 2021 at 9:33 AM Andres Freund wrote:
>
> On 2021-02-23 09:24:18 +0530, Amit Kapila wrote:
> > Okay, so is it sufficient to add comments in code, or do we want to
> > add something in docs? I am not completely sure if we need to add in
> > docs till we have core-implementation of pr
Hi
On 2021-02-23 09:24:18 +0530, Amit Kapila wrote:
> Okay, so is it sufficient to add comments in code, or do we want to
> add something in docs? I am not completely sure if we need to add in
> docs till we have core-implementation of prepare waiting to get
> logically replicated.
There's plenty
On Tue, Feb 23, 2021 at 9:09 AM Andres Freund wrote:
>
> On 2021-02-23 08:56:39 +0530, Amit Kapila wrote:
> > On Tue, Feb 23, 2021 at 3:58 AM Andres Freund wrote:
> > > Perhaps all that we need to do is to disallow 2PC prepare if [user]
> > > catalog tables have been locked exclusively?
>
> > Rig
Hi,
On 2021-02-23 08:56:39 +0530, Amit Kapila wrote:
> On Tue, Feb 23, 2021 at 3:58 AM Andres Freund wrote:
> > Perhaps all that we need to do is to disallow 2PC prepare if [user]
> > catalog tables have been locked exclusively?
> Right, and we have discussed this during development [1][2].
I r
On Tue, Feb 23, 2021 at 3:58 AM Andres Freund wrote:
>
>
> At first this seems to be a significant issue. But on the other hand, if
> you were to shut the cluster down in this situation (or disconnect all
> sessions), you have broken cluster on your hand - without logical
> decoding being involved
56 matches
Mail list logo
