On Fri, Jun 06, 2025 at 10:55:32AM +0900, Michael Paquier wrote:
> Okay, thanks. Let's wait for a couple of days in case there are more
> opinions and/or comments. I propose to apply the patch around the
> beginning of next week if there are no objections.
It took a bit longer than wanted, but a
On Thu, Jun 05, 2025 at 03:04:45PM -0500, Nathan Bossart wrote:
> IMHO a case can be reasonably made that this is an oversight in the related
> commit. I've added the rest of the RMT here in case they see it
> differently.
>
> The patch LGTM, too.
Okay, thanks. Let's wait for a couple of days i
On Thu, Jun 05, 2025 at 01:57:30PM +0900, Michael Paquier wrote:
> How does the RMT feel about this change? Nathan, would you be OK with
> that? It's not a big problem, as well, if the code is kept as-is, but
> as it's a simple change..
IMHO a case can be reasonably made that this is an oversigh
On Thu, Jun 05, 2025 at 10:04:23AM +0900, Shinya Kato wrote:
> Thank you. It looks good to me.
How does the RMT feel about this change? Nathan, would you be OK with
that? It's not a big problem, as well, if the code is kept as-is, but
as it's a simple change..
--
Michael
signature.asc
Descript
On Thu, Jun 5, 2025 at 9:23 AM Michael Paquier wrote:
> Agreed to not suggest the PARTITION BY clause in the tab completion as
> it is not supported by the backend for unlogged tables.
> tab-complete.in.c has some handling for CREATE UNLOGGED TABLE around
> line 3667, so we could just have an extr
On Wed, Jun 04, 2025 at 11:15:29AM -0500, Nathan Bossart wrote:
> I see no benefit in recommending things that are guaranteed to error. In
> commit 5c1ce1b, we removed tab completion for CREATE UNLOGGED MATERIALIZED
> VIEW even though it is supported by the grammar. The partitioned table
> case s
On Wed, Jun 04, 2025 at 07:05:20PM +0900, Shinya Kato wrote:
> On Wed, Jun 4, 2025 at 6:55 PM Shinya Kato wrote:
>> Should we consider preventing tab completion for PARTITION BY
>> immediately after CREATE TABLE name (...)? Or is it fine to leave it
>> as is, given that it's syntactically correct?
On Wed, Jun 4, 2025 at 6:55 PM Shinya Kato wrote:
>
> On Wed, Jun 4, 2025 at 6:42 PM Michael Paquier wrote:
> >
> > On Thu, Sep 19, 2024 at 01:08:33PM +0900, Michael Paquier wrote:
> > > I have applied 0001 for now to add ATT_PARTITIONED_TABLE. Attached is
> > > the remaining piece.
> >
> > And
On Wed, Jun 4, 2025 at 6:42 PM Michael Paquier wrote:
>
> On Thu, Sep 19, 2024 at 01:08:33PM +0900, Michael Paquier wrote:
> > I have applied 0001 for now to add ATT_PARTITIONED_TABLE. Attached is
> > the remaining piece.
>
> And the second piece is now applied as of e2bab2d79204.
> --
> Michael
On Thu, Sep 19, 2024 at 01:08:33PM +0900, Michael Paquier wrote:
> I have applied 0001 for now to add ATT_PARTITIONED_TABLE. Attached is
> the remaining piece.
And the second piece is now applied as of e2bab2d79204.
--
Michael
signature.asc
Description: PGP signature
On Fri, Sep 20, 2024 at 09:37:54AM +0900, Michael Paquier wrote:
> What do you think about adding a test with DETACH FINALIZE when
> attempting it on a normal table, its path being under a different
> subcommand than DETACH [CONCURRENTLY]?
>
> There are no tests for normal tables with DETACH CONCU
On Thu, Sep 19, 2024 at 10:03:09AM +0200, Alvaro Herrera wrote:
> It looks to me like these cases could be modified to accept only
> ATT_PARTITIONED_TABLE, not ATT_TABLE anymore. The ATT_TABLE cases are
> useless anyway, because they're rejected by transformPartitionCmd.
Makes sense to me, thanks
On Thu, Sep 19, 2024 at 10:03:09AM +0200, Alvaro Herrera wrote:
> It looks to me like these cases could be modified to accept only
> ATT_PARTITIONED_TABLE, not ATT_TABLE anymore. The ATT_TABLE cases are
> useless anyway, because they're rejected by transformPartitionCmd.
+1. If anything, this ma
On 2024-Sep-10, Michael Paquier wrote:
> @@ -5060,17 +5061,17 @@ ATPrepCmd(List **wqueue, Relation rel, AlterTableCmd
> *cmd,
> pass = AT_PASS_MISC;
> break;
> case AT_AttachPartition:
> - ATSimplePermissions(cmd->subty
On Thu, Sep 19, 2024 at 08:06:19AM +0900, Michael Paquier wrote:
> I did not notice this one. I have to admit that the error message
> consistency is welcome, not the extra checks required at
> transformation.
I have applied 0001 for now to add ATT_PARTITIONED_TABLE. Attached is
the remaining pi
On Wed, Sep 18, 2024 at 10:58:34AM -0500, Nathan Bossart wrote:
> On Wed, Sep 18, 2024 at 10:17:47AM -0500, Nathan Bossart wrote:
>> Could we also use ATT_PARTITIONED_TABLE to remove the partitioned table
>> check in ATExecAddIndexConstraint()?
>
> Eh, never mind. That ends up being gross because
On Wed, Sep 18, 2024 at 10:17:47AM -0500, Nathan Bossart wrote:
> Could we also use ATT_PARTITIONED_TABLE to remove the partitioned table
> check in ATExecAddIndexConstraint()?
Eh, never mind. That ends up being gross because you have to redo the
relation type check in a few places.
--
nathan
d
On Tue, Sep 10, 2024 at 09:42:31AM +0900, Michael Paquier wrote:
> On Mon, Sep 09, 2024 at 03:56:14PM +0900, Michael Paquier wrote:
>> How about inventing a new ATT_PARTITIONED_TABLE and make a clean split
>> between both relkinds? I'd guess that blocking both SET LOGGED and
>> UNLOGGED for partit
On Mon, Sep 09, 2024 at 03:56:14PM +0900, Michael Paquier wrote:
> How about inventing a new ATT_PARTITIONED_TABLE and make a clean split
> between both relkinds? I'd guess that blocking both SET LOGGED and
> UNLOGGED for partitioned tables is the best move, even if it is
> possible to block only
On Tue, Sep 03, 2024 at 10:33:02AM -0500, Nathan Bossart wrote:
> This works correctly for CREATE TABLE, but ALTER TABLE still succeeds.
> Interestingly, it doesn't seem to actually change relpersistence for
> partitioned tables. I think we might need to adjust
> ATPrepChangePersistence().
Adjust
On Tue, Sep 03, 2024 at 04:59:18PM +0900, Michael Paquier wrote:
> An idea is attached. The pgbench bit was unexpected.
This works correctly for CREATE TABLE, but ALTER TABLE still succeeds.
Interestingly, it doesn't seem to actually change relpersistence for
partitioned tables. I think we might
On Mon, Sep 02, 2024 at 08:35:15PM -0500, Nathan Bossart wrote:
> On Tue, Sep 03, 2024 at 09:22:58AM +0900, Michael Paquier wrote:
>> Okay. This is going to be disruptive if we do nothing about pg_dump,
>> unfortunately. How about tweaking dumpTableSchema() so as we'd never
>> issue UNLOGGED for
On Tue, Sep 03, 2024 at 09:22:58AM +0900, Michael Paquier wrote:
> On Thu, Aug 29, 2024 at 09:49:44AM -0500, Nathan Bossart wrote:
>> IMHO continuing to allow partitioned tables to be marked UNLOGGED just
>> preserves the illusion that it does something. An ERROR could help dispel
>> that misconce
On Thu, Aug 29, 2024 at 09:49:44AM -0500, Nathan Bossart wrote:
> IMHO continuing to allow partitioned tables to be marked UNLOGGED just
> preserves the illusion that it does something. An ERROR could help dispel
> that misconception.
Okay. This is going to be disruptive if we do nothing about p
On Thu, May 2, 2024 at 2:07 PM Michael Paquier wrote:
>
> On Thu, Apr 25, 2024 at 08:55:27AM +0900, Michael Paquier wrote:
> > On Wed, Apr 24, 2024 at 04:43:58PM -0700, David G. Johnston wrote:
> >> My point is that if you feel that treating logged as a copy-able property
> >> is OK then doing the
On Thu, Aug 29, 2024 at 03:44:45PM +0900, Michael Paquier wrote:
> On Tue, Aug 27, 2024 at 04:01:58PM -0500, Nathan Bossart wrote:
>> My current thinking is that it would be better to disallow marking
>> partitioned tables as LOGGED/UNLOGGED and continue to have users explicitly
>> specify what the
On Tue, Aug 27, 2024 at 04:01:58PM -0500, Nathan Bossart wrote:
> I've been thinking about this thread some more, and I'm finding myself -0.5
> for adding relpersistence inheritance for UNLOGGED. There are a few
> reasons:
>
> * Existing partitioned tables may be marked UNLOGGED, and after upgrad
On Thu, May 02, 2024 at 03:06:51PM +0900, Michael Paquier wrote:
> The case of a temporary persistence is actually *very* tricky. The
> namespace, where the relation is created, is guessed and locked with
> permission checks done based on the RangeVar when the CreateStmt is
> transformed, which is
On Thu, Apr 25, 2024 at 08:55:27AM +0900, Michael Paquier wrote:
> On Wed, Apr 24, 2024 at 04:43:58PM -0700, David G. Johnston wrote:
>> My point is that if you feel that treating logged as a copy-able property
>> is OK then doing the following should also just work:
>>
>> postgres=# create temp t
On Wed, Apr 24, 2024 at 04:43:58PM -0700, David G. Johnston wrote:
> My point is that if you feel that treating logged as a copy-able property
> is OK then doing the following should also just work:
>
> postgres=# create temp table parentt ( id integer ) partition by range (id);
> CREATE TABLE
> p
On Thu, Apr 25, 2024 at 08:35:32AM +0900, Michael Paquier wrote:
> That's why the current restrictions are in place: you should
> be able to mix them.
Correction due to a ENOCOFFEE: you should *not* be able to mix them.
--
Michael
signature.asc
Description: PGP signature
On Wed, Apr 24, 2024 at 4:35 PM Michael Paquier wrote:
>
> I disagree here, actually. Temporary tables are a different beast
> because they require automated cleanup which would include interacting
> with the partitionining information if temp and non-temp relations are
> mixed. That's why the
On Wed, Apr 24, 2024 at 03:36:35PM -0700, David G. Johnston wrote:
> On Wed, Apr 24, 2024 at 1:26 PM Nathan Bossart
> wrote:
>> On Wed, Apr 24, 2024 at 04:17:44PM +0900, Michael Paquier wrote:
>>> - CREATE TABLE PARTITION OF would make a new partition inherit the
>>> logged ness of the parent if U
On Wed, Apr 24, 2024 at 03:26:40PM -0500, Nathan Bossart wrote:
> On Wed, Apr 24, 2024 at 04:17:44PM +0900, Michael Paquier wrote:
> > - Support ALTER TABLE .. SET LOGGED/UNLOGGED for partitioned tables,
> > where the command only works on partitioned tables so that's only a
> > catalog switch.
>
On Wed, Apr 24, 2024 at 1:26 PM Nathan Bossart
wrote:
> On Wed, Apr 24, 2024 at 04:17:44PM +0900, Michael Paquier wrote:
> > - Support ALTER TABLE .. SET LOGGED/UNLOGGED for partitioned tables,
> > where the command only works on partitioned tables so that's only a
> > catalog switch.
>
> I'm not
On Wed, Apr 24, 2024 at 04:17:44PM +0900, Michael Paquier wrote:
> - Support ALTER TABLE .. SET LOGGED/UNLOGGED for partitioned tables,
> where the command only works on partitioned tables so that's only a
> catalog switch.
I'm not following what this means. Does SET [UN]LOGGED on a partitioned
t
Hi all,
As a recent poke on a thread of 2019 has reminded me, the current
situation of partitioned tables with unlogged is kind of weird:
https://www.postgresql.org/message-id/15954-b61523bed4b110c4%40postgresql.org
To sum up the situation:
- ALTER TABLE .. SET LOGGED/UNLOGGED does not affect par
37 matches
Mail list logo
