On Sat, Mar 23, 2024 at 1:12 PM Bharath Rupireddy
wrote:
>
> On Sat, Mar 23, 2024 at 11:27 AM Amit Kapila wrote:
> >
>
> > 2.
> > +# Get last_inactive_time value after slot's creation. Note that the
> > slot is still
> > +# inactive unless it's used by the standby below.
> > +my
Hi,
I am aware of few previous attempts and discussions on this topic
(eventually shelved or didn't materialize):
- https://www.postgresql.org/message-id/45e2a6ae.1080...@oss.ntt.co.jp
-
https://www.postgresql.org/message-id/CA%2BTgmoZgapzekbTqdBrcH8O8Yifi10_nB7uWLB8ajAhGL21M6A%40mail.gmail.com
On Fri, Mar 22, 2024 at 4:28 AM Peter Eisentraut wrote:
>
> I had written in [0] about my questions related to using this with
> connection poolers. I don't think this was addressed at all. I haven't
> seen any discussion about how to make this kind of facility usable in a
> full system. You
On Sat, Mar 23, 2024 at 2:34 PM Bertrand Drouvot
wrote:
>
> > > How about adding the test in 019_replslot_limit? It is not a direct
> > > fit but I feel later we can even add 'invalid_timeout' related tests
> > > in this file which will use last_inactive_time feature.
> >
> > I'm thinking the
On Tue, Mar 19, 2024 at 5:20 PM Alexander Korotkov wrote:
> On Tue, Nov 28, 2023 at 11:00 AM Pavel Borisov wrote:
> > > You're designing new APIs, days before the feature freeze.
> > On Wed, 5 Apr 2023 at 06:54, Michael Paquier wrote:
> > >
> > > On Tue, Apr 04, 2023 at 01:25:46AM +0300,
On Sat, Mar 23, 2024 at 3:00 PM Tom Lane wrote:
> I have a patch in the queue [1] that among other things tries to
> reduce the number of XIDs consumed during pg_upgrade by making
> pg_restore group its commands into batches of a thousand or so
> per transaction. This had been passing tests, so
On Thu, Mar 21, 2024 at 1:09 PM Robert Haas wrote:
>
> On Thu, Mar 14, 2024 at 9:07 PM James Coleman wrote:
> > If the goal here is the most minimal patch possible, then please
> > commit what you proposed. I am interested in improving the document
> > further, but I don't know how to do that
On Wed, Mar 20, 2024 at 2:15 PM Robert Haas wrote:
>
> On Thu, Mar 14, 2024 at 9:07 PM James Coleman wrote:
> > Obviously I have reasons for the other changes I made: for example,
> > "no longer visible" improves the correctness, since being an old
> > version isn't sufficient. I removed the "In
I have a patch in the queue [1] that among other things tries to
reduce the number of XIDs consumed during pg_upgrade by making
pg_restore group its commands into batches of a thousand or so
per transaction. This had been passing tests, so I was quite
surprised when the cfbot started to show it
> On Sat, Mar 23, 2024 at 04:13:44PM +0900, Yasuo Honda wrote:
> Hi, I'm interested in this feature. It looks like these patches have
> some conflicts.
>
> http://cfbot.cputube.org/patch_47_2837.log
>
> Would you rebase these patches?
Sure, I can rebase, give me a moment. If you don't want to
On 3/23/24 14:47, Tomas Vondra wrote:
> On 3/23/24 13:38, Robert Haas wrote:
>> On Fri, Mar 22, 2024 at 8:26 PM Thomas Munro wrote:
>>> Hmm, this discussion seems to assume that we only use
>>> copy_file_range() to copy/clone whole segment files, right? That's
>>> great and may even get most
Dear hackers,
I was looking at how foreign keys deal with collations, and I came across this comment about not
re-checking a foreign key if the column type changes in a compatible way:
* Since we require that all collations share the same notion of
* equality (which they do, because
> On 22 Mar 2024, at 10:11, Michał Kłeczek wrote:
>
>>
>> On 22 Mar 2024, at 01:29, Michał Kłeczek wrote:
>>
>>
>>
>>> On 21 Mar 2024, at 23:42, Matthias van de Meent
>>> wrote:
>>>
>>>
>>> You seem to already be using your own operator class, so you may want
>>> to look into CREATE
Robert Haas writes:
> On Fri, Mar 22, 2024 at 4:37 PM Tom Lane wrote:
>> I think these things are already dealt with. However, one thing
>> worth questioning is that CommitSubTransaction() will just silently
>> kill any workers started during the current subxact, and likewise
>>
Aleksander Alekseev writes:
> One thing I'm not 100% sure of is whether record_larger() should make
> a copy of its arguments or the current implementation is safe.
I don't see any copying happening in, say, text_larger or
numeric_larger, so this shouldn't need to either.
Personally I'd write
On 3/23/24 13:38, Robert Haas wrote:
> On Fri, Mar 22, 2024 at 8:26 PM Thomas Munro wrote:
>> Hmm, this discussion seems to assume that we only use
>> copy_file_range() to copy/clone whole segment files, right? That's
>> great and may even get most of the available benefit given typical
>>
On 3/22/24 19:40, Robert Haas wrote:
> On Fri, Mar 22, 2024 at 1:22 PM Tomas Vondra
> wrote:
>> Right, this will happen:
>>
>> pg_combinebackup: error: unable to use accelerated copy when manifest
>> checksums are to be calculated. Use --no-manifest
>>
>> Are you saying we should just
On Fri, Mar 22, 2024 at 4:37 PM Tom Lane wrote:
> Fair enough. In the attached v2, I wrote "change the transaction
> state (other than by using a subtransaction for error recovery)";
> what do you think of that?
I think that's pretty good. I wonder if there are some bizarre cases
where the
On Fri, Mar 22, 2024 at 8:26 PM Thomas Munro wrote:
> Hmm, this discussion seems to assume that we only use
> copy_file_range() to copy/clone whole segment files, right? That's
> great and may even get most of the available benefit given typical
> databases with many segments of old data that
On Fri, Mar 22, 2024 at 4:51 PM Nathan Bossart wrote:
> Actually, shouldn't this one be back-patched to v16? If so, I'd do that
> one separately from the other changes we are discussing.
Sure, that seems fine.
--
Robert Haas
EDB: http://www.enterprisedb.com
Hi,
> Exactly Tom, I see no fundamental problem for it not to be implemented, since
> comparison operator is already implemented. In fact, MIN/MAX should work for
> all types for which comparison operator is defined.
On second thought, this should work reasonably well.
PFA a WIP patch. At
On Mon, Mar 18, 2024 at 11:38 AM Michael Paquier wrote:
>
> On Sun, Mar 17, 2024 at 11:37:58AM +0530, Bharath Rupireddy wrote:
> > Rebase needed after 071e3ad59d6fd2d6d1277b2bd9579397d10ded28 due to a
> > conflict in meson.build. Please see the attached v23 patch.
>
> I've been reading this
Hi,
On Sat, Mar 23, 2024 at 01:11:50PM +0530, Bharath Rupireddy wrote:
> On Sat, Mar 23, 2024 at 11:27 AM Amit Kapila wrote:
> >
> > How about adding the test in 019_replslot_limit? It is not a direct
> > fit but I feel later we can even add 'invalid_timeout' related tests
> > in this file which
On Sat, Mar 23, 2024 at 11:27 AM Amit Kapila wrote:
>
> How about adding the test in 019_replslot_limit? It is not a direct
> fit but I feel later we can even add 'invalid_timeout' related tests
> in this file which will use last_inactive_time feature.
I'm thinking the other way. Now, the new
Hi, I'm interested in this feature. It looks like these patches have
some conflicts.
http://cfbot.cputube.org/patch_47_2837.log
Would you rebase these patches?
Thanks,
--
Yasuo Honda
On Sat, Mar 23, 2024 at 4:11 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
> > Oh, I see, thanks. Give me a
25 matches
Mail list logo
