Re: BUG #15954: Unable to alter partitioned table to set logged

I'm in a pickle here guys... I'm going to have to create a cron job to make sure any newly created partitions using pg_partman are ALTERed SET LOGGED from now on....
In my humble opinion/recommendation would be to follow the path of least resistance.... Allow mix logging across partitions just like is currently working now but let me set the parent's logging setting  to what I want.. PLEASE!!!!! As someone previously stated, I'm not sure why it was determine to skip tables with no storage set but i fee like if someone just concentrates on updating this logic to allow the parent to be ALTERed the world would be a better place, at least for me :-)
/* Relations without storage may be ignored here */
if (!RELKIND_HAS_STORAGE(tab->relkind))
continue;

I can see someone making a case to allow mixed setting for logging across partitions, I really do. And in my case, once I ran the ALTER SET LOGGED command against the individual partitions it worked like a charm, of course, it logged the entire partition table for each of the partitions I ran the ALTER against and I'm having to run the ALTER one table at a time, but it works!!!!
Thanks,Efrain J. Berdecia

On Tuesday, August 13, 2019, 11:17:36 PM EDT, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> wrote:

On Wed, 14 Aug 2019 at 14:48, Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Wed, Aug 14, 2019 at 01:57:26PM +1200, David Rowley wrote:
> > I'd say it's broken in a sense that we can create an unlogged
> > partitioned table in the first place.  I think that should have been
> > blocked.
>
> I don't think that it is that crazy to be able to define a partitioned
> table as unlogged, assuming that we could use that to make the
> children inherit the same state.

Since we have no persistence inheritance feature, what are you proposing here?

If we allow SET [UN]LOGGED on a partitioned table to cascade down to
each partition, then do we need to insist that the child partition's
persistence setting does not deviate from the parents? Or would
altering the parent just change the partitions that were not already
set that way?

What would the behaviour be of doing ATTACH PARTITION on a logged
table onto an unlogged partitioned table?

Also, since there is no CREATE LOGGED TABLE syntax, what would users
do if that wanted to create a logged partition on an unlogged
partition hierarchy?  For this to work ATTACH PARTITION would have to
not mess with the persistence setting but the user would have to
CREATE TABLE ... (LIKE partitioned_table); then ATTACH PARTITION.
That seems a bit messy to me, it's inevitable that someone would
eventually complain and ask for a CREATE LOGGED TABLE syntax.

I think if we don't allow mixed persistence partition hierarchies
we'll get complaints. I think it's valid to have them, just imagine
implementing a highspeed queue that does not require durability on
non-processed items. Processing an item updates the "processed" flag
which moves the tuple into a logged partition, thus making it durable.

So my thoughts are that unless someone is proposing to think of all
the corner cases for partitions inheriting their persistence from
their partitioned table, then allowing UNLOGGED partitioned tables is
busted.

--
David Rowley                  http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services