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
28 matches
Mail list logo
