On Wed, Mar 27, 2024 at 11:06 AM Nathan Bossart
wrote:
> IMHO the use-case where this doesn't work so well is when you have many,
> many servers to administer (e.g., a cloud provider). In those cases,
> picking a default timeout to try to prevent wraparound is going to be much
> less accurate,
On Wed, Mar 27, 2024 at 10:33:28AM -0400, Robert Haas wrote:
> FWIW, I thought the time-based one sounded more useful. I think it
> would be poor planning to say "well, if the slot reaches an XID age of
> a billion, kill it so we don't wrap around," because while that likely
> will prevent me from
On Wed, Mar 27, 2024 at 3:13 AM Bertrand Drouvot
wrote:
> Yeah, I think that both makes senses. The reason is that one depends of the
> database activity and slot activity (the xid age one) while the other (the
> timeout one) depends only of the slot activity.
FWIW, I thought the time-based one
Hi,
On Wed, Mar 27, 2024 at 12:28:06PM +0530, Bharath Rupireddy wrote:
> On Wed, Mar 27, 2024 at 10:10 AM Amit Kapila wrote:
> >
> > On Tue, Mar 26, 2024 at 9:10 PM Alvaro Herrera
> > wrote:
> > >
> > > On 2024-Mar-26, Nathan Bossart wrote:
> > >
> > > > FWIW I'd really prefer to have
On Wed, Mar 27, 2024 at 10:10 AM Amit Kapila wrote:
>
> On Tue, Mar 26, 2024 at 9:10 PM Alvaro Herrera
> wrote:
> >
> > On 2024-Mar-26, Nathan Bossart wrote:
> >
> > > FWIW I'd really prefer to have something like max_slot_xid_age for this.
> > > A
> > > time-based parameter would likely help
On Tue, Mar 26, 2024 at 9:10 PM Alvaro Herrera wrote:
>
> On 2024-Mar-26, Nathan Bossart wrote:
>
> > FWIW I'd really prefer to have something like max_slot_xid_age for this. A
> > time-based parameter would likely help with most cases, but transaction ID
> > usage will vary widely from server
Hi,
On Tue, Mar 26, 2024 at 04:39:55PM +0100, Alvaro Herrera wrote:
> On 2024-Mar-26, Nathan Bossart wrote:
> > I don't object to a
> > time-based setting as well, but that won't always work as well for this
> > particular use-case, especially if we are relying on users to set a
> > slot-level
On 2024-Mar-26, Nathan Bossart wrote:
> FWIW I'd really prefer to have something like max_slot_xid_age for this. A
> time-based parameter would likely help with most cases, but transaction ID
> usage will vary widely from server to server, so it'd be nice to have
> something to protect against
On Tue, Mar 26, 2024 at 03:44:29PM +0530, Amit Kapila wrote:
> On Tue, Mar 26, 2024 at 2:11 PM Alvaro Herrera
> wrote:
>> Well, I think a GUC is good to have regardless of the slot parameter,
>> because the GUC can be used as an instance-wide protection against going
>> out of disk space because
On Tue, Mar 26, 2024 at 2:11 PM Alvaro Herrera wrote:
>
> On 2024-Mar-26, Amit Kapila wrote:
>
> > On Tue, Mar 26, 2024 at 1:09 PM Alvaro Herrera
> > wrote:
> > > On 2024-Mar-26, Amit Kapila wrote:
> > > > I would also like to solicit your opinion on the other slot-level
> > > > parameter we
Hi,
On Tue, Mar 26, 2024 at 01:45:23PM +0530, Amit Kapila wrote:
> On Tue, Mar 26, 2024 at 1:09 PM Alvaro Herrera
> wrote:
> >
> > On 2024-Mar-26, Amit Kapila wrote:
> >
> > > We have a consensus on inactive_since, so I'll make that change.
> >
> > Sounds reasonable. So this is a timestamptz
On 2024-Mar-26, Amit Kapila wrote:
> On Tue, Mar 26, 2024 at 1:09 PM Alvaro Herrera
> wrote:
> > On 2024-Mar-26, Amit Kapila wrote:
> > > I would also like to solicit your opinion on the other slot-level
> > > parameter we are planning to introduce. This new slot-level parameter
> > > will be
On Tue, Mar 26, 2024 at 1:09 PM Alvaro Herrera wrote:
>
> On 2024-Mar-26, Amit Kapila wrote:
>
> > We have a consensus on inactive_since, so I'll make that change.
>
> Sounds reasonable. So this is a timestamptz if the slot is inactive,
> NULL if active, right?
>
Yes.
> What value is it going
On 2024-Mar-26, Amit Kapila wrote:
> We have a consensus on inactive_since, so I'll make that change.
Sounds reasonable. So this is a timestamptz if the slot is inactive,
NULL if active, right? What value is it going to have for sync slots?
> I would also like to solicit your opinion on the
On Tue, Mar 26, 2024 at 9:38 AM shveta malik wrote:
>
> On Mon, Mar 25, 2024 at 9:54 PM Bertrand Drouvot
> wrote:
> >
> > Hi,
> >
> > On Mon, Mar 25, 2024 at 07:32:11PM +0530, Amit Kapila wrote:
> > > On Mon, Mar 25, 2024 at 6:57 PM Robert Haas wrote:
> > > > And I'm suspicious that having an
On Tue, Mar 26, 2024 at 1:50 AM Bharath Rupireddy
wrote:
>
> On Tue, Mar 26, 2024 at 1:30 AM Nathan Bossart
> wrote:
> >
> > On Mon, Mar 25, 2024 at 04:49:12PM +, Bertrand Drouvot wrote:
> > > On Mon, Mar 25, 2024 at 12:25:37PM -0400, Robert Haas wrote:
> > >> In the same vein, I think
On Mon, Mar 25, 2024 at 9:54 PM Bertrand Drouvot
wrote:
>
> Hi,
>
> On Mon, Mar 25, 2024 at 07:32:11PM +0530, Amit Kapila wrote:
> > On Mon, Mar 25, 2024 at 6:57 PM Robert Haas wrote:
> > > And I'm suspicious that having an exception for slots being synced is
> > > a bad idea. That makes too
On Mon, Mar 25, 2024 at 9:55 PM Robert Haas wrote:
>
> On Mon, Mar 25, 2024 at 12:12 PM Bertrand Drouvot
> wrote:
>
> > Would "released_time" sounds better? (at the end this is exactly what it
> > does
> > represent unless for the case where it is restored from disk for which the
> > meaning
>
On Tue, Mar 26, 2024 at 1:30 AM Nathan Bossart wrote:
>
> On Mon, Mar 25, 2024 at 04:49:12PM +, Bertrand Drouvot wrote:
> > On Mon, Mar 25, 2024 at 12:25:37PM -0400, Robert Haas wrote:
> >> In the same vein, I think deactivated_at or inactive_since might be
> >> good names to consider. I
On Mon, Mar 25, 2024 at 04:49:12PM +, Bertrand Drouvot wrote:
> On Mon, Mar 25, 2024 at 12:25:37PM -0400, Robert Haas wrote:
>> In the same vein, I think deactivated_at or inactive_since might be
>> good names to consider. I think they get at the same thing as
>> released_time, but they avoid
Hi,
On Mon, Mar 25, 2024 at 12:25:37PM -0400, Robert Haas wrote:
> On Mon, Mar 25, 2024 at 12:12 PM Bertrand Drouvot
> wrote:
> > Would "released_time" sounds better? (at the end this is exactly what it
> > does
> > represent unless for the case where it is restored from disk for which the
> >
On Mon, Mar 25, 2024 at 12:12 PM Bertrand Drouvot
wrote:
> Now that I read your arguments I think that last__time could
> be
> both missleading because at the end they rely on users "expectation".
Well, the user is always going to expect *something* -- that's just
how language works.
> Would
Hi,
On Mon, Mar 25, 2024 at 07:32:11PM +0530, Amit Kapila wrote:
> On Mon, Mar 25, 2024 at 6:57 PM Robert Haas wrote:
> > And I'm suspicious that having an exception for slots being synced is
> > a bad idea. That makes too much of a judgement about how the user will
> > use this field. It's
Hi,
On Mon, Mar 25, 2024 at 11:49:00AM -0400, Robert Haas wrote:
> On Mon, Mar 25, 2024 at 11:16 AM Bertrand Drouvot
> wrote:
> > > IIUC, Bertrand's point was that users can interpret last_active_time
> > > as a value that gets updated each time they decode a change which is
> > > not what we
On Mon, Mar 25, 2024 at 11:16 AM Bertrand Drouvot
wrote:
> > IIUC, Bertrand's point was that users can interpret last_active_time
> > as a value that gets updated each time they decode a change which is
> > not what we are doing. So, this can confuse users. Your expectation of
> > answer (NULL)
Hi,
On Mon, Mar 25, 2024 at 08:59:55PM +0530, Amit Kapila wrote:
> On Mon, Mar 25, 2024 at 8:46 PM Bertrand Drouvot
> wrote:
> >
> > On Mon, Mar 25, 2024 at 08:38:16PM +0530, Amit Kapila wrote:
> > > On Mon, Mar 25, 2024 at 7:51 PM Robert Haas wrote:
> > > >
> > > > On Mon, Mar 25, 2024 at
On Mon, Mar 25, 2024 at 8:46 PM Bertrand Drouvot
wrote:
>
> On Mon, Mar 25, 2024 at 08:38:16PM +0530, Amit Kapila wrote:
> > On Mon, Mar 25, 2024 at 7:51 PM Robert Haas wrote:
> > >
> > > On Mon, Mar 25, 2024 at 10:02 AM Amit Kapila
> > > wrote:
> > > > We considered the other two names as
Hi,
On Mon, Mar 25, 2024 at 08:38:16PM +0530, Amit Kapila wrote:
> On Mon, Mar 25, 2024 at 7:51 PM Robert Haas wrote:
> >
> > On Mon, Mar 25, 2024 at 10:02 AM Amit Kapila
> > wrote:
> > > We considered the other two names as last_inactive_at and
> > > last_active_time. For the first
On Mon, Mar 25, 2024 at 7:51 PM Robert Haas wrote:
>
> On Mon, Mar 25, 2024 at 10:02 AM Amit Kapila wrote:
> > We considered the other two names as last_inactive_at and
> > last_active_time. For the first (last_inactive_at), there was an
> > argument that most other fields that display time ends
On Mon, Mar 25, 2024 at 10:02 AM Amit Kapila wrote:
> We considered the other two names as last_inactive_at and
> last_active_time. For the first (last_inactive_at), there was an
> argument that most other fields that display time ends with _time. For
> the second (last_active_time), there was an
On Mon, Mar 25, 2024 at 6:57 PM Robert Haas wrote:
>
> On Mon, Mar 25, 2024 at 7:11 AM Amit Kapila wrote:
> > Track last_inactive_time in pg_replication_slots.
> >
> > This commit adds a new property called last_inactive_time for slots. It is
> > set to 0 whenever a slot is made active/acquired
On Mon, Mar 25, 2024 at 7:11 AM Amit Kapila wrote:
> Track last_inactive_time in pg_replication_slots.
>
> This commit adds a new property called last_inactive_time for slots. It is
> set to 0 whenever a slot is made active/acquired and set to the current
> timestamp whenever the slot is
32 matches
Mail list logo
