On Thu, Sep 12, 2024 at 10:41:27PM -0500, Nathan Bossart wrote:
> Thanks for checking. I'll commit this fix in the morning.
Committed.
--
nathan
On Thu, Sep 12, 2024 at 10:40:11PM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> Here's a patch to make the sequence permanent and to make the output of
>> tuple_data_split() not depend on endianness.
>
> +1 --- I checked this on mamba's host and it does produce
> "\\x0101" regar
Nathan Bossart writes:
> Here's a patch to make the sequence permanent and to make the output of
> tuple_data_split() not depend on endianness.
+1 --- I checked this on mamba's host and it does produce
"\\x0101" regardless of endianness.
regards, tom lane
On Thu, Sep 12, 2024 at 08:42:09PM -0500, Nathan Bossart wrote:
> Oh, the answer seems to be commits aeaaf52 and 47a22dc. In short, we can't
> use a temporary sequence in this test for versions older than v15.
Here's a patch to make the sequence permanent and to make the output of
tuple_data_spli
On Thu, Sep 12, 2024 at 07:56:56PM -0500, Nathan Bossart wrote:
> I see that skimmer is failing with this error:
>
> ERROR: cannot access temporary tables during a parallel operation
>
> This makes sense because that machine has
> debug_parallel_query/force_parallel_mode set to "regress",
On Fri, Sep 13, 2024 at 09:47:36AM +0900, Michael Paquier wrote:
> On Thu, Sep 12, 2024 at 07:41:30PM -0500, Nathan Bossart wrote:
>> Ugh, the buildfarm is unhappy with the new tests [0] [1]. Will fix.
>
> I'd suggest to switch the test to return a count() and make sure that
> one record exists.
On Thu, Sep 12, 2024 at 07:41:30PM -0500, Nathan Bossart wrote:
> On Thu, Sep 12, 2024 at 04:39:14PM -0500, Nathan Bossart wrote:
> > Committed.
>
> Ugh, the buildfarm is unhappy with the new tests [0] [1]. Will fix.
I'd suggest to switch the test to return a count() and make sure that
one recor
On Thu, Sep 12, 2024 at 04:39:14PM -0500, Nathan Bossart wrote:
> Committed.
Ugh, the buildfarm is unhappy with the new tests [0] [1]. Will fix.
[0]
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=wrasse&dt=2024-09-12%2022%3A54%3A45
[1]
https://buildfarm.postgresql.org/cgi-bin/show_log
On Thu, Sep 12, 2024 at 11:19:00AM +0900, Michael Paquier wrote:
> On Wed, Sep 11, 2024 at 11:02:43PM +0100, Matthias van de Meent wrote:
>> As for patch v3, that seems fine with me.
>
> +1 from here as well, after looking at what v3 is doing for these two
> modules.
Committed.
--
nathan
On Wed, Sep 11, 2024 at 11:02:43PM +0100, Matthias van de Meent wrote:
> On Wed, 11 Sept 2024 at 21:36, Nathan Bossart
> wrote:
> >
> > Barring objections, I'm planning to commit v3 soon. Robert/Matthias, I'm
> > not sure you are convinced this is the right thing to do (or worth doing,
> > rathe
On Wed, 11 Sept 2024 at 21:36, Nathan Bossart wrote:
>
> Barring objections, I'm planning to commit v3 soon. Robert/Matthias, I'm
> not sure you are convinced this is the right thing to do (or worth doing,
> rather), but I don't sense that you are actually opposed to it, either.
> Please correct
Barring objections, I'm planning to commit v3 soon. Robert/Matthias, I'm
not sure you are convinced this is the right thing to do (or worth doing,
rather), but I don't sense that you are actually opposed to it, either.
Please correct me if I am wrong.
--
nathan
On Tue, Sep 03, 2024 at 10:19:33PM +0200, Matthias van de Meent wrote:
> On Fri, 30 Aug 2024, 23:06 Nathan Bossart, wrote:
>> Another related inconsistency I just noticed in pageinspect:
>>
>> postgres=# select t_data from heap_page_items(get_raw_page('s', 0));
>> t_data
>>
On Fri, 30 Aug 2024, 23:06 Nathan Bossart, wrote:
>
> On Fri, Aug 30, 2024 at 04:07:30PM -0400, Robert Haas wrote:
> > On Thu, Aug 29, 2024 at 1:36 PM Nathan Bossart
> > wrote:
> >> Thanks. Robert, do you have any concerns with this?
> >
> > I don't know if I'm exactly concerned but I don't und
Here is roughly what I had in mind to commit, but I'm not sure there's a
consensus on doing this.
--
nathan
>From 97e670e2e0b53a9dc91c5932ccb34bb1fd7eae6b Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Tue, 3 Sep 2024 14:49:24 -0500
Subject: [PATCH v3 1/1] Reintroduce support for sequences
On Fri, Aug 30, 2024 at 04:06:03PM -0500, Nathan Bossart wrote:
> I suppose it would be difficult to argue that it is actually useful, given
> it hasn't worked since v11 and apparently nobody noticed until recently.
> If we're content to leave it unsupported, then sure, let's just remove the
> "rel
On Fri, Aug 30, 2024 at 04:07:30PM -0400, Robert Haas wrote:
> On Thu, Aug 29, 2024 at 1:36 PM Nathan Bossart
> wrote:
>> Thanks. Robert, do you have any concerns with this?
>
> I don't know if I'm exactly concerned but I don't understand what
> problem we're solving, either. I thought Ayush sa
On Thu, Aug 29, 2024 at 1:36 PM Nathan Bossart wrote:
> Thanks. Robert, do you have any concerns with this?
I don't know if I'm exactly concerned but I don't understand what
problem we're solving, either. I thought Ayush said that the function
wouldn't produce useful results for sequences; so th
On Fri, Aug 30, 2024 at 12:17:47AM +0530, Ayush Vatsa wrote:
> The patch with all the changes is attached.
Looks generally reasonable to me.
--
nathan
> I'm concerned that some of this might be platform-dependent and make the
> test unstable. Perhaps we should just select count(*) here.
> Sure enough, the CI testing for 32-bit is failing here [0].
Thanks for catching that! I wasn't aware of this earlier.
> I think we should be a bit more descri
On Thu, Aug 29, 2024 at 12:36:35PM -0500, Nathan Bossart wrote:
> +select * from pgstattuple('serial');
> + table_len | tuple_count | tuple_len | tuple_percent | dead_tuple_count |
> dead_tuple_len | dead_tuple_percent | free_space | free_percent
> +---+-+---+-
On Thu, Aug 29, 2024 at 10:17:57PM +0530, Ayush Vatsa wrote:
> Please find attached the patch that re-enables
> support for sequences within the pgstattuple extension.
> I have also included the necessary test cases for
> sequences, implemented in the form of regress tests.
Thanks. Robert, do you
Hi all,
Please find attached the patch that re-enables
support for sequences within the pgstattuple extension.
I have also included the necessary test cases for
sequences, implemented in the form of regress tests.
Here is the commitfest link for the same -
https://commitfest.postgresql.org/49/5215
On Mon, Aug 26, 2024 at 01:35:52PM -0400, Robert Haas wrote:
> On Mon, Aug 26, 2024 at 1:26 PM Nathan Bossart
> wrote:
>> While it is apparently pretty uncommon to use pgstattuple on sequences,
>> this is arguably a bug that should be fixed and back-patched.
>
> I don't understand what would mak
> You state that the
> information pgstattuple provides isn't really useful for sequences, so
> that means there's no real reason to do (1)
That's correct, but we should consider that up until v11,
sequences were supported in pgstattuple. Their support
was removed unintentionally (I believe so). Th
On Mon, Aug 26, 2024 at 1:26 PM Nathan Bossart wrote:
> While it is apparently pretty uncommon to use pgstattuple on sequences,
> this is arguably a bug that should be fixed and back-patched.
I don't understand what would make it a bug.
> IMHO it would be good to establish some level of consiste
On Mon, Aug 26, 2024 at 09:14:27PM +0530, Ayush Vatsa wrote:
> Given the situation, I see two potential paths forward:
> *1/ Reintroduce Support for Sequences in pgstattuple*: This would be a
> relatively small change. However, it's important to note that the purpose
> of pgstattuple is to provide
On Mon, Aug 26, 2024 at 11:44 AM Ayush Vatsa wrote:
> Hi PostgreSQL Community,
> I have encountered an issue when attempting to use pgstattuple extension with
> sequences. When executing the following command:
>
> SELECT * FROM pgstattuple('serial');
> ERROR: only heap AM is supported
>
> This b
Hi PostgreSQL Community,
I have encountered an issue when attempting to use pgstattuple extension
with sequences. When executing the following command:
SELECT * FROM pgstattuple('serial');
ERROR: only heap AM is supported
This behaviour is observed in PostgreSQL versions post v11 [1] , where
seq
29 matches
Mail list logo
