On Wed, Sep 08, 2021 at 03:08:28PM +0900, Michael Paquier wrote:
> On top of the tests for needed for custom GUCs, this needs tests for
> the new int64 reloption. I would suggest to add something in
> dummy_index_am, where we test all the reloption APIs.
My review here was three weeks ago, and th
On Tue, Sep 07, 2021 at 02:38:13PM +0800, Julien Rouhaud wrote:
> On Tue, Sep 7, 2021 at 12:20 PM Michael Paquier wrote:
>> And a couple of months later, the development cycle of 15 has begun.
>> While re-reading the thread, I got the impression that there is no
>> reason to not move on with at le
On Tue, Sep 7, 2021 at 12:20 PM Michael Paquier wrote:
>
> On Fri, Mar 26, 2021 at 09:54:21AM -0400, David Steele wrote:
> > I'm going to move this to the 2021-07 CF and leave it in the Waiting for
> > Author state. It would probably be best to wait until just before the CF to
> > rebase since any
On Fri, Mar 26, 2021 at 09:54:21AM -0400, David Steele wrote:
> I'm going to move this to the 2021-07 CF and leave it in the Waiting for
> Author state. It would probably be best to wait until just before the CF to
> rebase since anything you do now will likely be broken by the flurry of
> commits
Hi Jim,
On 3/26/21 12:01 AM, Thomas Munro wrote:
On Fri, Mar 26, 2021 at 2:57 AM David Steele wrote:
On 1/22/21 6:46 PM, Finnerty, Jim wrote:
First 3 patches derived from the original 64-bit xid patch set by Alexander
Korotkov
The patches no longer apply
(http://cfbot.cputube.org/patch_32_
On Fri, Mar 26, 2021 at 2:57 AM David Steele wrote:
> On 1/22/21 6:46 PM, Finnerty, Jim wrote:
> > First 3 patches derived from the original 64-bit xid patch set by Alexander
> > Korotkov
>
> The patches no longer apply
> (http://cfbot.cputube.org/patch_32_2960.log), so marked Waiting on Author.
On 1/22/21 6:46 PM, Finnerty, Jim wrote:
First 3 patches derived from the original 64-bit xid patch set by Alexander
Korotkov
The patches no longer apply
(http://cfbot.cputube.org/patch_32_2960.log), so marked Waiting on Author.
I also removed the PG14 target since this is a fresh patch set
Hi,
On 2019-02-13 12:16:33 +0100, Chris Travers wrote:
> As a note here, I have worked on projects where there could be 2-week-long
> idle-in-transaction states (no joke, we tuned things to only use virtual
> xids for most of that time), and having an ability to set
> idle-in-transaction timeouts
On Thu, Mar 1, 2018 at 11:48 PM Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> Hi!
>
> On Fri, Mar 2, 2018 at 1:41 AM, Andres Freund wrote:
>
>> On 2018-01-11 01:02:52 +0300, Alexander Korotkov wrote:
>> > As I get from cputube, patchset doesn't compiles again. Please find
>> > revised
On Fri, Mar 2, 2018 at 12:07 AM Andres Freund wrote:
> On 2018-03-02 01:56:00 +0300, Alexander Korotkov wrote:
> > On Fri, Mar 2, 2018 at 1:51 AM, Andres Freund
> wrote:
> >
> > > On 2018-03-02 01:48:03 +0300, Alexander Korotkov wrote:
> > > > Also, the last commitfest is already too late for su
On 2018-03-02 01:56:00 +0300, Alexander Korotkov wrote:
> On Fri, Mar 2, 2018 at 1:51 AM, Andres Freund wrote:
>
> > On 2018-03-02 01:48:03 +0300, Alexander Korotkov wrote:
> > > Also, the last commitfest is already too late for such big changes.
> > > So, I'm marking this RWF.
> >
> > Agreed. P
On Fri, Mar 2, 2018 at 1:51 AM, Andres Freund wrote:
> On 2018-03-02 01:48:03 +0300, Alexander Korotkov wrote:
> > Also, the last commitfest is already too late for such big changes.
> > So, I'm marking this RWF.
>
> Agreed. Perhaps extract the 64bit GUC patch and track that separately?
> Seems
On 2018-03-02 01:48:03 +0300, Alexander Korotkov wrote:
> Also, the last commitfest is already too late for such big changes.
> So, I'm marking this RWF.
Agreed. Perhaps extract the 64bit GUC patch and track that separately?
Seems like something we should just do...
Greetings,
Andres Freund
Hi!
On Fri, Mar 2, 2018 at 1:41 AM, Andres Freund wrote:
> On 2018-01-11 01:02:52 +0300, Alexander Korotkov wrote:
> > As I get from cputube, patchset doesn't compiles again. Please find
> > revised version attached.
>
> It'd be good if you could maintain the patches as commits with some
> desc
Hi,
On 2018-01-11 01:02:52 +0300, Alexander Korotkov wrote:
> As I get from cputube, patchset doesn't compiles again. Please find
> revised version attached.
It'd be good if you could maintain the patches as commits with some
description of why you're doing these changes. It's a bit hard to
fig
Hi, Ryan!
On Sat, Jan 6, 2018 at 10:10 PM, Ryan Murphy wrote:
> Thanks for this contribution!
> I think it's a hard but important problem to upgrade these xids.
>
> Unfortunately, I've confirmed that this patch
> 0001-64bit-guc-relopt-3.patch doesn't apply correctly on my computer.
>
> Here's wh
Ryan Murphy writes:
> Alexander, what is the process you're using to create the patch? I've heard
> someone (maybe Tom Lane?) say that he sometimes uses "patch" directly instead
> of "git" to create the patch, with better results. I forget the exact
> command.
Nah, you've got that the other
Thanks for this contribution!
I think it's a hard but important problem to upgrade these xids.
Unfortunately, I've confirmed that this patch 0001-64bit-guc-relopt-3.patch
doesn't apply correctly on my computer.
Here's what I did:
I did a "git pull" to the current HEAD, which is
6271fceb8a4f07d
Since the Patch Tester (http://commitfest.cputube.org/) says this Patch will
not apply correctly, I am tempted to change the status to Waiting on Author.
However, I'm new to the CommitFest process, so I'm leaving the status as-is for
now and asking Stephen Frost whether he agrees.
I haven't tri
On Tue, Nov 28, 2017 at 6:41 AM, Alexander Korotkov
wrote:
> On Mon, Nov 27, 2017 at 10:56 PM, Robert Haas wrote:
>>
>> On Fri, Nov 24, 2017 at 5:33 AM, Alexander Korotkov
>> wrote:
>> > pg_prune_xid makes sense only for heap pages. Once we introduce special
>> > area for heap pages, we can mov
On Tue, Nov 28, 2017 at 4:56 AM, Robert Haas wrote:
> On Fri, Nov 24, 2017 at 5:33 AM, Alexander Korotkov
> wrote:
>> pg_prune_xid makes sense only for heap pages. Once we introduce special
>> area for heap pages, we can move pg_prune_xid there and save some bytes in
>> index pages. However, th
On Mon, Nov 27, 2017 at 10:56 PM, Robert Haas wrote:
> On Fri, Nov 24, 2017 at 5:33 AM, Alexander Korotkov
> wrote:
> > pg_prune_xid makes sense only for heap pages. Once we introduce special
> > area for heap pages, we can move pg_prune_xid there and save some bytes
> in
> > index pages. Howe
On Mon, Nov 27, 2017 at 11:56 AM, Robert Haas wrote:
> On Fri, Nov 24, 2017 at 5:33 AM, Alexander Korotkov
> wrote:
>> pg_prune_xid makes sense only for heap pages. Once we introduce special
>> area for heap pages, we can move pg_prune_xid there and save some bytes in
>> index pages. However, t
On Fri, Nov 24, 2017 at 5:33 AM, Alexander Korotkov
wrote:
> pg_prune_xid makes sense only for heap pages. Once we introduce special
> area for heap pages, we can move pg_prune_xid there and save some bytes in
> index pages. However, this is an optimization not directly related to
> 64-bit xids.
On Fri, Nov 24, 2017 at 4:03 PM, Alexander Korotkov
wrote:
>> > 0002-heap-page-special-1.patch
>> > Putting xid and multixact bases into PageHeaderData would take extra 16
>> > bytes on index pages too. That would be waste of space for indexes.
>> > This
>> > is why I decided to put bases into sp
Dear Amit,
Thank you for the attention to this patch.
On Thu, Nov 23, 2017 at 4:39 PM, Amit Kapila
wrote:
> On Thu, Jun 22, 2017 at 9:06 PM, Alexander Korotkov
> wrote:
> > Work on this patch took longer than I expected. It is still in not so
> good
> > shape, but I decided to publish it anyw
On Thu, Jun 22, 2017 at 9:06 PM, Alexander Korotkov
wrote:
> On Wed, Jun 7, 2017 at 11:33 AM, Alexander Korotkov
> wrote:
>>
>> On Tue, Jun 6, 2017 at 4:05 PM, Peter Eisentraut
>> wrote:
>>>
>>> On 6/6/17 08:29, Bruce Momjian wrote:
>>> > On Tue, Jun 6, 2017 at 06:00:54PM +0800, Craig Ringer wr
27 matches
Mail list logo
