On Wed, 3 Jan 2024 at 08:54, Amit Kapila wrote:
>
> On Wed, Jan 3, 2024 at 7:10 AM Michael Paquier wrote:
> >
> > On Tue, Jan 02, 2024 at 02:07:58PM +, Bertrand Drouvot wrote:
> > > + wal_level_insufficient means that the
> > > +is insufficient on the primary
> > > +
Hi,
On Wed, Jan 03, 2024 at 08:53:44AM +0530, Amit Kapila wrote:
> On Wed, Jan 3, 2024 at 7:10 AM Michael Paquier wrote:
> >
> > On Tue, Jan 02, 2024 at 02:07:58PM +, Bertrand Drouvot wrote:
> > > + wal_level_insufficient means that the
> > > +is insufficient on the
On Wed, Jan 3, 2024 at 7:10 AM Michael Paquier wrote:
>
> On Tue, Jan 02, 2024 at 02:07:58PM +, Bertrand Drouvot wrote:
> > + wal_level_insufficient means that the
> > +is insufficient on the primary
> > + server.
> >
> > I'd prefer "primary_wal_level" instead
On Tue, Jan 02, 2024 at 02:07:58PM +, Bertrand Drouvot wrote:
> + wal_level_insufficient means that the
> +is insufficient on the primary
> + server.
>
> I'd prefer "primary_wal_level" instead of "wal_level_insufficient". I think
> it's
> better to directly
Hi,
On Tue, Jan 02, 2024 at 10:35:59AM +0530, Amit Kapila wrote:
> On Mon, Jan 1, 2024 at 5:24 PM shveta malik wrote:
> >
> > Please ignore the previous patch and PFA new v4 (v4_2). The only
> > change from the earlier v4 is the subject correction in commit msg.
> >
Thanks for the patch!
> The
On Mon, Jan 1, 2024 at 5:24 PM shveta malik wrote:
>
> Please ignore the previous patch and PFA new v4 (v4_2). The only
> change from the earlier v4 is the subject correction in commit msg.
>
The patch looks good to me. I have slightly changed one of the
descriptions in the docs and also
On Mon, Jan 1, 2024 at 5:17 PM shveta malik wrote:
>
> On Mon, Jan 1, 2024 at 4:30 PM Amit Kapila wrote:
> >
> > On Mon, Jan 1, 2024 at 12:32 PM shveta malik wrote:
> > >
> > > PFA v3 after changing column name to 'conflict_reason'
> > >
> >
> > Few minor comments:
> > ===
> >
On Mon, Jan 1, 2024 at 4:30 PM Amit Kapila wrote:
>
> On Mon, Jan 1, 2024 at 12:32 PM shveta malik wrote:
> >
> > PFA v3 after changing column name to 'conflict_reason'
> >
>
> Few minor comments:
> ===
> 1.
> +
> + wal_removed = required WAL has been removed.
On Mon, Jan 1, 2024 at 12:32 PM shveta malik wrote:
>
> PFA v3 after changing column name to 'conflict_reason'
>
Few minor comments:
===
1.
+
+ wal_removed = required WAL has been removed.
+
+
+
+
+ rows_removed
On Mon, Jan 1, 2024 at 9:14 AM shveta malik wrote:
>
> On Fri, Dec 29, 2023 at 3:35 PM Michael Paquier wrote:
> >
> > On Fri, Dec 29, 2023 at 09:20:52AM +0530, Amit Kapila wrote:
> > > Does anyone have a preference for a column name? The options on the
> > > table are conflict_cause,
On Fri, Dec 29, 2023 at 3:35 PM Michael Paquier wrote:
>
> On Fri, Dec 29, 2023 at 09:20:52AM +0530, Amit Kapila wrote:
> > Does anyone have a preference for a column name? The options on the
> > table are conflict_cause, conflicting_cause, conflict_reason. Any
> > others? I was checking docs for
On Fri, Dec 29, 2023 at 09:20:52AM +0530, Amit Kapila wrote:
> Does anyone have a preference for a column name? The options on the
> table are conflict_cause, conflicting_cause, conflict_reason. Any
> others? I was checking docs for similar usage and found
> "pg_event_trigger_table_rewrite_reason"
On Thu, Dec 28, 2023 at 2:58 PM shveta malik wrote:
>
> PFA the v2-patch with all your comments addressed.
>
Does anyone have a preference for a column name? The options on the
table are conflict_cause, conflicting_cause, conflict_reason. Any
others? I was checking docs for similar usage and
On Thu, Dec 28, 2023 at 10:16 AM shveta malik wrote:
>
> On Wed, Dec 27, 2023 at 4:16 PM Amit Kapila wrote:
> >
> > On Wed, Dec 27, 2023 at 3:08 PM shveta malik wrote:
> > >
> > > PFA the patch which attempts to implement this.
> > >
> > > This patch changes the existing 'conflicting' field to
On Wed, Dec 27, 2023 at 4:16 PM Amit Kapila wrote:
>
> On Wed, Dec 27, 2023 at 3:08 PM shveta malik wrote:
> >
> > PFA the patch which attempts to implement this.
> >
> > This patch changes the existing 'conflicting' field to
> > 'conflicting_cause' in pg_replication_slots.
> >
>
> This name
On Wed, Dec 27, 2023 at 3:08 PM shveta malik wrote:
>
> PFA the patch which attempts to implement this.
>
> This patch changes the existing 'conflicting' field to
> 'conflicting_cause' in pg_replication_slots.
>
This name sounds a bit odd to me, would it be better to name it as
conflict_cause?
On Tue, Dec 26, 2023 at 7:35 PM Isaac Morland wrote:
>
> On Thu, 21 Dec 2023 at 09:26, Amit Kapila wrote:
>
>>
>> A conflicting column where NULL indicates no conflict, and other
>> > values indicate the reason for the conflict, doesn't seem too bad.
>> >
>>
>> This is fine too.
>
>
> I prefer
On Thu, 21 Dec 2023 at 09:26, Amit Kapila wrote:
> A conflicting column where NULL indicates no conflict, and other
> > values indicate the reason for the conflict, doesn't seem too bad.
> >
>
> This is fine too.
>
I prefer this option. There is precedent for doing it this way, for example
in
Hi,
On Tue, Dec 26, 2023 at 05:23:56PM +0900, Michael Paquier wrote:
> On Tue, Dec 26, 2023 at 08:44:44AM +0530, Amit Kapila wrote:
> > Does anyone else have a preference on whether to change the existing
> > column or add a new one?
>
> Just to be clear here, I'd vote for replacing the existing
On Tue, Dec 26, 2023 at 08:44:44AM +0530, Amit Kapila wrote:
> Does anyone else have a preference on whether to change the existing
> column or add a new one?
Just to be clear here, I'd vote for replacing the existing boolean
with a text.
--
Michael
signature.asc
Description: PGP signature
On Thu, Dec 21, 2023 at 8:21 PM Bertrand Drouvot
wrote:
>
> On Thu, Dec 21, 2023 at 07:55:51PM +0530, Amit Kapila wrote:
> > On Thu, Dec 21, 2023 at 5:05 PM Andres Freund wrote:
> > > I'm not entirely sure I understand the difference - just whether we add
> > > one
> > > new column or replace
On Fri, Dec 22, 2023 at 5:00 AM Michael Paquier wrote:
>
> On Thu, Dec 21, 2023 at 07:26:56AM -0800, Andres Freund wrote:
> > On 2023-12-21 19:55:51 +0530, Amit Kapila wrote:
> >> We can return int2 value from the function pg_get_replication_slots()
> >> and then use that to display a string in
On Thu, Dec 21, 2023 at 07:26:56AM -0800, Andres Freund wrote:
> On 2023-12-21 19:55:51 +0530, Amit Kapila wrote:
>> We can return int2 value from the function pg_get_replication_slots()
>> and then use that to display a string in the view
>> pg_replication_slots.
>
> I strongly dislike that
On 2023-12-21 19:55:51 +0530, Amit Kapila wrote:
> On Thu, Dec 21, 2023 at 5:05 PM Andres Freund wrote:
> > We clearly can't just expose the numerical value for a C enum. So it has to
> > be
> > converted to something SQL representable.
> >
>
> We can return int2 value from the function
Hi,
On Thu, Dec 21, 2023 at 07:55:51PM +0530, Amit Kapila wrote:
> On Thu, Dec 21, 2023 at 5:05 PM Andres Freund wrote:
> > I'm not entirely sure I understand the difference - just whether we add one
> > new column or replace the existing 'conflicting' column? I can see arguments
> > for either.
On Thu, Dec 21, 2023 at 5:05 PM Andres Freund wrote:
>
> On 2023-12-21 16:08:48 +0530, shveta malik wrote:
> > On Thu, Dec 21, 2023 at 3:10 PM Andres Freund wrote:
> > >
> > > Extra columns aren't free from a usability perspective. IFF we do
> > > something, I
> > > think it should be a single
On Thu, Dec 21, 2023 at 5:04 PM Andres Freund wrote:
>
> Hi,
>
> On 2023-12-21 16:08:48 +0530, shveta malik wrote:
> > On Thu, Dec 21, 2023 at 3:10 PM Andres Freund wrote:
> > >
> > > Hi,
> > >
> > > On 2023-12-21 09:21:04 +0900, Michael Paquier wrote:
> > > > While listening at Bertrand's talk
Hi,
On 2023-12-21 16:08:48 +0530, shveta malik wrote:
> On Thu, Dec 21, 2023 at 3:10 PM Andres Freund wrote:
> >
> > Hi,
> >
> > On 2023-12-21 09:21:04 +0900, Michael Paquier wrote:
> > > While listening at Bertrand's talk about logical decoding on standbys
> > > last week at Prague, I got
On Thu, Dec 21, 2023 at 3:10 PM Andres Freund wrote:
>
> Hi,
>
> On 2023-12-21 09:21:04 +0900, Michael Paquier wrote:
> > While listening at Bertrand's talk about logical decoding on standbys
> > last week at Prague, I got surprised by the fact that we do not
> > reflect in the catalogs the
Hi,
On 2023-12-21 09:21:04 +0900, Michael Paquier wrote:
> While listening at Bertrand's talk about logical decoding on standbys
> last week at Prague, I got surprised by the fact that we do not
> reflect in the catalogs the reason why a conflict happened for a slot.
> There are three of them
On Thu, Dec 21, 2023 at 08:20:16AM +0530, Amit Kapila wrote:
> The invalidation cause is also required by one of the features being
> discussed "Synchronize slots from primary to standby" [1] and there is
> already a thread to discuss the same [2]. As that thread started
> yesterday only, you may
On Thu, Dec 21, 2023 at 5:51 AM Michael Paquier wrote:
>
> While listening at Bertrand's talk about logical decoding on standbys
> last week at Prague, I got surprised by the fact that we do not
> reflect in the catalogs the reason why a conflict happened for a slot.
> There are three of them
Hi all,
(Bertrand and Andres in CC.)
While listening at Bertrand's talk about logical decoding on standbys
last week at Prague, I got surprised by the fact that we do not
reflect in the catalogs the reason why a conflict happened for a slot.
There are three of them depending on
33 matches
Mail list logo
