Re: Custom reloptions and lock modes
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Postgres hackers <pgsql-hackers@lists.postgresql.org>
Cc: Nikolay Shaplov <dhyan@nataraj.su>
Date: 2019-09-20T01:44:45Z
Lists: pgsql-hackers
On Fri, Sep 20, 2019 at 10:38:31AM +0900, Michael Paquier wrote: > Hi all, > > This is a new thread related to the bug analyzed here: > https://www.postgresql.org/message-id/20190919083203.GC21144@paquier.xyz > > And in short, if you attempt to do an ALTER TABLE with a custom > reloptions the command burns itself, like that for example this > sequence: > create extension bloom; > create table aa (a int); > create index aa_bloom ON aa USING bloom (a); > alter index aa_bloom set (length = 20); > > Which results in the following error: > - 0002 is a patch which we could use to extend the existing reloption > APIs to set the lock mode used. I am aware of the recent work done by > Nikolay in CC to rework this API set, but I am unsure where we are > going there, and the resulting patch is actually very short, being > 20-line long with the current infrastructure. That could go into > HEAD. Table AMs have been added in v12 so custom reloptions could > gain more in popularity, but as we are very close to the release it > would not be cool to break those APIs. The patch simplicity could > also be a reason sufficient for a back-patch, and I don't think that > there are many users of them yet. I mean a back-patch down to v12 for this part, but not further down. Sorry for the possible confusion. -- Michael
Commits
-
Allow definition of lock mode for custom reloptions
- 69f94108079d 13.0 landed
-
Fix failure with lock mode used for custom relation options
- 98b5c3785296 9.6.16 landed
- d48168003784 10.11 landed
- d01d4f23742b 11.6 landed
- 707f38e38e8d 12.0 landed
- 736b84eede6c 13.0 landed