On Tue, 10 Dec 2024 at 19:13, Tom Lane wrote:
> Pavel Borisov writes:
> > I see Aleksander worked on this patch (with many other hackers) and
> marked
> > it as rejected. And now Evgeniy, a new developer wants to continue and
> > rebase this patch and also the patches in another 64-xid thread
>
Pavel Borisov writes:
> I see Aleksander worked on this patch (with many other hackers) and marked
> it as rejected. And now Evgeniy, a new developer wants to continue and
> rebase this patch and also the patches in another 64-xid thread
> disregarding the fact that the patch is rejected. It's not
Hi, Wenhui!
On Tue, 10 Dec 2024 at 17:32, wenhui qiu wrote:
> Hi aleksander
>Didn't you mark this patch as rejected last time? Do we still need to
> continue this path?
>
>
> Thanks
>
> On Sun, Dec 8, 2024 at 10:16 PM Evgeny Voropaev
> wrote:
>
>> Hi hackers!
>>
>> Upgraded the "Int64 GUC"
Hi aleksander
Didn't you mark this patch as rejected last time? Do we still need to
continue this path?
Thanks
On Sun, Dec 8, 2024 at 10:16 PM Evgeny Voropaev
wrote:
> Hi hackers!
>
> Upgraded the "Int64 GUC" patch in order to conform to f3f06b13308e3
> updates. Rebased and tested upon the
Hi hackers!
Upgraded the "Int64 GUC" patch in order to conform to f3f06b13308e3
updates. Rebased and tested upon the current master (3f9b9621766). The
patch is still needed to be up to date as a part of the xid64 solution.
Best regards,
Evgeny Voropaev,
TantorLabs, LLC.
From 1ff7cc48d955e024
Hi hackers!
Upgraded the "Int64 GUC" patch in order to conform to f3f06b13308e3
updates. Rebased and tested upon the current master (3f9b9621766). The
patch is still needed to be up to date as a part of the xid64 solution.
Best regards,
Evgeny Voropaev,
TantorLabs, LLC.
Hi,
> I seriously doubt that _age values exceeding INT32_MAX would be
> useful, even in the still-extremely-doubtful situation that we
> get to true 64-bit XIDs. But if you think we must have that,
> we could still use float8 GUCs for them. float8 is exact up
> to 2^53 (given IEEE math), and you
On Thu, Sep 26, 2024 at 12:30 PM wenhui qiu wrote:
> I think we need int64 GUCs, due to these parameters（
> autovacuum_freeze_table_age, autovacuum_freeze_max_age,When a table age is
> greater than any of these parameters an aggressive vacuum will be performed,
> When we implementing xid
Alexander Korotkov writes:
> Do you think we don't need int64 GUCs just now, when 64-bit
> transaction ids are far from committable shape? Or do you think we
> don't need int64 GUCs even if we have 64-bit transaction ids? If yes,
> what do you think we should use for *_age variables with 64-bit
Hi Alexander
I think we need int64 GUCs, due to these parameters（
autovacuum_freeze_table_age, autovacuum_freeze_max_age,When a table age is
greater than any of these parameters an aggressive vacuum will be
performed, When we implementing xid64, is it still necessary to be in the
int range?
Hi, Tom!
On Wed, Sep 25, 2024 at 6:08 PM Tom Lane wrote:
> FWIW, I agree with the upthread opinions that we shouldn't do this
> (invent int64 GUCs). I don't think we need the added code bloat
> and risk of breaking user code that isn't expecting this new GUC
> type. We invented the notion of GU
FWIW, I agree with the upthread opinions that we shouldn't do this
(invent int64 GUCs). I don't think we need the added code bloat
and risk of breaking user code that isn't expecting this new GUC
type. We invented the notion of GUC units in part to ensure that
int32 GUCs could be adapted to handl
Hi,
> ```
> postgres=# alter system set autovacuum_vacuum_threshold to 2_147_483_648;
> ERROR: invalid value for parameter "autovacuum_vacuum_threshold":
> "2_147_483_648"
> postgres=# alter system set autovacuum_vacuum_threshold to 2_147_483_647;
> ALTER SYSTEM
> ```
>
> IIRC, the lexer only su
On Sep 25, 2024, at 19:03, Aleksander Alekseev wrote:
Hi,
I found the autovacuum_vacuum_threshold, autovacuum_vacuum_insert_threshold
and autovacuum_analyze_threshold is change to int64 for relation option,
however the GUCs are still integers.
```
postgres=# select * from pg_settings where nam
Hi,
> I found the autovacuum_vacuum_threshold, autovacuum_vacuum_insert_threshold
> and autovacuum_analyze_threshold is change to int64 for relation option,
> however the GUCs are still integers.
>
> ```
> postgres=# select * from pg_settings where name =
> 'autovacuum_vacuum_threshold' \gx
> -[
On Tue, Sep 24, 2024 at 12:27:20PM +0300, Aleksander Alekseev wrote:
>> It doesn't look like these *_age GUCs could benefit from being 64-bit,
>> before 64-bit transaction ids get in. However, I think there are some
>> better candidates.
>>
>> autovacuum_vacuum_threshold
>> autovacuum_vacuum_inser
Hi, Aleksander Alekseev
Thanks for updating the patch.
> On Sep 24, 2024, at 17:27, Aleksander Alekseev
> wrote:
>
> Hi, Alexander!
>
>> Thank you for your work on this subject.
>
> Thanks for your feedback.
>
>> It doesn't look like these *_age GUCs could benefit from being 64-bit,
>> befo
Hi,
> PFA the updated patch.
It is worth mentioning that v2 should not be merged as is.
Particularly although it changes the following GUCs:
> autovacuum_vacuum_threshold
> autovacuum_vacuum_insert_threshold
> autovacuum_analyze_threshold
... it doesn't affect the code that uses these GUCs whic
Hi, Alexander!
> Thank you for your work on this subject.
Thanks for your feedback.
> It doesn't look like these *_age GUCs could benefit from being 64-bit,
> before 64-bit transaction ids get in. However, I think there are some
> better candidates.
>
> autovacuum_vacuum_threshold
> autovacuum_
Hi, Aleksander!
Thank you for your work on this subject.
On Thu, Sep 12, 2024 at 2:08 PM Aleksander Alekseev
wrote:
> Attached is a self-sufficient patch extracted from a larger patchset
> [1]. The entire patchset probably will not proceed further in the
> nearest future. Since there was interes
On Thu, Sep 12, 2024 at 2:29 PM Pavel Borisov wrote:
> Hi, Alexander!
> Thank you for working on this!
>
> On Thu, 12 Sept 2024 at 15:08, Aleksander Alekseev
> wrote:
>>
>> Hi,
>>
>> Attached is a self-sufficient patch extracted from a larger patchset
>> [1]. The entire patchset probably will no
On Thu, Sep 12, 2024 at 02:08:15PM +0300, Aleksander Alekseev wrote:
> Secondly, the following core GUCs are made 64-bit:
>
> ```
> autovacuum_freeze_min_age
> autovacuum_freeze_max_age
> autovacuum_freeze_table_age
> autovacuum_multixact_freeze_min_age
> autovacuum_multixact_freeze_max_age
> auto
Hi Pavel,
> I think the direction is good and delivering 64-bit GUCs is very much worth
> committing.
> The patch itself looks good, but we could need to add locks against
> concurrently modifying 64-bit values, which could be non-atomic on older
> architectures.
Thanks for the feedback.
> I
Hi, Alexander!
Thank you for working on this!
On Thu, 12 Sept 2024 at 15:08, Aleksander Alekseev
wrote:
> Hi,
>
> Attached is a self-sufficient patch extracted from a larger patchset
> [1]. The entire patchset probably will not proceed further in the
> nearest future. Since there was interest in
Hi,
Attached is a self-sufficient patch extracted from a larger patchset
[1]. The entire patchset probably will not proceed further in the
nearest future. Since there was interest in this particular patch it
deserves being discussed in a separate thread.
Currently we support 32-bit integer values
25 matches
Mail list logo
