Horton

Thread

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Remove direct handling of reloptions for toast tables

  2. ATExecSetRelOptions: Reduce scope of 'isnull' variable

  1. Minor rework of ALTER TABLE SET RelOptions code

    Nikolay Shaplov <dhyan@nataraj.su> — 2025-03-07T17:02:08Z

    While working with my New Options Engine patch
https://commitfest.postgresql.org/patch/4688/
I found out that I can detach a small portion of it as a separate
patch. 
It has own value, even if big patch is never committed, and it would make 
smoother further committing of big patch if we ever get to it.

Patch description is following:

1. `isnull` variable is actually needed in a very narrow scope, so              
it is better to keep it in that scope, not keeping it in mind in while          
dealing with the rest of the code.                                              
                                                                                
2. Toast table RelOptions are never altered directly with ALTER command.        
One should do ATLER to a heap relation and use toast. reloption namespace       
to address toast's reloption. If you get `ATExecSetRelOptions` called with      
`RELKIND_TOASTVALUE` relation in the args, something is really wrong. We        
should throw asserts, errors and whistle as loud as we can.

-- 
Nikolay Shaplov aka Nataraj
Fuzzing Engineer at Postgres Professional
Matrix IM: @dhyan:nataraj.su

  2. Re: Minor rework of ALTER TABLE SET RelOptions code

    Timur Magomedov <t.magomedov@postgrespro.ru> — 2025-03-13T10:54:45Z

    On Fri, 2025-03-07 at 20:02 +0300, Nikolay Shaplov wrote:
> While working with my New Options Engine patch
> https://commitfest.postgresql.org/patch/4688/
> I found out that I can detach a small portion of it as a separate
> patch. 
> It has own value, even if big patch is never committed, and it would
> make 
> smoother further committing of big patch if we ever get to it.
> 
> Patch description is following:

Thanks for the patch!

> 1. `isnull` variable is actually needed in a very narrow scope,
> so              
> it is better to keep it in that scope, not keeping it in mind in
> while dealing with the rest of the code.

Since we already have datum=0 logic there, there is indeed no need to
have isnull variable on same scope.

>          
> 2. Toast table RelOptions are never altered directly with ALTER
> command.        
> One should do ATLER to a heap relation and use toast. reloption
> namespace       
> to address toast's reloption. If you get `ATExecSetRelOptions` called
> with      
> `RELKIND_TOASTVALUE` relation in the args, something is really wrong.
> We        
> should throw asserts, errors and whistle as loud as we can.

Seems reasonable to me. Toast tables are handled later by
"heap_reloptions(RELKIND_TOASTVALUE, ..." in same ATExecSetRelOptions()
function code.

LGTM

-------
Regards,
Timur Magomedov

  3. Re: Minor rework of ALTER TABLE SET RelOptions code

    Alvaro Herrera <alvherre@alvh.no-ip.org> — 2025-03-14T08:35:15Z

    On 2025-Mar-07, Nikolay Shaplov wrote:

> Patch description is following:
> 
> 1. `isnull` variable is actually needed in a very narrow scope, so              
> it is better to keep it in that scope, not keeping it in mind in while          
> dealing with the rest of the code.                                              
>                                                                                 
> 2. Toast table RelOptions are never altered directly with ALTER command.        
> One should do ATLER to a heap relation and use toast. reloption namespace       
> to address toast's reloption. If you get `ATExecSetRelOptions` called with      
> `RELKIND_TOASTVALUE` relation in the args, something is really wrong. We        
> should throw asserts, errors and whistle as loud as we can.

These are two separate things, I would have suggested to post them as
two separate patches.  And the second one lacked tests, so I added some.
I have pushed both now, thanks.

I can't unfortunately promise to review the larger reloption refactoring
patch for 18.

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/
"Java is clearly an example of money oriented programming"  (A. Stepanov)

  4. Re: Minor rework of ALTER TABLE SET RelOptions code

    Nikolay Shaplov <dhyan@nataraj.su> — 2025-03-18T13:38:02Z

    В письме от пятница, 14 марта 2025 г. 11:35:15 MSK пользователь Álvaro Herrera 
написал:

> > 1. `isnull` variable is actually needed in a very narrow scope, so
> > it is better to keep it in that scope, not keeping it in mind in while
> > dealing with the rest of the code.
> > 
> > 2. Toast table RelOptions are never altered directly with ALTER command.
> > One should do ATLER to a heap relation and use toast. reloption namespace
> > to address toast's reloption. If you get `ATExecSetRelOptions` called with
> > `RELKIND_TOASTVALUE` relation in the args, something is really wrong. We
> > should throw asserts, errors and whistle as loud as we can.
 
> These are two separate things, I would have suggested to post them as
> two separate patches.  
Sounds reasonable. 

> And the second one lacked tests, so I added some.
It never come into my mind that someone can try something like

ALTER TABLE pg_toast.pg_toast_2615 SET (fillfactor = '90')

and succeed.
Thanks for doing that.

> I have pushed both now, thanks.
Thank you for commit!

> I can't unfortunately promise to review the larger reloption refactoring
> patch for 18.
This is understandable. 
I will try to split this patch into parts for better readability in that time.

-- 
Nikolay Shaplov aka Nataraj
Fuzzing Engineer at Postgres Professional
Matrix IM: @dhyan:nataraj.su