agora inbox for pgsql-hackers@postgresql.org
help / color / mirror / Atom feedRe: PostgreSQL Developer meeting minutes up
538+ messages / 18 participants
[nested] [flat]
* Re: PostgreSQL Developer meeting minutes up
@ 2009-06-01 17:43 Markus Wanner <markus@bluegap.ch>
2009-06-01 18:08 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
0 siblings, 2 replies; 538+ messages in thread
From: Markus Wanner @ 2009-06-01 17:43 UTC (permalink / raw)
To: Aidan Van Dyk <aidan@highrise.ca>; +Cc: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
Hi,
a newish conversion with cvs2git is available to check here:
git://www.bluegap.ch/
(it's not incremental and will only stay for a few days)
For everybody interested, please check the committer names and emails.
I'm missing the names and email addresses for these committers:
'barry' : ('barry??', ''),
'dennis' : ('Dennis??', ''),
'inoue' : ('inoue??', ''),
'jurka' : ('jurka??', ''),
'pjw' : ('pjw??', ''),
And I'm guessing that 'peter' is the same as 'petere':
'peter' : ('Peter Eisentraut (?)', 'peter_e@gmx.net'),
I've compared all branch heads and all tags with a cvs checkout. The
only differences are keyword expansion errors. Most commonly the RCS
version "1.1" is used in the resulting git repository, instead of
version "1.1.1.1". This also leads to getting dates wrong ($Date keyword).
I'm unsure on how to test Tom's requirement that every commit and its
log message is included in the resulting git repository. Feel free to
clone and inspect the mentioned git repository and propose improvements
on the cvs2git options used.
Aidan Van Dyk wrote:
> Yes, but the point is you want an exact replica of CVS right? You're
> git repo should have $PostgreSQL$ and the cvs export/checkout (you do
> use -kk right) should also have $PostgreSQL$.
No, I'm testing against cvs checkout, as that's what everybody is used to.
> But it's important, because on *some* files you *do* want expanded
> "keywords" (like the $OpenBSD ... Exp $. One of the reasons pg CVS went
> to the $PostgreSQL$ keyword (I'm guessing) was so they could explictly
> de-couple them from other keywords that they didn't want munging on.
I don't care half as much about the keyword expansion stuff - that's
doomed to disappear anyway.
What I'm much more interested in is correctness WRT historic contents,
i.e. that git log, git blame, etc.. deliver correct results. That's
certainly harder to check.
In my experience, cvs2svn (or cvs2git) does a pretty decent job at that,
even in case of some corruptions. Plus it offers lots of options to fine
tune the conversion, see the attached configuration I've used.
> So, I wouldn't consider any conversion good unless it had all these:
>
> As well as stuff like:
> parsecvs-master:src/backend/access/index/genam.c: * $PostgreSQL$
I disagree here and find it more convenient for the git repository to
keep the "old" RCS versions - as in the source tarballs that got (and
still get) shipped. Just before switching over to git one can (and
should, IMO) remove these tags to avoid confusion.
Regards
Markus Wanner
Attachments:
[text/x-python] options.py (6.4K, ../../4A241340.9080903@bluegap.ch/2-options.py)
download | inline:
# (Be in -*- mode: python; coding: utf-8 -*- mode.)
import re
from cvs2svn_lib import config
from cvs2svn_lib import changeset_database
from cvs2svn_lib.common import CVSTextDecoder
from cvs2svn_lib.log import Log
from cvs2svn_lib.project import Project
from cvs2svn_lib.git_revision_recorder import GitRevisionRecorder
from cvs2svn_lib.git_output_option import GitRevisionMarkWriter
from cvs2svn_lib.git_output_option import GitOutputOption
from cvs2svn_lib.revision_manager import NullRevisionRecorder
from cvs2svn_lib.revision_manager import NullRevisionExcluder
from cvs2svn_lib.fulltext_revision_recorder \
import SimpleFulltextRevisionRecorderAdapter
from cvs2svn_lib.rcs_revision_manager import RCSRevisionReader
from cvs2svn_lib.cvs_revision_manager import CVSRevisionReader
from cvs2svn_lib.checkout_internal import InternalRevisionRecorder
from cvs2svn_lib.checkout_internal import InternalRevisionExcluder
from cvs2svn_lib.checkout_internal import InternalRevisionReader
from cvs2svn_lib.symbol_strategy import AllBranchRule
from cvs2svn_lib.symbol_strategy import AllTagRule
from cvs2svn_lib.symbol_strategy import BranchIfCommitsRule
from cvs2svn_lib.symbol_strategy import ExcludeRegexpStrategyRule
from cvs2svn_lib.symbol_strategy import ForceBranchRegexpStrategyRule
from cvs2svn_lib.symbol_strategy import ForceTagRegexpStrategyRule
from cvs2svn_lib.symbol_strategy import ExcludeTrivialImportBranchRule
from cvs2svn_lib.symbol_strategy import ExcludeVendorBranchRule
from cvs2svn_lib.symbol_strategy import HeuristicStrategyRule
from cvs2svn_lib.symbol_strategy import UnambiguousUsageRule
from cvs2svn_lib.symbol_strategy import HeuristicPreferredParentRule
from cvs2svn_lib.symbol_strategy import SymbolHintsFileRule
from cvs2svn_lib.symbol_transform import ReplaceSubstringsSymbolTransform
from cvs2svn_lib.symbol_transform import RegexpSymbolTransform
from cvs2svn_lib.symbol_transform import IgnoreSymbolTransform
from cvs2svn_lib.symbol_transform import NormalizePathsSymbolTransform
from cvs2svn_lib.property_setters import AutoPropsPropertySetter
from cvs2svn_lib.property_setters import CVSBinaryFileDefaultMimeTypeSetter
from cvs2svn_lib.property_setters import CVSBinaryFileEOLStyleSetter
from cvs2svn_lib.property_setters import CVSRevisionNumberSetter
from cvs2svn_lib.property_setters import DefaultEOLStyleSetter
from cvs2svn_lib.property_setters import EOLStyleFromMimeTypeSetter
from cvs2svn_lib.property_setters import ExecutablePropertySetter
from cvs2svn_lib.property_setters import KeywordsPropertySetter
from cvs2svn_lib.property_setters import MimeMapper
from cvs2svn_lib.property_setters import SVNBinaryFileKeywordsPropertySetter
Log().log_level = Log.NORMAL
ctx.revision_recorder = SimpleFulltextRevisionRecorderAdapter(
CVSRevisionReader(cvs_executable=r'cvs'),
GitRevisionRecorder('cvs2git-tmp/git-blob.dat'),
)
ctx.revision_excluder = NullRevisionExcluder()
ctx.revision_reader = None
ctx.sort_executable = r'sort'
ctx.trunk_only = False
ctx.cvs_author_decoder = CVSTextDecoder(
['ascii', 'latin1'],
)
ctx.cvs_log_decoder = CVSTextDecoder(
['ascii', 'latin1'],
)
ctx.cvs_filename_decoder = CVSTextDecoder(
['ascii', 'latin1'],
)
ctx.initial_project_commit_message = (
'Standard project directories initialized by cvs2git.'
)
ctx.post_commit_message = (
'This commit was generated by cvs2git to track changes on a CVS '
'vendor branch.'
)
ctx.symbol_commit_message = (
"This commit was manufactured by cvs2git to create %(symbol_type)s "
"'%(symbol_name)s'."
)
ctx.decode_apple_single = False
ctx.symbol_info_filename = None
global_symbol_strategy_rules = [
ExcludeTrivialImportBranchRule(),
UnambiguousUsageRule(),
BranchIfCommitsRule(),
HeuristicStrategyRule(),
# Convert all ambiguous symbols as branches:
AllBranchRule(),
# Convert all ambiguous symbols as tags:
AllTagRule(),
# The last rule is here to choose the preferred parent of branches
# and tags, that is, the line of development from which the symbol
# sprouts.
HeuristicPreferredParentRule(),
]
ctx.username = 'cvs2git'
ctx.svn_property_setters.extend([
CVSBinaryFileEOLStyleSetter(),
CVSBinaryFileDefaultMimeTypeSetter(),
DefaultEOLStyleSetter(None),
SVNBinaryFileKeywordsPropertySetter(),
KeywordsPropertySetter(config.SVN_KEYWORDS_VALUE),
ExecutablePropertySetter(),
])
ctx.tmpdir = r'cvs2git-tmp'
ctx.cross_project_commits = False
ctx.cross_branch_commits = False
ctx.keep_cvsignore = True
ctx.retain_conflicting_attic_files = True
author_transforms={
'adunstan' : ('Androw Dunstan', 'andrew@dunslane.net'),
'alvherre' : ('Alvaro Herrera', 'alvherre@commandprompt.com'),
'barry' : ('barry??', ''),
'bryanh' : ('Bryan Henderson', 'bryanh@giraffe.netgate.net'),
'darcy' : ('D\'Arcy J.M. Cain', 'darcy@druid.net'),
'dennis' : ('Dennis??', ''),
'heikki' : ('Heikki Linnakangas', 'heikki.linnakangas@enterprisedb.com'),
'inoue' : ('inoue??', ''),
'ishii' : ('Tatsuo Ishii', 'ishii@sraoss.co.jp'),
'joe' : ('Joe Conway', 'mail@joeconway.com'),
'jurka' : ('jurka??', ''),
'meskes' : ('Michael Meskes', 'meskes@postgresql.org'),
'mha': ('Magnus Hagander', 'magnus@hagander.net'),
'momjian' : ('Bruce Momjian', 'bruce@momjian.us'),
'neilc' : ('Neil Conway', 'neil.conway@gmail.com'),
'petere' : ('Peter Eisentraut', 'peter_e@gmx.net'),
'peter' : ('Peter Eisentraut (?)', 'peter_e@gmx.net'),
'pjw' : ('pjw??', ''),
'scrappy' : ('Marc G. Fournier', 'scrappy@postgresql.org'),
'teodor' : ('Teodor Sigaev', 'teodor@sigaev.ru'),
'tgl' : ('Tom Lane', 'tgl@sss.pgh.pa.us'),
'vadim' : ('Vadim B. Mikheev', 'vadim4o@yahoo.com'),
'wieck' : ('Jan Wieck', 'JanWieck@yahoo.com'),
'cvs2git' : ('cvs2git', 'admin@postgresql.org'),
}
# This is the main option that causes cvs2svn to output to git rather
# than Subversion:
ctx.output_option = GitOutputOption(
'cvs2git-tmp/git-dump.dat',
GitRevisionMarkWriter(),
max_merges=None,
author_transforms=author_transforms,
)
run_options.profiling = False
changeset_database.use_mmap_for_cvs_item_to_changeset_table = True
run_options.set_project(
r'../postgresql.org/pgsql',
symbol_transforms=[
ReplaceSubstringsSymbolTransform('\\','/'),
NormalizePathsSymbolTransform(),
],
symbol_strategy_rules=global_symbol_strategy_rules,
)
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
@ 2009-06-01 18:08 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-06-01 18:35 ` Re: PostgreSQL Developer meeting minutes up Alvaro Herrera <alvherre@commandprompt.com>
1 sibling, 1 reply; 538+ messages in thread
From: Tom Lane @ 2009-06-01 18:08 UTC (permalink / raw)
To: Markus Wanner <markus@bluegap.ch>; +Cc: Aidan Van Dyk <aidan@highrise.ca>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
Markus Wanner <markus@bluegap.ch> writes:
> I'm missing the names and email addresses for these committers:
> 'barry' : ('barry??', ''),
Barry Lind, formerly one of the JDBC bunch, been inactive for awhile
> 'dennis' : ('Dennis??', ''),
I suppose this must be Dennis Björklund, but I didn't realize he
used to be a committer.
> 'inoue' : ('inoue??', ''),
Hiroshi Inoue, still active, but ODBC is not part of core anymore
> 'jurka' : ('jurka??', ''),
Kris Jurka, still active, but JDBC is not part of core anymore
> 'pjw' : ('pjw??', ''),
Philip Warner, inactive (still reads the lists though)
> And I'm guessing that 'peter' is the same as 'petere':
> 'peter' : ('Peter Eisentraut (?)', 'peter_e@gmx.net'),
No, that would be Peter Mount, also a retired JDBC hacker.
regards, tom lane
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-01 18:08 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
@ 2009-06-01 18:35 ` Alvaro Herrera <alvherre@commandprompt.com>
2009-06-01 18:46 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 538+ messages in thread
From: Alvaro Herrera @ 2009-06-01 18:35 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Markus Wanner <markus@bluegap.ch>; Aidan Van Dyk <aidan@highrise.ca>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
Tom Lane wrote:
> Markus Wanner <markus@bluegap.ch> writes:
> > 'dennis' : ('Dennis??', ''),
>
> I suppose this must be Dennis Björklund, but I didn't realize he
> used to be a committer.
IIRC he was given commit privs for translation files.
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-01 18:08 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
2009-06-01 18:35 ` Re: PostgreSQL Developer meeting minutes up Alvaro Herrera <alvherre@commandprompt.com>
@ 2009-06-01 18:46 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-06-04 09:14 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
0 siblings, 1 reply; 538+ messages in thread
From: Tom Lane @ 2009-06-01 18:46 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@commandprompt.com>; +Cc: Markus Wanner <markus@bluegap.ch>; Aidan Van Dyk <aidan@highrise.ca>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
Alvaro Herrera <alvherre@commandprompt.com> writes:
> Tom Lane wrote:
>> I suppose this must be Dennis Björklund, but I didn't realize he
>> used to be a committer.
> IIRC he was given commit privs for translation files.
Ah, right, that does ring a bell now.
BTW, Markus: you do realize "thomas" is not me but Tom Lockhart?
regards, tom lane
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-01 18:08 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
2009-06-01 18:35 ` Re: PostgreSQL Developer meeting minutes up Alvaro Herrera <alvherre@commandprompt.com>
2009-06-01 18:46 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
@ 2009-06-04 09:14 ` Markus Wanner <markus@bluegap.ch>
0 siblings, 0 replies; 538+ messages in thread
From: Markus Wanner @ 2009-06-04 09:14 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Alvaro Herrera <alvherre@commandprompt.com>; Aidan Van Dyk <aidan@highrise.ca>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
Hi,
Quoting "Tom Lane" <tgl@sss.pgh.pa.us>:
> BTW, Markus: you do realize "thomas" is not me but Tom Lockhart?
Uh.. thanks, that name has fallen through the cracks, before. I've
added it now, it will be included in the next sample conversion.
Regards
Markus Wanner
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
@ 2009-06-02 06:43 ` Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:08 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
1 sibling, 2 replies; 538+ messages in thread
From: Marko Kreen @ 2009-06-02 06:43 UTC (permalink / raw)
To: Markus Wanner <markus@bluegap.ch>; +Cc: Aidan Van Dyk <aidan@highrise.ca>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
On 6/1/09, Markus Wanner <markus@bluegap.ch> wrote:
> a newish conversion with cvs2git is available to check here:
>
> git://www.bluegap.ch/
>
> (it's not incremental and will only stay for a few days)
+1 for the idea of replacing CVS usernames with full names.
The knowledge about CVS usernames will be increasingly obscure.
Also worth mentioning is that there is no need to assign absolutely
up-to-date email addresses, it's enough if they uniquely identify
person.
> Aidan Van Dyk wrote:
> > Yes, but the point is you want an exact replica of CVS right? You're
> > git repo should have $PostgreSQL$ and the cvs export/checkout (you do
> > use -kk right) should also have $PostgreSQL$.
>
>
> No, I'm testing against cvs checkout, as that's what everybody is used to.
>
>
> > But it's important, because on *some* files you *do* want expanded
> > "keywords" (like the $OpenBSD ... Exp $. One of the reasons pg CVS went
> > to the $PostgreSQL$ keyword (I'm guessing) was so they could explictly
> > de-couple them from other keywords that they didn't want munging on.
>
>
> I don't care half as much about the keyword expansion stuff - that's
> doomed to disappear anyway.
But this is one aspect we need to get right for the conversion.
So preferably we test it sooner not later.
I think Aidan got it right - expand $PostgreSQL$ and others that are
actually expanded on current repo, but not $OpenBSD$ and others
coming from external sources.
> What I'm much more interested in is correctness WRT historic contents,
> i.e. that git log, git blame, etc.. deliver correct results. That's
> certainly harder to check.
>
> In my experience, cvs2svn (or cvs2git) does a pretty decent job at that,
> even in case of some corruptions. Plus it offers lots of options to fine
> tune the conversion, see the attached configuration I've used.
>
>
> > So, I wouldn't consider any conversion good unless it had all these:
> >
>
> > As well as stuff like:
> > parsecvs-master:src/backend/access/index/genam.c: * $PostgreSQL$
>
>
> I disagree here and find it more convenient for the git repository to
> keep the "old" RCS versions - as in the source tarballs that got (and
> still get) shipped. Just before switching over to git one can (and
> should, IMO) remove these tags to avoid confusion.
I'd prefer we immediately test full conversion and not leave some
steps to last moment.
--
marko
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
@ 2009-06-02 07:13 ` Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
1 sibling, 1 reply; 538+ messages in thread
From: Marko Kreen @ 2009-06-02 07:13 UTC (permalink / raw)
To: Markus Wanner <markus@bluegap.ch>; +Cc: Aidan Van Dyk <aidan@highrise.ca>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
On 6/2/09, Marko Kreen <markokr@gmail.com> wrote:
> On 6/1/09, Markus Wanner <markus@bluegap.ch> wrote:
> > a newish conversion with cvs2git is available to check here:
> >
> > git://www.bluegap.ch/
> >
> > (it's not incremental and will only stay for a few days)
Btw this conversion seems broken as it contains random merge commits.
parsecvs managed to do it without them.
--
marko
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
@ 2009-06-02 11:48 ` Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
0 siblings, 1 reply; 538+ messages in thread
From: Markus Wanner @ 2009-06-02 11:48 UTC (permalink / raw)
To: Marko Kreen <markokr@gmail.com>; +Cc: Aidan Van Dyk <aidan@highrise.ca>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
Hi,
Quoting "Marko Kreen" <markokr@gmail.com>:
> Btw this conversion seems broken as it contains random merge commits.
Well, that's a feature, not a bug ;-)
When a commit adds a file to the master *and* then to the branch as
well, cvs2git prefers to represent this as a merge from the master
branch, instead of adding the file twice, once on the master and once
on the branch.
This way the target VCS knows it's the *same* file, originating from
one single commit. This may be important for later merges - otherwise
you may suddenly end up with duplicated files after a merge, because
the VCS doesn't know they are in fact the same.
(Okay, git assumes two files to have the same origin/history as long
as they have the same filename. But just rename one of the two, and
you are have the same troubles, again).
Also note that these situations occur rather frequently in the
Postgres CVS repository. Every back-patch which adds files ends up as
a merge. (One could even argue that in the perfect conversion *all*
back-patches should be represented as merges, rather than as separate
commits).
> parsecvs managed to do it without them.
Now, I'm not calling it broken, but cvs2git's output is arguably
better in that regard.
As you certainly see by now, conversion from CVS is neither simple nor
unambiguous.
Regards
Markus Wanner
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
@ 2009-06-02 12:46 ` Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
0 siblings, 1 reply; 538+ messages in thread
From: Marko Kreen @ 2009-06-02 12:46 UTC (permalink / raw)
To: Markus Wanner <markus@bluegap.ch>; +Cc: Aidan Van Dyk <aidan@highrise.ca>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
On 6/2/09, Markus Wanner <markus@bluegap.ch> wrote:
> Quoting "Marko Kreen" <markokr@gmail.com>:
> > Btw this conversion seems broken as it contains random merge commits.
> >
>
> Well, that's a feature, not a bug ;-)
>
> When a commit adds a file to the master *and* then to the branch as well,
> cvs2git prefers to represent this as a merge from the master branch, instead
> of adding the file twice, once on the master and once on the branch.
>
> This way the target VCS knows it's the *same* file, originating from one
> single commit. This may be important for later merges - otherwise you may
> suddenly end up with duplicated files after a merge, because the VCS doesn't
> know they are in fact the same.
>
> (Okay, git assumes two files to have the same origin/history as long as
> they have the same filename. But just rename one of the two, and you are
> have the same troubles, again).
Not a problem for git I think - it assumes they are same if they have
same contents...
> Also note that these situations occur rather frequently in the Postgres CVS
> repository. Every back-patch which adds files ends up as a merge. (One could
> even argue that in the perfect conversion *all* back-patches should be
> represented as merges, rather than as separate commits).
Well, such behaviour may be a feature for some repo with complex CVS
usage, but currently we should aim for simple and clear conversion.
The question is - do such merges make any sense to human looking at
history - and the answer is no, as no VCS level merge was happening,
just some copying around (if your description is correct). And
we don't need to add noise for the benefit of GIT as it works fine
without any fake merges.
Our target should be each branch having simple linear history,
without any fake merges. This will result in minimal confusion
to both humans looking history and also GIT itself.
So please turn the merge logic off. If this cannot be turned off,
cvs2git is not usable for conversion.
> > parsecvs managed to do it without them.
> >
>
> Now, I'm not calling it broken, but cvs2git's output is arguably better in
> that regard.
Seems it contains more complex logic to handle more complex CVS usage
cases, but seems like overkill for us if it creates a mess of history.
> As you certainly see by now, conversion from CVS is neither simple nor
> unambiguous.
I know, thats why I'm discussing the tradeoffs. Simple+clear vs.
complex+messy. :)
--
marko
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
@ 2009-06-02 14:23 ` Markus Wanner <markus@bluegap.ch>
2009-06-02 14:50 ` Re: PostgreSQL Developer meeting minutes up Aidan Van Dyk <aidan@highrise.ca>
2009-06-02 15:34 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
0 siblings, 2 replies; 538+ messages in thread
From: Markus Wanner @ 2009-06-02 14:23 UTC (permalink / raw)
To: Marko Kreen <markokr@gmail.com>; +Cc: Aidan Van Dyk <aidan@highrise.ca>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
Hi,
Quoting "Marko Kreen" <markokr@gmail.com>:
> Not a problem for git I think
Knowing that git doesn't track files as "hard" as monotone, I
certainly doubt that.
> - it assumes they are same if they have
> same contents...
Why do you assume they have the same contents? Obviously these are
different branches, where files can (and will!) have different contents.
> Well, such behaviour may be a feature for some repo with complex CVS
> usage, but currently we should aim for simple and clear conversion.
First of all, we should aim for a correct one.
> The question is - do such merges make any sense to human looking at
> history - and the answer is no, as no VCS level merge was happening,
> just some copying around (if your description is correct). And
> we don't need to add noise for the benefit of GIT as it works fine
> without any fake merges.
For low expectations of "it works", maybe yes. However if you don't
tell git, it has no chance of knowing that two (different) files
should actually be the same.
Try the following:
git init
echo "base" > basefile
git add basefile
git commit -m "base commit"
git checkout -b branch
echo "hello, world" > testfile
git add testfile
git commit testfile -m "addition on branch"
git checkout master
echo "hello world" > testfile
git add testfile
git commit testfile -m "addition on master"
# here we are a similar point like after a lacking conversion, having two
# distinct, i.e. historically independent files called "testfile"
git mv testfile movedfile
git commit -m "file moved"
git checkout branch
git merge master
ls
# Bang, you suddenly have 'testfile' and 'movedfile', go figure!
I leave it as an exercise for the reader to try the same with a single
historic origin of the file, as cvs2git does the conversion.
> Our target should be each branch having simple linear history,
> without any fake merges. This will result in minimal confusion
> to both humans looking history and also GIT itself.
I don't consider the above a "minimal confusion". And concerning
humans... you get used to merge commits pretty quickly. I for one am
more confused by a linear history which in fact is not.
As mentioned before, I'd personally favor *all* of the back-ports to
actually be merges of some sort, because that's what they effectively
are. However, that also bring up the question of how we are going to
do back-patches in the future with git.
> So please turn the merge logic off. If this cannot be turned off,
> cvs2git is not usable for conversion.
As far as I know, it cannot be turned off. Use parsecvs if you want to
get silly side effects later on in history. ;-)
> Seems it contains more complex logic to handle more complex CVS usage
> cases, but seems like overkill for us if it creates a mess of history.
You consider it a mess, I consider it a better and more valid
representation of the mess that CVS is.
Regards
Markus Wanner
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
@ 2009-06-02 14:50 ` Aidan Van Dyk <aidan@highrise.ca>
2009-06-02 15:02 ` Re: PostgreSQL Developer meeting minutes up Alvaro Herrera <alvherre@commandprompt.com>
2009-06-02 15:08 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
2009-06-02 15:19 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 16:27 ` Re: PostgreSQL Developer meeting minutes up Ron Mayer <rm_pg@cheapcomplexdevices.com>
1 sibling, 4 replies; 538+ messages in thread
From: Aidan Van Dyk @ 2009-06-02 14:50 UTC (permalink / raw)
To: Markus Wanner <markus@bluegap.ch>; +Cc: Marko Kreen <markokr@gmail.com>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
* Markus Wanner <markus@bluegap.ch> [090602 10:23]:
> # Bang, you suddenly have 'testfile' and 'movedfile', go figure!
>
> I leave it as an exercise for the reader to try the same with a single
> historic origin of the file, as cvs2git does the conversion.
Sure, and we can all construct example where that move is both right and
wrong... But the point is that in PostgreSQL, (and that may be mainly
because we're using CVS), merges *aren't* something that happens.
Patches are written against HEAD (master) and then back-patched...
If you want to turn PostgreSQL devellopment on it's head, then we can
switch this around, so that patches are always done on the oldest
branch, and fixes always merged "forward"...
I'm not going to be the one that pushes that though ;-)
> I don't consider the above a "minimal confusion". And concerning
> humans... you get used to merge commits pretty quickly. I for one am
> more confused by a linear history which in fact is not.
But the fact is, everyone using CVS wants a "linear history"..... All
they care about is "cvs update...wait...cvs update ... time ... cvs
update ..."... Everything *was* linear to them. Any "merge" type things
certaily wasn't intentional in CVS...
> As mentioned before, I'd personally favor *all* of the back-ports to
> actually be merges of some sort, because that's what they effectively
> are. However, that also bring up the question of how we are going to do
> back-patches in the future with git.
Well, if people get comfortable with it, I expect that "backports" don't
happenen.. Bugs are fixed where they happen, and "merged" forward into
all affected "later development" based on the bugged area.
> As far as I know, it cannot be turned off. Use parsecvs if you want to
> get silly side effects later on in history. ;-)
Ya, that's one of the reasons I considered parsecvs the leading
candidate... And why I went thouth, and showed that with the exception
of the one REL_8_0_0 tip, it *was* and exact copy of the current CVS
repository (minus the 1 messed up tag in the repository).
> You consider it a mess, I consider it a better and more valid
> representation of the mess that CVS is.
So much better that it makes the history as useless as CVS... I think
one of the reasons people are wanting tomove from CVS to git is that it
makes things *better*... The "exact" history will *always* be
available, right in CVS if people need it. I thin the goal is to make
the "git" history as close to CVS as possible, such that it's useful. I
mean, if we want it to be a "more valid" representation, then really, we
should be doing every file change in a single commit, and "merging" that
file commit into the branch *every* *single* *time*... I don't think
anybody wants our conversion to be that much "better and move valid
representation of the mess that CVS is"...
It's a balance... We're moving because we want *better* tools and
access, not the same "mess that CVS is".
--
Aidan Van Dyk Create like a god,
aidan@highrise.ca command like a king,
http://www.highrise.ca/ work like a slave.
Attachments:
[application/pgp-signature] signature.asc (189B, ../../20090602145000.GE23972@yugib.highrise.ca/2-signature.asc)
download
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 14:50 ` Re: PostgreSQL Developer meeting minutes up Aidan Van Dyk <aidan@highrise.ca>
@ 2009-06-02 15:02 ` Alvaro Herrera <alvherre@commandprompt.com>
2009-06-02 15:19 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
3 siblings, 1 reply; 538+ messages in thread
From: Alvaro Herrera @ 2009-06-02 15:02 UTC (permalink / raw)
To: Aidan Van Dyk <aidan@highrise.ca>; +Cc: Markus Wanner <markus@bluegap.ch>; Marko Kreen <markokr@gmail.com>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
Aidan Van Dyk escribió:
> * Markus Wanner <markus@bluegap.ch> [090602 10:23]:
>
> > # Bang, you suddenly have 'testfile' and 'movedfile', go figure!
> >
> > I leave it as an exercise for the reader to try the same with a single
> > historic origin of the file, as cvs2git does the conversion.
>
> Sure, and we can all construct example where that move is both right and
> wrong... But the point is that in PostgreSQL, (and that may be mainly
> because we're using CVS), merges *aren't* something that happens.
> Patches are written against HEAD (master) and then back-patched...
>
> If you want to turn PostgreSQL devellopment on it's head, then we can
> switch this around, so that patches are always done on the oldest
> branch, and fixes always merged "forward"...
The Monotone folk call this "daggy fixes" and it seems a clean way to
handle things.
http://www.monotone.ca/wiki/DaggyFixes/
However,
> I'm not going to be the one that pushes that though ;-)
I'm not either. Maybe someday we'll be familiar enough with the tools
to make things this way, but I think just after the migration we'll
mainly want to be able to press on with development and not waste too
much time learning the new toys.
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 14:50 ` Re: PostgreSQL Developer meeting minutes up Aidan Van Dyk <aidan@highrise.ca>
2009-06-02 15:02 ` Re: PostgreSQL Developer meeting minutes up Alvaro Herrera <alvherre@commandprompt.com>
@ 2009-06-02 15:19 ` Greg Stark <stark@enterprisedb.com>
0 siblings, 0 replies; 538+ messages in thread
From: Greg Stark @ 2009-06-02 15:19 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@commandprompt.com>; +Cc: Aidan Van Dyk <aidan@highrise.ca>; Markus Wanner <markus@bluegap.ch>; Marko Kreen <markokr@gmail.com>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
On Tue, Jun 2, 2009 at 4:02 PM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:
>
>
> The Monotone folk call this "daggy fixes" and it seems a clean way to
> handle things.
>
> http://www.monotone.ca/wiki/DaggyFixes/
Is this like what git calls an octopus? I've been wondering what the
point of such things were.
Or maybe not. I thought an octopus was two patches with the same
parent -- ie, two patches that could independently be applied in any
order.
--
greg
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 14:50 ` Re: PostgreSQL Developer meeting minutes up Aidan Van Dyk <aidan@highrise.ca>
@ 2009-06-02 15:08 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-06-02 15:20 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 15:44 ` Re: PostgreSQL Developer meeting minutes up Robert Haas <robertmhaas@gmail.com>
2009-06-02 15:46 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
3 siblings, 3 replies; 538+ messages in thread
From: Tom Lane @ 2009-06-02 15:08 UTC (permalink / raw)
To: Aidan Van Dyk <aidan@highrise.ca>; +Cc: Markus Wanner <markus@bluegap.ch>; Marko Kreen <markokr@gmail.com>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
Aidan Van Dyk <aidan@highrise.ca> writes:
> * Markus Wanner <markus@bluegap.ch> [090602 10:23]:
>> You consider it a mess, I consider it a better and more valid
>> representation of the mess that CVS is.
> So much better that it makes the history as useless as CVS... I think
> one of the reasons people are wanting tomove from CVS to git is that it
> makes things *better*...
FWIW, the tool that I customarily use (cvs2cl) considers commits on
different branches to be "the same" if they have the same commit message
and occur sufficiently close together (within a few minutes). My
committing habits have been designed around that behavior for years,
and I believe other PG committers have been doing likewise.
I would consider a git conversion to be less useful to me, not more,
if it insists on showing me such cases as separate commits --- and if
it then adds useless "merge" messages on top of that, I'd start to get
seriously annoyed.
What we want here is a readable equivalent of the CVS history, not
necessarily something that is theoretically an exact equivalent.
regards, tom lane
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 14:50 ` Re: PostgreSQL Developer meeting minutes up Aidan Van Dyk <aidan@highrise.ca>
2009-06-02 15:08 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
@ 2009-06-02 15:20 ` Marko Kreen <markokr@gmail.com>
2 siblings, 0 replies; 538+ messages in thread
From: Marko Kreen @ 2009-06-02 15:20 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Aidan Van Dyk <aidan@highrise.ca>; Markus Wanner <markus@bluegap.ch>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
On 6/2/09, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Aidan Van Dyk <aidan@highrise.ca> writes:
> > * Markus Wanner <markus@bluegap.ch> [090602 10:23]:
>
> >> You consider it a mess, I consider it a better and more valid
> >> representation of the mess that CVS is.
>
> > So much better that it makes the history as useless as CVS... I think
> > one of the reasons people are wanting tomove from CVS to git is that it
> > makes things *better*...
>
>
> FWIW, the tool that I customarily use (cvs2cl) considers commits on
> different branches to be "the same" if they have the same commit message
> and occur sufficiently close together (within a few minutes). My
> committing habits have been designed around that behavior for years,
> and I believe other PG committers have been doing likewise.
>
> I would consider a git conversion to be less useful to me, not more,
> if it insists on showing me such cases as separate commits --- and if
> it then adds useless "merge" messages on top of that, I'd start to get
> seriously annoyed.
They cannot be same commits in GIT as the resulting tree is different.
You could tie them with some sort of merge commits, but doubt the
result would be worth the noise.
Also I doubt there is tool grokking such commits anyway, the merge
discussion above was for full files with exact contents appearing
in several branches.
> What we want here is a readable equivalent of the CVS history, not
> necessarily something that is theoretically an exact equivalent.
I suggest setting the goal to be simple and clear representation
of CVS history that we can make sense later, instead of revising
CVS history to look like we used some better VCS system...
--
marko
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 14:50 ` Re: PostgreSQL Developer meeting minutes up Aidan Van Dyk <aidan@highrise.ca>
2009-06-02 15:08 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
@ 2009-06-02 15:44 ` Robert Haas <robertmhaas@gmail.com>
2 siblings, 0 replies; 538+ messages in thread
From: Robert Haas @ 2009-06-02 15:44 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Aidan Van Dyk <aidan@highrise.ca>; Markus Wanner <markus@bluegap.ch>; Marko Kreen <markokr@gmail.com>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
On Tue, Jun 2, 2009 at 11:08 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Aidan Van Dyk <aidan@highrise.ca> writes:
>> * Markus Wanner <markus@bluegap.ch> [090602 10:23]:
>>> You consider it a mess, I consider it a better and more valid
>>> representation of the mess that CVS is.
>
>> So much better that it makes the history as useless as CVS... I think
>> one of the reasons people are wanting tomove from CVS to git is that it
>> makes things *better*...
>
> FWIW, the tool that I customarily use (cvs2cl) considers commits on
> different branches to be "the same" if they have the same commit message
> and occur sufficiently close together (within a few minutes). Â My
> committing habits have been designed around that behavior for years,
> and I believe other PG committers have been doing likewise.
Interesting. I was wondering why all your commit messages always show
up simultaneously for all the back branches.
> I would consider a git conversion to be less useful to me, not more,
> if it insists on showing me such cases as separate commits --- and if
> it then adds useless "merge" messages on top of that, I'd start to get
> seriously annoyed.
There's no help for them being separate commits, but I agree that
useless merge commits are a bad thing. There are plenty of ways to
avoid that, though; I've been using git cherry-pick a lot recently,
and I think git rebase --onto also has some potential.
...Robert
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 14:50 ` Re: PostgreSQL Developer meeting minutes up Aidan Van Dyk <aidan@highrise.ca>
2009-06-02 15:08 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
@ 2009-06-02 15:46 ` Markus Wanner <markus@bluegap.ch>
2 siblings, 0 replies; 538+ messages in thread
From: Markus Wanner @ 2009-06-02 15:46 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Aidan Van Dyk <aidan@highrise.ca>; Marko Kreen <markokr@gmail.com>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
Hi,
Quoting "Tom Lane" <tgl@sss.pgh.pa.us>:
> FWIW, the tool that I customarily use (cvs2cl) considers commits on
> different branches to be "the same" if they have the same commit message
> and occur sufficiently close together (within a few minutes). My
> committing habits have been designed around that behavior for years,
> and I believe other PG committers have been doing likewise.
Yeah, that's how I see things as well.
> I would consider a git conversion to be less useful to me, not more,
> if it insists on showing me such cases as separate commits --- and if
> it then adds useless "merge" messages on top of that, I'd start to get
> seriously annoyed.
Hm.. well, in git, there's no such thing as a commit that spans
multiple branches. So it's impossible to fulfill both of your wishes
here.
parsecvs creates multiple independent commits in such a case.
cvs2git creates a single commit and propagates this to the back
branches with merge commits (however, only if new files are added,
otherwise it does the same as parsecvs).
> What we want here is a readable equivalent of the CVS history, not
> necessarily something that is theoretically an exact equivalent.
Understood. However, readability depends on the user's habits. But
failing to merge due to a lacking conversion potentially hurts
everybody who wants to merge.
Having used merging (in combination with renaming) often enough, I'd
certainly be pretty annoyed if merges suddenly begin to bring up
spurious file duplicates.
Regards
Markus Wanner
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 14:50 ` Re: PostgreSQL Developer meeting minutes up Aidan Van Dyk <aidan@highrise.ca>
@ 2009-06-02 15:19 ` Markus Wanner <markus@bluegap.ch>
3 siblings, 0 replies; 538+ messages in thread
From: Markus Wanner @ 2009-06-02 15:19 UTC (permalink / raw)
To: Aidan Van Dyk <aidan@highrise.ca>; +Cc: Marko Kreen <markokr@gmail.com>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
Hi,
Quoting "Aidan Van Dyk" <aidan@highrise.ca>:
> Sure, and we can all construct example where that move is both right and
> wrong...
Huh? The problem is the file duplication. The move is an action of a
committer - it's neither right nor wrong in this example.
I cannot see any use case for seemingly random files poping up out of
nowhere, just because git doesn't know how to merge two files after a
mv and a merge.
> But the point is that in PostgreSQL, (and that may be mainly
> because we're using CVS), merges *aren't* something that happens.
> Patches are written against HEAD (master) and then back-patched...
..which can (and better is) represented as a merge in git (for the
sake of comfortable automated merging).
> If you want to turn PostgreSQL devellopment on it's head, then we can
> switch this around, so that patches are always done on the oldest
> branch, and fixes always merged "forward"...
I'd consider that good use of tools, yes. However, I realize that this
probably is pipe-dreaming...
> But the fact is, everyone using CVS wants a "linear history"..... All
> they care about is "cvs update...wait...cvs update ... time ... cvs
> update ..."... Everything *was* linear to them. Any "merge" type things
> certaily wasn't intentional in CVS...
..no, it just wasn't possible in CVS. Switching to git, people soon
want "merge type things". Heck, it's probably *the* reason for
switching to git.
> So much better that it makes the history as useless as CVS... I think
> one of the reasons people are wanting tomove from CVS to git is that it
> makes things *better*...
Yes, especially merging. Please don't cripple that ability just
because CVS once upon a time enforced a linear history.
> The "exact" history will *always* be
> available, right in CVS if people need it.
Agreed. Please note that I mostly talk about a more correct
representation *of history*, as it happened. This has nothing to do
with single commits per file.
> It's a balance... We're moving because we want *better* tools and
> access, not the same "mess that CVS is".
Agreed. And please cut as many of its burdens of the past, like
linearity. History is not linear and has never been. But I'm stopping
now before getting overly philosophic...
Regards
Markus Wanner
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 14:50 ` Re: PostgreSQL Developer meeting minutes up Aidan Van Dyk <aidan@highrise.ca>
@ 2009-06-02 16:27 ` Ron Mayer <rm_pg@cheapcomplexdevices.com>
3 siblings, 0 replies; 538+ messages in thread
From: Ron Mayer @ 2009-06-02 16:27 UTC (permalink / raw)
To: Aidan Van Dyk <aidan@highrise.ca>; +Cc: Markus Wanner <markus@bluegap.ch>; Marko Kreen <markokr@gmail.com>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
Aidan Van Dyk wrote:
> * Markus Wanner <markus@bluegap.ch> [090602 10:23]:
>> As mentioned before, I'd personally favor *all* of the back-ports to
>> actually be merges of some sort, because that's what they effectively
>> are. However, that also bring up the question of how we are going to do
>> back-patches in the future with git.
>
> Well, if people get comfortable with it, I expect that "backports" don't
> happenen.. Bugs are fixed where they happen, and "merged" forward into
> all affected "later development" based on the bugged area.
I imagine the closest thing to existing practices would be that people
would to use "git-cherry-pick -x -n" to backport only the commits they
wanted from the current branch into the back branches.
AFAICT, this doesn't record a merge in the GIT history, but looks a lot
like the linear history from CVS - with the exception that the comment
added by "-x" explicitly refers to the exact commit from the main branch.
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
@ 2009-06-02 15:34 ` Marko Kreen <markokr@gmail.com>
2009-06-02 16:07 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
1 sibling, 1 reply; 538+ messages in thread
From: Marko Kreen @ 2009-06-02 15:34 UTC (permalink / raw)
To: Markus Wanner <markus@bluegap.ch>; +Cc: Aidan Van Dyk <aidan@highrise.ca>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
On 6/2/09, Markus Wanner <markus@bluegap.ch> wrote:
> [academic nitpicking]
Sorry, not going there. Just look at the state of VCS systems
that have prioritized academic issues insead of practicality...
(arch/darcs/monotone/etc..)
> > So please turn the merge logic off. If this cannot be turned off,
> > cvs2git is not usable for conversion.
> >
>
> As far as I know, it cannot be turned off. Use parsecvs if you want to get
> silly side effects later on in history. ;-)
--no-cross-branch-commits seems sort of that direction?
And what silly side effects are you talking about? I see only cvs2git
doing silly things...
(I'm talking about only in context of Postgres CVS repo, not in general.)
> > Seems it contains more complex logic to handle more complex CVS usage
> > cases, but seems like overkill for us if it creates a mess of history.
> >
>
> You consider it a mess, I consider it a better and more valid
> representation of the mess that CVS is.
Note that merge is no file-level but tree level. Also note we don't
use branches for feature developement but for major version maintenance.
So how can single file appearing in 2 branches means merge of 2 trees?
How can that be valid?
--
marko
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 15:34 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
@ 2009-06-02 16:07 ` Markus Wanner <markus@bluegap.ch>
2009-06-02 16:17 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
0 siblings, 1 reply; 538+ messages in thread
From: Markus Wanner @ 2009-06-02 16:07 UTC (permalink / raw)
To: Marko Kreen <markokr@gmail.com>; +Cc: Aidan Van Dyk <aidan@highrise.ca>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
Hi,
Quoting "Marko Kreen" <markokr@gmail.com>:
> Sorry, not going there. Just look at the state of VCS systems
> that have prioritized academic issues insead of practicality...
> (arch/darcs/monotone/etc..)
I already am there. And I don't want to go back, thanks. But my bias
for monotone certainly shines through, yes ;-)
> --no-cross-branch-commits seems sort of that direction?
Yes, that could lead to the same defect. Uhm.. thank you for pointing
that out, I'm not gonna try it, sorry.
> And what silly side effects are you talking about?
I'm talking about spurious file duplicates popping up after a rename
and a merge, see my example in this thread.
>> You consider it a mess, I consider it a better and more valid
>> representation of the mess that CVS is.
>
> Note that merge is no file-level but tree level.
Depends on your point of view. Each file gets merged pretty
indivitually, but the result ends up in a single commit, yes.
> Also note we don't
> use branches for feature developement but for major version maintenance.
So? You think you are never going to merge?
> So how can single file appearing in 2 branches means merge of 2 trees?
> How can that be valid?
I'm not sure what you are questioning here.
I find it perfectly reasonable to build something on top of
REL8_3_STABLE and later on wanting to merge to REL8_4_STABLE. And I
don't want to manually merge my changes, just because of a rename in
8.4 and a bad decision during the migration to git.
(And no, I don't think any of the other git tools will help with this,
due to the academic-nitpick-reasons above).
Regards
Markus Wanner
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 15:34 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 16:07 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
@ 2009-06-02 16:17 ` Marko Kreen <markokr@gmail.com>
2009-06-03 11:10 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
0 siblings, 1 reply; 538+ messages in thread
From: Marko Kreen @ 2009-06-02 16:17 UTC (permalink / raw)
To: Markus Wanner <markus@bluegap.ch>; +Cc: Aidan Van Dyk <aidan@highrise.ca>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
On 6/2/09, Markus Wanner <markus@bluegap.ch> wrote:
> Quoting "Marko Kreen" <markokr@gmail.com>:
> > And what silly side effects are you talking about?
> >
>
> I'm talking about spurious file duplicates popping up after a rename and a
> merge, see my example in this thread.
The example was not actual case from Postgres CVS history,
but hypotetical situation without checking if it already works
with GIT.
> > Also note we don't
> > use branches for feature developement but for major version maintenance.
> >
>
> So? You think you are never going to merge?
>
>
> > So how can single file appearing in 2 branches means merge of 2 trees?
> > How can that be valid?
> >
>
> I'm not sure what you are questioning here.
>
> I find it perfectly reasonable to build something on top of REL8_3_STABLE
> and later on wanting to merge to REL8_4_STABLE. And I don't want to manually
> merge my changes, just because of a rename in 8.4 and a bad decision during
> the migration to git.
>
> (And no, I don't think any of the other git tools will help with this, due
> to the academic-nitpick-reasons above).
Merging between branches with GIT is fine workflow in the future.
But we are currently discussing how to convert CVS history to GIT.
My point is that we should avoid fake merges, to avoid obfuscating
history.
--
marko
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 15:34 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 16:07 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 16:17 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
@ 2009-06-03 11:10 ` Markus Wanner <markus@bluegap.ch>
2009-06-03 12:08 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
0 siblings, 1 reply; 538+ messages in thread
From: Markus Wanner @ 2009-06-03 11:10 UTC (permalink / raw)
To: Marko Kreen <markokr@gmail.com>; +Cc: Aidan Van Dyk <aidan@highrise.ca>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
Hi,
Quoting "Marko Kreen" <markokr@gmail.com>:
> The example was not actual case from Postgres CVS history,
> but hypotetical situation without checking if it already works
> with GIT.
Of course it is a simplified example, but it resembles what could
happen i.e. to the file doc/src/sgml/generate_history.pl, which got
added from a backported patch after forking off REL8_3_STABLE.
If you create separate commits during the conversion, rename that file
on the master branch and then - for whatever reason - try to merge the
two branches, you will end up having that file twice. That's what I'm
warning about. Changes on either or both sides of the merge make the
situation worse.
> Merging between branches with GIT is fine workflow in the future.
Do you consider the above scenario a fine merge?
> My point is that we should avoid fake merges, to avoid obfuscating
> history.
Understood. It looks like I'm pretty much the only one who cares more
about merge capability than nice looking history :-(
Attached is my current options file for cvs2git, it includes requested
changes by Alvaro and additional names and emails as given by Tom
(thanks again). A current conversion with cvs2git (and with the
merges) results in a repository with exactly 0 differences against any
branch or tag symbol compared to cvs checkout -kk.
Regards
Markus Wanner
# (Be in -*- mode: python; coding: utf-8 -*- mode.)
import re
from cvs2svn_lib import config
from cvs2svn_lib import changeset_database
from cvs2svn_lib.common import CVSTextDecoder
from cvs2svn_lib.log import Log
from cvs2svn_lib.project import Project
from cvs2svn_lib.git_revision_recorder import GitRevisionRecorder
from cvs2svn_lib.git_output_option import GitRevisionMarkWriter
from cvs2svn_lib.git_output_option import GitOutputOption
from cvs2svn_lib.revision_manager import NullRevisionRecorder
from cvs2svn_lib.revision_manager import NullRevisionExcluder
from cvs2svn_lib.fulltext_revision_recorder \
import SimpleFulltextRevisionRecorderAdapter
from cvs2svn_lib.rcs_revision_manager import RCSRevisionReader
from cvs2svn_lib.cvs_revision_manager import CVSRevisionReader
from cvs2svn_lib.checkout_internal import InternalRevisionRecorder
from cvs2svn_lib.checkout_internal import InternalRevisionExcluder
from cvs2svn_lib.checkout_internal import InternalRevisionReader
from cvs2svn_lib.symbol_strategy import AllBranchRule
from cvs2svn_lib.symbol_strategy import AllTagRule
from cvs2svn_lib.symbol_strategy import BranchIfCommitsRule
from cvs2svn_lib.symbol_strategy import ExcludeRegexpStrategyRule
from cvs2svn_lib.symbol_strategy import ForceBranchRegexpStrategyRule
from cvs2svn_lib.symbol_strategy import ForceTagRegexpStrategyRule
from cvs2svn_lib.symbol_strategy import ExcludeTrivialImportBranchRule
from cvs2svn_lib.symbol_strategy import ExcludeVendorBranchRule
from cvs2svn_lib.symbol_strategy import HeuristicStrategyRule
from cvs2svn_lib.symbol_strategy import UnambiguousUsageRule
from cvs2svn_lib.symbol_strategy import HeuristicPreferredParentRule
from cvs2svn_lib.symbol_strategy import SymbolHintsFileRule
from cvs2svn_lib.symbol_transform import ReplaceSubstringsSymbolTransform
from cvs2svn_lib.symbol_transform import RegexpSymbolTransform
from cvs2svn_lib.symbol_transform import IgnoreSymbolTransform
from cvs2svn_lib.symbol_transform import NormalizePathsSymbolTransform
from cvs2svn_lib.property_setters import AutoPropsPropertySetter
from cvs2svn_lib.property_setters import CVSBinaryFileDefaultMimeTypeSetter
from cvs2svn_lib.property_setters import CVSBinaryFileEOLStyleSetter
from cvs2svn_lib.property_setters import CVSRevisionNumberSetter
from cvs2svn_lib.property_setters import DefaultEOLStyleSetter
from cvs2svn_lib.property_setters import EOLStyleFromMimeTypeSetter
from cvs2svn_lib.property_setters import ExecutablePropertySetter
from cvs2svn_lib.property_setters import KeywordsPropertySetter
from cvs2svn_lib.property_setters import MimeMapper
from cvs2svn_lib.property_setters import SVNBinaryFileKeywordsPropertySetter
Log().log_level = Log.NORMAL
ctx.revision_recorder = SimpleFulltextRevisionRecorderAdapter(
CVSRevisionReader(cvs_executable=r'cvs'),
GitRevisionRecorder('cvs2git-tmp/git-blob.dat'),
)
ctx.revision_excluder = NullRevisionExcluder()
ctx.revision_reader = None
ctx.sort_executable = r'sort'
ctx.trunk_only = False
ctx.cvs_author_decoder = CVSTextDecoder(
['ascii', 'latin1'],
)
ctx.cvs_log_decoder = CVSTextDecoder(
['ascii', 'latin1'],
)
ctx.cvs_filename_decoder = CVSTextDecoder(
['ascii', 'latin1'],
)
ctx.initial_project_commit_message = (
'Standard project directories initialized by cvs2git.'
)
ctx.post_commit_message = (
'This commit was generated by cvs2git to track changes on a CVS '
'vendor branch.'
)
ctx.symbol_commit_message = (
"This commit was manufactured by cvs2git to create %(symbol_type)s "
"'%(symbol_name)s'."
)
ctx.decode_apple_single = False
ctx.symbol_info_filename = None
global_symbol_strategy_rules = [
ExcludeTrivialImportBranchRule(),
UnambiguousUsageRule(),
BranchIfCommitsRule(),
HeuristicStrategyRule(),
# Convert all ambiguous symbols as branches:
AllBranchRule(),
# Convert all ambiguous symbols as tags:
AllTagRule(),
# The last rule is here to choose the preferred parent of branches
# and tags, that is, the line of development from which the symbol
# sprouts.
HeuristicPreferredParentRule(),
]
ctx.username = 'cvs2git'
ctx.svn_property_setters.extend([
CVSBinaryFileEOLStyleSetter(),
CVSBinaryFileDefaultMimeTypeSetter(),
DefaultEOLStyleSetter(None),
SVNBinaryFileKeywordsPropertySetter(),
KeywordsPropertySetter(config.SVN_KEYWORDS_VALUE),
ExecutablePropertySetter(),
])
ctx.tmpdir = r'cvs2git-tmp'
ctx.cross_project_commits = False
ctx.cross_branch_commits = False
ctx.keep_cvsignore = True
ctx.retain_conflicting_attic_files = True
author_transforms={
'adunstan' : ('Andrew Dunstan', 'andrew@dunslane.net'),
'alvherre' : ('Alvaro Herrera', 'alvherre@alvh.no-ip.org'),
'barry' : ('Barry Lind', 'blind@xythos.com'),
'bryanh' : ('Bryan Henderson', 'bryanh@giraffe.netgate.net'),
'darcy' : ('D\'Arcy J.M. Cain', 'darcy@druid.net'),
'dennis' : ('Dennis Björklund', 'db@zigo.dhs.org'),
'heikki' : ('Heikki Linnakangas', 'heikki.linnakangas@enterprisedb.com'),
'inoue' : ('Hiroshi Inoue', 'Inoue@tpf.co.jp'),
'ishii' : ('Tatsuo Ishii', 'ishii@sraoss.co.jp'),
'joe' : ('Joe Conway', 'mail@joeconway.com'),
'jurka' : ('Kris Jurka', 'books@ejurka.com'),
'meskes' : ('Michael Meskes', 'meskes@postgresql.org'),
'mha': ('Magnus Hagander', 'magnus@hagander.net'),
'momjian' : ('Bruce Momjian', 'bruce@momjian.us'),
'neilc' : ('Neil Conway', 'neil.conway@gmail.com'),
'petere' : ('Peter Eisentraut', 'peter_e@gmx.net'),
'peter' : ('Peter Mount', 'peter@retep.org.uk'),
'pjw' : ('Philip Warner', 'pjw@rhyme.com.au'),
'scrappy' : ('Marc G. Fournier', 'scrappy@postgresql.org'),
'teodor' : ('Teodor Sigaev', 'teodor@sigaev.ru'),
'tgl' : ('Tom Lane', 'tgl@sss.pgh.pa.us'),
'vadim' : ('Vadim B. Mikheev', 'vadim4o@yahoo.com'),
'wieck' : ('Jan Wieck', 'JanWieck@yahoo.com'),
'cvs2git' : ('cvs2git', 'admin@postgresql.org'),
}
# This is the main option that causes cvs2svn to output to git rather
# than Subversion:
ctx.output_option = GitOutputOption(
'cvs2git-tmp/git-dump.dat',
GitRevisionMarkWriter(),
max_merges=None,
author_transforms=author_transforms,
)
run_options.profiling = False
changeset_database.use_mmap_for_cvs_item_to_changeset_table = True
run_options.set_project(
r'../postgresql.org/pgsql',
symbol_transforms=[
ReplaceSubstringsSymbolTransform('\\','/'),
NormalizePathsSymbolTransform(),
],
symbol_strategy_rules=global_symbol_strategy_rules,
)
Attachments:
[text/plain] options.py (6.5K, ../../20090603131004.12934iyrr4f7rlsc@mail.bluegap.ch/2-options.py)
download | inline:
# (Be in -*- mode: python; coding: utf-8 -*- mode.)
import re
from cvs2svn_lib import config
from cvs2svn_lib import changeset_database
from cvs2svn_lib.common import CVSTextDecoder
from cvs2svn_lib.log import Log
from cvs2svn_lib.project import Project
from cvs2svn_lib.git_revision_recorder import GitRevisionRecorder
from cvs2svn_lib.git_output_option import GitRevisionMarkWriter
from cvs2svn_lib.git_output_option import GitOutputOption
from cvs2svn_lib.revision_manager import NullRevisionRecorder
from cvs2svn_lib.revision_manager import NullRevisionExcluder
from cvs2svn_lib.fulltext_revision_recorder \
import SimpleFulltextRevisionRecorderAdapter
from cvs2svn_lib.rcs_revision_manager import RCSRevisionReader
from cvs2svn_lib.cvs_revision_manager import CVSRevisionReader
from cvs2svn_lib.checkout_internal import InternalRevisionRecorder
from cvs2svn_lib.checkout_internal import InternalRevisionExcluder
from cvs2svn_lib.checkout_internal import InternalRevisionReader
from cvs2svn_lib.symbol_strategy import AllBranchRule
from cvs2svn_lib.symbol_strategy import AllTagRule
from cvs2svn_lib.symbol_strategy import BranchIfCommitsRule
from cvs2svn_lib.symbol_strategy import ExcludeRegexpStrategyRule
from cvs2svn_lib.symbol_strategy import ForceBranchRegexpStrategyRule
from cvs2svn_lib.symbol_strategy import ForceTagRegexpStrategyRule
from cvs2svn_lib.symbol_strategy import ExcludeTrivialImportBranchRule
from cvs2svn_lib.symbol_strategy import ExcludeVendorBranchRule
from cvs2svn_lib.symbol_strategy import HeuristicStrategyRule
from cvs2svn_lib.symbol_strategy import UnambiguousUsageRule
from cvs2svn_lib.symbol_strategy import HeuristicPreferredParentRule
from cvs2svn_lib.symbol_strategy import SymbolHintsFileRule
from cvs2svn_lib.symbol_transform import ReplaceSubstringsSymbolTransform
from cvs2svn_lib.symbol_transform import RegexpSymbolTransform
from cvs2svn_lib.symbol_transform import IgnoreSymbolTransform
from cvs2svn_lib.symbol_transform import NormalizePathsSymbolTransform
from cvs2svn_lib.property_setters import AutoPropsPropertySetter
from cvs2svn_lib.property_setters import CVSBinaryFileDefaultMimeTypeSetter
from cvs2svn_lib.property_setters import CVSBinaryFileEOLStyleSetter
from cvs2svn_lib.property_setters import CVSRevisionNumberSetter
from cvs2svn_lib.property_setters import DefaultEOLStyleSetter
from cvs2svn_lib.property_setters import EOLStyleFromMimeTypeSetter
from cvs2svn_lib.property_setters import ExecutablePropertySetter
from cvs2svn_lib.property_setters import KeywordsPropertySetter
from cvs2svn_lib.property_setters import MimeMapper
from cvs2svn_lib.property_setters import SVNBinaryFileKeywordsPropertySetter
Log().log_level = Log.NORMAL
ctx.revision_recorder = SimpleFulltextRevisionRecorderAdapter(
CVSRevisionReader(cvs_executable=r'cvs'),
GitRevisionRecorder('cvs2git-tmp/git-blob.dat'),
)
ctx.revision_excluder = NullRevisionExcluder()
ctx.revision_reader = None
ctx.sort_executable = r'sort'
ctx.trunk_only = False
ctx.cvs_author_decoder = CVSTextDecoder(
['ascii', 'latin1'],
)
ctx.cvs_log_decoder = CVSTextDecoder(
['ascii', 'latin1'],
)
ctx.cvs_filename_decoder = CVSTextDecoder(
['ascii', 'latin1'],
)
ctx.initial_project_commit_message = (
'Standard project directories initialized by cvs2git.'
)
ctx.post_commit_message = (
'This commit was generated by cvs2git to track changes on a CVS '
'vendor branch.'
)
ctx.symbol_commit_message = (
"This commit was manufactured by cvs2git to create %(symbol_type)s "
"'%(symbol_name)s'."
)
ctx.decode_apple_single = False
ctx.symbol_info_filename = None
global_symbol_strategy_rules = [
ExcludeTrivialImportBranchRule(),
UnambiguousUsageRule(),
BranchIfCommitsRule(),
HeuristicStrategyRule(),
# Convert all ambiguous symbols as branches:
AllBranchRule(),
# Convert all ambiguous symbols as tags:
AllTagRule(),
# The last rule is here to choose the preferred parent of branches
# and tags, that is, the line of development from which the symbol
# sprouts.
HeuristicPreferredParentRule(),
]
ctx.username = 'cvs2git'
ctx.svn_property_setters.extend([
CVSBinaryFileEOLStyleSetter(),
CVSBinaryFileDefaultMimeTypeSetter(),
DefaultEOLStyleSetter(None),
SVNBinaryFileKeywordsPropertySetter(),
KeywordsPropertySetter(config.SVN_KEYWORDS_VALUE),
ExecutablePropertySetter(),
])
ctx.tmpdir = r'cvs2git-tmp'
ctx.cross_project_commits = False
ctx.cross_branch_commits = False
ctx.keep_cvsignore = True
ctx.retain_conflicting_attic_files = True
author_transforms={
'adunstan' : ('Andrew Dunstan', 'andrew@dunslane.net'),
'alvherre' : ('Alvaro Herrera', 'alvherre@alvh.no-ip.org'),
'barry' : ('Barry Lind', 'blind@xythos.com'),
'bryanh' : ('Bryan Henderson', 'bryanh@giraffe.netgate.net'),
'darcy' : ('D\'Arcy J.M. Cain', 'darcy@druid.net'),
'dennis' : ('Dennis Björklund', 'db@zigo.dhs.org'),
'heikki' : ('Heikki Linnakangas', 'heikki.linnakangas@enterprisedb.com'),
'inoue' : ('Hiroshi Inoue', 'Inoue@tpf.co.jp'),
'ishii' : ('Tatsuo Ishii', 'ishii@sraoss.co.jp'),
'joe' : ('Joe Conway', 'mail@joeconway.com'),
'jurka' : ('Kris Jurka', 'books@ejurka.com'),
'meskes' : ('Michael Meskes', 'meskes@postgresql.org'),
'mha': ('Magnus Hagander', 'magnus@hagander.net'),
'momjian' : ('Bruce Momjian', 'bruce@momjian.us'),
'neilc' : ('Neil Conway', 'neil.conway@gmail.com'),
'petere' : ('Peter Eisentraut', 'peter_e@gmx.net'),
'peter' : ('Peter Mount', 'peter@retep.org.uk'),
'pjw' : ('Philip Warner', 'pjw@rhyme.com.au'),
'scrappy' : ('Marc G. Fournier', 'scrappy@postgresql.org'),
'teodor' : ('Teodor Sigaev', 'teodor@sigaev.ru'),
'tgl' : ('Tom Lane', 'tgl@sss.pgh.pa.us'),
'vadim' : ('Vadim B. Mikheev', 'vadim4o@yahoo.com'),
'wieck' : ('Jan Wieck', 'JanWieck@yahoo.com'),
'cvs2git' : ('cvs2git', 'admin@postgresql.org'),
}
# This is the main option that causes cvs2svn to output to git rather
# than Subversion:
ctx.output_option = GitOutputOption(
'cvs2git-tmp/git-dump.dat',
GitRevisionMarkWriter(),
max_merges=None,
author_transforms=author_transforms,
)
run_options.profiling = False
changeset_database.use_mmap_for_cvs_item_to_changeset_table = True
run_options.set_project(
r'../postgresql.org/pgsql',
symbol_transforms=[
ReplaceSubstringsSymbolTransform('\\','/'),
NormalizePathsSymbolTransform(),
],
symbol_strategy_rules=global_symbol_strategy_rules,
)
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 15:34 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 16:07 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 16:17 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-03 11:10 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
@ 2009-06-03 12:08 ` Greg Stark <stark@enterprisedb.com>
2009-06-03 12:19 ` Re: PostgreSQL Developer meeting minutes up Andres Freund <andres@anarazel.de>
2009-06-04 08:11 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
0 siblings, 2 replies; 538+ messages in thread
From: Greg Stark @ 2009-06-03 12:08 UTC (permalink / raw)
To: Markus Wanner <markus@bluegap.ch>; +Cc: Marko Kreen <markokr@gmail.com>; Aidan Van Dyk <aidan@highrise.ca>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
On Wed, Jun 3, 2009 at 12:10 PM, Markus Wanner <markus@bluegap.ch> wrote:
> If you create separate commits during the conversion, rename that file on
> the master branch
This is all completely irrelevant to the CVS import. I don't think
we've ever renamed files because CVS can't handle it cleanly.
It does sound to me like we really ought to have merge commits marking
the bug fixes in old releases as merged in the equivalent commits to
later branches based on Tom's commit messages.
That would make the git history match Tom's "same commit message"
implicit CVS history that cvs2pcl was giving him. I find git-log's
output including merge commits kind of strange and annoying myself but
having them at least gives us a chance to have a tool that understands
them output something like cvs2pcl. Throwing away that information
because we don't like the clutter in the tool output seems like a
short-sighted plan.
That said, the commit log message isn't being lost. We could always
import the history linearly and add the merge commits later if we
decide having them would help some tool implement cvs2pcl summaries.
--
greg
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 15:34 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 16:07 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 16:17 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-03 11:10 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-03 12:08 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
@ 2009-06-03 12:19 ` Andres Freund <andres@anarazel.de>
2009-06-03 14:01 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
1 sibling, 1 reply; 538+ messages in thread
From: Andres Freund @ 2009-06-03 12:19 UTC (permalink / raw)
To: Greg Stark <stark@enterprisedb.com>; +Cc: Markus Wanner <markus@bluegap.ch>; Marko Kreen <markokr@gmail.com>; Aidan Van Dyk <aidan@highrise.ca>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
Hi,
On 06/03/2009 02:08 PM, Greg Stark wrote:
> On Wed, Jun 3, 2009 at 12:10 PM, Markus Wanner<markus@bluegap.ch> wrote:
> That would make the git history match Tom's "same commit message"
> implicit CVS history that cvs2pcl was giving him. I find git-log's
> output including merge commits kind of strange and annoying myself but
> having them at least gives us a chance to have a tool that understands
> them output something like cvs2pcl.
"git log --no-merges" hides the actual merge commits if that is what you
want.
Andres
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 15:34 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 16:07 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 16:17 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-03 11:10 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-03 12:08 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 12:19 ` Re: PostgreSQL Developer meeting minutes up Andres Freund <andres@anarazel.de>
@ 2009-06-03 14:01 ` Greg Stark <stark@enterprisedb.com>
2009-06-03 14:13 ` Re: PostgreSQL Developer meeting minutes up Magnus Hagander <magnus@hagander.net>
2009-06-03 14:20 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
0 siblings, 2 replies; 538+ messages in thread
From: Greg Stark @ 2009-06-03 14:01 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; +Cc: Markus Wanner <markus@bluegap.ch>; Marko Kreen <markokr@gmail.com>; Aidan Van Dyk <aidan@highrise.ca>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
On Wed, Jun 3, 2009 at 1:19 PM, Andres Freund <andres@anarazel.de> wrote:
> "git log --no-merges" hides the actual merge commits if that is what you
> want.
Ooh! Life seems so much sweeter now!
Given that we don't have to see them then I'm all for marking bug fix
patches which were applied to multiple branches as merges. That seems
like it would make it easier for tools like gitk or to show useful
information analogous to the cvs2pcl info.
Given that Tom's been intentionally marking the commits with identical
commit messages we ought to be able to find *all* of them and mark
them properly. That would be way better than only finding patches that
are absolutely identical.
I'm not sure whether we should mark the old branches getting merges
down or the new branches getting merged up. I suspect I'm missing
something but I don't see any reason one is better than the other.
--
greg
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 15:34 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 16:07 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 16:17 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-03 11:10 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-03 12:08 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 12:19 ` Re: PostgreSQL Developer meeting minutes up Andres Freund <andres@anarazel.de>
2009-06-03 14:01 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
@ 2009-06-03 14:13 ` Magnus Hagander <magnus@hagander.net>
2009-06-03 14:17 ` Re: PostgreSQL Developer meeting minutes up Robert Haas <robertmhaas@gmail.com>
2009-06-03 14:36 ` Re: PostgreSQL Developer meeting minutes up Aidan Van Dyk <aidan@highrise.ca>
1 sibling, 2 replies; 538+ messages in thread
From: Magnus Hagander @ 2009-06-03 14:13 UTC (permalink / raw)
To: Greg Stark <stark@enterprisedb.com>; +Cc: Andres Freund <andres@anarazel.de>; Markus Wanner <markus@bluegap.ch>; Marko Kreen <markokr@gmail.com>; Aidan Van Dyk <aidan@highrise.ca>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
Greg Stark wrote:
> On Wed, Jun 3, 2009 at 1:19 PM, Andres Freund <andres@anarazel.de> wrote:
>> "git log --no-merges" hides the actual merge commits if that is what you
>> want.
>
> Ooh! Life seems so much sweeter now!
>
> Given that we don't have to see them then I'm all for marking bug fix
> patches which were applied to multiple branches as merges. That seems
> like it would make it easier for tools like gitk or to show useful
> information analogous to the cvs2pcl info.
Right, if it adds additional metadata that lets the tools do their magic
better, and it's still easy to filter out, I don't see a downside.
> Given that Tom's been intentionally marking the commits with identical
> commit messages we ought to be able to find *all* of them and mark
> them properly. That would be way better than only finding patches that
> are absolutely identical.
Just to be clear, not just Tom. All committers. I was told to do that
right after my first backpatch which *didn't* do it :-)
So it's an established project practice. That has other advantages as
well, of course..
> I'm not sure whether we should mark the old branches getting merges
> down or the new branches getting merged up. I suspect I'm missing
> something but I don't see any reason one is better than the other.
If you go from older to newer, the automatic merge algorithms have a
better chance of doing something smart since they can track previous
changes. At least I think that's how it works.
But I think for most of the changes it wouldn't make a huge difference,
though - manual merging would be needed anyway.
//Magnus
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 15:34 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 16:07 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 16:17 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-03 11:10 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-03 12:08 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 12:19 ` Re: PostgreSQL Developer meeting minutes up Andres Freund <andres@anarazel.de>
2009-06-03 14:01 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 14:13 ` Re: PostgreSQL Developer meeting minutes up Magnus Hagander <magnus@hagander.net>
@ 2009-06-03 14:17 ` Robert Haas <robertmhaas@gmail.com>
2009-06-03 14:18 ` Re: PostgreSQL Developer meeting minutes up Magnus Hagander <magnus@hagander.net>
1 sibling, 1 reply; 538+ messages in thread
From: Robert Haas @ 2009-06-03 14:17 UTC (permalink / raw)
To: Magnus Hagander <magnus@hagander.net>; +Cc: Greg Stark <stark@enterprisedb.com>; Andres Freund <andres@anarazel.de>; Markus Wanner <markus@bluegap.ch>; Marko Kreen <markokr@gmail.com>; Aidan Van Dyk <aidan@highrise.ca>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
On Wed, Jun 3, 2009 at 10:13 AM, Magnus Hagander <magnus@hagander.net> wrote:
> Greg Stark wrote:
>> On Wed, Jun 3, 2009 at 1:19 PM, Andres Freund <andres@anarazel.de> wrote:
>>> "git log --no-merges" hides the actual merge commits if that is what you
>>> want.
>>
>> Ooh! Life seems so much sweeter now!
>>
>> Given that we don't have to see them then I'm all for marking bug fix
>> patches which were applied to multiple branches as merges. That seems
>> like it would make it easier for tools like gitk or to show useful
>> information analogous to the cvs2pcl info.
>
> Right, if it adds additional metadata that lets the tools do their magic
> better, and it's still easy to filter out, I don't see a downside.
>
>> I'm not sure whether we should mark the old branches getting merges
>> down or the new branches getting merged up. I suspect I'm missing
>> something but I don't see any reason one is better than the other.
>
> If you go from older to newer, the automatic merge algorithms have a
> better chance of doing something smart since they can track previous
> changes. At least I think that's how it works.
>
> But I think for most of the changes it wouldn't make a huge difference,
> though - manual merging would be needed anyway.
In practice, isn't it more likely that you would develop the change on
the newest branch and then try to back-port it? However you do the
import, you're going to want to do subsequent things the same way.
...Robert
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 15:34 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 16:07 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 16:17 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-03 11:10 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-03 12:08 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 12:19 ` Re: PostgreSQL Developer meeting minutes up Andres Freund <andres@anarazel.de>
2009-06-03 14:01 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 14:13 ` Re: PostgreSQL Developer meeting minutes up Magnus Hagander <magnus@hagander.net>
2009-06-03 14:17 ` Re: PostgreSQL Developer meeting minutes up Robert Haas <robertmhaas@gmail.com>
@ 2009-06-03 14:18 ` Magnus Hagander <magnus@hagander.net>
2009-06-03 14:26 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
0 siblings, 1 reply; 538+ messages in thread
From: Magnus Hagander @ 2009-06-03 14:18 UTC (permalink / raw)
To: Robert Haas <robertmhaas@gmail.com>; +Cc: Greg Stark <stark@enterprisedb.com>; Andres Freund <andres@anarazel.de>; Markus Wanner <markus@bluegap.ch>; Marko Kreen <markokr@gmail.com>; Aidan Van Dyk <aidan@highrise.ca>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
Robert Haas wrote:
> On Wed, Jun 3, 2009 at 10:13 AM, Magnus Hagander <magnus@hagander.net> wrote:
>>> I'm not sure whether we should mark the old branches getting merges
>>> down or the new branches getting merged up. I suspect I'm missing
>>> something but I don't see any reason one is better than the other.
>> If you go from older to newer, the automatic merge algorithms have a
>> better chance of doing something smart since they can track previous
>> changes. At least I think that's how it works.
>>
>> But I think for most of the changes it wouldn't make a huge difference,
>> though - manual merging would be needed anyway.
>
> In practice, isn't it more likely that you would develop the change on
> the newest branch and then try to back-port it? However you do the
> import, you're going to want to do subsequent things the same way.
That's definitely the order in which *I* work, and I think that's how
most others do it as well.
--
Magnus Hagander
Self: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 15:34 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 16:07 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 16:17 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-03 11:10 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-03 12:08 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 12:19 ` Re: PostgreSQL Developer meeting minutes up Andres Freund <andres@anarazel.de>
2009-06-03 14:01 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 14:13 ` Re: PostgreSQL Developer meeting minutes up Magnus Hagander <magnus@hagander.net>
2009-06-03 14:17 ` Re: PostgreSQL Developer meeting minutes up Robert Haas <robertmhaas@gmail.com>
2009-06-03 14:18 ` Re: PostgreSQL Developer meeting minutes up Magnus Hagander <magnus@hagander.net>
@ 2009-06-03 14:26 ` Marko Kreen <markokr@gmail.com>
2009-06-03 14:38 ` Re: PostgreSQL Developer meeting minutes up Aidan Van Dyk <aidan@highrise.ca>
0 siblings, 1 reply; 538+ messages in thread
From: Marko Kreen @ 2009-06-03 14:26 UTC (permalink / raw)
To: Magnus Hagander <magnus@hagander.net>; +Cc: Robert Haas <robertmhaas@gmail.com>; Greg Stark <stark@enterprisedb.com>; Andres Freund <andres@anarazel.de>; Markus Wanner <markus@bluegap.ch>; Aidan Van Dyk <aidan@highrise.ca>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
On 6/3/09, Magnus Hagander <magnus@hagander.net> wrote:
> Robert Haas wrote:
> > On Wed, Jun 3, 2009 at 10:13 AM, Magnus Hagander <magnus@hagander.net> wrote:
>
> >>> I'm not sure whether we should mark the old branches getting merges
> >>> down or the new branches getting merged up. I suspect I'm missing
> >>> something but I don't see any reason one is better than the other.
> >> If you go from older to newer, the automatic merge algorithms have a
> >> better chance of doing something smart since they can track previous
> >> changes. At least I think that's how it works.
> >>
> >> But I think for most of the changes it wouldn't make a huge difference,
> >> though - manual merging would be needed anyway.
> >
> > In practice, isn't it more likely that you would develop the change on
> > the newest branch and then try to back-port it? However you do the
> > import, you're going to want to do subsequent things the same way.
>
>
> That's definitely the order in which *I* work, and I think that's how
> most others do it as well.
Thats true, but it's not representable in VCS, unless you use cherry-pick,
which is just UI around patch transport. But considering separate
local trees (with can optionally contain local per-fix branches),
it is possible to separate the fix-developement from final representation.
--
marko
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 15:34 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 16:07 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 16:17 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-03 11:10 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-03 12:08 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 12:19 ` Re: PostgreSQL Developer meeting minutes up Andres Freund <andres@anarazel.de>
2009-06-03 14:01 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 14:13 ` Re: PostgreSQL Developer meeting minutes up Magnus Hagander <magnus@hagander.net>
2009-06-03 14:17 ` Re: PostgreSQL Developer meeting minutes up Robert Haas <robertmhaas@gmail.com>
2009-06-03 14:18 ` Re: PostgreSQL Developer meeting minutes up Magnus Hagander <magnus@hagander.net>
2009-06-03 14:26 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
@ 2009-06-03 14:38 ` Aidan Van Dyk <aidan@highrise.ca>
2009-06-03 15:07 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
0 siblings, 1 reply; 538+ messages in thread
From: Aidan Van Dyk @ 2009-06-03 14:38 UTC (permalink / raw)
To: Marko Kreen <markokr@gmail.com>; +Cc: Magnus Hagander <magnus@hagander.net>; Robert Haas <robertmhaas@gmail.com>; Greg Stark <stark@enterprisedb.com>; Andres Freund <andres@anarazel.de>; Markus Wanner <markus@bluegap.ch>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
* Marko Kreen <markokr@gmail.com> [090603 10:26]:
> Thats true, but it's not representable in VCS, unless you use cherry-pick,
> which is just UI around patch transport. But considering separate
> local trees (with can optionally contain local per-fix branches),
> it is possible to separate the fix-developement from final representation.
I'll note that in git, cherry-pick is *more* than just "patch
transport". I would more call it "patch commute". It does actually
look at the history between the "pick"ed patch, and the current
tree, any merge/fork points, and the differences on each path that lead
to the changes in the current tree and the picked patch.
a.
--
Aidan Van Dyk Create like a god,
aidan@highrise.ca command like a king,
http://www.highrise.ca/ work like a slave.
Attachments:
[application/pgp-signature] signature.asc (189B, ../../20090603143830.GM23972@yugib.highrise.ca/2-signature.asc)
download
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 15:34 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 16:07 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 16:17 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-03 11:10 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-03 12:08 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 12:19 ` Re: PostgreSQL Developer meeting minutes up Andres Freund <andres@anarazel.de>
2009-06-03 14:01 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 14:13 ` Re: PostgreSQL Developer meeting minutes up Magnus Hagander <magnus@hagander.net>
2009-06-03 14:17 ` Re: PostgreSQL Developer meeting minutes up Robert Haas <robertmhaas@gmail.com>
2009-06-03 14:18 ` Re: PostgreSQL Developer meeting minutes up Magnus Hagander <magnus@hagander.net>
2009-06-03 14:26 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-03 14:38 ` Re: PostgreSQL Developer meeting minutes up Aidan Van Dyk <aidan@highrise.ca>
@ 2009-06-03 15:07 ` Marko Kreen <markokr@gmail.com>
2009-06-03 15:25 ` Re: PostgreSQL Developer meeting minutes up Aidan Van Dyk <aidan@highrise.ca>
0 siblings, 1 reply; 538+ messages in thread
From: Marko Kreen @ 2009-06-03 15:07 UTC (permalink / raw)
To: Aidan Van Dyk <aidan@highrise.ca>; +Cc: Magnus Hagander <magnus@hagander.net>; Robert Haas <robertmhaas@gmail.com>; Greg Stark <stark@enterprisedb.com>; Andres Freund <andres@anarazel.de>; Markus Wanner <markus@bluegap.ch>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
On 6/3/09, Aidan Van Dyk <aidan@highrise.ca> wrote:
> * Marko Kreen <markokr@gmail.com> [090603 10:26]:
> > Thats true, but it's not representable in VCS, unless you use cherry-pick,
> > which is just UI around patch transport. But considering separate
> > local trees (with can optionally contain local per-fix branches),
> > it is possible to separate the fix-developement from final representation.
>
>
> I'll note that in git, cherry-pick is *more* than just "patch
> transport". I would more call it "patch commute". It does actually
> look at the history between the "pick"ed patch, and the current
> tree, any merge/fork points, and the differences on each path that lead
> to the changes in the current tree and the picked patch.
Well, thats good to know, but this also seems to mean it's rather bad
tool for back-patching, as you risk including random unwanted commits
too that happened in the HEAD meantime. But also, it's very good
tool for forward-patching.
But my point was not about that - rather I was pointing out that
this "patch-commute" will result in duplicate commits, that have
no ties in DAG.
--
marko
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 15:34 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 16:07 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 16:17 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-03 11:10 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-03 12:08 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 12:19 ` Re: PostgreSQL Developer meeting minutes up Andres Freund <andres@anarazel.de>
2009-06-03 14:01 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 14:13 ` Re: PostgreSQL Developer meeting minutes up Magnus Hagander <magnus@hagander.net>
2009-06-03 14:17 ` Re: PostgreSQL Developer meeting minutes up Robert Haas <robertmhaas@gmail.com>
2009-06-03 14:18 ` Re: PostgreSQL Developer meeting minutes up Magnus Hagander <magnus@hagander.net>
2009-06-03 14:26 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-03 14:38 ` Re: PostgreSQL Developer meeting minutes up Aidan Van Dyk <aidan@highrise.ca>
2009-06-03 15:07 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
@ 2009-06-03 15:25 ` Aidan Van Dyk <aidan@highrise.ca>
2009-06-03 15:28 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
0 siblings, 1 reply; 538+ messages in thread
From: Aidan Van Dyk @ 2009-06-03 15:25 UTC (permalink / raw)
To: Marko Kreen <markokr@gmail.com>; +Cc: Magnus Hagander <magnus@hagander.net>; Robert Haas <robertmhaas@gmail.com>; Greg Stark <stark@enterprisedb.com>; Andres Freund <andres@anarazel.de>; Markus Wanner <markus@bluegap.ch>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
* Marko Kreen <markokr@gmail.com> [090603 11:12]:
> Well, thats good to know, but this also seems to mean it's rather bad
> tool for back-patching, as you risk including random unwanted commits
> too that happened in the HEAD meantime. But also, it's very good
> tool for forward-patching.
It doesn't "pull in commits" in the sense that darcs does... But rather,
its more like "the patch changes $XXX in $file, but that $file was
really $old_file at the common point between the 2 commits, and
$old_file is still $old file in the commit I'm trying to apply the patch
to".
It looks at the history of the changes to figure out why (or why
not) they apply, and see if they should still be applied to the same
file, or another file (in case of a rename/moved file in 1 branch), or
if the changed area has been moved drastically in the file in one
branch, and the change should be applied there instead.
> But my point was not about that - rather I was pointing out that
> this "patch-commute" will result in duplicate commits, that have
> no ties in DAG.
Yes. That's a cherry-pick, if you want a merge, you merge ;-) But
merge carries the baggage of expectation that *all* changes in both
parents have been combined.
--
Aidan Van Dyk Create like a god,
aidan@highrise.ca command like a king,
http://www.highrise.ca/ work like a slave.
Attachments:
[application/pgp-signature] signature.asc (189B, ../../20090603152530.GN23972@yugib.highrise.ca/2-signature.asc)
download
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 15:34 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 16:07 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 16:17 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-03 11:10 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-03 12:08 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 12:19 ` Re: PostgreSQL Developer meeting minutes up Andres Freund <andres@anarazel.de>
2009-06-03 14:01 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 14:13 ` Re: PostgreSQL Developer meeting minutes up Magnus Hagander <magnus@hagander.net>
2009-06-03 14:17 ` Re: PostgreSQL Developer meeting minutes up Robert Haas <robertmhaas@gmail.com>
2009-06-03 14:18 ` Re: PostgreSQL Developer meeting minutes up Magnus Hagander <magnus@hagander.net>
2009-06-03 14:26 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-03 14:38 ` Re: PostgreSQL Developer meeting minutes up Aidan Van Dyk <aidan@highrise.ca>
2009-06-03 15:07 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-03 15:25 ` Re: PostgreSQL Developer meeting minutes up Aidan Van Dyk <aidan@highrise.ca>
@ 2009-06-03 15:28 ` Marko Kreen <markokr@gmail.com>
2009-06-03 15:52 ` Re: PostgreSQL Developer meeting minutes up Aidan Van Dyk <aidan@highrise.ca>
0 siblings, 1 reply; 538+ messages in thread
From: Marko Kreen @ 2009-06-03 15:28 UTC (permalink / raw)
To: Aidan Van Dyk <aidan@highrise.ca>; +Cc: Magnus Hagander <magnus@hagander.net>; Robert Haas <robertmhaas@gmail.com>; Greg Stark <stark@enterprisedb.com>; Andres Freund <andres@anarazel.de>; Markus Wanner <markus@bluegap.ch>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
On 6/3/09, Aidan Van Dyk <aidan@highrise.ca> wrote:
> * Marko Kreen <markokr@gmail.com> [090603 11:12]:
> > Well, thats good to know, but this also seems to mean it's rather bad
> > tool for back-patching, as you risk including random unwanted commits
> > too that happened in the HEAD meantime. But also, it's very good
> > tool for forward-patching.
>
> It doesn't "pull in commits" in the sense that darcs does... But rather,
> its more like "the patch changes $XXX in $file, but that $file was
> really $old_file at the common point between the 2 commits, and
> $old_file is still $old file in the commit I'm trying to apply the patch
> to".
>
> It looks at the history of the changes to figure out why (or why
> not) they apply, and see if they should still be applied to the same
> file, or another file (in case of a rename/moved file in 1 branch), or
> if the changed area has been moved drastically in the file in one
> branch, and the change should be applied there instead.
I'm not certain, but I remember using cherry pick and seeing
several commits in result. This seems to be a point that needs
to be checked.
> > But my point was not about that - rather I was pointing out that
> > this "patch-commute" will result in duplicate commits, that have
> > no ties in DAG.
>
>
> Yes. That's a cherry-pick, if you want a merge, you merge ;-) But
> merge carries the baggage of expectation that *all* changes in both
> parents have been combined.
But in forward-merge case it's true.
--
marko
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 15:34 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 16:07 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 16:17 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-03 11:10 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-03 12:08 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 12:19 ` Re: PostgreSQL Developer meeting minutes up Andres Freund <andres@anarazel.de>
2009-06-03 14:01 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 14:13 ` Re: PostgreSQL Developer meeting minutes up Magnus Hagander <magnus@hagander.net>
2009-06-03 14:17 ` Re: PostgreSQL Developer meeting minutes up Robert Haas <robertmhaas@gmail.com>
2009-06-03 14:18 ` Re: PostgreSQL Developer meeting minutes up Magnus Hagander <magnus@hagander.net>
2009-06-03 14:26 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-03 14:38 ` Re: PostgreSQL Developer meeting minutes up Aidan Van Dyk <aidan@highrise.ca>
2009-06-03 15:07 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-03 15:25 ` Re: PostgreSQL Developer meeting minutes up Aidan Van Dyk <aidan@highrise.ca>
2009-06-03 15:28 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
@ 2009-06-03 15:52 ` Aidan Van Dyk <aidan@highrise.ca>
0 siblings, 0 replies; 538+ messages in thread
From: Aidan Van Dyk @ 2009-06-03 15:52 UTC (permalink / raw)
To: Marko Kreen <markokr@gmail.com>; +Cc: Magnus Hagander <magnus@hagander.net>; Robert Haas <robertmhaas@gmail.com>; Greg Stark <stark@enterprisedb.com>; Andres Freund <andres@anarazel.de>; Markus Wanner <markus@bluegap.ch>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
* Marko Kreen <markokr@gmail.com> [090603 11:28]:
> I'm not certain, but I remember using cherry pick and seeing
> several commits in result. This seems to be a point that needs
> to be checked.
I'm not sure what you're recalling, but git cherry-pick takes a single
commit, and applies it as a single commit (or, with -n, doesn't actually
commit it). That's what it does... There are various *other* tools (like
rebase, am, cherry, etc) which operate on "sets" of commits.
--
Aidan Van Dyk Create like a god,
aidan@highrise.ca command like a king,
http://www.highrise.ca/ work like a slave.
Attachments:
[application/pgp-signature] signature.asc (189B, ../../20090603155249.GO23972@yugib.highrise.ca/2-signature.asc)
download
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 15:34 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 16:07 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 16:17 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-03 11:10 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-03 12:08 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 12:19 ` Re: PostgreSQL Developer meeting minutes up Andres Freund <andres@anarazel.de>
2009-06-03 14:01 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 14:13 ` Re: PostgreSQL Developer meeting minutes up Magnus Hagander <magnus@hagander.net>
@ 2009-06-03 14:36 ` Aidan Van Dyk <aidan@highrise.ca>
1 sibling, 0 replies; 538+ messages in thread
From: Aidan Van Dyk @ 2009-06-03 14:36 UTC (permalink / raw)
To: Magnus Hagander <magnus@hagander.net>; +Cc: Greg Stark <stark@enterprisedb.com>; Andres Freund <andres@anarazel.de>; Markus Wanner <markus@bluegap.ch>; Marko Kreen <markokr@gmail.com>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
* Magnus Hagander <magnus@hagander.net> [090603 10:13]:
>
> Right, if it adds additional metadata that lets the tools do their magic
> better, and it's still easy to filter out, I don't see a downside.
Note, that it could (and likely will) have a downside when you get to
doing real merge-based development... A "merge" means that *all* changes
in *both* parents have been combined in *this* commit. And all merge
tools depend on this. That's the directed part of the "DAG" in git. So
if you want to be working in a way that the merge tools work, you
*don't* have master/HEAD merged into REL8_2_STABLE. You can have
REL8_2_STABLE merged into master/head.
I'll concede that in GIT, it's flexible (some say arbitrary) enough that
you can *construct* the DAG otherwise, but then you've done something in
such a fashion that the DAG has no bearing on "real merging", and thus
you loose all the power of DAGs "merge tracking" when working on new
real merging....
a.
--
Aidan Van Dyk Create like a god,
aidan@highrise.ca command like a king,
http://www.highrise.ca/ work like a slave.
Attachments:
[application/pgp-signature] signature.asc (189B, ../../20090603143622.GL23972@yugib.highrise.ca/2-signature.asc)
download
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 15:34 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 16:07 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 16:17 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-03 11:10 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-03 12:08 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 12:19 ` Re: PostgreSQL Developer meeting minutes up Andres Freund <andres@anarazel.de>
2009-06-03 14:01 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
@ 2009-06-03 14:20 ` Marko Kreen <markokr@gmail.com>
2009-06-03 14:46 ` Re: PostgreSQL Developer meeting minutes up Robert Haas <robertmhaas@gmail.com>
2009-06-04 09:46 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
1 sibling, 2 replies; 538+ messages in thread
From: Marko Kreen @ 2009-06-03 14:20 UTC (permalink / raw)
To: Greg Stark <stark@enterprisedb.com>; +Cc: Andres Freund <andres@anarazel.de>; Markus Wanner <markus@bluegap.ch>; Aidan Van Dyk <aidan@highrise.ca>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
On 6/3/09, Greg Stark <stark@enterprisedb.com> wrote:
> On Wed, Jun 3, 2009 at 1:19 PM, Andres Freund <andres@anarazel.de> wrote:
> > "git log --no-merges" hides the actual merge commits if that is what you
> > want.
>
>
> Ooh! Life seems so much sweeter now!
>
> Given that we don't have to see them then I'm all for marking bug fix
> patches which were applied to multiple branches as merges. That seems
> like it would make it easier for tools like gitk or to show useful
> information analogous to the cvs2pcl info.
>
> Given that Tom's been intentionally marking the commits with identical
> commit messages we ought to be able to find *all* of them and mark
> them properly. That would be way better than only finding patches that
> are absolutely identical.
>
> I'm not sure whether we should mark the old branches getting merges
> down or the new branches getting merged up. I suspect I'm missing
> something but I don't see any reason one is better than the other.
Although "mark Tom's back-branch fixes as merges" makes much more
sense than "mark new files as merges", it is quite a step up from
"do tags match official releases".
It seems to require noticeable development effort to get a importer
to a level it can do it. Will this be a requirement for import?
Or just a good thing to have? Also how to check if all such merges
are sensible?
And note that such effort will affect only old imported history,
it will not make easier to handle back-branch fixes in the future...
Various scenarios with git cherry-pick and similar tools would still
result in duplicate commits, so we would need a git log post-processor
anyway if we want to somehow group them together for eg. weekly commit
summary. And such post-processor would work on old history too.
Maybe that's better direction to work on, than to potentially risk in
messy history in GIT?
--
marko
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 15:34 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 16:07 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 16:17 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-03 11:10 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-03 12:08 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 12:19 ` Re: PostgreSQL Developer meeting minutes up Andres Freund <andres@anarazel.de>
2009-06-03 14:01 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 14:20 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
@ 2009-06-03 14:46 ` Robert Haas <robertmhaas@gmail.com>
2009-06-03 19:33 ` Re: PostgreSQL Developer meeting minutes up Ron Mayer <rm_pg@cheapcomplexdevices.com>
1 sibling, 1 reply; 538+ messages in thread
From: Robert Haas @ 2009-06-03 14:46 UTC (permalink / raw)
To: Marko Kreen <markokr@gmail.com>; +Cc: Greg Stark <stark@enterprisedb.com>; Andres Freund <andres@anarazel.de>; Markus Wanner <markus@bluegap.ch>; Aidan Van Dyk <aidan@highrise.ca>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
On Wed, Jun 3, 2009 at 10:20 AM, Marko Kreen <markokr@gmail.com> wrote:
> Various scenarios with git cherry-pick and similar tools would still
> result in duplicate commits, so we would need a git log post-processor
> anyway if we want to somehow group them together for eg. weekly commit
> summary. Â And such post-processor would work on old history too.
>
> Maybe that's better direction to work on, than to potentially risk in
> messy history in GIT?
I think it is. cherry-picking seems like a much better way of
back-patching than merging, so putting a lot of effort into making
merges "work" doesn't seem like a good expenditure of effort.
It seems pretty clear that searching through the histories of each
branch for duplicate commit messages and producing a unified report is
pretty straightforward if we assume that the commit messages are
byte-for-byte identical (or even modulo whitespace changes). But I
wonder if it would make more sense to include some kind of metadata in
the commit message (or some other property of the commit? does git
support that?) to make it not depend on that. I suppose Tom et. al.
like the way they do it now, so maybe we should just stick with text
comparison, but it seems a bit awkward to me.
...Robert
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 15:34 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 16:07 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 16:17 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-03 11:10 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-03 12:08 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 12:19 ` Re: PostgreSQL Developer meeting minutes up Andres Freund <andres@anarazel.de>
2009-06-03 14:01 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 14:20 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-03 14:46 ` Re: PostgreSQL Developer meeting minutes up Robert Haas <robertmhaas@gmail.com>
@ 2009-06-03 19:33 ` Ron Mayer <rm_pg@cheapcomplexdevices.com>
0 siblings, 0 replies; 538+ messages in thread
From: Ron Mayer @ 2009-06-03 19:33 UTC (permalink / raw)
To: Robert Haas <robertmhaas@gmail.com>; +Cc: Marko Kreen <markokr@gmail.com>; Greg Stark <stark@enterprisedb.com>; Andres Freund <andres@anarazel.de>; Markus Wanner <markus@bluegap.ch>; Aidan Van Dyk <aidan@highrise.ca>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
Robert Haas wrote:
> But I
> wonder if it would make more sense to include some kind of metadata in
> the commit message (or some other property of the commit? does git
> support that?) to make it not depend on that.
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 15:34 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 16:07 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 16:17 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-03 11:10 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-03 12:08 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 12:19 ` Re: PostgreSQL Developer meeting minutes up Andres Freund <andres@anarazel.de>
2009-06-03 14:01 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 14:20 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
@ 2009-06-04 09:46 ` Markus Wanner <markus@bluegap.ch>
2009-06-04 21:20 ` Re: PostgreSQL Developer meeting minutes up Ron Mayer <rm_pg@cheapcomplexdevices.com>
1 sibling, 1 reply; 538+ messages in thread
From: Markus Wanner @ 2009-06-04 09:46 UTC (permalink / raw)
To: Marko Kreen <markokr@gmail.com>; +Cc: Greg Stark <stark@enterprisedb.com>; Andres Freund <andres@anarazel.de>; Aidan Van Dyk <aidan@highrise.ca>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
Hi,
Quoting "Marko Kreen" <markokr@gmail.com>:
>> I'm not sure whether we should mark the old branches getting merges
>> down or the new branches getting merged up. I suspect I'm missing
>> something but I don't see any reason one is better than the other.
As pointed out by others, it doesn't make sense to merge (all commits
since the last merge) from HEAD to the back branches. You'd have to
cherry-pick only the commits which actually have to get back patched.
The "new branches getting merged up" could work. That is, applying the
fix to the oldest back-branch which requires the fix first and then
merge it to all newer ones, including HEAD. However, that would
require some rethinking: instead of creating bugfix-patches for HEAD,
then manually adjust patches for back-branches and then group
committing, you'd have to create a bugfix-patch for the oldest branch
first, commit that and then merge that to the newer branches.
I consider merging a cleaner and simpler operation than
cherry-picking, because merging allows the VCS to keep track of what
needs to be propagated, while with cherry-picking, you'd have to keep
track of that manually (or with the help of other tools).
An example for that is the very same unability to properly track
renames when cherry-picking, just like what I explained for the CVS
conversion.
> It seems to require noticeable development effort to get a importer
> to a level it can do it. Will this be a requirement for import?
> Or just a good thing to have? Also how to check if all such merges
> are sensible?
If that's how you'd like to have the CVS repository represented in git
(which I'd support as well), I'd give it a try. With all of the work
I've done for mtn cvs_import I certainly have the necessary experience
in CVS conversion and with the cvs2svn algorithm itself.
> And note that such effort will affect only old imported history,
> it will not make easier to handle back-branch fixes in the future...
Hm.. depends, if you want to merge from older branches to newer ones,
instead of cherry-picking, it would certainly help to get the history
clean.
> Various scenarios with git cherry-pick and similar tools would still
> result in duplicate commits, so we would need a git log post-processor
> anyway if we want to somehow group them together for eg. weekly commit
> summary. And such post-processor would work on old history too.
I think we should decide on either using merges or using duplicate
commits we try to link somehow. But then, we should IMO use that
scheme for the conversion as well as later on, so as not to get a
messy history, as you put it.
Regards
Markus Wanner
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 15:34 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 16:07 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 16:17 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-03 11:10 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-03 12:08 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 12:19 ` Re: PostgreSQL Developer meeting minutes up Andres Freund <andres@anarazel.de>
2009-06-03 14:01 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 14:20 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-04 09:46 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
@ 2009-06-04 21:20 ` Ron Mayer <rm_pg@cheapcomplexdevices.com>
2009-06-05 07:05 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
0 siblings, 1 reply; 538+ messages in thread
From: Ron Mayer @ 2009-06-04 21:20 UTC (permalink / raw)
To: Markus Wanner <markus@bluegap.ch>; +Cc: Marko Kreen <markokr@gmail.com>; Greg Stark <stark@enterprisedb.com>; Andres Freund <andres@anarazel.de>; Aidan Van Dyk <aidan@highrise.ca>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
Markus Wanner wrote:
> The "new branches getting merged up" could work. That is, applying the
> fix to the oldest back-branch which requires the fix first and then
> merge it to all newer ones, including HEAD. However, that would require
> some rethinking: instead of creating bugfix-patches for HEAD, then
> manually adjust patches for back-branches and then group committing,
> you'd have to create a bugfix-patch for the oldest branch first, commit
> that and then merge that to the newer branches.
That sounds a bit dangerous too, since I imagine there are some
changes in the old release branches you wouldn't want merged into
the newest releases (say, code affecting sections that got redesigned).
Seems you'd want to do is create a new branch as close to the point
where the bug was introduced - and then merge that forward into each
of the branches. This concept was mentioned in a page linked earlier
in the thread[1] and seems like the way monotone recommends people
use their system[2]. See that page for more reasons why they think
it's good.
[1]http://archives.postgresql.org/pgsql-hackers/2009-06/msg00153.php
[2]http://www.monotone.ca/wiki/DaggyFixes/
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 15:34 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 16:07 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 16:17 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-03 11:10 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-03 12:08 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 12:19 ` Re: PostgreSQL Developer meeting minutes up Andres Freund <andres@anarazel.de>
2009-06-03 14:01 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 14:20 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-04 09:46 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-04 21:20 ` Re: PostgreSQL Developer meeting minutes up Ron Mayer <rm_pg@cheapcomplexdevices.com>
@ 2009-06-05 07:05 ` Markus Wanner <markus@bluegap.ch>
2009-06-05 13:38 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 538+ messages in thread
From: Markus Wanner @ 2009-06-05 07:05 UTC (permalink / raw)
To: Ron Mayer <rm_pg@cheapcomplexdevices.com>; +Cc: Marko Kreen <markokr@gmail.com>; Greg Stark <stark@enterprisedb.com>; Andres Freund <andres@anarazel.de>; Aidan Van Dyk <aidan@highrise.ca>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
Hi,
Quoting "Ron Mayer" <rm_pg@cheapcomplexdevices.com>:
> Seems you'd want to do is create a new branch as close to the point
> where the bug was introduced - and then merge that forward into each
> of the branches.
Thank you for pointing this out. As a fan of monotone I certainly know
and like that way. However, for people who are used to CVS, lots of
branching and merging quickly sound dangerous and messy. So I'd like
to keep things as simple as possible while still keeping possibilities
open for the future.
Note that a requirement for daggy fixes is that "the bug is fixed
close to the point where it was introduced". So fixing it on the
oldest stable branch that introduced a bug instead of fixing it on
HEAD and then back-porting would certainly be a step into the right
direction. And I think it would be sufficient in most cases. If not,
we can still enhance that and used daggy fixes later on (as long as we
have a conversion that allows merging, that is).
Regards
Markus Wanner
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 15:34 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 16:07 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 16:17 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-03 11:10 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-03 12:08 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 12:19 ` Re: PostgreSQL Developer meeting minutes up Andres Freund <andres@anarazel.de>
2009-06-03 14:01 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 14:20 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-04 09:46 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-04 21:20 ` Re: PostgreSQL Developer meeting minutes up Ron Mayer <rm_pg@cheapcomplexdevices.com>
2009-06-05 07:05 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
@ 2009-06-05 13:38 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-06-05 13:51 ` Re: PostgreSQL Developer meeting minutes up Andrew Dunstan <andrew@dunslane.net>
2009-06-05 15:29 ` Re: PostgreSQL Developer meeting minutes up Robert Haas <robertmhaas@gmail.com>
2009-06-06 15:40 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
0 siblings, 3 replies; 538+ messages in thread
From: Tom Lane @ 2009-06-05 13:38 UTC (permalink / raw)
To: Markus Wanner <markus@bluegap.ch>; +Cc: Ron Mayer <rm_pg@cheapcomplexdevices.com>; Marko Kreen <markokr@gmail.com>; Greg Stark <stark@enterprisedb.com>; Andres Freund <andres@anarazel.de>; Aidan Van Dyk <aidan@highrise.ca>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
"Markus Wanner" <markus@bluegap.ch> writes:
> Note that a requirement for daggy fixes is that "the bug is fixed
> close to the point where it was introduced". So fixing it on the
> oldest stable branch that introduced a bug instead of fixing it on
> HEAD and then back-porting would certainly be a step into the right
> direction.
I think it's already been made crystal clear that the people who
actually do this work don't do it that way, and are uninterested in
allowing their tools to force them to do it that way. Patching from
HEAD back works better for us for a number of reasons, the main one
being that HEAD is the version of the code that's most "swapped into"
our awareness.
However, so long as we can have a separate working copy per branch,
I see no problem with preparing all the versions of a patch and then
committing them back-to-front. What I'm not clear about is the
mechanics for doing that. Would someone explain exactly what the
steps should be to produce the nicest-looking git history?
regards, tom lane
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 15:34 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 16:07 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 16:17 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-03 11:10 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-03 12:08 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 12:19 ` Re: PostgreSQL Developer meeting minutes up Andres Freund <andres@anarazel.de>
2009-06-03 14:01 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 14:20 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-04 09:46 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-04 21:20 ` Re: PostgreSQL Developer meeting minutes up Ron Mayer <rm_pg@cheapcomplexdevices.com>
2009-06-05 07:05 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-05 13:38 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
@ 2009-06-05 13:51 ` Andrew Dunstan <andrew@dunslane.net>
2009-06-05 18:28 ` Re: PostgreSQL Developer meeting minutes up Aidan Van Dyk <aidan@highrise.ca>
2009-06-06 15:41 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2 siblings, 2 replies; 538+ messages in thread
From: Andrew Dunstan @ 2009-06-05 13:51 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Markus Wanner <markus@bluegap.ch>; Ron Mayer <rm_pg@cheapcomplexdevices.com>; Marko Kreen <markokr@gmail.com>; Greg Stark <stark@enterprisedb.com>; Andres Freund <andres@anarazel.de>; Aidan Van Dyk <aidan@highrise.ca>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers
Tom Lane wrote:
> "Markus Wanner" <markus@bluegap.ch> writes:
>
>> Note that a requirement for daggy fixes is that "the bug is fixed
>> close to the point where it was introduced". So fixing it on the
>> oldest stable branch that introduced a bug instead of fixing it on
>> HEAD and then back-porting would certainly be a step into the right
>> direction.
>>
>
> I think it's already been made crystal clear that the people who
> actually do this work don't do it that way, and are uninterested in
> allowing their tools to force them to do it that way. Patching from
> HEAD back works better for us for a number of reasons, the main one
> being that HEAD is the version of the code that's most "swapped into"
> our awareness.
>
Yeah, a requirement to work from the back branch forward is quite
unacceptable IMNSHO. It's also quite unreasonable. The tool is there to
help, not to force an unnatural work pattern on us.
cheers
andrew
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 15:34 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 16:07 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 16:17 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-03 11:10 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-03 12:08 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 12:19 ` Re: PostgreSQL Developer meeting minutes up Andres Freund <andres@anarazel.de>
2009-06-03 14:01 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 14:20 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-04 09:46 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-04 21:20 ` Re: PostgreSQL Developer meeting minutes up Ron Mayer <rm_pg@cheapcomplexdevices.com>
2009-06-05 07:05 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-05 13:38 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
2009-06-05 13:51 ` Re: PostgreSQL Developer meeting minutes up Andrew Dunstan <andrew@dunslane.net>
@ 2009-06-05 18:28 ` Aidan Van Dyk <aidan@highrise.ca>
2009-06-05 18:41 ` Re: PostgreSQL Developer meeting minutes up Andrew Dunstan <andrew@dunslane.net>
1 sibling, 1 reply; 538+ messages in thread
From: Aidan Van Dyk @ 2009-06-05 18:28 UTC (permalink / raw)
To: Andrew Dunstan <andrew@dunslane.net>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers
* Andrew Dunstan <andrew@dunslane.net> [090605 13:55]:
> Yeah, a requirement to work from the back branch forward is quite
> unacceptable IMNSHO. It's also quite unreasonable. The tool is there to
> help, not to force an unnatural work pattern on us.
Again, just to make it clear, git isn't going to *force* anyone to
drastically change their workflow. For people who want to keep a
separate "working directory" per branch, and just work on them as
independently as they do with CVS, *nothing* is going to have to change,
except the possible "git push" step required to actually publish your
committed changes... But, if you want, you could just also have a
post-commit hook that will do that push for you too, and you just don't
commit until you're sure (a-la-cvs-style):
cvs update === git stash save && git pull && git stash apply
cvs commit === git commit -a && git push
The "git stash" is because git won't pull/merge remote work into a
"dirty" workdir... This is the classic conflict CVS mess that git avoids,
and then allows you to use all it's powerful merge machinery to "merge"
any of your stashed local changes back into what you've just pulled.
But....
I have a feeling that as people (specifically the comitters) get slowly
introduced and exposed to some of the more advanced things git lets you
do, and as you get comfortable with using it, people will *want* to
start altering how they do thing, simply because they start to find out
that git really allows them to do what they really want, rather than
what they have "thought they want" because they've been so brainwashed
by CVS...
;-)
--
Aidan Van Dyk Create like a god,
aidan@highrise.ca command like a king,
http://www.highrise.ca/ work like a slave.
Attachments:
[application/pgp-signature] signature.asc (189B, ../../20090605182822.GC10839@yugib.highrise.ca/2-signature.asc)
download
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 15:34 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 16:07 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 16:17 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-03 11:10 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-03 12:08 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 12:19 ` Re: PostgreSQL Developer meeting minutes up Andres Freund <andres@anarazel.de>
2009-06-03 14:01 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 14:20 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-04 09:46 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-04 21:20 ` Re: PostgreSQL Developer meeting minutes up Ron Mayer <rm_pg@cheapcomplexdevices.com>
2009-06-05 07:05 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-05 13:38 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
2009-06-05 13:51 ` Re: PostgreSQL Developer meeting minutes up Andrew Dunstan <andrew@dunslane.net>
2009-06-05 18:28 ` Re: PostgreSQL Developer meeting minutes up Aidan Van Dyk <aidan@highrise.ca>
@ 2009-06-05 18:41 ` Andrew Dunstan <andrew@dunslane.net>
2009-06-05 19:33 ` Re: PostgreSQL Developer meeting minutes up Aidan Van Dyk <aidan@highrise.ca>
0 siblings, 1 reply; 538+ messages in thread
From: Andrew Dunstan @ 2009-06-05 18:41 UTC (permalink / raw)
To: Aidan Van Dyk <aidan@highrise.ca>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers
Aidan Van Dyk wrote:
> * Andrew Dunstan <andrew@dunslane.net> [090605 13:55]:
>
>
>> Yeah, a requirement to work from the back branch forward is quite
>> unacceptable IMNSHO. It's also quite unreasonable. The tool is there to
>> help, not to force an unnatural work pattern on us.
>>
>
> Again, just to make it clear, git isn't going to *force* anyone to
> drastically change their workflow.
My reaction was against someone saying in effect "don't work that way,
work this way".
So make your argument to that person ;-)
[...]
> I have a feeling that as people (specifically the comitters) get slowly
> introduced and exposed to some of the more advanced things git lets you
> do, and as you get comfortable with using it, people will *want* to
> start altering how they do thing, simply because they start to find out
> that git really allows them to do what they really want, rather than
> what they have "thought they want" because they've been so brainwashed
> by CVS...
>
>
>
The whole point is that we want something better *that suits our work
patterns*. Almost all the backpatching that gets done is by the
committers. So we have a bunch of concerns that are not relevant to that
vast majority of developers. In particular, it would be nice to be able
to make a bunch of changes on different branches and then commit it all
in one hit. If that's possible, then well and good. If it's not, that's
a pity.
cheers
andrew
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 15:34 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 16:07 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 16:17 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-03 11:10 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-03 12:08 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 12:19 ` Re: PostgreSQL Developer meeting minutes up Andres Freund <andres@anarazel.de>
2009-06-03 14:01 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 14:20 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-04 09:46 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-04 21:20 ` Re: PostgreSQL Developer meeting minutes up Ron Mayer <rm_pg@cheapcomplexdevices.com>
2009-06-05 07:05 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-05 13:38 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
2009-06-05 13:51 ` Re: PostgreSQL Developer meeting minutes up Andrew Dunstan <andrew@dunslane.net>
2009-06-05 18:28 ` Re: PostgreSQL Developer meeting minutes up Aidan Van Dyk <aidan@highrise.ca>
2009-06-05 18:41 ` Re: PostgreSQL Developer meeting minutes up Andrew Dunstan <andrew@dunslane.net>
@ 2009-06-05 19:33 ` Aidan Van Dyk <aidan@highrise.ca>
0 siblings, 0 replies; 538+ messages in thread
From: Aidan Van Dyk @ 2009-06-05 19:33 UTC (permalink / raw)
To: pgsql-hackers; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Andrew Dunstan <andrew@dunslane.net>; Magnus Hagander <magnus@hagander.net>
* Andrew Dunstan <andrew@dunslane.net> [090605 14:41]:
> The whole point is that we want something better *that suits our work
> patterns*. Almost all the backpatching that gets done is by the
> committers. So we have a bunch of concerns that are not relevant to that
> vast majority of developers. In particular, it would be nice to be able
> to make a bunch of changes on different branches and then commit it all
> in one hit. If that's possible, then well and good. If it's not, that's
> a pity.
My only concern is that I am seeing 2 requirements emerge:
1) Everything has to work as it currently does with CVS
2) We want better information about how patches relate for possible
future stuff
Unfortunately, those 2 requirements are conflicting... If you (not
anyone personally, but the more general "PostgreSQL committer") want the
repository to properly track the "fixes" and show their relationship,
and extra through all the branches than you really do want the
"branch-to-fix" and merge the fix forward into all your STABLE/master
branches, like the "daggy" type thing mentioned elsewhere... But
notice, that is *very* different from the current work patterns based on
the CVS model where everything is completely independent (save the
commit message), and it's a huge change to the way developers work.
If you want to stay with the current CVS style, then you aren't going to
get any closer than "commit messages matching" (or possibly a reference
to another commit as an extra line) that we currently have with CVS.
My suggestion is to keep it simple. Just work independently, like you
currently do. You don't want every committer to have to completely
learn the advanced features of a new tool just to use it... You can use
it as you use the less feature-full tool as you learn all the
features...
But as people start to use the new tool, and start to use it's more
advanced features, then it's natural that their results will start to be
reflected the main repository.
But insisting that people currently comfortable and proficient in the
current work patterns *have* to learn completely new ones for a
"flag-day" type switch and start using them immediately is going to:
* Piss them off
* Create great ill-will against the tool
And neither of those will be the fault of the tool itself, but of the
way a "new process" was forced in conjunction with a new tool...
I don't want to see the PG project trying to *force* a radical change in
the way the development/branches currently work at the same time as a
switch to git. Replace the tool, and allow the current processes and
work-flows to gradually improve. The process and work-flow improvements
will be an iterative and collaborative process, just like the actual
code improvements, where huge radical patches are generally frowned
upon.
I've used git for a long time, on many different projects. I do know
how radically it *can* change the process, and how much more efficient
and "natural" the improved processes can be. But the change is not an
overnight change. And it's not going to happen unless the people
needing to change *see* it's benefits. And that's going to take time
and experience with the new tool...
Anyways, I said previously that I was over with this thread, but now I
mean it ;-) If someone want specific git information or help, I'm
available.
a.
--
Aidan Van Dyk Create like a god,
aidan@highrise.ca command like a king,
http://www.highrise.ca/ work like a slave.
Attachments:
[application/pgp-signature] signature.asc (189B, ../../20090605193331.GD10839@yugib.highrise.ca/2-signature.asc)
download
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 15:34 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 16:07 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 16:17 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-03 11:10 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-03 12:08 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 12:19 ` Re: PostgreSQL Developer meeting minutes up Andres Freund <andres@anarazel.de>
2009-06-03 14:01 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 14:20 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-04 09:46 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-04 21:20 ` Re: PostgreSQL Developer meeting minutes up Ron Mayer <rm_pg@cheapcomplexdevices.com>
2009-06-05 07:05 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-05 13:38 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
2009-06-05 13:51 ` Re: PostgreSQL Developer meeting minutes up Andrew Dunstan <andrew@dunslane.net>
@ 2009-06-06 15:41 ` Markus Wanner <markus@bluegap.ch>
2009-06-06 16:42 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
2009-06-06 16:56 ` Re: PostgreSQL Developer meeting minutes up Andrew Dunstan <andrew@dunslane.net>
1 sibling, 2 replies; 538+ messages in thread
From: Markus Wanner @ 2009-06-06 15:41 UTC (permalink / raw)
To: Andrew Dunstan <andrew@dunslane.net>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Ron Mayer <rm_pg@cheapcomplexdevices.com>; Marko Kreen <markokr@gmail.com>; Greg Stark <stark@enterprisedb.com>; Andres Freund <andres@anarazel.de>; Aidan Van Dyk <aidan@highrise.ca>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers
Hi,
Andrew Dunstan wrote:
> Yeah, a requirement to work from the back branch forward is quite
> unacceptable IMNSHO. It's also quite unreasonable.
The monotone page about daggy fixes does quite a good job in explaining
why it is helpful. I think it's how to make best use of these tools. And
it's obviously not the same as what worked well in practice with CVS.
Out of interest, and not necessarily related to Postgres: why do you
think it's unreasonable? Fixing the problem where it was introduced
sounds like the most reasonable place to fix it, IMO.
Regards
Markus Wanner
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 15:34 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 16:07 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 16:17 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-03 11:10 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-03 12:08 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 12:19 ` Re: PostgreSQL Developer meeting minutes up Andres Freund <andres@anarazel.de>
2009-06-03 14:01 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 14:20 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-04 09:46 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-04 21:20 ` Re: PostgreSQL Developer meeting minutes up Ron Mayer <rm_pg@cheapcomplexdevices.com>
2009-06-05 07:05 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-05 13:38 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
2009-06-05 13:51 ` Re: PostgreSQL Developer meeting minutes up Andrew Dunstan <andrew@dunslane.net>
2009-06-06 15:41 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
@ 2009-06-06 16:42 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-06-06 20:30 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-13 16:13 ` Re: PostgreSQL Developer meeting minutes up kris@shannon.id.au
1 sibling, 2 replies; 538+ messages in thread
From: Tom Lane @ 2009-06-06 16:42 UTC (permalink / raw)
To: Markus Wanner <markus@bluegap.ch>; +Cc: Andrew Dunstan <andrew@dunslane.net>; Ron Mayer <rm_pg@cheapcomplexdevices.com>; Marko Kreen <markokr@gmail.com>; Greg Stark <stark@enterprisedb.com>; Andres Freund <andres@anarazel.de>; Aidan Van Dyk <aidan@highrise.ca>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers
Markus Wanner <markus@bluegap.ch> writes:
> Out of interest, and not necessarily related to Postgres: why do you
> think it's unreasonable? Fixing the problem where it was introduced
> sounds like the most reasonable place to fix it, IMO.
There are a number of possible reasons, but here are a few that hold for me:
* I always prefer to isolate a bug in HEAD if possible. It's the
version of the code that's most familiar at the moment, and there are
often new features available that make it easier to test a problem.
So that generally leads to formulating the fix in terms of the HEAD code
first. After that you start to think about whether (some form of) the
bug exists in back branches and how to fix those branches.
* Experience has shown that later branches tend to have more places
affected by an issue than older ones; eg you might need to touch four
places to fix a bug now, but only three of those places exist in the
older branches. ISTM you'd be far more likely to miss fixing the
fourth place if you do your initial investigation and fixing/testing
in the oldest affected branch.
* We want HEAD to have the cleanest, most maintainable version of the
fix. It's not infrequently the case that the most natural way of fixing
a problem varies across branches --- for instance, there might be a
helpful subroutine available in later branches. If you design the fix
in terms of what works in the oldest branch that has the problem,
you're more likely to come up with something that's suboptimal for later
branches. For instance in the helpful-subroutine case, I'd be more
likely to decide to back-port the subroutine along with the fix if
I work from HEAD back than if I try to work the other way.
* We are often willing to adopt a fairly invasive fix for HEAD, if
that's what's needed to have a clean maintainable solution, and then
look for a less invasive but klugy solution for the back branches.
Approaching it the other way around would strongly encourage use of
the kluge solution as a permanent fix.
So there are a lot of good reasons to work backwards in patching.
I don't believe that these would be outweighed by some advantage
in the mechanics of applying an unchanging patch to multiple
branches (especially since AFAICT the mechanical advantage would
be pretty darn minimal anyhow).
regards, tom lane
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 15:34 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 16:07 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 16:17 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-03 11:10 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-03 12:08 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 12:19 ` Re: PostgreSQL Developer meeting minutes up Andres Freund <andres@anarazel.de>
2009-06-03 14:01 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 14:20 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-04 09:46 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-04 21:20 ` Re: PostgreSQL Developer meeting minutes up Ron Mayer <rm_pg@cheapcomplexdevices.com>
2009-06-05 07:05 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-05 13:38 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
2009-06-05 13:51 ` Re: PostgreSQL Developer meeting minutes up Andrew Dunstan <andrew@dunslane.net>
2009-06-06 15:41 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-06 16:42 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
@ 2009-06-06 20:30 ` Markus Wanner <markus@bluegap.ch>
1 sibling, 0 replies; 538+ messages in thread
From: Markus Wanner @ 2009-06-06 20:30 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Andrew Dunstan <andrew@dunslane.net>; Ron Mayer <rm_pg@cheapcomplexdevices.com>; Marko Kreen <markokr@gmail.com>; Greg Stark <stark@enterprisedb.com>; Andres Freund <andres@anarazel.de>; Aidan Van Dyk <aidan@highrise.ca>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers
Hi,
Tom Lane wrote:
> There are a number of possible reasons, but here are a few that hold for me:
Thank you for this very good collection. I'm still wondering about
what's the best way to represent this in git (or others). Cherry-picking
is arguably the simplest variant. Maybe that can be combined with
merging to preserve merge capability. I'll try that...
> So there are a lot of good reasons to work backwards in patching.
Agreed and understood. However, there are good reasons for keeping merge
capability between branches intact as well. I still hope we can get both
somehow, if not, I'm certainly accepting that backward patching is more
important.
Regards
Markus Wanner
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 15:34 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 16:07 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 16:17 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-03 11:10 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-03 12:08 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 12:19 ` Re: PostgreSQL Developer meeting minutes up Andres Freund <andres@anarazel.de>
2009-06-03 14:01 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 14:20 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-04 09:46 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-04 21:20 ` Re: PostgreSQL Developer meeting minutes up Ron Mayer <rm_pg@cheapcomplexdevices.com>
2009-06-05 07:05 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-05 13:38 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
2009-06-05 13:51 ` Re: PostgreSQL Developer meeting minutes up Andrew Dunstan <andrew@dunslane.net>
2009-06-06 15:41 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-06 16:42 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
@ 2009-06-13 16:13 ` kris@shannon.id.au
1 sibling, 0 replies; 538+ messages in thread
From: kris@shannon.id.au @ 2009-06-13 16:13 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Markus Wanner <markus@bluegap.ch>; Andrew Dunstan <andrew@dunslane.net>; Ron Mayer <rm_pg@cheapcomplexdevices.com>; Marko Kreen <markokr@gmail.com>; Greg Stark <stark@enterprisedb.com>; Andres Freund <andres@anarazel.de>; Aidan Van Dyk <aidan@highrise.ca>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers
2009/6/7 Tom Lane <tgl@sss.pgh.pa.us>:
> So there are a lot of good reasons to work backwards in patching.
> I don't believe that these would be outweighed by some advantage
> in the mechanics of applying an unchanging patch to multiple
> branches (especially since AFAICT the mechanical advantage would
> be pretty darn minimal anyhow).
As another data point, the stable branches of the linux kernel are
actually maintained this way. There is a policy that any patch for the
stable branches must have already be included (in some form) in HEAD.
There is no merging going on. They aren't even using git cherry-pick, but
that's because all backpatching goes into a review list rather than happening
immediately.
The multiple branches and merging that is going on in the linux kernel
is all about development of new features, not fixing of bugs.
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 15:34 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 16:07 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 16:17 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-03 11:10 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-03 12:08 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 12:19 ` Re: PostgreSQL Developer meeting minutes up Andres Freund <andres@anarazel.de>
2009-06-03 14:01 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 14:20 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-04 09:46 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-04 21:20 ` Re: PostgreSQL Developer meeting minutes up Ron Mayer <rm_pg@cheapcomplexdevices.com>
2009-06-05 07:05 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-05 13:38 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
2009-06-05 13:51 ` Re: PostgreSQL Developer meeting minutes up Andrew Dunstan <andrew@dunslane.net>
2009-06-06 15:41 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
@ 2009-06-06 16:56 ` Andrew Dunstan <andrew@dunslane.net>
2009-06-06 17:22 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
2009-06-06 20:56 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
1 sibling, 2 replies; 538+ messages in thread
From: Andrew Dunstan @ 2009-06-06 16:56 UTC (permalink / raw)
To: Markus Wanner <markus@bluegap.ch>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Ron Mayer <rm_pg@cheapcomplexdevices.com>; Marko Kreen <markokr@gmail.com>; Greg Stark <stark@enterprisedb.com>; Andres Freund <andres@anarazel.de>; Aidan Van Dyk <aidan@highrise.ca>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers
Markus Wanner wrote:
> Hi,
>
> Andrew Dunstan wrote:
>
>> Yeah, a requirement to work from the back branch forward is quite
>> unacceptable IMNSHO. It's also quite unreasonable.
>>
>
> The monotone page about daggy fixes does quite a good job in explaining
> why it is helpful. I think it's how to make best use of these tools. And
> it's obviously not the same as what worked well in practice with CVS.
> Out of interest, and not necessarily related to Postgres: why do you
> think it's unreasonable? Fixing the problem where it was introduced
> sounds like the most reasonable place to fix it, IMO.
>
>
>
Half the trouble with this discussion is that it has not been related
enough to how the Postgres project actually works IMNSHO.
One fact to keep in mind is that, unlike most other FOSS projects, we
keep quite a large number of branches live. If we don't remove one (and
so far there is no great reason to that I know of) that number will be
seven when we release 8.4. There is a huge benefit from this to the user
community. It means that they can deploy Postgres with confidence that
they will not have to upgrade for quite a few years. In the corporate
world, especially, that is a major issue. I occasionally have clients
running 7.4 or even older versions. Anyway, the large number of branches
alone means that our patterns are unlikely to match those of other
projects.
The question we often face in backpatching is not "where did it first
occur?" but "how far back should we patch it?". Problems are almost
always discovered near the top of the version list, overwhelmingly on
the HEAD or most recent stable branches. So the way we work is not to
try to develop a fix where the problem first occurred (which might not
even be on a supported branch at all) but as high up the list as the
problem goes (usually HEAD) and then work out how far down the list to
apply the fix. And the notion that a fix of any complexity at all is
going to be simply applicable across six or seven branches simply defies
our experience. It almost never does. Frequently it won't apply cleanly
from *any* one branch to another. Even fairly trivial patches can suffer
from this: the pretty small plperl fixes I applied yesterday and the day
before, required adjustment going from one branch to the previous one in
about three out of five back branch cases. Sometimes these adjustments
are small, sometimes they are quite large. So the idea that we can just
create a fix on say, the 7.4 branch, and then just merge it forward
nicely, is just fanciful in most cases, as well as being contrary to our
methods of work.
Most of this stuff is almost invisible to most of the community. But
people like Tom work with it every day. And we want to keep Tom
productive, right? ;-)
cheers
andrew
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 15:34 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 16:07 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 16:17 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-03 11:10 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-03 12:08 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 12:19 ` Re: PostgreSQL Developer meeting minutes up Andres Freund <andres@anarazel.de>
2009-06-03 14:01 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 14:20 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-04 09:46 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-04 21:20 ` Re: PostgreSQL Developer meeting minutes up Ron Mayer <rm_pg@cheapcomplexdevices.com>
2009-06-05 07:05 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-05 13:38 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
2009-06-05 13:51 ` Re: PostgreSQL Developer meeting minutes up Andrew Dunstan <andrew@dunslane.net>
2009-06-06 15:41 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-06 16:56 ` Re: PostgreSQL Developer meeting minutes up Andrew Dunstan <andrew@dunslane.net>
@ 2009-06-06 17:22 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-06-06 17:55 ` Re: PostgreSQL Developer meeting minutes up Mark Mielke <mark@mark.mielke.cc>
2009-06-06 23:03 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
1 sibling, 2 replies; 538+ messages in thread
From: Tom Lane @ 2009-06-06 17:22 UTC (permalink / raw)
To: Andrew Dunstan <andrew@dunslane.net>; +Cc: Markus Wanner <markus@bluegap.ch>; Ron Mayer <rm_pg@cheapcomplexdevices.com>; Marko Kreen <markokr@gmail.com>; Greg Stark <stark@enterprisedb.com>; Andres Freund <andres@anarazel.de>; Aidan Van Dyk <aidan@highrise.ca>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
> [ most of a good summary omitted ]
> ... Even fairly trivial patches can suffer
> from this: the pretty small plperl fixes I applied yesterday and the day
> before, required adjustment going from one branch to the previous one in
> about three out of five back branch cases. Sometimes these adjustments
> are small, sometimes they are quite large. So the idea that we can just
> create a fix on say, the 7.4 branch, and then just merge it forward
> nicely, is just fanciful in most cases, as well as being contrary to our
> methods of work.
I have heard it claimed that git is more intelligent than plain
diff/patch and could successfully merge patches in cases that currently
require manual adjustment of the sort Andrew describes. If that's
really true to any significant extent, then it could represent a benefit
large enough to persuade us to alter work flows (at least for simple
patches that don't require significant rethinking across branches).
However, I have yet to see any actual *evidence* in support of this
claim. How robust is git about dealing with whitespace changes,
nearby variable renamings, and such?
Andrew's plperl patches would be an excellent small test case. Anybody
want to try them against the experimental git repository and see if git
does any better than plain patch?
regards, tom lane
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 15:34 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 16:07 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 16:17 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-03 11:10 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-03 12:08 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 12:19 ` Re: PostgreSQL Developer meeting minutes up Andres Freund <andres@anarazel.de>
2009-06-03 14:01 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 14:20 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-04 09:46 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-04 21:20 ` Re: PostgreSQL Developer meeting minutes up Ron Mayer <rm_pg@cheapcomplexdevices.com>
2009-06-05 07:05 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-05 13:38 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
2009-06-05 13:51 ` Re: PostgreSQL Developer meeting minutes up Andrew Dunstan <andrew@dunslane.net>
2009-06-06 15:41 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-06 16:56 ` Re: PostgreSQL Developer meeting minutes up Andrew Dunstan <andrew@dunslane.net>
2009-06-06 17:22 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
@ 2009-06-06 17:55 ` Mark Mielke <mark@mark.mielke.cc>
2009-06-06 17:59 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 1 reply; 538+ messages in thread
From: Mark Mielke @ 2009-06-06 17:55 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Andrew Dunstan <andrew@dunslane.net>; Markus Wanner <markus@bluegap.ch>; Ron Mayer <rm_pg@cheapcomplexdevices.com>; Marko Kreen <markokr@gmail.com>; Greg Stark <stark@enterprisedb.com>; Andres Freund <andres@anarazel.de>; Aidan Van Dyk <aidan@highrise.ca>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers
Tom Lane wrote:
> I have heard it claimed that git is more intelligent than plain
> diff/patch and could successfully merge patches in cases that currently
> require manual adjustment of the sort Andrew describes. If that's
> really true to any significant extent, then it could represent a benefit
> large enough to persuade us to alter work flows (at least for simple
> patches that don't require significant rethinking across branches).
> However, I have yet to see any actual *evidence* in support of this
> claim. How robust is git about dealing with whitespace changes,
> nearby variable renamings, and such?
>
> Andrew's plperl patches would be an excellent small test case. Anybody
> want to try them against the experimental git repository and see if git
> does any better than plain patch
Any revision control system should be able to do better than diff/patch
as these systems have more information available to them. Normal GIT
uses the relatively common 3-way merge based upon the most recent common
ancestor algorithm. Assuming there is a most recent common ancestor that
isn't "file creation", it will have a better chance of doing the right
thing.
Systems such as ClearCase have had these capabilities for a long time.
The difference with distributed version control systems is that they
absolutely must work well, as every user has their own repository, and
every repository represents a branch, therefore each user of the system
is working on a different branch. The need for reliable merges goes up
under a distributed version control system.
Not to say GIT is truly best-in-class here, but it definitely has
motivation to be and benefit of being better than diff/patch.
These sorts of tools usually work with another tool such as kdiff3 to
allow for only the conflicts the be resolved. If you set it up properly,
you can have the automatic merges completely successful, and kdiff3 or
similar can present you a graphical interface that allow you to identify
and resolve the conflicts that require help. I've used these sorts of
tools long enough to completely take them for granted now, and it feels
painful to go back to anything more primitive.
Cheers,
mark
--
Mark Mielke <mark@mielke.cc>
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 15:34 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 16:07 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 16:17 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-03 11:10 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-03 12:08 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 12:19 ` Re: PostgreSQL Developer meeting minutes up Andres Freund <andres@anarazel.de>
2009-06-03 14:01 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 14:20 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-04 09:46 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-04 21:20 ` Re: PostgreSQL Developer meeting minutes up Ron Mayer <rm_pg@cheapcomplexdevices.com>
2009-06-05 07:05 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-05 13:38 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
2009-06-05 13:51 ` Re: PostgreSQL Developer meeting minutes up Andrew Dunstan <andrew@dunslane.net>
2009-06-06 15:41 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-06 16:56 ` Re: PostgreSQL Developer meeting minutes up Andrew Dunstan <andrew@dunslane.net>
2009-06-06 17:22 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
2009-06-06 17:55 ` Re: PostgreSQL Developer meeting minutes up Mark Mielke <mark@mark.mielke.cc>
@ 2009-06-06 17:59 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-06-06 20:05 ` Re: PostgreSQL Developer meeting minutes up Andrew Dunstan <andrew@dunslane.net>
2009-06-07 01:20 ` Re: PostgreSQL Developer meeting minutes up Mark Mielke <mark@mark.mielke.cc>
0 siblings, 2 replies; 538+ messages in thread
From: Tom Lane @ 2009-06-06 17:59 UTC (permalink / raw)
To: Mark Mielke <mark@mark.mielke.cc>; +Cc: Andrew Dunstan <andrew@dunslane.net>; Markus Wanner <markus@bluegap.ch>; Ron Mayer <rm_pg@cheapcomplexdevices.com>; Marko Kreen <markokr@gmail.com>; Greg Stark <stark@enterprisedb.com>; Andres Freund <andres@anarazel.de>; Aidan Van Dyk <aidan@highrise.ca>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers
Mark Mielke <mark@mark.mielke.cc> writes:
> Tom Lane wrote:
>> I have heard it claimed that git is more intelligent than plain
>> diff/patch and could successfully merge patches in cases that currently
>> require manual adjustment of the sort Andrew describes.
>> ...
>> However, I have yet to see any actual *evidence* in support of this
>> claim.
> Any revision control system should be able to do better than diff/patch
> as these systems have more information available to them. Normal GIT
> uses the relatively common 3-way merge based upon the most recent common
> ancestor algorithm. Assuming there is a most recent common ancestor that
> isn't "file creation", it will have a better chance of doing the right
> thing.
And I still haven't seen any actual evidence. Could we have fewer
undocumented assertions and more experimental evidence? Take Andrew's
plperl patches and see if git does any better with them than plain patch
does. (If it's not successful with that patch, it's pointless to try it
on any bigger cases, I fear.)
regards, tom lane
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 15:34 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 16:07 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 16:17 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-03 11:10 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-03 12:08 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 12:19 ` Re: PostgreSQL Developer meeting minutes up Andres Freund <andres@anarazel.de>
2009-06-03 14:01 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 14:20 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-04 09:46 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-04 21:20 ` Re: PostgreSQL Developer meeting minutes up Ron Mayer <rm_pg@cheapcomplexdevices.com>
2009-06-05 07:05 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-05 13:38 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
2009-06-05 13:51 ` Re: PostgreSQL Developer meeting minutes up Andrew Dunstan <andrew@dunslane.net>
2009-06-06 15:41 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-06 16:56 ` Re: PostgreSQL Developer meeting minutes up Andrew Dunstan <andrew@dunslane.net>
2009-06-06 17:22 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
2009-06-06 17:55 ` Re: PostgreSQL Developer meeting minutes up Mark Mielke <mark@mark.mielke.cc>
2009-06-06 17:59 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
@ 2009-06-06 20:05 ` Andrew Dunstan <andrew@dunslane.net>
1 sibling, 0 replies; 538+ messages in thread
From: Andrew Dunstan @ 2009-06-06 20:05 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Mark Mielke <mark@mark.mielke.cc>; Markus Wanner <markus@bluegap.ch>; Ron Mayer <rm_pg@cheapcomplexdevices.com>; Marko Kreen <markokr@gmail.com>; Greg Stark <stark@enterprisedb.com>; Andres Freund <andres@anarazel.de>; Aidan Van Dyk <aidan@highrise.ca>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers
Tom Lane wrote:
>> Any revision control system should be able to do better than diff/patch
>> as these systems have more information available to them. Normal GIT
>> uses the relatively common 3-way merge based upon the most recent common
>> ancestor algorithm. Assuming there is a most recent common ancestor that
>> isn't "file creation", it will have a better chance of doing the right
>> thing.
>>
>
> And I still haven't seen any actual evidence. Could we have fewer
> undocumented assertions and more experimental evidence? Take Andrew's
> plperl patches and see if git does any better with them than plain patch
> does. (If it's not successful with that patch, it's pointless to try it
> on any bigger cases, I fear.)
>
>
>
The plperl stuff is actually a tough case. In 7.4 we didn't have
provision for two interpreters, so PERL_SYS_INIT3 is called
unconditionally, and we didn't have a Windows port either, so the
comment is also different.
I guess that in itself illustrates the problems.
I also entirely agree with your point about us being more kludgey and
less invasive on back branches.
cheers
andrew
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 15:34 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 16:07 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 16:17 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-03 11:10 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-03 12:08 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 12:19 ` Re: PostgreSQL Developer meeting minutes up Andres Freund <andres@anarazel.de>
2009-06-03 14:01 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 14:20 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-04 09:46 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-04 21:20 ` Re: PostgreSQL Developer meeting minutes up Ron Mayer <rm_pg@cheapcomplexdevices.com>
2009-06-05 07:05 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-05 13:38 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
2009-06-05 13:51 ` Re: PostgreSQL Developer meeting minutes up Andrew Dunstan <andrew@dunslane.net>
2009-06-06 15:41 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-06 16:56 ` Re: PostgreSQL Developer meeting minutes up Andrew Dunstan <andrew@dunslane.net>
2009-06-06 17:22 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
2009-06-06 17:55 ` Re: PostgreSQL Developer meeting minutes up Mark Mielke <mark@mark.mielke.cc>
2009-06-06 17:59 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
@ 2009-06-07 01:20 ` Mark Mielke <mark@mark.mielke.cc>
2009-06-08 08:45 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-08 12:36 ` Re: PostgreSQL Developer meeting minutes up Mark Mielke <mark@mark.mielke.cc>
1 sibling, 2 replies; 538+ messages in thread
From: Mark Mielke @ 2009-06-07 01:20 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Andrew Dunstan <andrew@dunslane.net>; Markus Wanner <markus@bluegap.ch>; Ron Mayer <rm_pg@cheapcomplexdevices.com>; Marko Kreen <markokr@gmail.com>; Greg Stark <stark@enterprisedb.com>; Andres Freund <andres@anarazel.de>; Aidan Van Dyk <aidan@highrise.ca>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers
Tom Lane wrote:
>> Any revision control system should be able to do better than diff/patch
>> as these systems have more information available to them. Normal GIT
>> uses the relatively common 3-way merge based upon the most recent common
>> ancestor algorithm. Assuming there is a most recent common ancestor that
>> isn't "file creation", it will have a better chance of doing the right
>> thing.
>>
> And I still haven't seen any actual evidence. Could we have fewer
> undocumented assertions and more experimental evidence? Take Andrew's
> plperl patches and see if git does any better with them than plain patch
> does. (If it's not successful with that patch, it's pointless to try it
> on any bigger cases, I fear.)
>
This comes to the theory vs profiling I suppose. I am a theory person -
I run things in my head. To me, the concept of having more context to
make the right decision, and an algorithm that takes advantage of this
context to make the right decision, is simple and compelling on its own.
Knowing the algorithms that are in use, including how it selects the
most recent common ancestor gives me confidence. You have the
capabilities to test things for yourself. If you have any questions, try
it out. No amount of discussions where others say "it works great" and
you say "I don't believe you until you provide me with output" is going
to get anywhere. I could set up a few scenarios or grab actual patches
and show you particular success cases and particular failure cases, but
will you really believe it? Because you shouldn't. For all you know, I
picked the cases I knew would work and put them up against the cases I
knew would fail.
I've used ClearCase for around 10 years now, and with the exception of
"cherry picking", it has very strong and mature merge support. We rely
on merges being safe while managing many projects much larger than
PostgreSQL. Many of the projects have hundreds of users working on them
at the same time. CVS is *unusable* in these environments. Recently,
however, in spite of investments into ClearCase, we are looking at GIT
as providing *stronger* merge capabilities than ClearCase, specifically
with regard to propagating changes from one release to another. I'm not
going to pull up the last ten years of history and make it available to you.
Nothing is going to prove this to you other than trying it out for
yourself. People need to be burned by unreliable merge algorithms before
they respect the value of a reliable merge algorithm. People need to
experience reliable merging before they buy the product.
If the theory doesn't work for you, you really are going to have to try
it out for yourself.
Or not.
It doesn't matter to me. :-)
In any case - you raised the question - I explained how it works - and
you shot me done without any evidence of your own. I explained how it
works. It's up to you to try it out for yourself and decide if you are a
believer.
Cheers,
mark
P.S. I'm only a bit insulted by these threads. There are a lot of
sceptical people in the crowd who until now have raised questions which
only make it clear that these people have not ever worked with a capable
SCM system on a major project before. I really shouldn't hold this
against you, which is why I continue to try and provide the theory and
background, so that when you do give it a chance, it will all start to
make sense. You'll try it out - find it works great - and wonder "how
does it do that?" Then, hopefully you can go back to my post (or the
many others who have tried to help out) and read how it works and say
"ah hah! excellent!"
--
Mark Mielke <mark@mielke.cc>
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 15:34 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 16:07 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 16:17 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-03 11:10 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-03 12:08 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 12:19 ` Re: PostgreSQL Developer meeting minutes up Andres Freund <andres@anarazel.de>
2009-06-03 14:01 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 14:20 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-04 09:46 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-04 21:20 ` Re: PostgreSQL Developer meeting minutes up Ron Mayer <rm_pg@cheapcomplexdevices.com>
2009-06-05 07:05 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-05 13:38 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
2009-06-05 13:51 ` Re: PostgreSQL Developer meeting minutes up Andrew Dunstan <andrew@dunslane.net>
2009-06-06 15:41 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-06 16:56 ` Re: PostgreSQL Developer meeting minutes up Andrew Dunstan <andrew@dunslane.net>
2009-06-06 17:22 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
2009-06-06 17:55 ` Re: PostgreSQL Developer meeting minutes up Mark Mielke <mark@mark.mielke.cc>
2009-06-06 17:59 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
2009-06-07 01:20 ` Re: PostgreSQL Developer meeting minutes up Mark Mielke <mark@mark.mielke.cc>
@ 2009-06-08 08:45 ` Markus Wanner <markus@bluegap.ch>
1 sibling, 0 replies; 538+ messages in thread
From: Markus Wanner @ 2009-06-08 08:45 UTC (permalink / raw)
To: Mark Mielke <mark@mark.mielke.cc>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Andrew Dunstan <andrew@dunslane.net>; Ron Mayer <rm_pg@cheapcomplexdevices.com>; Marko Kreen <markokr@gmail.com>; Greg Stark <stark@enterprisedb.com>; Andres Freund <andres@anarazel.de>; Aidan Van Dyk <aidan@highrise.ca>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers
Hi,
Quoting "Mark Mielke" <mark@mark.mielke.cc>:
> I am a theory person - I run things in my head. To me, the concept
> of having more context to make the right decision, and an algorithm
> that takes advantage of this context to make the right decision, is
> simple and compelling on its own. Knowing the algorithms that are in
> use, including how it selects the most recent common ancestor gives
> me confidence.
Than makes me wondering why you are speaking against merges, where
there are common ancestors. I'd argue that in theory (and generally) a
merge yields better results than cherry-picking (where there is no
common ancestor, thus less information). Especially for back-branches,
where there obviously is a common ancestor.
> No amount of discussions where others say "it works great" and you
> say "I don't believe you until you provide me with output" is going
> to get anywhere.
Well, I guess it can be frustrating for both sides. However, I think
these discussions are worthwhile (and necessary) none the less.
As not even those who highly appreciate merge algorithms (you and me,
for example) are in agreement on how to use them (cherry-picking vs.
merging) it doesn't surprise me that others are generally skeptic.
Regards
Markus Wanner
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 15:34 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 16:07 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 16:17 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-03 11:10 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-03 12:08 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 12:19 ` Re: PostgreSQL Developer meeting minutes up Andres Freund <andres@anarazel.de>
2009-06-03 14:01 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 14:20 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-04 09:46 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-04 21:20 ` Re: PostgreSQL Developer meeting minutes up Ron Mayer <rm_pg@cheapcomplexdevices.com>
2009-06-05 07:05 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-05 13:38 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
2009-06-05 13:51 ` Re: PostgreSQL Developer meeting minutes up Andrew Dunstan <andrew@dunslane.net>
2009-06-06 15:41 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-06 16:56 ` Re: PostgreSQL Developer meeting minutes up Andrew Dunstan <andrew@dunslane.net>
2009-06-06 17:22 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
2009-06-06 17:55 ` Re: PostgreSQL Developer meeting minutes up Mark Mielke <mark@mark.mielke.cc>
2009-06-06 17:59 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
2009-06-07 01:20 ` Re: PostgreSQL Developer meeting minutes up Mark Mielke <mark@mark.mielke.cc>
@ 2009-06-08 12:36 ` Mark Mielke <mark@mark.mielke.cc>
1 sibling, 0 replies; 538+ messages in thread
From: Mark Mielke @ 2009-06-08 12:36 UTC (permalink / raw)
To: Markus Wanner <markus@bluegap.ch>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Andrew Dunstan <andrew@dunslane.net>; Ron Mayer <rm_pg@cheapcomplexdevices.com>; Marko Kreen <markokr@gmail.com>; Greg Stark <stark@enterprisedb.com>; Andres Freund <andres@anarazel.de>; Aidan Van Dyk <aidan@highrise.ca>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers
Markus Wanner wrote:
> Quoting "Mark Mielke" <mark@mark.mielke.cc>:
>> I am a theory person - I run things in my head. To me, the concept of
>> having more context to make the right decision, and an algorithm that
>> takes advantage of this context to make the right decision, is simple
>> and compelling on its own. Knowing the algorithms that are in use,
>> including how it selects the most recent common ancestor gives me
>> confidence.
>
> Than makes me wondering why you are speaking against merges, where
> there are common ancestors. I'd argue that in theory (and generally) a
> merge yields better results than cherry-picking (where there is no
> common ancestor, thus less information). Especially for back-branches,
> where there obviously is a common ancestor.
Nope - definitely not speaking against merges. Automatic merges = best.
Automatic cherry picking = second best if the work flow doesn't allow
for merges. Doing things by hand = bad but sometimes necessary.
Automatic merges or automatic cherry picking with some manual tweaking
(hopefully possible from kdiff3) = necessary at times but still better
than doing things by hand completely. I think you and I are in
agreement. (Even Tom and I are in agreement on many things - I just
didn't respond to his well thought out great posts, like the one that
describes why back patching is often better than forward patching when
having multiple parallel releases open at the same time)
>> No amount of discussions where others say "it works great" and you
>> say "I don't believe you until you provide me with output" is going
>> to get anywhere.
> Well, I guess it can be frustrating for both sides. However, I think
> these discussions are worthwhile (and necessary) none the less.
>
> As not even those who highly appreciate merge algorithms (you and me,
> for example) are in agreement on how to use them (cherry-picking vs.
> merging) it doesn't surprise me that others are generally skeptic.
We're in agreement on the merge algorithms I think. :-)
That said, it is a large domain, and there is room for disagreement even
between those with experience, and you are right that it shouldn't be
surprising that others are generally sceptic.
Cheers,
mark
--
Mark Mielke <mark@mielke.cc>
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 15:34 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 16:07 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 16:17 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-03 11:10 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-03 12:08 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 12:19 ` Re: PostgreSQL Developer meeting minutes up Andres Freund <andres@anarazel.de>
2009-06-03 14:01 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 14:20 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-04 09:46 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-04 21:20 ` Re: PostgreSQL Developer meeting minutes up Ron Mayer <rm_pg@cheapcomplexdevices.com>
2009-06-05 07:05 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-05 13:38 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
2009-06-05 13:51 ` Re: PostgreSQL Developer meeting minutes up Andrew Dunstan <andrew@dunslane.net>
2009-06-06 15:41 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-06 16:56 ` Re: PostgreSQL Developer meeting minutes up Andrew Dunstan <andrew@dunslane.net>
2009-06-06 17:22 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
@ 2009-06-06 23:03 ` Markus Wanner <markus@bluegap.ch>
2009-06-07 07:26 ` Re: PostgreSQL Developer meeting minutes up Nicolas Barbier <nicolas.barbier@gmail.com>
1 sibling, 1 reply; 538+ messages in thread
From: Markus Wanner @ 2009-06-06 23:03 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Andrew Dunstan <andrew@dunslane.net>; Ron Mayer <rm_pg@cheapcomplexdevices.com>; Marko Kreen <markokr@gmail.com>; Greg Stark <stark@enterprisedb.com>; Andres Freund <andres@anarazel.de>; Aidan Van Dyk <aidan@highrise.ca>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers
Hi,
Tom Lane wrote:
> How robust is git about dealing with whitespace changes,
> nearby variable renamings, and such?
Monotone tracks changes line by line. I'm not sure about git. Kdiff3,
which is used to do the manual merge, if necessary, uses some finer
grained method, AFAIK.
However, there's no special whitespace treatment. Nor anything remotely
as clever as "nearby variable renaming". There's no such magic, the
developer still needs to tell the tool what he wants.
However, I'd argue that monotone (as well as git) do an incredible job
at "remembering" these decisions and merges, so you never need to do a
manual merge twice. (Which I remember doing a lot with diff/patch, quilt
or subversion).
> Andrew's plperl patches would be an excellent small test case. Anybody
> want to try them against the experimental git repository and see if git
> does any better than plain patch?
I've given that patch a try under monotone (just because I happen to
know that a lot better). The results should be the same as with git.
I've started with the patch against 7.4 (which I know doesn't resemble
the current workflow, but is sufficient for testing merging
capabilities). Merging that to 8.0 worked without any conflicts.
Although the result then differed from Andrew's work in that the
variable dummy_perl_env is declared after the "#ifdef WIN32" block as
opposed to before in 7.4. The addition in the comment ("notably on
Windows") of course also didn't appear automatically.
It merged from 8.0 to 8.1 without any conflicts, results were equal.
Merging from 8.1 to 8.2 resulted in one merge conflict, because of the
additional condition ('if (interp_state == INTERP_NONE)') that got added
between 8.1 and 8.2.
Merging from 8.2 to 8.3 and then to HEAD as well was conflict free
again. The results differ in whitespace changes exclusively.
So, three out of the five merges would have been equally perfect with
automatic merging, while requiring only one single command, which could
even be scripted, because it remains the same over time, i.e. for
monotone it was something similar to:
mtn propagate REL8_0_STABLE REL8_1_STABLE
Regards
Markus Wanner
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 15:34 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 16:07 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 16:17 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-03 11:10 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-03 12:08 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 12:19 ` Re: PostgreSQL Developer meeting minutes up Andres Freund <andres@anarazel.de>
2009-06-03 14:01 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 14:20 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-04 09:46 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-04 21:20 ` Re: PostgreSQL Developer meeting minutes up Ron Mayer <rm_pg@cheapcomplexdevices.com>
2009-06-05 07:05 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-05 13:38 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
2009-06-05 13:51 ` Re: PostgreSQL Developer meeting minutes up Andrew Dunstan <andrew@dunslane.net>
2009-06-06 15:41 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-06 16:56 ` Re: PostgreSQL Developer meeting minutes up Andrew Dunstan <andrew@dunslane.net>
2009-06-06 17:22 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
2009-06-06 23:03 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
@ 2009-06-07 07:26 ` Nicolas Barbier <nicolas.barbier@gmail.com>
2009-06-08 09:10 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
0 siblings, 1 reply; 538+ messages in thread
From: Nicolas Barbier @ 2009-06-07 07:26 UTC (permalink / raw)
To: Markus Wanner <markus@bluegap.ch>; +Cc: pgsql-hackers
2009/6/7 Markus Wanner <markus@bluegap.ch>:
> However, there's no special whitespace treatment. Nor anything remotely
> as clever as "nearby variable renaming". There's no such magic, the
> developer still needs to tell the tool what he wants.
If I understand correctly, "nearby variable renaming" refers to
changes to the few lines surrounding the changes-to-be-merged. There
is certainly supposed to be an advantage relative to diff/patch here:
as all changes leading to both versions are known (up to some common
ancestor), git doesn't need "context lines" to recognize the position
in the file that is supposed to receive the updates.
Example:
Original file:
a
b
c
Random other changes later (a and c are updated to incorporate "nearby
variable renaming" or somesuch):
extra line
a'
b
c'
(Note that the extra line is important, because if the line numbers
stay the same and the lines-to-update are exactly the same, patch
could just ignore the context lines.)
An update to line b yields:
extra line
a'
b'
c'
This change would not be diff/patch-mergeable to the original file,
because the "context lines" a' and c' wouldn't be found. Git is
smarter than this and doesn't need the context lines; rather it uses
the full history to determine that the change to line 3 becomes a
change to line 2 in the original file. It therefore merges this change
to yield:
a
b'
c
Disclaimer: I don't use git, but I assume that this is how all systems
that are smarter than diff/patch work.
Nicolas
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 15:34 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 16:07 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 16:17 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-03 11:10 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-03 12:08 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 12:19 ` Re: PostgreSQL Developer meeting minutes up Andres Freund <andres@anarazel.de>
2009-06-03 14:01 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 14:20 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-04 09:46 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-04 21:20 ` Re: PostgreSQL Developer meeting minutes up Ron Mayer <rm_pg@cheapcomplexdevices.com>
2009-06-05 07:05 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-05 13:38 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
2009-06-05 13:51 ` Re: PostgreSQL Developer meeting minutes up Andrew Dunstan <andrew@dunslane.net>
2009-06-06 15:41 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-06 16:56 ` Re: PostgreSQL Developer meeting minutes up Andrew Dunstan <andrew@dunslane.net>
2009-06-06 17:22 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
2009-06-06 23:03 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-07 07:26 ` Re: PostgreSQL Developer meeting minutes up Nicolas Barbier <nicolas.barbier@gmail.com>
@ 2009-06-08 09:10 ` Markus Wanner <markus@bluegap.ch>
2009-06-08 14:17 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
0 siblings, 1 reply; 538+ messages in thread
From: Markus Wanner @ 2009-06-08 09:10 UTC (permalink / raw)
To: Nicolas Barbier <nicolas.barbier@gmail.com>; +Cc: pgsql-hackers
Hi,
Quoting "Nicolas Barbier" <nicolas.barbier@gmail.com>:
> If I understand correctly, "nearby variable renaming" refers to
> changes to the few lines surrounding the changes-to-be-merged.
Hm.. I took that to mean "changes on the same line". I now realize
this interpretation has been an overly strict interpretation.
> There
> is certainly supposed to be an advantage relative to diff/patch here:
> as all changes leading to both versions are known (up to some common
> ancestor), git doesn't need "context lines" to recognize the position
> in the file that is supposed to receive the updates.
Yes, that's how I understand it as well. Your example seems fine
(except that it does not make much sense to merge with an ancestor).
I'm not sure if git also works line by line (as does monotone).
However, IIRC kdiff3 uses some finer grained comparison, so it can
even merge unrelated change on the same line, i.e.:
ancestor: aaa bbb
left: axa bbb (modified a -> x)
right: aaa byb (modified b -> y)
merge: axa byb (contains both modifications)
Regards
Markus Wanner
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 15:34 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 16:07 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 16:17 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-03 11:10 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-03 12:08 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 12:19 ` Re: PostgreSQL Developer meeting minutes up Andres Freund <andres@anarazel.de>
2009-06-03 14:01 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 14:20 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-04 09:46 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-04 21:20 ` Re: PostgreSQL Developer meeting minutes up Ron Mayer <rm_pg@cheapcomplexdevices.com>
2009-06-05 07:05 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-05 13:38 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
2009-06-05 13:51 ` Re: PostgreSQL Developer meeting minutes up Andrew Dunstan <andrew@dunslane.net>
2009-06-06 15:41 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-06 16:56 ` Re: PostgreSQL Developer meeting minutes up Andrew Dunstan <andrew@dunslane.net>
2009-06-06 17:22 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
2009-06-06 23:03 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-07 07:26 ` Re: PostgreSQL Developer meeting minutes up Nicolas Barbier <nicolas.barbier@gmail.com>
2009-06-08 09:10 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
@ 2009-06-08 14:17 ` Markus Wanner <markus@bluegap.ch>
0 siblings, 0 replies; 538+ messages in thread
From: Markus Wanner @ 2009-06-08 14:17 UTC (permalink / raw)
To: Nicolas Barbier <nicolas.barbier@gmail.com>; +Cc: pgsql-hackers
Hi,
Quoting "Nicolas Barbier" <nicolas.barbier@gmail.com>:
> ISTM that back-patching
I take this to mean "back-patching by cherry picking".
> a change to a file that wasn't modified on the
> back-branch leads exactly to merging a change to a (file-wise)
> ancestor?
Regarding the file's contents - and therefore the immediately visible
result - that's correct. However, for a merge, the two ancestor
revisions are stored, where as with cherry-pinging this information is
lost (at least for git).
So, trying to merge on top of a cherry-pick, git must merge these
changes again (which might or might not work). Merging on top of
merging works just fine.
Regards
Markus Wanner
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 15:34 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 16:07 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 16:17 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-03 11:10 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-03 12:08 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 12:19 ` Re: PostgreSQL Developer meeting minutes up Andres Freund <andres@anarazel.de>
2009-06-03 14:01 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 14:20 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-04 09:46 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-04 21:20 ` Re: PostgreSQL Developer meeting minutes up Ron Mayer <rm_pg@cheapcomplexdevices.com>
2009-06-05 07:05 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-05 13:38 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
2009-06-05 13:51 ` Re: PostgreSQL Developer meeting minutes up Andrew Dunstan <andrew@dunslane.net>
2009-06-06 15:41 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-06 16:56 ` Re: PostgreSQL Developer meeting minutes up Andrew Dunstan <andrew@dunslane.net>
@ 2009-06-06 20:56 ` Markus Wanner <markus@bluegap.ch>
1 sibling, 0 replies; 538+ messages in thread
From: Markus Wanner @ 2009-06-06 20:56 UTC (permalink / raw)
To: Andrew Dunstan <andrew@dunslane.net>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Ron Mayer <rm_pg@cheapcomplexdevices.com>; Marko Kreen <markokr@gmail.com>; Greg Stark <stark@enterprisedb.com>; Andres Freund <andres@anarazel.de>; Aidan Van Dyk <aidan@highrise.ca>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers
Hi,
Andrew Dunstan wrote:
> One fact to keep in mind is that, unlike most other FOSS projects, we
> keep quite a large number of branches live.
So far I thought exactly that would be a good reason for migrating to
something like git. Those claim to ease working on multiple branches in
parallel, and in my experience that works pretty well. I'd like to find
a good way to allow the Postgres project to make use of these features
to ease development.
> It means that they can deploy Postgres with confidence that
> they will not have to upgrade for quite a few years. In the corporate
> world, especially, that is a major issue. I occasionally have clients
> running 7.4 or even older versions.
I agree and appreciate that very much as well.
> The question we often face in backpatching is not "where did it first
> occur?" but "how far back should we patch it?".
Uh.. the difference here mostly being *when* the question comes up,
right? Because the possible answers "in 8.1" or "back to 8.1" are pretty
close.
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 15:34 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 16:07 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 16:17 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-03 11:10 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-03 12:08 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 12:19 ` Re: PostgreSQL Developer meeting minutes up Andres Freund <andres@anarazel.de>
2009-06-03 14:01 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 14:20 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-04 09:46 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-04 21:20 ` Re: PostgreSQL Developer meeting minutes up Ron Mayer <rm_pg@cheapcomplexdevices.com>
2009-06-05 07:05 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-05 13:38 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
@ 2009-06-05 15:29 ` Robert Haas <robertmhaas@gmail.com>
2009-06-05 15:37 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
2 siblings, 1 reply; 538+ messages in thread
From: Robert Haas @ 2009-06-05 15:29 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Markus Wanner <markus@bluegap.ch>; Ron Mayer <rm_pg@cheapcomplexdevices.com>; Marko Kreen <markokr@gmail.com>; Greg Stark <stark@enterprisedb.com>; Andres Freund <andres@anarazel.de>; Aidan Van Dyk <aidan@highrise.ca>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
On Fri, Jun 5, 2009 at 9:38 AM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
> "Markus Wanner" <markus@bluegap.ch> writes:
>> Note that a requirement for daggy fixes is that "the bug is fixed
>> close to the point where it was introduced". So fixing it on the
>> oldest stable branch that introduced a bug instead of fixing it on
>> HEAD and then back-porting would certainly be a step into the right
>> direction.
>
> I think it's already been made crystal clear that the people who
> actually do this work don't do it that way, and are uninterested in
> allowing their tools to force them to do it that way. Â Patching from
> HEAD back works better for us for a number of reasons, the main one
> being that HEAD is the version of the code that's most "swapped into"
> our awareness.
>
> However, so long as we can have a separate working copy per branch,
> I see no problem with preparing all the versions of a patch and then
> committing them back-to-front. Â What I'm not clear about is the
> mechanics for doing that. Â Would someone explain exactly what the
> steps should be to produce the nicest-looking git history?
I'm sure someone is going to come in here and again recommend merging,
but I'm going to again recommend not merging. Cherry-picking is the
way to go here. Or just commit to each branch completely separately
with the same commit message; cherry-pick at least IMO is just a
convenience to help you attempt to apply the patch to a different
branch.
The way you're using commit messages to construct the release notes
really puts a limits on what the history has to look like. I think it
would be good to find a better way to generate release notes that
isn't quite so dependent on having a very tight history, but even if
we do that I think in this particular situation cherry-picking is
going to be less work for the committers than any of the other options
that have been proposed.
...Robert
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 15:34 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 16:07 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 16:17 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-03 11:10 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-03 12:08 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 12:19 ` Re: PostgreSQL Developer meeting minutes up Andres Freund <andres@anarazel.de>
2009-06-03 14:01 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 14:20 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-04 09:46 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-04 21:20 ` Re: PostgreSQL Developer meeting minutes up Ron Mayer <rm_pg@cheapcomplexdevices.com>
2009-06-05 07:05 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-05 13:38 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
2009-06-05 15:29 ` Re: PostgreSQL Developer meeting minutes up Robert Haas <robertmhaas@gmail.com>
@ 2009-06-05 15:37 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-06-05 15:59 ` Re: PostgreSQL Developer meeting minutes up Robert Haas <robertmhaas@gmail.com>
2009-06-06 18:15 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
0 siblings, 2 replies; 538+ messages in thread
From: Tom Lane @ 2009-06-05 15:37 UTC (permalink / raw)
To: Robert Haas <robertmhaas@gmail.com>; +Cc: Markus Wanner <markus@bluegap.ch>; Ron Mayer <rm_pg@cheapcomplexdevices.com>; Marko Kreen <markokr@gmail.com>; Greg Stark <stark@enterprisedb.com>; Andres Freund <andres@anarazel.de>; Aidan Van Dyk <aidan@highrise.ca>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> I'm sure someone is going to come in here and again recommend merging,
> but I'm going to again recommend not merging. Cherry-picking is the
> way to go here. Or just commit to each branch completely separately
> with the same commit message; cherry-pick at least IMO is just a
> convenience to help you attempt to apply the patch to a different
> branch.
"Commit to each branch separately" is surely the closest analog to what
we have done historically. What I'm trying to understand is whether
there's an easy variant on that that'd expose the related-ness of the
patch versions in a way git understands, hopefully giving us more
ability to leverage git's capabilities in future.
However, given that we don't do any real development on the back
branches, it might be that trying to be smart about this is a waste of
time anyway. Surely only the HEAD version of the patch is going to be
something that other developers care about merging with.
regards, tom lane
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 15:34 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 16:07 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 16:17 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-03 11:10 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-03 12:08 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 12:19 ` Re: PostgreSQL Developer meeting minutes up Andres Freund <andres@anarazel.de>
2009-06-03 14:01 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 14:20 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-04 09:46 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-04 21:20 ` Re: PostgreSQL Developer meeting minutes up Ron Mayer <rm_pg@cheapcomplexdevices.com>
2009-06-05 07:05 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-05 13:38 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
2009-06-05 15:29 ` Re: PostgreSQL Developer meeting minutes up Robert Haas <robertmhaas@gmail.com>
2009-06-05 15:37 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
@ 2009-06-05 15:59 ` Robert Haas <robertmhaas@gmail.com>
2009-06-05 16:15 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 1 reply; 538+ messages in thread
From: Robert Haas @ 2009-06-05 15:59 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Markus Wanner <markus@bluegap.ch>; Ron Mayer <rm_pg@cheapcomplexdevices.com>; Marko Kreen <markokr@gmail.com>; Greg Stark <stark@enterprisedb.com>; Andres Freund <andres@anarazel.de>; Aidan Van Dyk <aidan@highrise.ca>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
On Fri, Jun 5, 2009 at 11:37 AM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
> However, given that we don't do any real development on the back
> branches, it might be that trying to be smart about this is a waste of
> time anyway. Â Surely only the HEAD version of the patch is going to be
> something that other developers care about merging with.
I think that's about right. I think there would be some benefit in
developning better tools - release notes seem to be the main issue -
so that, for example, if I develop a complex feature and you think my
code is great (ok, now I'm dreaming), you could actually merge my
commits rather than flattening them. The EXPLAIN stuff I'm working on
right now is a good example where it's a lot easier to review the
changes piece by piece rather than as a big unit, but I know you won't
want to commit it that way because (1) with CVS, it would be a lot
more work to do that, and (2) it would suck a lot of extra commits
into the data you use to generate release notes, thereby making that
process more complex.
I'm actually going to the trouble of trying to make sure that each of
my commits does one and only one thing that can be separately checked,
tested, and either accepted (hopefully) or rejected (hopefully not).
Hopefully, that will still help with reviewing, but then if you commit
it, it'll probably go in as one stomping commit that changes the
world, or at most as two or three commits that are all still pretty
big. There are certainly cases where big stomping commits are good (I
have them in my own projects, too, and branches with long histories of
little dumb commits regularly get squashed and rebased before merging)
but I think it would be nice to have other options.
(As a side benefit, if one of my little micro-commits turns out to
have a bug, you can easily revert *just that commit*, without having
to manually sort out exactly which pieces related to that change.)
...Robert
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 15:34 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 16:07 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 16:17 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-03 11:10 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-03 12:08 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 12:19 ` Re: PostgreSQL Developer meeting minutes up Andres Freund <andres@anarazel.de>
2009-06-03 14:01 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 14:20 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-04 09:46 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-04 21:20 ` Re: PostgreSQL Developer meeting minutes up Ron Mayer <rm_pg@cheapcomplexdevices.com>
2009-06-05 07:05 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-05 13:38 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
2009-06-05 15:29 ` Re: PostgreSQL Developer meeting minutes up Robert Haas <robertmhaas@gmail.com>
2009-06-05 15:37 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
2009-06-05 15:59 ` Re: PostgreSQL Developer meeting minutes up Robert Haas <robertmhaas@gmail.com>
@ 2009-06-05 16:15 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-06-05 16:18 ` Re: PostgreSQL Developer meeting minutes up Bruce Momjian <bruce@momjian.us>
2009-06-05 16:20 ` Re: PostgreSQL Developer meeting minutes up Robert Haas <robertmhaas@gmail.com>
0 siblings, 2 replies; 538+ messages in thread
From: Tom Lane @ 2009-06-05 16:15 UTC (permalink / raw)
To: Robert Haas <robertmhaas@gmail.com>; +Cc: Markus Wanner <markus@bluegap.ch>; Ron Mayer <rm_pg@cheapcomplexdevices.com>; Marko Kreen <markokr@gmail.com>; Greg Stark <stark@enterprisedb.com>; Andres Freund <andres@anarazel.de>; Aidan Van Dyk <aidan@highrise.ca>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> [ about micro commits ]
> (As a side benefit, if one of my little micro-commits turns out to
> have a bug, you can easily revert *just that commit*, without having
> to manually sort out exactly which pieces related to that change.)
I don't actually have a lot of faith in such an approach. My experience
is that bugs arise from unforeseen interactions of changes, and that
"backing out just one" isn't a useful thing to do, even if none of the
later parts of the patch directly depend on it.
So, yeah, presenting a patch as a series of edits can be useful for
review purposes, but I'm not at all excited about cluttering the
long-term project history with a zillion micro-commits. One of the
things I find most annoying about reviewing the current commit history
is that Bruce has taken a micro-commit approach to managing the TODO
list --- I was seldom so happy as the day that disappeared from CVS,
because of the ensuing reduction in noise level.
regards, tom lane
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 15:34 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 16:07 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 16:17 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-03 11:10 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-03 12:08 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 12:19 ` Re: PostgreSQL Developer meeting minutes up Andres Freund <andres@anarazel.de>
2009-06-03 14:01 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 14:20 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-04 09:46 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-04 21:20 ` Re: PostgreSQL Developer meeting minutes up Ron Mayer <rm_pg@cheapcomplexdevices.com>
2009-06-05 07:05 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-05 13:38 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
2009-06-05 15:29 ` Re: PostgreSQL Developer meeting minutes up Robert Haas <robertmhaas@gmail.com>
2009-06-05 15:37 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
2009-06-05 15:59 ` Re: PostgreSQL Developer meeting minutes up Robert Haas <robertmhaas@gmail.com>
2009-06-05 16:15 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
@ 2009-06-05 16:18 ` Bruce Momjian <bruce@momjian.us>
1 sibling, 0 replies; 538+ messages in thread
From: Bruce Momjian @ 2009-06-05 16:18 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Robert Haas <robertmhaas@gmail.com>; Markus Wanner <markus@bluegap.ch>; Ron Mayer <rm_pg@cheapcomplexdevices.com>; Marko Kreen <markokr@gmail.com>; Greg Stark <stark@enterprisedb.com>; Andres Freund <andres@anarazel.de>; Aidan Van Dyk <aidan@highrise.ca>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > [ about micro commits ]
> > (As a side benefit, if one of my little micro-commits turns out to
> > have a bug, you can easily revert *just that commit*, without having
> > to manually sort out exactly which pieces related to that change.)
>
> I don't actually have a lot of faith in such an approach. My experience
> is that bugs arise from unforeseen interactions of changes, and that
> "backing out just one" isn't a useful thing to do, even if none of the
> later parts of the patch directly depend on it.
>
> So, yeah, presenting a patch as a series of edits can be useful for
> review purposes, but I'm not at all excited about cluttering the
> long-term project history with a zillion micro-commits. One of the
> things I find most annoying about reviewing the current commit history
> is that Bruce has taken a micro-commit approach to managing the TODO
> list --- I was seldom so happy as the day that disappeared from CVS,
> because of the ensuing reduction in noise level.
Yea, that was a problem that is now fixed.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 15:34 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 16:07 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 16:17 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-03 11:10 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-03 12:08 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 12:19 ` Re: PostgreSQL Developer meeting minutes up Andres Freund <andres@anarazel.de>
2009-06-03 14:01 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 14:20 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-04 09:46 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-04 21:20 ` Re: PostgreSQL Developer meeting minutes up Ron Mayer <rm_pg@cheapcomplexdevices.com>
2009-06-05 07:05 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-05 13:38 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
2009-06-05 15:29 ` Re: PostgreSQL Developer meeting minutes up Robert Haas <robertmhaas@gmail.com>
2009-06-05 15:37 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
2009-06-05 15:59 ` Re: PostgreSQL Developer meeting minutes up Robert Haas <robertmhaas@gmail.com>
2009-06-05 16:15 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
@ 2009-06-05 16:20 ` Robert Haas <robertmhaas@gmail.com>
2009-06-08 08:56 ` Re: PostgreSQL Developer meeting minutes up Ron Mayer <rm_pg@cheapcomplexdevices.com>
1 sibling, 1 reply; 538+ messages in thread
From: Robert Haas @ 2009-06-05 16:20 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Markus Wanner <markus@bluegap.ch>; Ron Mayer <rm_pg@cheapcomplexdevices.com>; Marko Kreen <markokr@gmail.com>; Greg Stark <stark@enterprisedb.com>; Andres Freund <andres@anarazel.de>; Aidan Van Dyk <aidan@highrise.ca>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
On Fri, Jun 5, 2009 at 12:15 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> [ about micro commits ]
>> (As a side benefit, if one of my little micro-commits turns out to
>> have a bug, you can easily revert *just that commit*, without having
>> to manually sort out exactly which pieces related to that change.)
>
> I don't actually have a lot of faith in such an approach. Â My experience
> is that bugs arise from unforeseen interactions of changes, and that
> "backing out just one" isn't a useful thing to do, even if none of the
> later parts of the patch directly depend on it.
>
> So, yeah, presenting a patch as a series of edits can be useful for
> review purposes, but I'm not at all excited about cluttering the
> long-term project history with a zillion micro-commits. Â One of the
> things I find most annoying about reviewing the current commit history
> is that Bruce has taken a micro-commit approach to managing the TODO
> list --- I was seldom so happy as the day that disappeared from CVS,
> because of the ensuing reduction in noise level.
I've never even noticed that noise, even when reviewing older history.
The power of "git log" to get you exactly the commits you care about
is not to be underestimated.
With regard to micro-commits, I don't have hugely strong feelings on
the issue. I like them in certain situations, and I think that git
makes it feasible to use them that way if you want to; but if you
don't want to, I don't think that's a disaster either.
...Robert
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 15:34 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 16:07 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 16:17 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-03 11:10 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-03 12:08 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 12:19 ` Re: PostgreSQL Developer meeting minutes up Andres Freund <andres@anarazel.de>
2009-06-03 14:01 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 14:20 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-04 09:46 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-04 21:20 ` Re: PostgreSQL Developer meeting minutes up Ron Mayer <rm_pg@cheapcomplexdevices.com>
2009-06-05 07:05 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-05 13:38 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
2009-06-05 15:29 ` Re: PostgreSQL Developer meeting minutes up Robert Haas <robertmhaas@gmail.com>
2009-06-05 15:37 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
2009-06-05 15:59 ` Re: PostgreSQL Developer meeting minutes up Robert Haas <robertmhaas@gmail.com>
2009-06-05 16:15 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
2009-06-05 16:20 ` Re: PostgreSQL Developer meeting minutes up Robert Haas <robertmhaas@gmail.com>
@ 2009-06-08 08:56 ` Ron Mayer <rm_pg@cheapcomplexdevices.com>
0 siblings, 0 replies; 538+ messages in thread
From: Ron Mayer @ 2009-06-08 08:56 UTC (permalink / raw)
To: Robert Haas <robertmhaas@gmail.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Markus Wanner <markus@bluegap.ch>; Ron Mayer <rm_pg@cheapcomplexdevices.com>; Marko Kreen <markokr@gmail.com>; Greg Stark <stark@enterprisedb.com>; Andres Freund <andres@anarazel.de>; Aidan Van Dyk <aidan@highrise.ca>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
Robert Haas wrote:
> On Fri, Jun 5, 2009 at 12:15 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
>> ... but I'm not at all excited about cluttering the
>> long-term project history with a zillion micro-commits. One of the
>> things I find most annoying about reviewing the current commit history
>> is that Bruce has taken a micro-commit approach to managing the TODO
>> list --- I was seldom so happy as the day that disappeared from CVS,
>> because of the ensuing reduction in noise level.
For better or worse, git also includes a command "git-rebase" that can
collapse such micro-commits into a larger one.
Quoting the git-rebase man page:
A range of commits could also be removed with rebase. If we have the
following situation:
E---F---G---H---I---J topicA
then the command
git-rebase --onto topicA~5 topicA~3 topicA
would result in the removal of commits F and G:
E---H´---I´---J´ topicA
While I wouldn't recommend using this for historical revisionism, I
imagine it could be useful during code-review time when the
micro-commits (from both the patch submitter and patch reviewer)
are interesting. After the review, the commits could be collapsed
into meaningful-sized-chunks just before they're merged into the
official branches.
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 15:34 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 16:07 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 16:17 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-03 11:10 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-03 12:08 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 12:19 ` Re: PostgreSQL Developer meeting minutes up Andres Freund <andres@anarazel.de>
2009-06-03 14:01 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 14:20 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-04 09:46 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-04 21:20 ` Re: PostgreSQL Developer meeting minutes up Ron Mayer <rm_pg@cheapcomplexdevices.com>
2009-06-05 07:05 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-05 13:38 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
2009-06-05 15:29 ` Re: PostgreSQL Developer meeting minutes up Robert Haas <robertmhaas@gmail.com>
2009-06-05 15:37 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
@ 2009-06-06 18:15 ` Greg Stark <stark@enterprisedb.com>
2009-06-06 23:29 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
1 sibling, 1 reply; 538+ messages in thread
From: Greg Stark @ 2009-06-06 18:15 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Robert Haas <robertmhaas@gmail.com>; Markus Wanner <markus@bluegap.ch>; Ron Mayer <rm_pg@cheapcomplexdevices.com>; Marko Kreen <markokr@gmail.com>; Andres Freund <andres@anarazel.de>; Aidan Van Dyk <aidan@highrise.ca>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
On Fri, Jun 5, 2009 at 4:37 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
>
> However, given that we don't do any real development on the back
> branches, it might be that trying to be smart about this is a waste of
> time anyway. Â Surely only the HEAD version of the patch is going to be
> something that other developers care about merging with.
For what it's worth that's certainly not true. Any user maintaining a
patched version of the source tree for production use will want to
merge in any patches for older releases. For example anyone using the
CONNECT BY patch with 8.3 will surely want to take any 8.3 patch
releases. Of course EDB in particular has to maintain sources based on
old patch releases as well as the current branch.
That said, I don't see that this really affects the decision here.
These devleopers will just merge in the patch as it was applied to the
back branch anyways.
--
greg
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 15:34 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 16:07 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 16:17 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-03 11:10 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-03 12:08 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 12:19 ` Re: PostgreSQL Developer meeting minutes up Andres Freund <andres@anarazel.de>
2009-06-03 14:01 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 14:20 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-04 09:46 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-04 21:20 ` Re: PostgreSQL Developer meeting minutes up Ron Mayer <rm_pg@cheapcomplexdevices.com>
2009-06-05 07:05 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-05 13:38 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
2009-06-05 15:29 ` Re: PostgreSQL Developer meeting minutes up Robert Haas <robertmhaas@gmail.com>
2009-06-05 15:37 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
2009-06-06 18:15 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
@ 2009-06-06 23:29 ` Markus Wanner <markus@bluegap.ch>
0 siblings, 0 replies; 538+ messages in thread
From: Markus Wanner @ 2009-06-06 23:29 UTC (permalink / raw)
To: Greg Stark <stark@enterprisedb.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Robert Haas <robertmhaas@gmail.com>; Ron Mayer <rm_pg@cheapcomplexdevices.com>; Marko Kreen <markokr@gmail.com>; Andres Freund <andres@anarazel.de>; Aidan Van Dyk <aidan@highrise.ca>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
Hi,
Greg Stark wrote:
> For what it's worth that's certainly not true. Any user maintaining a
> patched version of the source tree for production use will want to
> merge in any patches for older releases. For example anyone using the
> CONNECT BY patch with 8.3 will surely want to take any 8.3 patch
> releases.
..or port that forward to 8.4, once it's released. To me it doesn't seem
that unreasonable to develop something on top of a stable branch and to
want to migrate that to a newer stable branch or HEAD later on. Git
could certainly help to reduce bit-rotting here, in my experience.
Regards
Markus Wanner
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 15:34 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 16:07 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 16:17 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-03 11:10 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-03 12:08 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 12:19 ` Re: PostgreSQL Developer meeting minutes up Andres Freund <andres@anarazel.de>
2009-06-03 14:01 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-03 14:20 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-04 09:46 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-04 21:20 ` Re: PostgreSQL Developer meeting minutes up Ron Mayer <rm_pg@cheapcomplexdevices.com>
2009-06-05 07:05 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-05 13:38 ` Re: PostgreSQL Developer meeting minutes up Tom Lane <tgl@sss.pgh.pa.us>
@ 2009-06-06 15:40 ` Markus Wanner <markus@bluegap.ch>
2 siblings, 0 replies; 538+ messages in thread
From: Markus Wanner @ 2009-06-06 15:40 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Ron Mayer <rm_pg@cheapcomplexdevices.com>; Marko Kreen <markokr@gmail.com>; Greg Stark <stark@enterprisedb.com>; Andres Freund <andres@anarazel.de>; Aidan Van Dyk <aidan@highrise.ca>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
Hi,
Tom Lane wrote:
> I think it's already been made crystal clear that the people who
> actually do this work don't do it that way, and are uninterested in
> allowing their tools to force them to do it that way.
That's well understood.
> Patching from
> HEAD back works better for us for a number of reasons, the main one
> being that HEAD is the version of the code that's most "swapped into"
> our awareness.
Committing on the oldest back-branch first doesn't necessarily mean
having to develop the patch there.
> However, so long as we can have a separate working copy per branch,
> I see no problem with preparing all the versions of a patch and then
> committing them back-to-front.
That's what I think as well.
However, I bet git could help a lot with creating all the versions of a
patch in the first place. You don't *need* to use that feature, but
preserving the option could help.
> What I'm not clear about is the
> mechanics for doing that.
If you create each of the patches individually, there's not much magic
required from git. It should be trivial to commit those as merges.
> Would someone explain exactly what the
> steps should be to produce the nicest-looking git history?
I fear the cherry-picking approach creates the "nicest-looking" history
(especially to the CVS trained eye).
Regards
Markus Wanner
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 15:34 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 16:07 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 16:17 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-03 11:10 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-03 12:08 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
@ 2009-06-04 08:11 ` Markus Wanner <markus@bluegap.ch>
2009-06-04 08:33 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <greg.stark@enterprisedb.com>
1 sibling, 1 reply; 538+ messages in thread
From: Markus Wanner @ 2009-06-04 08:11 UTC (permalink / raw)
To: Greg Stark <stark@enterprisedb.com>; +Cc: Marko Kreen <markokr@gmail.com>; Aidan Van Dyk <aidan@highrise.ca>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
Hi,
Quoting "Greg Stark" <stark@enterprisedb.com>:
> This is all completely irrelevant to the CVS import.
To the CVS import it is, yes. After all, CVS has no notion of renaming
files. But my example is about renaming with git *after* the
conversion. Git *does* support renaming (to some extent). However, it
fails as explained if you feed it with "corrupt" data (the corruption
being the missing link between the two added files - after a rename,
git simply has no chance of knowing it should be the same file).
> I don't think
> we've ever renamed files because CVS can't handle it cleanly.
Yes, that applies to the past. But I think we *are* going to rename
files *after* the switch, because git *can* handle it cleanly - given
a correct import.
If that defect would only affect historic information, I'd not be half
as pestering as I am. But it's such delayed effects which might
surprise you years after the cause, which make me nervous.
> It does sound to me like we really ought to have merge commits marking
> the bug fixes in old releases as merged in the equivalent commits to
> later branches based on Tom's commit messages.
Now, I don't know how you got to that conclusion, but I absolutely agree ;-)
Regards
Markus Wanner
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 15:34 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 16:07 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 16:17 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-03 11:10 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-03 12:08 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-04 08:11 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
@ 2009-06-04 08:33 ` Greg Stark <greg.stark@enterprisedb.com>
2009-06-04 09:07 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
0 siblings, 1 reply; 538+ messages in thread
From: Greg Stark @ 2009-06-04 08:33 UTC (permalink / raw)
To: Markus Wanner <markus@bluegap.ch>; +Cc: Greg Stark <stark@enterprisedb.com>; Marko Kreen <markokr@gmail.com>; Aidan Van Dyk <aidan@highrise.ca>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
On 4 Jun 2009, at 09:11, "Markus Wanner" <markus@bluegap.ch> wrote:
> Hi,
>
> Quoting "Greg Stark" <stark@enterprisedb.com>:
>> This is all completely irrelevant to the CVS import.
>
> To the CVS import it is, yes. After all, CVS has no notion of
> renaming files. But my example is about renaming with git *after*
> the conversion. Git *does* support renaming (to some extent).
> However, it fails as explained if you feed it with "corrupt" data
> (the corruption being the missing link between the two added files -
> after a rename, git simply has no chance of knowing it should be the
> same file).
>
Hmm. I see. I'm not sure we've ever added files to back branches
either. I'm less sure of that though.
>> I don't think
>> we've ever renamed files because CVS can't handle it cleanly.
>
> Yes, that applies to the past. But I think we *are* going to rename
> files *after* the switch, because git *can* handle it cleanly -
> given a correct import.
>
> If that defect would only affect historic information, I'd not be
> half as pestering as I am. But it's such delayed effects which might
> surprise you years after the cause, which make me nervous.
>
>> It does sound to me like we really ought to have merge commits
>> marking
>> the bug fixes in old releases as merged in the equivalent commits to
>> later branches based on Tom's commit messages.
>
> Now, I don't know how you got to that conclusion, but I absolutely
> agree ;-)
>
> Regards
>
> Markus Wanner
>
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 15:34 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 16:07 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 16:17 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-03 11:10 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-03 12:08 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <stark@enterprisedb.com>
2009-06-04 08:11 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-04 08:33 ` Re: PostgreSQL Developer meeting minutes up Greg Stark <greg.stark@enterprisedb.com>
@ 2009-06-04 09:07 ` Markus Wanner <markus@bluegap.ch>
0 siblings, 0 replies; 538+ messages in thread
From: Markus Wanner @ 2009-06-04 09:07 UTC (permalink / raw)
To: Greg Stark <greg.stark@enterprisedb.com>; +Cc: Greg Stark <stark@enterprisedb.com>; Marko Kreen <markokr@gmail.com>; Aidan Van Dyk <aidan@highrise.ca>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
Hi,
Quoting "Greg Stark" <greg.stark@enterprisedb.com>:
> Hmm. I see. I'm not sure we've ever added files to back branches
> either. I'm less sure of that though.
We did from time to time. Every merge commit in my current conversion
contains at least one such file that got added as part of a back
patch. The perl file mentioned in the example upstream is one of them.
Regards
Markus Wanner
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
@ 2009-06-02 11:08 ` Markus Wanner <markus@bluegap.ch>
2009-06-02 11:25 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 12:48 ` Re: PostgreSQL Developer meeting minutes up Aidan Van Dyk <aidan@highrise.ca>
1 sibling, 2 replies; 538+ messages in thread
From: Markus Wanner @ 2009-06-02 11:08 UTC (permalink / raw)
To: Marko Kreen <markokr@gmail.com>; +Cc: Aidan Van Dyk <aidan@highrise.ca>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
Hi,
Quoting "Marko Kreen" <markokr@gmail.com>:
>> I don't care half as much about the keyword expansion stuff - that's
>> doomed to disappear anyway.
>
> But this is one aspect we need to get right for the conversion.
What's your definition of "right"? I personally prefer the keyword
expansion to match a cvs checkout as closely as possible.
> So preferably we test it sooner not later.
I actually *am* testing against that. As mentioned, the only
differences are insignificant, IMO. For example having "1.1.1.1"
instead of "1.1" (or vice versa, I don't remember).
> I think Aidan got it right - expand $PostgreSQL$ and others that are
> actually expanded on current repo, but not $OpenBSD$ and others
> coming from external sources.
AFAIU Aidan proposed the exact opposite.
I'm proposing to leave both expanded, as in a CVS checkout and as
shipped in the source release tarballs.
> I'd prefer we immediately test full conversion and not leave some
> steps to last moment.
IMO that would equal to changing history, so that a checkout from git
doesn't match a released tarball as good as possible.
What you call "leave(ing) some steps to last moment" is IMO not part
of the conversion. It's rather a conscious decision to drop these
keywords as soon as we switch to git. This step should be represented
in history as a separate commit, IMO.
What do others think?
Regards
Markus Wanner
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:08 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
@ 2009-06-02 11:25 ` Marko Kreen <markokr@gmail.com>
2009-06-02 11:50 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
1 sibling, 1 reply; 538+ messages in thread
From: Marko Kreen @ 2009-06-02 11:25 UTC (permalink / raw)
To: Markus Wanner <markus@bluegap.ch>; +Cc: Aidan Van Dyk <aidan@highrise.ca>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
On 6/2/09, Markus Wanner <markus@bluegap.ch> wrote:
> Quoting "Marko Kreen" <markokr@gmail.com>:
> > > I don't care half as much about the keyword expansion stuff - that's
> > > doomed to disappear anyway.
> > >
> >
> > But this is one aspect we need to get right for the conversion.
> >
>
> What's your definition of "right"? I personally prefer the keyword
> expansion to match a cvs checkout as closely as possible.
This is Definitely Wrong (tm). You seem to be thinking that comparing
GIT checkout to random parallel CVS checkout (eg. from .tgz.) is the
main use-case. It is not. Browsing history and looking and diffs
between versions is. And expanded CVS keywords would be total PITA
for that.
> > So preferably we test it sooner not later.
> >
>
> I actually *am* testing against that. As mentioned, the only differences
> are insignificant, IMO. For example having "1.1.1.1" instead of "1.1" (or
> vice versa, I don't remember).
Why have those at all...
> > I think Aidan got it right - expand $PostgreSQL$ and others that are
> > actually expanded on current repo, but not $OpenBSD$ and others
> > coming from external sources.
> >
>
> AFAIU Aidan proposed the exact opposite.
Ah, sorry, my thinko. s/expanded/stripped/. Take Aidan's description
as authoritative.. :)
> I'm proposing to leave both expanded, as in a CVS checkout and as shipped
> in the source release tarballs.
No, the noise they add to history would seriously hurt usability.
> > I'd prefer we immediately test full conversion and not leave some
> > steps to last moment.
> >
>
> IMO that would equal to changing history, so that a checkout from git
> doesn't match a released tarball as good as possible.
We need to compare against tarballs only when checking the conversion.
And only then. Writing few scripts for that should not be a problem.
> What you call "leave(ing) some steps to last moment" is IMO not part of the
> conversion. It's rather a conscious decision to drop these keywords as soon
> as we switch to git. This step should be represented in history as a
> separate commit, IMO.
The question is how they should appear in historical commits.
I have no strong opinion whether to edit them out or not in the future.
Doing it during the periodic reindent would be good moment tho'.
--
marko
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:08 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 11:25 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
@ 2009-06-02 11:50 ` Markus Wanner <markus@bluegap.ch>
0 siblings, 0 replies; 538+ messages in thread
From: Markus Wanner @ 2009-06-02 11:50 UTC (permalink / raw)
To: Marko Kreen <markokr@gmail.com>; +Cc: Aidan Van Dyk <aidan@highrise.ca>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
Hi,
Quoting "Marko Kreen" <markokr@gmail.com>:
> This is Definitely Wrong (tm). You seem to be thinking that comparing
> GIT checkout to random parallel CVS checkout (eg. from .tgz.) is the
> main use-case. It is not. Browsing history and looking and diffs
> between versions is. And expanded CVS keywords would be total PITA
> for that.
That's an agrument. Point taken. I'll check if cvs2git supports that as well.
Regards
Markus Wanner
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:08 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
@ 2009-06-02 12:48 ` Aidan Van Dyk <aidan@highrise.ca>
2009-06-02 13:37 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
1 sibling, 1 reply; 538+ messages in thread
From: Aidan Van Dyk @ 2009-06-02 12:48 UTC (permalink / raw)
To: Markus Wanner <markus@bluegap.ch>; +Cc: Marko Kreen <markokr@gmail.com>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
* Markus Wanner <markus@bluegap.ch> [090602 07:08]:
> Hi,
>
> Quoting "Marko Kreen" <markokr@gmail.com>:
>>> I don't care half as much about the keyword expansion stuff - that's
>>> doomed to disappear anyway.
>>
>> But this is one aspect we need to get right for the conversion.
>
> What's your definition of "right"? I personally prefer the keyword
> expansion to match a cvs checkout as closely as possible.
> AFAIU Aidan proposed the exact opposite.
>
> I'm proposing to leave both expanded, as in a CVS checkout and as
> shipped in the source release tarballs.
Well, since I have -kk set in my .cvsrc, "mine" matches exactly the CVS
checkout l-)
Basically, I want the git to be identical to the cvs checkout. If you
use -kk, that means the "PostgreSQL CVS repository keywords" *aren't*
expanded. If you like -kv, that means they are.
Pick your poison (after all, it's CVS), either way, I think the 2 of
*us* are going to disagree which is best here ;-)
But, which ever way (exact to -kk or exact to -kv), the conversion
should be exact, and there should be no reason to "filter out
keyword-like stuff" in the diffs.
> What you call "leave(ing) some steps to last moment" is IMO not part of
> the conversion. It's rather a conscious decision to drop these keywords
> as soon as we switch to git. This step should be represented in history
> as a separate commit, IMO.
>
> What do others think?
I'm assuming they will get removed from the source eventually too - but
that step is *outside* the conversion. Somebody could do it now in CVS
before the conversion, or afterwards, but it's still outside the
conversion.
--
Aidan Van Dyk Create like a god,
aidan@highrise.ca command like a king,
http://www.highrise.ca/ work like a slave.
Attachments:
[application/pgp-signature] signature.asc (189B, ../../20090602124806.GA23972@yugib.highrise.ca/2-signature.asc)
download
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:08 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:48 ` Re: PostgreSQL Developer meeting minutes up Aidan Van Dyk <aidan@highrise.ca>
@ 2009-06-02 13:37 ` Markus Wanner <markus@bluegap.ch>
2009-06-02 13:54 ` Re: PostgreSQL Developer meeting minutes up Aidan Van Dyk <aidan@highrise.ca>
0 siblings, 1 reply; 538+ messages in thread
From: Markus Wanner @ 2009-06-02 13:37 UTC (permalink / raw)
To: Aidan Van Dyk <aidan@highrise.ca>; +Cc: Marko Kreen <markokr@gmail.com>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
Hi,
Quoting "Aidan Van Dyk" <aidan@highrise.ca>:
> Pick your poison (after all, it's CVS), either way, I think the 2 of
> *us* are going to disagree which is best here ;-)
Marko already convinced me of -kk, I'm trying that with cvs2git.
> But, which ever way (exact to -kk or exact to -kv), the conversion
> should be exact, and there should be no reason to "filter out
> keyword-like stuff" in the diffs.
I just really didn't want to care about keyword expansion. Besides
lacking consistency, it's one of the worst misfeatures of CVS, IMNSHO.
;-)
I'll let you know how cvs2git behaves WRT -kk.
Regards
Markus Wanner
^ permalink raw reply [nested|flat] 538+ messages in thread
* Re: PostgreSQL Developer meeting minutes up
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Re: PostgreSQL Developer meeting minutes up Marko Kreen <markokr@gmail.com>
2009-06-02 11:08 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-02 12:48 ` Re: PostgreSQL Developer meeting minutes up Aidan Van Dyk <aidan@highrise.ca>
2009-06-02 13:37 ` Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
@ 2009-06-02 13:54 ` Aidan Van Dyk <aidan@highrise.ca>
0 siblings, 0 replies; 538+ messages in thread
From: Aidan Van Dyk @ 2009-06-02 13:54 UTC (permalink / raw)
To: Markus Wanner <markus@bluegap.ch>; +Cc: Marko Kreen <markokr@gmail.com>; Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
* Markus Wanner <markus@bluegap.ch> [090602 09:37]:
> Marko already convinced me of -kk, I'm trying that with cvs2git.
Good ;-)
> I just really didn't want to care about keyword expansion. Besides
> lacking consistency, it's one of the worst misfeatures of CVS, IMNSHO.
> ;-)
Absolutely... And one of the reasons I've had -kk in my .cvsrc for
years, even before I started with git.
> I'll let you know how cvs2git behaves WRT -kk.
Cool..
a.
--
Aidan Van Dyk Create like a god,
aidan@highrise.ca command like a king,
http://www.highrise.ca/ work like a slave.
Attachments:
[application/pgp-signature] signature.asc (189B, ../../20090602135437.GC23972@yugib.highrise.ca/2-signature.asc)
download
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Asymmetric partitionwise join.
@ 2021-04-02 06:02 Andrey Lepikhov <a.lepikhov@postgrespro.ru>
0 siblings, 0 replies; 538+ messages in thread
From: Andrey Lepikhov @ 2021-04-02 06:02 UTC (permalink / raw)
Teach optimizer to consider partitionwise join of non-partitioned
table with each partition of partitioned table.
This technique cause changes of 'reparameterize by child' machinery.
---
src/backend/optimizer/path/joinpath.c | 9 +
src/backend/optimizer/path/joinrels.c | 151 ++++++++++++++
src/backend/optimizer/util/appendinfo.c | 28 ++-
src/backend/optimizer/util/pathnode.c | 9 +-
src/backend/optimizer/util/relnode.c | 14 +-
src/include/optimizer/paths.h | 7 +-
src/test/regress/expected/partition_join.out | 209 +++++++++++++++++++
src/test/regress/sql/partition_join.sql | 99 +++++++++
8 files changed, 509 insertions(+), 17 deletions(-)
diff --git a/src/backend/optimizer/path/joinpath.c b/src/backend/optimizer/path/joinpath.c
index e9b6968b1d..6ba6d32ae4 100644
--- a/src/backend/optimizer/path/joinpath.c
+++ b/src/backend/optimizer/path/joinpath.c
@@ -335,6 +335,15 @@ add_paths_to_joinrel(PlannerInfo *root,
if (set_join_pathlist_hook)
set_join_pathlist_hook(root, joinrel, outerrel, innerrel,
jointype, &extra);
+
+ /*
+ * 7. If outer relation is delivered from partition-tables, consider
+ * distributing inner relation to every partition-leaf prior to
+ * append these leafs.
+ */
+ try_asymmetric_partitionwise_join(root, joinrel,
+ outerrel, innerrel,
+ jointype, &extra);
}
/*
diff --git a/src/backend/optimizer/path/joinrels.c b/src/backend/optimizer/path/joinrels.c
index 0dbe2ac726..6f900475bb 100644
--- a/src/backend/optimizer/path/joinrels.c
+++ b/src/backend/optimizer/path/joinrels.c
@@ -16,6 +16,7 @@
#include "miscadmin.h"
#include "optimizer/appendinfo.h"
+#include "optimizer/cost.h"
#include "optimizer/joininfo.h"
#include "optimizer/pathnode.h"
#include "optimizer/paths.h"
@@ -1551,6 +1552,156 @@ try_partitionwise_join(PlannerInfo *root, RelOptInfo *rel1, RelOptInfo *rel2,
}
}
+/*
+ * Build RelOptInfo on JOIN of each partition of the outer relation and the inner
+ * relation. Return List of such RelOptInfo's. Return NIL, if at least one of
+ * these JOINs are impossible to build.
+ */
+static List *
+extract_asymmetric_partitionwise_subjoin(PlannerInfo *root,
+ RelOptInfo *joinrel,
+ AppendPath *append_path,
+ RelOptInfo *inner_rel,
+ JoinType jointype,
+ JoinPathExtraData *extra)
+{
+ List *result = NIL;
+ ListCell *lc;
+
+ foreach (lc, append_path->subpaths)
+ {
+ Path *child_path = lfirst(lc);
+ RelOptInfo *child_rel = child_path->parent;
+ Relids child_join_relids;
+ RelOptInfo *child_join_rel;
+ SpecialJoinInfo *child_sjinfo;
+ List *child_restrictlist;
+ AppendRelInfo **appinfos;
+ int nappinfos;
+
+ child_join_relids = bms_union(child_rel->relids,
+ inner_rel->relids);
+ appinfos = find_appinfos_by_relids(root, child_join_relids,
+ &nappinfos);
+ child_sjinfo = build_child_join_sjinfo(root, extra->sjinfo,
+ child_rel->relids,
+ inner_rel->relids);
+ child_restrictlist = (List *)
+ adjust_appendrel_attrs(root, (Node *)extra->restrictlist,
+ nappinfos, appinfos);
+ pfree(appinfos);
+
+ child_join_rel = find_join_rel(root, child_join_relids);
+ if (!child_join_rel)
+ {
+ child_join_rel = build_child_join_rel(root,
+ child_rel,
+ inner_rel,
+ joinrel,
+ child_restrictlist,
+ child_sjinfo,
+ jointype);
+ if (!child_join_rel)
+ {
+ /*
+ * If can't build JOIN between inner relation and one of the outer
+ * partitions - return immediately.
+ */
+ return NIL;
+ }
+ }
+ else
+ {
+ /*
+ * TODO:
+ * Can't imagine situation when join relation already exists. But in
+ * the 'partition_join' regression test it happens.
+ * It may be an indicator of possible problems.
+ */
+ }
+
+ populate_joinrel_with_paths(root,
+ child_rel,
+ inner_rel,
+ child_join_rel,
+ child_sjinfo,
+ child_restrictlist);
+
+ /* Give up if asymmetric partition-wise join is not available */
+ if (child_join_rel->pathlist == NIL)
+ return NIL;
+
+ set_cheapest(child_join_rel);
+ result = lappend(result, child_join_rel);
+ }
+ return result;
+}
+
+void
+try_asymmetric_partitionwise_join(PlannerInfo *root,
+ RelOptInfo *joinrel,
+ RelOptInfo *outer_rel,
+ RelOptInfo *inner_rel,
+ JoinType jointype,
+ JoinPathExtraData *extra)
+{
+ ListCell *lc;
+
+ if (!enable_partitionwise_join)
+ return;
+
+ if (IS_OTHER_REL(outer_rel) || IS_OTHER_REL(inner_rel))
+ return;
+
+ if (jointype != JOIN_INNER && jointype != JOIN_LEFT)
+ return;
+
+ foreach (lc, outer_rel->pathlist)
+ {
+ AppendPath *append_path = lfirst(lc);
+
+ /*
+ * MEMO: We assume this pathlist keeps at least one AppendPath that
+ * represents partitioned table-scan, symmetric or asymmetric
+ * partition-wise join. It is not correct right now, however, a hook
+ * on add_path() to give additional decision for path removel allows
+ * to retain this kind of AppendPath, regardless of its cost.
+ */
+ if (IsA(append_path, AppendPath))
+ {
+ List **join_rel_level_saved;
+ List *live_childrels = NIL;
+
+ join_rel_level_saved = root->join_rel_level;
+ PG_TRY();
+ {
+ /* temporary disables "dynamic programming" algorithm */
+ root->join_rel_level = NULL;
+
+ live_childrels =
+ extract_asymmetric_partitionwise_subjoin(root,
+ joinrel,
+ append_path,
+ inner_rel,
+ jointype,
+ extra);
+ }
+ PG_CATCH();
+ {
+ root->join_rel_level = join_rel_level_saved;
+ PG_RE_THROW();
+ }
+ PG_END_TRY();
+ root->join_rel_level = join_rel_level_saved;
+
+ if (live_childrels != NIL)
+ add_paths_to_append_rel(root, joinrel, live_childrels);
+
+ break;
+ }
+ }
+}
+
/*
* Construct the SpecialJoinInfo for a child-join by translating
* SpecialJoinInfo for the join between parents. left_relids and right_relids
diff --git a/src/backend/optimizer/util/appendinfo.c b/src/backend/optimizer/util/appendinfo.c
index af46f581ac..be4624b619 100644
--- a/src/backend/optimizer/util/appendinfo.c
+++ b/src/backend/optimizer/util/appendinfo.c
@@ -202,7 +202,9 @@ adjust_appendrel_attrs(PlannerInfo *root, Node *node, int nappinfos,
context.appinfos = appinfos;
/* If there's nothing to adjust, don't call this function. */
- Assert(nappinfos >= 1 && appinfos != NULL);
+ /* If there's nothing to adjust, just return a duplication */
+ if (nappinfos == 0)
+ return copyObject(node);
/* Should never be translating a Query tree. */
Assert(node == NULL || !IsA(node, Query));
@@ -494,8 +496,6 @@ adjust_appendrel_attrs_multilevel(PlannerInfo *root, Node *node,
int nappinfos;
int cnt;
- Assert(bms_num_members(child_relids) == bms_num_members(top_parent_relids));
-
appinfos = find_appinfos_by_relids(root, child_relids, &nappinfos);
/* Construct relids set for the immediate parent of given child. */
@@ -506,8 +506,13 @@ adjust_appendrel_attrs_multilevel(PlannerInfo *root, Node *node,
parent_relids = bms_add_member(parent_relids, appinfo->parent_relid);
}
- /* Recurse if immediate parent is not the top parent. */
- if (!bms_equal(parent_relids, top_parent_relids))
+ /*
+ * Recurse if immediate parent is not the top parent. Keep in mind that in a
+ * case of asymmetric JOIN top_parent_relids can contain relids which aren't
+ * part of an append node.
+ */
+ if (!bms_equal(parent_relids, top_parent_relids) &&
+ !bms_is_subset(parent_relids, top_parent_relids))
node = adjust_appendrel_attrs_multilevel(root, node, parent_relids,
top_parent_relids);
@@ -565,6 +570,7 @@ adjust_child_relids_multilevel(PlannerInfo *root, Relids relids,
AppendRelInfo **appinfos;
int nappinfos;
Relids parent_relids = NULL;
+ Relids normal_relids = NULL;
Relids result;
Relids tmp_result = NULL;
int cnt;
@@ -579,12 +585,17 @@ adjust_child_relids_multilevel(PlannerInfo *root, Relids relids,
appinfos = find_appinfos_by_relids(root, child_relids, &nappinfos);
/* Construct relids set for the immediate parent of the given child. */
+ normal_relids = bms_copy(child_relids);
for (cnt = 0; cnt < nappinfos; cnt++)
{
AppendRelInfo *appinfo = appinfos[cnt];
parent_relids = bms_add_member(parent_relids, appinfo->parent_relid);
+ normal_relids = bms_del_member(normal_relids, appinfo->child_relid);
}
+ parent_relids = bms_union(parent_relids, normal_relids);
+ if (normal_relids)
+ bms_free(normal_relids);
/* Recurse if immediate parent is not the top parent. */
if (!bms_equal(parent_relids, top_parent_relids))
@@ -715,11 +726,11 @@ AppendRelInfo **
find_appinfos_by_relids(PlannerInfo *root, Relids relids, int *nappinfos)
{
AppendRelInfo **appinfos;
+ int nrooms = bms_num_members(relids);
int cnt = 0;
int i;
- *nappinfos = bms_num_members(relids);
- appinfos = (AppendRelInfo **) palloc(sizeof(AppendRelInfo *) * *nappinfos);
+ appinfos = (AppendRelInfo **) palloc(sizeof(AppendRelInfo *) * nrooms);
i = -1;
while ((i = bms_next_member(relids, i)) >= 0)
@@ -727,10 +738,11 @@ find_appinfos_by_relids(PlannerInfo *root, Relids relids, int *nappinfos)
AppendRelInfo *appinfo = root->append_rel_array[i];
if (!appinfo)
- elog(ERROR, "child rel %d not found in append_rel_array", i);
+ continue;
appinfos[cnt++] = appinfo;
}
+ *nappinfos = cnt;
return appinfos;
}
diff --git a/src/backend/optimizer/util/pathnode.c b/src/backend/optimizer/util/pathnode.c
index b248b038e0..73cfb4748d 100644
--- a/src/backend/optimizer/util/pathnode.c
+++ b/src/backend/optimizer/util/pathnode.c
@@ -4209,7 +4209,14 @@ do { \
MemoryContextSwitchTo(oldcontext);
}
- bms_free(required_outer);
+
+ /*
+ * If adjust_child_relids_multilevel don't do replacements it returns
+ * the original set, not a copy. It is possible in the case of asymmetric
+ * JOIN and child_rel->relids contains relids only of plane relations.
+ */
+ if (required_outer != old_ppi->ppi_req_outer)
+ bms_free(required_outer);
new_path->param_info = new_ppi;
diff --git a/src/backend/optimizer/util/relnode.c b/src/backend/optimizer/util/relnode.c
index e105a4d5f1..f98a82e725 100644
--- a/src/backend/optimizer/util/relnode.c
+++ b/src/backend/optimizer/util/relnode.c
@@ -790,11 +790,8 @@ build_child_join_rel(PlannerInfo *root, RelOptInfo *outer_rel,
AppendRelInfo **appinfos;
int nappinfos;
- /* Only joins between "other" relations land here. */
- Assert(IS_OTHER_REL(outer_rel) && IS_OTHER_REL(inner_rel));
-
- /* The parent joinrel should have consider_partitionwise_join set. */
- Assert(parent_joinrel->consider_partitionwise_join);
+ /* Either of relations must be "other" relation at least. */
+ Assert(IS_OTHER_REL(outer_rel) || IS_OTHER_REL(inner_rel));
joinrel->reloptkind = RELOPT_OTHER_JOINREL;
joinrel->relids = bms_union(outer_rel->relids, inner_rel->relids);
@@ -851,8 +848,11 @@ build_child_join_rel(PlannerInfo *root, RelOptInfo *outer_rel,
joinrel->partexprs = NULL;
joinrel->nullable_partexprs = NULL;
- joinrel->top_parent_relids = bms_union(outer_rel->top_parent_relids,
- inner_rel->top_parent_relids);
+ joinrel->top_parent_relids =
+ bms_union(IS_OTHER_REL(outer_rel) ?
+ outer_rel->top_parent_relids : outer_rel->relids,
+ IS_OTHER_REL(inner_rel) ?
+ inner_rel->top_parent_relids : inner_rel->relids);
/* Compute information relevant to foreign relations. */
set_foreign_rel_properties(joinrel, outer_rel, inner_rel);
diff --git a/src/include/optimizer/paths.h b/src/include/optimizer/paths.h
index 035d3e1206..d64aa37f80 100644
--- a/src/include/optimizer/paths.h
+++ b/src/include/optimizer/paths.h
@@ -109,7 +109,12 @@ extern bool have_join_order_restriction(PlannerInfo *root,
extern bool have_dangerous_phv(PlannerInfo *root,
Relids outer_relids, Relids inner_params);
extern void mark_dummy_rel(RelOptInfo *rel);
-
+extern void try_asymmetric_partitionwise_join(PlannerInfo *root,
+ RelOptInfo *joinrel,
+ RelOptInfo *outer_rel,
+ RelOptInfo *inner_rel,
+ JoinType jointype,
+ JoinPathExtraData *extra);
/*
* equivclass.c
* routines for managing EquivalenceClasses
diff --git a/src/test/regress/expected/partition_join.out b/src/test/regress/expected/partition_join.out
index 27f7525b3e..2bc7ad70d9 100644
--- a/src/test/regress/expected/partition_join.out
+++ b/src/test/regress/expected/partition_join.out
@@ -2320,6 +2320,215 @@ SELECT t1.a, t1.c, t2.b, t2.c FROM prt1_adv t1 INNER JOIN prt2_adv t2 ON (t1.a =
375 | 0375 | 375 | 0375
(8 rows)
+--
+-- For asymmetric partition-wise join
+--
+CREATE TABLE prt5 (hkey int, a int, b int) PARTITION BY HASH(hkey);
+CREATE TABLE prt5_p0 PARTITION OF prt5
+ FOR VALUES WITH (modulus 3, remainder 0);
+CREATE TABLE prt5_p1 PARTITION OF prt5
+ FOR VALUES WITH (modulus 3, remainder 1);
+CREATE TABLE prt5_p2 PARTITION OF prt5
+ FOR VALUES WITH (modulus 3, remainder 2);
+CREATE TABLE t5_1 (aid int, alabel text);
+CREATE TABLE t5_2 (bid int, blabel text);
+INSERT INTO prt5 (SELECT x, (1000.0 * random())::int,
+ (1000.0 * random())::int
+ FROM generate_series(1,1000000) x);
+INSERT INTO t5_1 (SELECT x, md5(x::text) FROM generate_series(-200, 800) x);
+INSERT INTO t5_2 (SELECT x, md5(x::text) FROM generate_series(-200, 800) x);
+VACUUM ANALYZE prt5;
+VACUUM ANALYZE t5_1;
+VACUUM ANALYZE t5_2;
+SET max_parallel_workers_per_gather = 0;
+EXPLAIN (COSTS OFF)
+SELECT *
+ FROM prt5 JOIN t5_1 ON a = aid AND alabel like '%abc%';
+ QUERY PLAN
+-------------------------------------------------------
+ Append
+ -> Hash Join
+ Hash Cond: (prt5_1.a = t5_1.aid)
+ -> Seq Scan on prt5_p0 prt5_1
+ -> Hash
+ -> Seq Scan on t5_1
+ Filter: (alabel ~~ '%abc%'::text)
+ -> Hash Join
+ Hash Cond: (prt5_2.a = t5_1.aid)
+ -> Seq Scan on prt5_p1 prt5_2
+ -> Hash
+ -> Seq Scan on t5_1
+ Filter: (alabel ~~ '%abc%'::text)
+ -> Hash Join
+ Hash Cond: (prt5_3.a = t5_1.aid)
+ -> Seq Scan on prt5_p2 prt5_3
+ -> Hash
+ -> Seq Scan on t5_1
+ Filter: (alabel ~~ '%abc%'::text)
+(19 rows)
+
+EXPLAIN (COSTS OFF)
+SELECT *
+ FROM prt5 JOIN t5_1 ON a = aid AND alabel like '%ab%'
+ JOIN t5_2 ON b = bid AND blabel like '%cd%';
+ QUERY PLAN
+------------------------------------------------------------
+ Append
+ -> Hash Join
+ Hash Cond: (prt5_1.a = t5_1.aid)
+ -> Hash Join
+ Hash Cond: (prt5_1.b = t5_2.bid)
+ -> Seq Scan on prt5_p0 prt5_1
+ -> Hash
+ -> Seq Scan on t5_2
+ Filter: (blabel ~~ '%cd%'::text)
+ -> Hash
+ -> Seq Scan on t5_1
+ Filter: (alabel ~~ '%ab%'::text)
+ -> Hash Join
+ Hash Cond: (prt5_2.a = t5_1.aid)
+ -> Hash Join
+ Hash Cond: (prt5_2.b = t5_2.bid)
+ -> Seq Scan on prt5_p1 prt5_2
+ -> Hash
+ -> Seq Scan on t5_2
+ Filter: (blabel ~~ '%cd%'::text)
+ -> Hash
+ -> Seq Scan on t5_1
+ Filter: (alabel ~~ '%ab%'::text)
+ -> Hash Join
+ Hash Cond: (prt5_3.a = t5_1.aid)
+ -> Hash Join
+ Hash Cond: (prt5_3.b = t5_2.bid)
+ -> Seq Scan on prt5_p2 prt5_3
+ -> Hash
+ -> Seq Scan on t5_2
+ Filter: (blabel ~~ '%cd%'::text)
+ -> Hash
+ -> Seq Scan on t5_1
+ Filter: (alabel ~~ '%ab%'::text)
+(34 rows)
+
+-- unable to extract non-partitioned right relation
+EXPLAIN (COSTS OFF)
+SELECT * FROM prt5 RIGHT JOIN t5_1 ON a = aid AND alabel like '%abc%';
+ QUERY PLAN
+-----------------------------------------------
+ Hash Right Join
+ Hash Cond: (prt5.a = t5_1.aid)
+ Join Filter: (t5_1.alabel ~~ '%abc%'::text)
+ -> Append
+ -> Seq Scan on prt5_p0 prt5_1
+ -> Seq Scan on prt5_p1 prt5_2
+ -> Seq Scan on prt5_p2 prt5_3
+ -> Hash
+ -> Seq Scan on t5_1
+(9 rows)
+
+-- left side can be extracted, but no cost benefit
+EXPLAIN (COSTS OFF)
+SELECT * FROM prt5 LEFT JOIN t5_1 ON a = aid AND alabel like '%abc%';
+ QUERY PLAN
+-------------------------------------------------
+ Hash Left Join
+ Hash Cond: (prt5.a = t5_1.aid)
+ -> Append
+ -> Seq Scan on prt5_p0 prt5_1
+ -> Seq Scan on prt5_p1 prt5_2
+ -> Seq Scan on prt5_p2 prt5_3
+ -> Hash
+ -> Seq Scan on t5_1
+ Filter: (alabel ~~ '%abc%'::text)
+(9 rows)
+
+-- validation of the results with/without asymmetric partition-wise join
+SELECT * INTO pg_temp.result01a
+ FROM prt5 JOIN t5_1 ON a = aid AND alabel like '%abc%';
+SELECT * INTO pg_temp.result02a
+ FROM prt5 JOIN t5_1 ON a = aid AND alabel like '%ab%'
+ JOIN t5_2 ON b = bid AND blabel like '%cd%';
+SET enable_partitionwise_join = off;
+SELECT * INTO pg_temp.result01b
+ FROM prt5 JOIN t5_1 ON a = aid AND alabel like '%abc%';
+SELECT * INTO pg_temp.result02b
+ FROM prt5 JOIN t5_1 ON a = aid AND alabel like '%ab%'
+ JOIN t5_2 ON b = bid AND blabel like '%cd%';
+SELECT * FROM pg_temp.result01a EXCEPT SELECT * FROM pg_temp.result01b;
+ hkey | a | b | aid | alabel
+------+---+---+-----+--------
+(0 rows)
+
+SELECT * FROM pg_temp.result02a EXCEPT SELECT * FROM pg_temp.result02b;
+ hkey | a | b | aid | alabel | bid | blabel
+------+---+---+-----+--------+-----+--------
+(0 rows)
+
+RESET max_parallel_workers_per_gather;
+SET enable_partitionwise_join = true;
+-- Parameterized path examples.
+CREATE TABLE prta (id integer, payload text) PARTITION BY HASH (id);
+CREATE TABLE prta1 PARTITION OF prta FOR VALUES WITH (modulus 2, remainder 0);
+CREATE TABLE prta2 PARTITION OF prta FOR VALUES WITH (modulus 2, remainder 1);
+CREATE UNIQUE INDEX ON prta1 (id);
+CREATE UNIQUE INDEX ON prta2 (id);
+INSERT INTO prta (id, payload)
+ (SELECT *, ('abc' || id)::text AS payload
+ FROM generate_series(1,1) AS id);
+CREATE TABLE prtb (id integer, payload text) PARTITION BY HASH (id);
+CREATE TABLE prtb1 PARTITION OF prtb FOR VALUES WITH (modulus 2, remainder 0);
+CREATE TABLE prtb2 PARTITION OF prtb FOR VALUES WITH (modulus 2, remainder 1);
+CREATE UNIQUE INDEX ON prtb1 (id);
+CREATE UNIQUE INDEX ON prtb2 (id);
+INSERT INTO prtb (id, payload)
+ (SELECT *, ('def' || id)::text AS payload
+ FROM generate_series(1,1000) AS id);
+CREATE TABLE e (id integer, payload text) PARTITION BY HASH (id);
+CREATE TABLE e1 PARTITION OF e FOR VALUES WITH (modulus 2, remainder 0);
+CREATE TABLE e2 PARTITION OF e FOR VALUES WITH (modulus 2, remainder 1);
+INSERT INTO e (id, payload)
+ (SELECT *, ('ghi' || id)::text AS payload
+ FROM generate_series(1,1000) AS id);
+CREATE UNIQUE INDEX ON e1 (id);
+CREATE UNIQUE INDEX ON e2 (id);
+ANALYZE prta,prtb,e;
+EXPLAIN (COSTS OFF)
+SELECT * FROM prta,prtb WHERE prta.id=prtb.id;
+ QUERY PLAN
+-----------------------------------------------------------
+ Append
+ -> Nested Loop
+ -> Seq Scan on prta1 prta_1
+ -> Index Scan using prtb1_id_idx on prtb1 prtb_1
+ Index Cond: (id = prta_1.id)
+ -> Nested Loop
+ -> Seq Scan on prta2 prta_2
+ -> Index Scan using prtb2_id_idx on prtb2 prtb_2
+ Index Cond: (id = prta_2.id)
+(9 rows)
+
+EXPLAIN (COSTS OFF)
+SELECT * FROM prta,prtb,e WHERE prta.id=prtb.id AND prta.id=e.id;
+ QUERY PLAN
+-----------------------------------------------------------------
+ Append
+ -> Nested Loop
+ Join Filter: (prta_1.id = e_1.id)
+ -> Nested Loop
+ -> Seq Scan on prta1 prta_1
+ -> Index Scan using prtb1_id_idx on prtb1 prtb_1
+ Index Cond: (id = prta_1.id)
+ -> Index Scan using e1_id_idx on e1 e_1
+ Index Cond: (id = prtb_1.id)
+ -> Nested Loop
+ Join Filter: (prta_2.id = e_2.id)
+ -> Nested Loop
+ -> Seq Scan on prta2 prta_2
+ -> Index Scan using prtb2_id_idx on prtb2 prtb_2
+ Index Cond: (id = prta_2.id)
+ -> Index Scan using e2_id_idx on e2 e_2
+ Index Cond: (id = prtb_2.id)
+(17 rows)
+
-- semi join
EXPLAIN (COSTS OFF)
SELECT t1.* FROM prt1_adv t1 WHERE EXISTS (SELECT 1 FROM prt2_adv t2 WHERE t1.a = t2.b) AND t1.b = 0 ORDER BY t1.a;
diff --git a/src/test/regress/sql/partition_join.sql b/src/test/regress/sql/partition_join.sql
index d97b5b69ff..c206fd736a 100644
--- a/src/test/regress/sql/partition_join.sql
+++ b/src/test/regress/sql/partition_join.sql
@@ -536,6 +536,105 @@ EXPLAIN (COSTS OFF)
SELECT t1.a, t1.c, t2.b, t2.c FROM prt1_adv t1 INNER JOIN prt2_adv t2 ON (t1.a = t2.b) WHERE t1.b = 0 ORDER BY t1.a, t2.b;
SELECT t1.a, t1.c, t2.b, t2.c FROM prt1_adv t1 INNER JOIN prt2_adv t2 ON (t1.a = t2.b) WHERE t1.b = 0 ORDER BY t1.a, t2.b;
+--
+-- For asymmetric partition-wise join
+--
+CREATE TABLE prt5 (hkey int, a int, b int) PARTITION BY HASH(hkey);
+CREATE TABLE prt5_p0 PARTITION OF prt5
+ FOR VALUES WITH (modulus 3, remainder 0);
+CREATE TABLE prt5_p1 PARTITION OF prt5
+ FOR VALUES WITH (modulus 3, remainder 1);
+CREATE TABLE prt5_p2 PARTITION OF prt5
+ FOR VALUES WITH (modulus 3, remainder 2);
+CREATE TABLE t5_1 (aid int, alabel text);
+CREATE TABLE t5_2 (bid int, blabel text);
+
+INSERT INTO prt5 (SELECT x, (1000.0 * random())::int,
+ (1000.0 * random())::int
+ FROM generate_series(1,1000000) x);
+INSERT INTO t5_1 (SELECT x, md5(x::text) FROM generate_series(-200, 800) x);
+INSERT INTO t5_2 (SELECT x, md5(x::text) FROM generate_series(-200, 800) x);
+
+VACUUM ANALYZE prt5;
+VACUUM ANALYZE t5_1;
+VACUUM ANALYZE t5_2;
+
+SET max_parallel_workers_per_gather = 0;
+EXPLAIN (COSTS OFF)
+SELECT *
+ FROM prt5 JOIN t5_1 ON a = aid AND alabel like '%abc%';
+
+EXPLAIN (COSTS OFF)
+SELECT *
+ FROM prt5 JOIN t5_1 ON a = aid AND alabel like '%ab%'
+ JOIN t5_2 ON b = bid AND blabel like '%cd%';
+
+-- unable to extract non-partitioned right relation
+EXPLAIN (COSTS OFF)
+SELECT * FROM prt5 RIGHT JOIN t5_1 ON a = aid AND alabel like '%abc%';
+-- left side can be extracted, but no cost benefit
+EXPLAIN (COSTS OFF)
+SELECT * FROM prt5 LEFT JOIN t5_1 ON a = aid AND alabel like '%abc%';
+
+-- validation of the results with/without asymmetric partition-wise join
+SELECT * INTO pg_temp.result01a
+ FROM prt5 JOIN t5_1 ON a = aid AND alabel like '%abc%';
+
+SELECT * INTO pg_temp.result02a
+ FROM prt5 JOIN t5_1 ON a = aid AND alabel like '%ab%'
+ JOIN t5_2 ON b = bid AND blabel like '%cd%';
+
+SET enable_partitionwise_join = off;
+
+SELECT * INTO pg_temp.result01b
+ FROM prt5 JOIN t5_1 ON a = aid AND alabel like '%abc%';
+
+SELECT * INTO pg_temp.result02b
+ FROM prt5 JOIN t5_1 ON a = aid AND alabel like '%ab%'
+ JOIN t5_2 ON b = bid AND blabel like '%cd%';
+
+SELECT * FROM pg_temp.result01a EXCEPT SELECT * FROM pg_temp.result01b;
+SELECT * FROM pg_temp.result02a EXCEPT SELECT * FROM pg_temp.result02b;
+
+RESET max_parallel_workers_per_gather;
+SET enable_partitionwise_join = true;
+
+-- Parameterized path examples.
+CREATE TABLE prta (id integer, payload text) PARTITION BY HASH (id);
+CREATE TABLE prta1 PARTITION OF prta FOR VALUES WITH (modulus 2, remainder 0);
+CREATE TABLE prta2 PARTITION OF prta FOR VALUES WITH (modulus 2, remainder 1);
+CREATE UNIQUE INDEX ON prta1 (id);
+CREATE UNIQUE INDEX ON prta2 (id);
+INSERT INTO prta (id, payload)
+ (SELECT *, ('abc' || id)::text AS payload
+ FROM generate_series(1,1) AS id);
+
+CREATE TABLE prtb (id integer, payload text) PARTITION BY HASH (id);
+CREATE TABLE prtb1 PARTITION OF prtb FOR VALUES WITH (modulus 2, remainder 0);
+CREATE TABLE prtb2 PARTITION OF prtb FOR VALUES WITH (modulus 2, remainder 1);
+CREATE UNIQUE INDEX ON prtb1 (id);
+CREATE UNIQUE INDEX ON prtb2 (id);
+INSERT INTO prtb (id, payload)
+ (SELECT *, ('def' || id)::text AS payload
+ FROM generate_series(1,1000) AS id);
+
+CREATE TABLE e (id integer, payload text) PARTITION BY HASH (id);
+CREATE TABLE e1 PARTITION OF e FOR VALUES WITH (modulus 2, remainder 0);
+CREATE TABLE e2 PARTITION OF e FOR VALUES WITH (modulus 2, remainder 1);
+INSERT INTO e (id, payload)
+ (SELECT *, ('ghi' || id)::text AS payload
+ FROM generate_series(1,1000) AS id);
+CREATE UNIQUE INDEX ON e1 (id);
+CREATE UNIQUE INDEX ON e2 (id);
+
+ANALYZE prta,prtb,e;
+
+EXPLAIN (COSTS OFF)
+SELECT * FROM prta,prtb WHERE prta.id=prtb.id;
+
+EXPLAIN (COSTS OFF)
+SELECT * FROM prta,prtb,e WHERE prta.id=prtb.id AND prta.id=e.id;
+
-- semi join
EXPLAIN (COSTS OFF)
SELECT t1.* FROM prt1_adv t1 WHERE EXISTS (SELECT 1 FROM prt2_adv t2 WHERE t1.a = t2.b) AND t1.b = 0 ORDER BY t1.a;
--
2.25.1
--------------8EB2F9A6243C623F4024291E--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Asymmetric partitionwise join.
@ 2021-04-02 06:02 Andrey Lepikhov <a.lepikhov@postgrespro.ru>
0 siblings, 0 replies; 538+ messages in thread
From: Andrey Lepikhov @ 2021-04-02 06:02 UTC (permalink / raw)
Teach optimizer to consider partitionwise join of non-partitioned
table with each partition of partitioned table.
Disallow asymmetric machinery for joining of two partitioned (or appended)
relations because it could cause huge consumption of CPU and memory
during reparameterization of NestLoop path.
Change logic of the multilevel child relids adjustment, because this
feature allows the optimizer to plan in new way.
---
src/backend/optimizer/path/joinpath.c | 9 +
src/backend/optimizer/path/joinrels.c | 187 +++++++++
src/backend/optimizer/plan/setrefs.c | 17 +-
src/backend/optimizer/util/appendinfo.c | 51 ++-
src/backend/optimizer/util/pathnode.c | 9 +-
src/backend/optimizer/util/relnode.c | 19 +-
src/include/optimizer/paths.h | 7 +-
src/test/regress/expected/partition_join.out | 378 +++++++++++++++++++
src/test/regress/sql/partition_join.sql | 167 ++++++++
9 files changed, 808 insertions(+), 36 deletions(-)
diff --git a/src/backend/optimizer/path/joinpath.c b/src/backend/optimizer/path/joinpath.c
index 6407ede12a..32618ebbd5 100644
--- a/src/backend/optimizer/path/joinpath.c
+++ b/src/backend/optimizer/path/joinpath.c
@@ -335,6 +335,15 @@ add_paths_to_joinrel(PlannerInfo *root,
if (set_join_pathlist_hook)
set_join_pathlist_hook(root, joinrel, outerrel, innerrel,
jointype, &extra);
+
+ /*
+ * 7. If outer relation is delivered from partition-tables, consider
+ * distributing inner relation to every partition-leaf prior to
+ * append these leafs.
+ */
+ try_asymmetric_partitionwise_join(root, joinrel,
+ outerrel, innerrel,
+ jointype, &extra);
}
/*
diff --git a/src/backend/optimizer/path/joinrels.c b/src/backend/optimizer/path/joinrels.c
index 8b69870cf4..9453258f83 100644
--- a/src/backend/optimizer/path/joinrels.c
+++ b/src/backend/optimizer/path/joinrels.c
@@ -16,6 +16,7 @@
#include "miscadmin.h"
#include "optimizer/appendinfo.h"
+#include "optimizer/cost.h"
#include "optimizer/joininfo.h"
#include "optimizer/pathnode.h"
#include "optimizer/paths.h"
@@ -1552,6 +1553,192 @@ try_partitionwise_join(PlannerInfo *root, RelOptInfo *rel1, RelOptInfo *rel2,
}
}
+/*
+ * Build RelOptInfo on JOIN of each partition of the outer relation and the inner
+ * relation. Return List of such RelOptInfo's. Return NIL, if at least one of
+ * these JOINs is impossible to build.
+ */
+static List *
+extract_asymmetric_partitionwise_subjoin(PlannerInfo *root,
+ RelOptInfo *joinrel,
+ AppendPath *append_path,
+ RelOptInfo *inner_rel,
+ JoinType jointype,
+ JoinPathExtraData *extra)
+{
+ List *result = NIL;
+ ListCell *lc;
+
+ foreach (lc, append_path->subpaths)
+ {
+ Path *child_path = lfirst(lc);
+ RelOptInfo *child_rel = child_path->parent;
+ Relids child_joinrelids;
+ Relids parent_relids;
+ RelOptInfo *child_joinrel;
+ SpecialJoinInfo *child_sjinfo;
+ List *child_restrictlist;
+
+ child_joinrelids = bms_union(child_rel->relids, inner_rel->relids);
+ parent_relids = bms_union(append_path->path.parent->relids,
+ inner_rel->relids);
+
+ child_sjinfo = build_child_join_sjinfo(root, extra->sjinfo,
+ child_rel->relids,
+ inner_rel->relids);
+ child_restrictlist = (List *)
+ adjust_appendrel_attrs_multilevel(root, (Node *)extra->restrictlist,
+ child_joinrelids, parent_relids);
+
+ child_joinrel = find_join_rel(root, child_joinrelids);
+ if (!child_joinrel)
+ child_joinrel = build_child_join_rel(root,
+ child_rel,
+ inner_rel,
+ joinrel,
+ child_restrictlist,
+ child_sjinfo,
+ jointype);
+ else
+ {
+ /*
+ * The join relation already exists. For example, it could happen if
+ * we join two plane tables with partitioned table(s).
+ * Populating this join with additional paths could push out some
+ * previously added paths which could be pointed in a subplans list
+ * of an higher level append.
+ * Of course, we could save such paths before generating new. But it
+ * can increase too much the number of paths in complex queries. It
+ * can be a task for future work.
+ */
+ return NIL;
+ }
+
+ populate_joinrel_with_paths(root,
+ child_rel,
+ inner_rel,
+ child_joinrel,
+ child_sjinfo,
+ child_restrictlist);
+
+ /* Give up if asymmetric partition-wise join is not available */
+ if (child_joinrel->pathlist == NIL)
+ return NIL;
+
+ set_cheapest(child_joinrel);
+ result = lappend(result, child_joinrel);
+ }
+ return result;
+}
+
+static bool
+is_asymmetric_join_feasible(PlannerInfo *root,
+ RelOptInfo *outer_rel,
+ RelOptInfo *inner_rel,
+ JoinType jointype)
+{
+ ListCell *lc;
+
+ if (jointype != JOIN_INNER && jointype != JOIN_LEFT)
+ return false;
+
+ if (IS_OTHER_REL(outer_rel) || IS_OTHER_REL(inner_rel))
+ return false;
+
+ /* Disallow recursive usage of asymmertic join machinery */
+ if (root->join_rel_level == NULL)
+ return false;
+
+ /*
+ * Don't allow asymmetric JOIN of two append subplans.
+ * In the case of a parameterized NL join, a reparameterization procedure
+ * will lead to large memory allocations and a CPU consumption:
+ * each reparameterization will induce subpath duplication, creating new
+ * ParamPathInfo instance and increasing of ppilist up to number of
+ * partitions in the inner. Also, if we have many partitions, each bitmapset
+ * variable will be large and many leaks of such variable (caused by relid
+ * replacement) will highly increase memory consumption.
+ * So, we deny such paths for now.
+ */
+ foreach(lc, inner_rel->pathlist)
+ {
+ if (IsA(lfirst(lc), AppendPath))
+ return false;
+ }
+
+ return true;
+}
+
+void
+try_asymmetric_partitionwise_join(PlannerInfo *root,
+ RelOptInfo *joinrel,
+ RelOptInfo *outer_rel,
+ RelOptInfo *inner_rel,
+ JoinType jointype,
+ JoinPathExtraData *extra)
+{
+ ListCell *lc;
+
+ /*
+ * Try this kind of paths if we allow complex partitionwise joins and we know
+ * we can build this join safely.
+ */
+ if (!enable_partitionwise_join ||
+ !is_asymmetric_join_feasible(root, outer_rel, inner_rel, jointype))
+ return;
+
+ foreach (lc, outer_rel->pathlist)
+ {
+ AppendPath *append_path = lfirst(lc);
+
+ /*
+ * We assume this pathlist keeps at least one AppendPath that
+ * represents partitioned table-scan, symmetric or asymmetric
+ * partition-wise join. Asymmetric join isn't needed if the append node
+ * has only one child.
+ */
+ if (IsA(append_path, AppendPath) &&
+ list_length(append_path->subpaths) > 1)
+ {
+ List **join_rel_level_saved;
+ List *live_childrels = NIL;
+
+ join_rel_level_saved = root->join_rel_level;
+ PG_TRY();
+ {
+ /* temporary disables "dynamic programming" algorithm */
+ root->join_rel_level = NULL;
+
+ live_childrels =
+ extract_asymmetric_partitionwise_subjoin(root,
+ joinrel,
+ append_path,
+ inner_rel,
+ jointype,
+ extra);
+ }
+ PG_FINALLY();
+ {
+ root->join_rel_level = join_rel_level_saved;
+ }
+ PG_END_TRY();
+
+ if (live_childrels != NIL)
+ {
+ /*
+ * Add new append relation. We must choose cheapest paths after
+ * this operation because the pathlist possibly contains
+ * joinrels and appendrels that can be suboptimal.
+ */
+ add_paths_to_append_rel(root, joinrel, live_childrels);
+ set_cheapest(joinrel);
+ }
+
+ break;
+ }
+ }
+}
+
/*
* Construct the SpecialJoinInfo for a child-join by translating
* SpecialJoinInfo for the join between parents. left_relids and right_relids
diff --git a/src/backend/optimizer/plan/setrefs.c b/src/backend/optimizer/plan/setrefs.c
index e50624c465..fccc0685d7 100644
--- a/src/backend/optimizer/plan/setrefs.c
+++ b/src/backend/optimizer/plan/setrefs.c
@@ -281,24 +281,29 @@ set_plan_references(PlannerInfo *root, Plan *plan)
/*
* Adjust RT indexes of AppendRelInfos and add to final appendrels list.
- * We assume the AppendRelInfos were built during planning and don't need
- * to be copied.
+ * The AppendRelInfos are copied, because as a part of a subplan they could
+ * be visited many times in the case of asymmetric join.
*/
foreach(lc, root->append_rel_list)
{
AppendRelInfo *appinfo = lfirst_node(AppendRelInfo, lc);
+ AppendRelInfo *newappinfo;
+
+ /* flat copy is enough since all valuable fields are scalars */
+ newappinfo = (AppendRelInfo *) palloc(sizeof(AppendRelInfo));
+ memcpy(newappinfo, appinfo, sizeof(AppendRelInfo));
/* adjust RT indexes */
- appinfo->parent_relid += rtoffset;
- appinfo->child_relid += rtoffset;
+ newappinfo->parent_relid += rtoffset;
+ newappinfo->child_relid += rtoffset;
/*
* Rather than adjust the translated_vars entries, just drop 'em.
* Neither the executor nor EXPLAIN currently need that data.
*/
- appinfo->translated_vars = NIL;
+ newappinfo->translated_vars = NIL;
- glob->appendRelations = lappend(glob->appendRelations, appinfo);
+ glob->appendRelations = lappend(glob->appendRelations, newappinfo);
}
/* Now fix the Plan tree */
diff --git a/src/backend/optimizer/util/appendinfo.c b/src/backend/optimizer/util/appendinfo.c
index af46f581ac..3ae25f3444 100644
--- a/src/backend/optimizer/util/appendinfo.c
+++ b/src/backend/optimizer/util/appendinfo.c
@@ -202,7 +202,9 @@ adjust_appendrel_attrs(PlannerInfo *root, Node *node, int nappinfos,
context.appinfos = appinfos;
/* If there's nothing to adjust, don't call this function. */
- Assert(nappinfos >= 1 && appinfos != NULL);
+ /* If there's nothing to adjust, just return a duplication */
+ if (nappinfos == 0)
+ return copyObject(node);
/* Should never be translating a Query tree. */
Assert(node == NULL || !IsA(node, Query));
@@ -489,12 +491,10 @@ adjust_appendrel_attrs_multilevel(PlannerInfo *root, Node *node,
Relids child_relids,
Relids top_parent_relids)
{
- AppendRelInfo **appinfos;
- Bitmapset *parent_relids = NULL;
- int nappinfos;
- int cnt;
-
- Assert(bms_num_members(child_relids) == bms_num_members(top_parent_relids));
+ AppendRelInfo **appinfos;
+ Relids parent_relids = NULL;
+ int nappinfos;
+ int cnt;
appinfos = find_appinfos_by_relids(root, child_relids, &nappinfos);
@@ -506,8 +506,13 @@ adjust_appendrel_attrs_multilevel(PlannerInfo *root, Node *node,
parent_relids = bms_add_member(parent_relids, appinfo->parent_relid);
}
- /* Recurse if immediate parent is not the top parent. */
- if (!bms_equal(parent_relids, top_parent_relids))
+ /*
+ * Recurse if immediate parent is not the top parent. Keep in mind that in a
+ * case of asymmetric JOIN top_parent_relids can contain relids which aren't
+ * part of an append node.
+ */
+ if (!bms_equal(parent_relids, top_parent_relids) &&
+ !bms_is_subset(parent_relids, top_parent_relids))
node = adjust_appendrel_attrs_multilevel(root, node, parent_relids,
top_parent_relids);
@@ -515,12 +520,13 @@ adjust_appendrel_attrs_multilevel(PlannerInfo *root, Node *node,
node = adjust_appendrel_attrs(root, node, nappinfos, appinfos);
pfree(appinfos);
+ pfree(parent_relids);
return node;
}
/*
- * Substitute child relids for parent relids in a Relid set. The array of
+ * Substitute child relids for parent relids in a Relid set. The array of
* appinfos specifies the substitutions to be performed.
*/
Relids
@@ -565,8 +571,9 @@ adjust_child_relids_multilevel(PlannerInfo *root, Relids relids,
AppendRelInfo **appinfos;
int nappinfos;
Relids parent_relids = NULL;
+ Relids normal_relids = NULL;
Relids result;
- Relids tmp_result = NULL;
+ Relids tmp_result = relids;
int cnt;
/*
@@ -579,12 +586,17 @@ adjust_child_relids_multilevel(PlannerInfo *root, Relids relids,
appinfos = find_appinfos_by_relids(root, child_relids, &nappinfos);
/* Construct relids set for the immediate parent of the given child. */
+ normal_relids = bms_copy(child_relids);
for (cnt = 0; cnt < nappinfos; cnt++)
{
AppendRelInfo *appinfo = appinfos[cnt];
parent_relids = bms_add_member(parent_relids, appinfo->parent_relid);
+ normal_relids = bms_del_member(normal_relids, appinfo->child_relid);
}
+ parent_relids = bms_union(parent_relids, normal_relids);
+ if (normal_relids)
+ bms_free(normal_relids);
/* Recurse if immediate parent is not the top parent. */
if (!bms_equal(parent_relids, top_parent_relids))
@@ -592,13 +604,15 @@ adjust_child_relids_multilevel(PlannerInfo *root, Relids relids,
tmp_result = adjust_child_relids_multilevel(root, relids,
parent_relids,
top_parent_relids);
- relids = tmp_result;
}
- result = adjust_child_relids(relids, nappinfos, appinfos);
+ result = adjust_child_relids(tmp_result, nappinfos, appinfos);
- /* Free memory consumed by any intermediate result. */
- if (tmp_result)
+ /*
+ * Free memory consumed by any intermediate result. If recursive pass did't
+ * replace any relids, tmp_result point to the original set, not a copy.
+ */
+ if (tmp_result != relids)
bms_free(tmp_result);
bms_free(parent_relids);
pfree(appinfos);
@@ -715,11 +729,11 @@ AppendRelInfo **
find_appinfos_by_relids(PlannerInfo *root, Relids relids, int *nappinfos)
{
AppendRelInfo **appinfos;
+ int nrooms = bms_num_members(relids);
int cnt = 0;
int i;
- *nappinfos = bms_num_members(relids);
- appinfos = (AppendRelInfo **) palloc(sizeof(AppendRelInfo *) * *nappinfos);
+ appinfos = (AppendRelInfo **) palloc(sizeof(AppendRelInfo *) * nrooms);
i = -1;
while ((i = bms_next_member(relids, i)) >= 0)
@@ -727,10 +741,11 @@ find_appinfos_by_relids(PlannerInfo *root, Relids relids, int *nappinfos)
AppendRelInfo *appinfo = root->append_rel_array[i];
if (!appinfo)
- elog(ERROR, "child rel %d not found in append_rel_array", i);
+ continue;
appinfos[cnt++] = appinfo;
}
+ *nappinfos = cnt;
return appinfos;
}
diff --git a/src/backend/optimizer/util/pathnode.c b/src/backend/optimizer/util/pathnode.c
index cedb3848dd..17e215b72d 100644
--- a/src/backend/optimizer/util/pathnode.c
+++ b/src/backend/optimizer/util/pathnode.c
@@ -4225,7 +4225,14 @@ do { \
MemoryContextSwitchTo(oldcontext);
}
- bms_free(required_outer);
+
+ /*
+ * If adjust_child_relids_multilevel don't do replacements it returns
+ * the original set, not a copy. It is possible in the case of asymmetric
+ * JOIN and child_rel->relids contains relids only of plane relations.
+ */
+ if (required_outer != old_ppi->ppi_req_outer)
+ bms_free(required_outer);
new_path->param_info = new_ppi;
diff --git a/src/backend/optimizer/util/relnode.c b/src/backend/optimizer/util/relnode.c
index 47769cea45..ddf0f5a876 100644
--- a/src/backend/optimizer/util/relnode.c
+++ b/src/backend/optimizer/util/relnode.c
@@ -792,11 +792,8 @@ build_child_join_rel(PlannerInfo *root, RelOptInfo *outer_rel,
AppendRelInfo **appinfos;
int nappinfos;
- /* Only joins between "other" relations land here. */
- Assert(IS_OTHER_REL(outer_rel) && IS_OTHER_REL(inner_rel));
-
- /* The parent joinrel should have consider_partitionwise_join set. */
- Assert(parent_joinrel->consider_partitionwise_join);
+ /* Either of relations must be "other" relation at least. */
+ Assert(IS_OTHER_REL(outer_rel) || IS_OTHER_REL(inner_rel));
joinrel->reloptkind = RELOPT_OTHER_JOINREL;
joinrel->relids = bms_union(outer_rel->relids, inner_rel->relids);
@@ -854,8 +851,11 @@ build_child_join_rel(PlannerInfo *root, RelOptInfo *outer_rel,
joinrel->partexprs = NULL;
joinrel->nullable_partexprs = NULL;
- joinrel->top_parent_relids = bms_union(outer_rel->top_parent_relids,
- inner_rel->top_parent_relids);
+ joinrel->top_parent_relids =
+ bms_union(IS_OTHER_REL(outer_rel) ?
+ outer_rel->top_parent_relids : outer_rel->relids,
+ IS_OTHER_REL(inner_rel) ?
+ inner_rel->top_parent_relids : inner_rel->relids);
/* Compute information relevant to foreign relations. */
set_foreign_rel_properties(joinrel, outer_rel, inner_rel);
@@ -2036,9 +2036,8 @@ build_child_join_reltarget(PlannerInfo *root,
{
/* Build the targetlist */
childrel->reltarget->exprs = (List *)
- adjust_appendrel_attrs(root,
- (Node *) parentrel->reltarget->exprs,
- nappinfos, appinfos);
+ adjust_appendrel_attrs_multilevel(root, (Node *)parentrel->reltarget->exprs,
+ childrel->relids, parentrel->relids);
/* Set the cost and width fields */
childrel->reltarget->cost.startup = parentrel->reltarget->cost.startup;
diff --git a/src/include/optimizer/paths.h b/src/include/optimizer/paths.h
index f1d111063c..a0106dc539 100644
--- a/src/include/optimizer/paths.h
+++ b/src/include/optimizer/paths.h
@@ -109,7 +109,12 @@ extern bool have_join_order_restriction(PlannerInfo *root,
extern bool have_dangerous_phv(PlannerInfo *root,
Relids outer_relids, Relids inner_params);
extern void mark_dummy_rel(RelOptInfo *rel);
-
+extern void try_asymmetric_partitionwise_join(PlannerInfo *root,
+ RelOptInfo *joinrel,
+ RelOptInfo *outer_rel,
+ RelOptInfo *inner_rel,
+ JoinType jointype,
+ JoinPathExtraData *extra);
/*
* equivclass.c
* routines for managing EquivalenceClasses
diff --git a/src/test/regress/expected/partition_join.out b/src/test/regress/expected/partition_join.out
index 27f7525b3e..327505676c 100644
--- a/src/test/regress/expected/partition_join.out
+++ b/src/test/regress/expected/partition_join.out
@@ -2320,6 +2320,384 @@ SELECT t1.a, t1.c, t2.b, t2.c FROM prt1_adv t1 INNER JOIN prt2_adv t2 ON (t1.a =
375 | 0375 | 375 | 0375
(8 rows)
+--
+-- For asymmetric partition-wise join
+--
+CREATE TABLE prt5 (hkey int, a int, b int) PARTITION BY HASH(hkey);
+CREATE TABLE prt5_p0 PARTITION OF prt5
+ FOR VALUES WITH (modulus 3, remainder 0);
+CREATE TABLE prt5_p1 PARTITION OF prt5
+ FOR VALUES WITH (modulus 3, remainder 1);
+CREATE TABLE prt5_p2 PARTITION OF prt5
+ FOR VALUES WITH (modulus 3, remainder 2);
+CREATE TABLE prt6 (aid int, alabel text) PARTITION BY HASH(aid);
+CREATE TABLE prt6_p0 PARTITION OF prt6
+ FOR VALUES WITH (modulus 2, remainder 0);
+CREATE TABLE prt6_p1 PARTITION OF prt6
+ FOR VALUES WITH (modulus 2, remainder 1);
+CREATE TABLE t5_1 (aid int, alabel text);
+CREATE TABLE t5_2 (bid int, blabel text);
+INSERT INTO prt5 (SELECT x, (x % 1000)::int,
+ ((x+1) % 1000)::int
+ FROM generate_series(1,1000000) x);
+INSERT INTO t5_1 (SELECT x, md5(x::text) FROM generate_series(-200, 1500) x);
+INSERT INTO t5_2 (SELECT x, md5(x::text) FROM generate_series(-200, 1500) x);
+INSERT INTO prt6 (SELECT * FROM t5_1);
+VACUUM ANALYZE prt5,prt6,t5_1,t5_2;
+SET max_parallel_workers_per_gather = 0;
+-- Trivial asymmetric JOIN of partitioned table with a relation
+EXPLAIN (COSTS OFF)
+SELECT *
+ FROM prt5 JOIN t5_1 ON a = aid AND alabel like '%abc%';
+ QUERY PLAN
+-------------------------------------------------------
+ Append
+ -> Hash Join
+ Hash Cond: (prt5_1.a = t5_1.aid)
+ -> Seq Scan on prt5_p0 prt5_1
+ -> Hash
+ -> Seq Scan on t5_1
+ Filter: (alabel ~~ '%abc%'::text)
+ -> Hash Join
+ Hash Cond: (prt5_2.a = t5_1.aid)
+ -> Seq Scan on prt5_p1 prt5_2
+ -> Hash
+ -> Seq Scan on t5_1
+ Filter: (alabel ~~ '%abc%'::text)
+ -> Hash Join
+ Hash Cond: (prt5_3.a = t5_1.aid)
+ -> Seq Scan on prt5_p2 prt5_3
+ -> Hash
+ -> Seq Scan on t5_1
+ Filter: (alabel ~~ '%abc%'::text)
+(19 rows)
+
+-- The same, but appended with UNION ALL
+EXPLAIN (COSTS OFF)
+SELECT * FROM (
+ (SELECT * FROM prt5_p0)
+ UNION ALL
+ (SELECT * FROM prt5_p1)
+ UNION ALL
+ (SELECT * FROM prt5_p2)
+ ) AS sq1
+JOIN t5_1 ON a = aid AND alabel like '%abc%';
+ QUERY PLAN
+-------------------------------------------------------
+ Append
+ -> Hash Join
+ Hash Cond: (prt5_p0.a = t5_1.aid)
+ -> Seq Scan on prt5_p0
+ -> Hash
+ -> Seq Scan on t5_1
+ Filter: (alabel ~~ '%abc%'::text)
+ -> Hash Join
+ Hash Cond: (prt5_p1.a = t5_1.aid)
+ -> Seq Scan on prt5_p1
+ -> Hash
+ -> Seq Scan on t5_1
+ Filter: (alabel ~~ '%abc%'::text)
+ -> Hash Join
+ Hash Cond: (prt5_p2.a = t5_1.aid)
+ -> Seq Scan on prt5_p2
+ -> Hash
+ -> Seq Scan on t5_1
+ Filter: (alabel ~~ '%abc%'::text)
+(19 rows)
+
+-- Don't allow asymmetric JOIN of two partitioned tables.
+EXPLAIN (COSTS OFF)
+SELECT count(*) FROM prt5 JOIN prt6 ON a = aid AND alabel like '%abc%';
+ QUERY PLAN
+-------------------------------------------------------------
+ Aggregate
+ -> Hash Join
+ Hash Cond: (prt5.a = prt6.aid)
+ -> Append
+ -> Seq Scan on prt5_p0 prt5_1
+ -> Seq Scan on prt5_p1 prt5_2
+ -> Seq Scan on prt5_p2 prt5_3
+ -> Hash
+ -> Append
+ -> Seq Scan on prt6_p0 prt6_1
+ Filter: (alabel ~~ '%abc%'::text)
+ -> Seq Scan on prt6_p1 prt6_2
+ Filter: (alabel ~~ '%abc%'::text)
+(13 rows)
+
+SELECT count(*) FROM prt5 JOIN prt6 ON a = aid AND alabel like '%abc%';
+ count
+-------
+ 4000
+(1 row)
+
+-- Check asymmetric JOIN with Subquery
+EXPLAIN (COSTS OFF)
+SELECT count(*) FROM prt5 JOIN (
+ SELECT * FROM prt6 LIMIT 1000
+) AS sq1 ON a = aid AND alabel like '%abc%';
+ QUERY PLAN
+----------------------------------------------------------------------
+ Aggregate
+ -> Append
+ -> Hash Join
+ Hash Cond: (prt5_1.a = sq1.aid)
+ -> Seq Scan on prt5_p0 prt5_1
+ -> Hash
+ -> Subquery Scan on sq1
+ Filter: (sq1.alabel ~~ '%abc%'::text)
+ -> Limit
+ -> Append
+ -> Seq Scan on prt6_p0 prt6_1
+ -> Seq Scan on prt6_p1 prt6_2
+ -> Hash Join
+ Hash Cond: (prt5_2.a = sq1.aid)
+ -> Seq Scan on prt5_p1 prt5_2
+ -> Hash
+ -> Subquery Scan on sq1
+ Filter: (sq1.alabel ~~ '%abc%'::text)
+ -> Limit
+ -> Append
+ -> Seq Scan on prt6_p0 prt6_4
+ -> Seq Scan on prt6_p1 prt6_5
+ -> Hash Join
+ Hash Cond: (prt5_3.a = sq1.aid)
+ -> Seq Scan on prt5_p2 prt5_3
+ -> Hash
+ -> Subquery Scan on sq1
+ Filter: (sq1.alabel ~~ '%abc%'::text)
+ -> Limit
+ -> Append
+ -> Seq Scan on prt6_p0 prt6_7
+ -> Seq Scan on prt6_p1 prt6_8
+(32 rows)
+
+SELECT count(*) FROM prt5 JOIN (SELECT * FROM prt6 LIMIT 1000) AS sq1
+ ON a = aid AND alabel like '%abc%';
+ count
+-------
+ 2000
+(1 row)
+
+-- Asymmetric JOIN of two plane tables and one partitioned
+EXPLAIN (COSTS OFF)
+SELECT count(*)
+ FROM prt5 JOIN t5_1 ON a = aid AND alabel like '%ab%'
+ JOIN t5_2 ON b = bid AND blabel like '%cd%';
+ QUERY PLAN
+------------------------------------------------------------------
+ Aggregate
+ -> Append
+ -> Hash Join
+ Hash Cond: (prt5_1.b = t5_2.bid)
+ -> Hash Join
+ Hash Cond: (prt5_1.a = t5_1.aid)
+ -> Seq Scan on prt5_p0 prt5_1
+ -> Hash
+ -> Seq Scan on t5_1
+ Filter: (alabel ~~ '%ab%'::text)
+ -> Hash
+ -> Seq Scan on t5_2
+ Filter: (blabel ~~ '%cd%'::text)
+ -> Hash Join
+ Hash Cond: (prt5_2.b = t5_2.bid)
+ -> Hash Join
+ Hash Cond: (prt5_2.a = t5_1.aid)
+ -> Seq Scan on prt5_p1 prt5_2
+ -> Hash
+ -> Seq Scan on t5_1
+ Filter: (alabel ~~ '%ab%'::text)
+ -> Hash
+ -> Seq Scan on t5_2
+ Filter: (blabel ~~ '%cd%'::text)
+ -> Hash Join
+ Hash Cond: (prt5_3.b = t5_2.bid)
+ -> Hash Join
+ Hash Cond: (prt5_3.a = t5_1.aid)
+ -> Seq Scan on prt5_p2 prt5_3
+ -> Hash
+ -> Seq Scan on t5_1
+ Filter: (alabel ~~ '%ab%'::text)
+ -> Hash
+ -> Seq Scan on t5_2
+ Filter: (blabel ~~ '%cd%'::text)
+(35 rows)
+
+SELECT count(*)
+ FROM prt5 JOIN t5_1 ON a = aid AND alabel like '%ab%'
+ JOIN t5_2 ON b = bid AND blabel like '%cd%';
+ count
+-------
+ 11000
+(1 row)
+
+-- unable to extract non-partitioned right relation
+EXPLAIN (COSTS OFF)
+SELECT * FROM prt5 RIGHT JOIN t5_1 ON a = aid AND alabel like '%abc%';
+ QUERY PLAN
+-----------------------------------------------
+ Hash Right Join
+ Hash Cond: (prt5.a = t5_1.aid)
+ Join Filter: (t5_1.alabel ~~ '%abc%'::text)
+ -> Append
+ -> Seq Scan on prt5_p0 prt5_1
+ -> Seq Scan on prt5_p1 prt5_2
+ -> Seq Scan on prt5_p2 prt5_3
+ -> Hash
+ -> Seq Scan on t5_1
+(9 rows)
+
+-- left side can be extracted, but no cost benefit
+EXPLAIN (COSTS OFF)
+SELECT * FROM prt5 LEFT JOIN t5_1 ON a = aid AND alabel like '%abc%';
+ QUERY PLAN
+-------------------------------------------------
+ Hash Left Join
+ Hash Cond: (prt5.a = t5_1.aid)
+ -> Append
+ -> Seq Scan on prt5_p0 prt5_1
+ -> Seq Scan on prt5_p1 prt5_2
+ -> Seq Scan on prt5_p2 prt5_3
+ -> Hash
+ -> Seq Scan on t5_1
+ Filter: (alabel ~~ '%abc%'::text)
+(9 rows)
+
+-- validation of the results with/without asymmetric partition-wise join
+SELECT * INTO pg_temp.result01a
+ FROM prt5 JOIN t5_1 ON a = aid AND alabel like '%abc%';
+SELECT * INTO pg_temp.result02a
+ FROM prt5 JOIN t5_1 ON a = aid AND alabel like '%ab%'
+ JOIN t5_2 ON b = bid AND blabel like '%cd%';
+SET enable_partitionwise_join = off;
+SELECT * INTO pg_temp.result01b
+ FROM prt5 JOIN t5_1 ON a = aid AND alabel like '%abc%';
+SELECT * INTO pg_temp.result02b
+ FROM prt5 JOIN t5_1 ON a = aid AND alabel like '%ab%'
+ JOIN t5_2 ON b = bid AND blabel like '%cd%';
+SELECT * FROM pg_temp.result01a EXCEPT SELECT * FROM pg_temp.result01b;
+ hkey | a | b | aid | alabel
+------+---+---+-----+--------
+(0 rows)
+
+SELECT * FROM pg_temp.result02a EXCEPT SELECT * FROM pg_temp.result02b;
+ hkey | a | b | aid | alabel | bid | blabel
+------+---+---+-----+--------+-----+--------
+(0 rows)
+
+SET enable_partitionwise_join = on;
+-- Check reparameterization code when required_outer set contains relid of plain
+-- relation entry, not 'other' entry.
+SET enable_hashjoin = 'off';
+SET enable_mergejoin = 'off';
+SET enable_material = 'off';
+CREATE TABLE big AS SELECT x AS x FROM generate_series(1,1E4) x;
+CREATE INDEX ON big(x);
+CREATE TABLE small AS SELECT x, -x AS y FROM generate_series(1,100) x;
+CREATE TABLE part_l0 (x int, y int, z int) PARTITION BY HASH (y);
+CREATE TABLE part0_l1 PARTITION OF part_l0 (y)
+ FOR VALUES WITH (modulus 2, remainder 0) PARTITION BY HASH (z);
+CREATE TABLE part0_l2 PARTITION OF part0_l1 (z)
+ FOR VALUES WITH (modulus 2, remainder 0);
+CREATE TABLE part1_l2 PARTITION OF part0_l1 (z)
+ FOR VALUES WITH (modulus 2, remainder 1);
+CREATE TABLE part1_l1 PARTITION OF part_l0 (y)
+ FOR VALUES WITH (modulus 2, remainder 1);
+INSERT INTO part_l0 (x, y, z) (SELECT x,x,x FROM generate_series(1,1E4) x);
+ANALYZE big,small,part_l0;
+EXPLAIN
+SELECT small.* FROM small
+ JOIN part_l0 ON small.y = part_l0.y AND small.y + part_l0.y < 10
+ LEFT JOIN big ON big.x = small.x;
+ QUERY PLAN
+-----------------------------------------------------------------------------------------
+ Nested Loop Left Join (cost=0.29..33230.19 rows=33 width=8)
+ -> Append (cost=0.00..33008.08 rows=67 width=8)
+ -> Nested Loop (cost=0.00..16604.25 rows=33 width=8)
+ Join Filter: ((small.y = part_l0_1.y) AND ((small.y + part_l0_1.y) < 10))
+ -> Seq Scan on small (cost=0.00..2.00 rows=100 width=8)
+ -> Seq Scan on part0_l2 part_l0_1 (cost=0.00..78.19 rows=5019 width=4)
+ -> Nested Loop (cost=0.00..3.75 rows=1 width=8)
+ Join Filter: ((small.y = part_l0_2.y) AND ((small.y + part_l0_2.y) < 10))
+ -> Seq Scan on part1_l2 part_l0_2 (cost=0.00..0.00 rows=1 width=4)
+ -> Seq Scan on small (cost=0.00..2.00 rows=100 width=8)
+ -> Nested Loop (cost=0.00..16399.75 rows=33 width=8)
+ Join Filter: ((small.y = part_l0_3.y) AND ((small.y + part_l0_3.y) < 10))
+ -> Seq Scan on small (cost=0.00..2.00 rows=100 width=8)
+ -> Seq Scan on part1_l1 part_l0_3 (cost=0.00..76.81 rows=4981 width=4)
+ -> Index Only Scan using big_x_idx on big (cost=0.29..3.31 rows=1 width=5)
+ Index Cond: (x = (small.x)::numeric)
+(16 rows)
+
+DROP TABLE IF EXISTS big,small,part_l0 CASCADE;
+RESET enable_hashjoin;
+RESET enable_mergejoin;
+RESET enable_material;
+RESET max_parallel_workers_per_gather;
+-- Parameterized path examples.
+CREATE TABLE prta (id integer, payload text) PARTITION BY HASH (id);
+CREATE TABLE prta1 PARTITION OF prta FOR VALUES WITH (modulus 2, remainder 0);
+CREATE TABLE prta2 PARTITION OF prta FOR VALUES WITH (modulus 2, remainder 1);
+CREATE UNIQUE INDEX ON prta1 (id);
+CREATE UNIQUE INDEX ON prta2 (id);
+INSERT INTO prta (id, payload)
+ (SELECT *, ('abc' || id)::text AS payload
+ FROM generate_series(1,1) AS id);
+CREATE TABLE prtb (id integer, payload text) PARTITION BY HASH (id);
+CREATE TABLE prtb1 PARTITION OF prtb FOR VALUES WITH (modulus 2, remainder 0);
+CREATE TABLE prtb2 PARTITION OF prtb FOR VALUES WITH (modulus 2, remainder 1);
+CREATE UNIQUE INDEX ON prtb1 (id);
+CREATE UNIQUE INDEX ON prtb2 (id);
+INSERT INTO prtb (id, payload)
+ (SELECT *, ('def' || id)::text AS payload
+ FROM generate_series(1,1000) AS id);
+CREATE TABLE e (id integer, payload text) PARTITION BY HASH (id);
+CREATE TABLE e1 PARTITION OF e FOR VALUES WITH (modulus 2, remainder 0);
+CREATE TABLE e2 PARTITION OF e FOR VALUES WITH (modulus 2, remainder 1);
+INSERT INTO e (id, payload)
+ (SELECT *, ('ghi' || id)::text AS payload
+ FROM generate_series(1,1000) AS id);
+CREATE UNIQUE INDEX ON e1 (id);
+CREATE UNIQUE INDEX ON e2 (id);
+ANALYZE prta,prtb,e;
+EXPLAIN (COSTS OFF)
+SELECT * FROM prta,prtb WHERE prta.id=prtb.id;
+ QUERY PLAN
+-----------------------------------------------------------
+ Append
+ -> Nested Loop
+ -> Seq Scan on prta1 prta_1
+ -> Index Scan using prtb1_id_idx on prtb1 prtb_1
+ Index Cond: (id = prta_1.id)
+ -> Nested Loop
+ -> Seq Scan on prta2 prta_2
+ -> Index Scan using prtb2_id_idx on prtb2 prtb_2
+ Index Cond: (id = prta_2.id)
+(9 rows)
+
+EXPLAIN (COSTS OFF)
+SELECT * FROM prta,prtb,e WHERE prta.id=prtb.id AND prta.id=e.id;
+ QUERY PLAN
+-----------------------------------------------------------------
+ Append
+ -> Nested Loop
+ Join Filter: (prta_1.id = e_1.id)
+ -> Nested Loop
+ -> Seq Scan on prta1 prta_1
+ -> Index Scan using prtb1_id_idx on prtb1 prtb_1
+ Index Cond: (id = prta_1.id)
+ -> Index Scan using e1_id_idx on e1 e_1
+ Index Cond: (id = prtb_1.id)
+ -> Nested Loop
+ Join Filter: (prta_2.id = e_2.id)
+ -> Nested Loop
+ -> Seq Scan on prta2 prta_2
+ -> Index Scan using prtb2_id_idx on prtb2 prtb_2
+ Index Cond: (id = prta_2.id)
+ -> Index Scan using e2_id_idx on e2 e_2
+ Index Cond: (id = prtb_2.id)
+(17 rows)
+
-- semi join
EXPLAIN (COSTS OFF)
SELECT t1.* FROM prt1_adv t1 WHERE EXISTS (SELECT 1 FROM prt2_adv t2 WHERE t1.a = t2.b) AND t1.b = 0 ORDER BY t1.a;
diff --git a/src/test/regress/sql/partition_join.sql b/src/test/regress/sql/partition_join.sql
index d97b5b69ff..364b3216f8 100644
--- a/src/test/regress/sql/partition_join.sql
+++ b/src/test/regress/sql/partition_join.sql
@@ -536,6 +536,173 @@ EXPLAIN (COSTS OFF)
SELECT t1.a, t1.c, t2.b, t2.c FROM prt1_adv t1 INNER JOIN prt2_adv t2 ON (t1.a = t2.b) WHERE t1.b = 0 ORDER BY t1.a, t2.b;
SELECT t1.a, t1.c, t2.b, t2.c FROM prt1_adv t1 INNER JOIN prt2_adv t2 ON (t1.a = t2.b) WHERE t1.b = 0 ORDER BY t1.a, t2.b;
+--
+-- For asymmetric partition-wise join
+--
+CREATE TABLE prt5 (hkey int, a int, b int) PARTITION BY HASH(hkey);
+CREATE TABLE prt5_p0 PARTITION OF prt5
+ FOR VALUES WITH (modulus 3, remainder 0);
+CREATE TABLE prt5_p1 PARTITION OF prt5
+ FOR VALUES WITH (modulus 3, remainder 1);
+CREATE TABLE prt5_p2 PARTITION OF prt5
+ FOR VALUES WITH (modulus 3, remainder 2);
+CREATE TABLE prt6 (aid int, alabel text) PARTITION BY HASH(aid);
+CREATE TABLE prt6_p0 PARTITION OF prt6
+ FOR VALUES WITH (modulus 2, remainder 0);
+CREATE TABLE prt6_p1 PARTITION OF prt6
+ FOR VALUES WITH (modulus 2, remainder 1);
+CREATE TABLE t5_1 (aid int, alabel text);
+CREATE TABLE t5_2 (bid int, blabel text);
+
+INSERT INTO prt5 (SELECT x, (x % 1000)::int,
+ ((x+1) % 1000)::int
+ FROM generate_series(1,1000000) x);
+INSERT INTO t5_1 (SELECT x, md5(x::text) FROM generate_series(-200, 1500) x);
+INSERT INTO t5_2 (SELECT x, md5(x::text) FROM generate_series(-200, 1500) x);
+INSERT INTO prt6 (SELECT * FROM t5_1);
+
+VACUUM ANALYZE prt5,prt6,t5_1,t5_2;
+
+SET max_parallel_workers_per_gather = 0;
+
+-- Trivial asymmetric JOIN of partitioned table with a relation
+EXPLAIN (COSTS OFF)
+SELECT *
+ FROM prt5 JOIN t5_1 ON a = aid AND alabel like '%abc%';
+
+-- The same, but appended with UNION ALL
+EXPLAIN (COSTS OFF)
+SELECT * FROM (
+ (SELECT * FROM prt5_p0)
+ UNION ALL
+ (SELECT * FROM prt5_p1)
+ UNION ALL
+ (SELECT * FROM prt5_p2)
+ ) AS sq1
+JOIN t5_1 ON a = aid AND alabel like '%abc%';
+
+-- Don't allow asymmetric JOIN of two partitioned tables.
+EXPLAIN (COSTS OFF)
+SELECT count(*) FROM prt5 JOIN prt6 ON a = aid AND alabel like '%abc%';
+SELECT count(*) FROM prt5 JOIN prt6 ON a = aid AND alabel like '%abc%';
+
+-- Check asymmetric JOIN with Subquery
+EXPLAIN (COSTS OFF)
+SELECT count(*) FROM prt5 JOIN (
+ SELECT * FROM prt6 LIMIT 1000
+) AS sq1 ON a = aid AND alabel like '%abc%';
+SELECT count(*) FROM prt5 JOIN (SELECT * FROM prt6 LIMIT 1000) AS sq1
+ ON a = aid AND alabel like '%abc%';
+
+-- Asymmetric JOIN of two plane tables and one partitioned
+EXPLAIN (COSTS OFF)
+SELECT count(*)
+ FROM prt5 JOIN t5_1 ON a = aid AND alabel like '%ab%'
+ JOIN t5_2 ON b = bid AND blabel like '%cd%';
+SELECT count(*)
+ FROM prt5 JOIN t5_1 ON a = aid AND alabel like '%ab%'
+ JOIN t5_2 ON b = bid AND blabel like '%cd%';
+
+-- unable to extract non-partitioned right relation
+EXPLAIN (COSTS OFF)
+SELECT * FROM prt5 RIGHT JOIN t5_1 ON a = aid AND alabel like '%abc%';
+-- left side can be extracted, but no cost benefit
+EXPLAIN (COSTS OFF)
+SELECT * FROM prt5 LEFT JOIN t5_1 ON a = aid AND alabel like '%abc%';
+
+-- validation of the results with/without asymmetric partition-wise join
+SELECT * INTO pg_temp.result01a
+ FROM prt5 JOIN t5_1 ON a = aid AND alabel like '%abc%';
+
+SELECT * INTO pg_temp.result02a
+ FROM prt5 JOIN t5_1 ON a = aid AND alabel like '%ab%'
+ JOIN t5_2 ON b = bid AND blabel like '%cd%';
+
+SET enable_partitionwise_join = off;
+
+SELECT * INTO pg_temp.result01b
+ FROM prt5 JOIN t5_1 ON a = aid AND alabel like '%abc%';
+
+SELECT * INTO pg_temp.result02b
+ FROM prt5 JOIN t5_1 ON a = aid AND alabel like '%ab%'
+ JOIN t5_2 ON b = bid AND blabel like '%cd%';
+
+SELECT * FROM pg_temp.result01a EXCEPT SELECT * FROM pg_temp.result01b;
+SELECT * FROM pg_temp.result02a EXCEPT SELECT * FROM pg_temp.result02b;
+
+SET enable_partitionwise_join = on;
+
+-- Check reparameterization code when required_outer set contains relid of plain
+-- relation entry, not 'other' entry.
+
+SET enable_hashjoin = 'off';
+SET enable_mergejoin = 'off';
+SET enable_material = 'off';
+
+CREATE TABLE big AS SELECT x AS x FROM generate_series(1,1E4) x;
+CREATE INDEX ON big(x);
+CREATE TABLE small AS SELECT x, -x AS y FROM generate_series(1,100) x;
+
+CREATE TABLE part_l0 (x int, y int, z int) PARTITION BY HASH (y);
+CREATE TABLE part0_l1 PARTITION OF part_l0 (y)
+ FOR VALUES WITH (modulus 2, remainder 0) PARTITION BY HASH (z);
+CREATE TABLE part0_l2 PARTITION OF part0_l1 (z)
+ FOR VALUES WITH (modulus 2, remainder 0);
+CREATE TABLE part1_l2 PARTITION OF part0_l1 (z)
+ FOR VALUES WITH (modulus 2, remainder 1);
+CREATE TABLE part1_l1 PARTITION OF part_l0 (y)
+ FOR VALUES WITH (modulus 2, remainder 1);
+INSERT INTO part_l0 (x, y, z) (SELECT x,x,x FROM generate_series(1,1E4) x);
+
+ANALYZE big,small,part_l0;
+
+EXPLAIN
+SELECT small.* FROM small
+ JOIN part_l0 ON small.y = part_l0.y AND small.y + part_l0.y < 10
+ LEFT JOIN big ON big.x = small.x;
+
+DROP TABLE IF EXISTS big,small,part_l0 CASCADE;
+RESET enable_hashjoin;
+RESET enable_mergejoin;
+RESET enable_material;
+RESET max_parallel_workers_per_gather;
+
+-- Parameterized path examples.
+CREATE TABLE prta (id integer, payload text) PARTITION BY HASH (id);
+CREATE TABLE prta1 PARTITION OF prta FOR VALUES WITH (modulus 2, remainder 0);
+CREATE TABLE prta2 PARTITION OF prta FOR VALUES WITH (modulus 2, remainder 1);
+CREATE UNIQUE INDEX ON prta1 (id);
+CREATE UNIQUE INDEX ON prta2 (id);
+INSERT INTO prta (id, payload)
+ (SELECT *, ('abc' || id)::text AS payload
+ FROM generate_series(1,1) AS id);
+
+CREATE TABLE prtb (id integer, payload text) PARTITION BY HASH (id);
+CREATE TABLE prtb1 PARTITION OF prtb FOR VALUES WITH (modulus 2, remainder 0);
+CREATE TABLE prtb2 PARTITION OF prtb FOR VALUES WITH (modulus 2, remainder 1);
+CREATE UNIQUE INDEX ON prtb1 (id);
+CREATE UNIQUE INDEX ON prtb2 (id);
+INSERT INTO prtb (id, payload)
+ (SELECT *, ('def' || id)::text AS payload
+ FROM generate_series(1,1000) AS id);
+
+CREATE TABLE e (id integer, payload text) PARTITION BY HASH (id);
+CREATE TABLE e1 PARTITION OF e FOR VALUES WITH (modulus 2, remainder 0);
+CREATE TABLE e2 PARTITION OF e FOR VALUES WITH (modulus 2, remainder 1);
+INSERT INTO e (id, payload)
+ (SELECT *, ('ghi' || id)::text AS payload
+ FROM generate_series(1,1000) AS id);
+CREATE UNIQUE INDEX ON e1 (id);
+CREATE UNIQUE INDEX ON e2 (id);
+
+ANALYZE prta,prtb,e;
+
+EXPLAIN (COSTS OFF)
+SELECT * FROM prta,prtb WHERE prta.id=prtb.id;
+
+EXPLAIN (COSTS OFF)
+SELECT * FROM prta,prtb,e WHERE prta.id=prtb.id AND prta.id=e.id;
+
-- semi join
EXPLAIN (COSTS OFF)
SELECT t1.* FROM prt1_adv t1 WHERE EXISTS (SELECT 1 FROM prt2_adv t2 WHERE t1.a = t2.b) AND t1.b = 0 ORDER BY t1.a;
--
2.25.1
--------------3592BFA68FFAC61CCE0AF115--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Asymmetric partitionwise join.
@ 2021-04-02 06:02 Andrey Lepikhov <a.lepikhov@postgrespro.ru>
0 siblings, 0 replies; 538+ messages in thread
From: Andrey Lepikhov @ 2021-04-02 06:02 UTC (permalink / raw)
Teach optimizer to consider partitionwise join of non-partitioned
table with each partition of partitioned table.
Disallow asymmetric machinery for joining of two partitioned (or appended)
relations because it could cause huge consumption of CPU and memory
during reparameterization of NestLoop path.
Change logic of the multilevel child relids adjustment, because this
feature allows the optimizer to plan in new way.
---
src/backend/optimizer/path/joinpath.c | 9 +
src/backend/optimizer/path/joinrels.c | 187 ++++++++
src/backend/optimizer/plan/setrefs.c | 17 +-
src/backend/optimizer/util/appendinfo.c | 44 +-
src/backend/optimizer/util/pathnode.c | 9 +-
src/backend/optimizer/util/relnode.c | 19 +-
src/include/optimizer/paths.h | 7 +-
src/test/regress/expected/partition_join.out | 425 +++++++++++++++++++
src/test/regress/sql/partition_join.sql | 180 ++++++++
9 files changed, 867 insertions(+), 30 deletions(-)
diff --git a/src/backend/optimizer/path/joinpath.c b/src/backend/optimizer/path/joinpath.c
index 6407ede12a..32618ebbd5 100644
--- a/src/backend/optimizer/path/joinpath.c
+++ b/src/backend/optimizer/path/joinpath.c
@@ -335,6 +335,15 @@ add_paths_to_joinrel(PlannerInfo *root,
if (set_join_pathlist_hook)
set_join_pathlist_hook(root, joinrel, outerrel, innerrel,
jointype, &extra);
+
+ /*
+ * 7. If outer relation is delivered from partition-tables, consider
+ * distributing inner relation to every partition-leaf prior to
+ * append these leafs.
+ */
+ try_asymmetric_partitionwise_join(root, joinrel,
+ outerrel, innerrel,
+ jointype, &extra);
}
/*
diff --git a/src/backend/optimizer/path/joinrels.c b/src/backend/optimizer/path/joinrels.c
index 8b69870cf4..9453258f83 100644
--- a/src/backend/optimizer/path/joinrels.c
+++ b/src/backend/optimizer/path/joinrels.c
@@ -16,6 +16,7 @@
#include "miscadmin.h"
#include "optimizer/appendinfo.h"
+#include "optimizer/cost.h"
#include "optimizer/joininfo.h"
#include "optimizer/pathnode.h"
#include "optimizer/paths.h"
@@ -1552,6 +1553,192 @@ try_partitionwise_join(PlannerInfo *root, RelOptInfo *rel1, RelOptInfo *rel2,
}
}
+/*
+ * Build RelOptInfo on JOIN of each partition of the outer relation and the inner
+ * relation. Return List of such RelOptInfo's. Return NIL, if at least one of
+ * these JOINs is impossible to build.
+ */
+static List *
+extract_asymmetric_partitionwise_subjoin(PlannerInfo *root,
+ RelOptInfo *joinrel,
+ AppendPath *append_path,
+ RelOptInfo *inner_rel,
+ JoinType jointype,
+ JoinPathExtraData *extra)
+{
+ List *result = NIL;
+ ListCell *lc;
+
+ foreach (lc, append_path->subpaths)
+ {
+ Path *child_path = lfirst(lc);
+ RelOptInfo *child_rel = child_path->parent;
+ Relids child_joinrelids;
+ Relids parent_relids;
+ RelOptInfo *child_joinrel;
+ SpecialJoinInfo *child_sjinfo;
+ List *child_restrictlist;
+
+ child_joinrelids = bms_union(child_rel->relids, inner_rel->relids);
+ parent_relids = bms_union(append_path->path.parent->relids,
+ inner_rel->relids);
+
+ child_sjinfo = build_child_join_sjinfo(root, extra->sjinfo,
+ child_rel->relids,
+ inner_rel->relids);
+ child_restrictlist = (List *)
+ adjust_appendrel_attrs_multilevel(root, (Node *)extra->restrictlist,
+ child_joinrelids, parent_relids);
+
+ child_joinrel = find_join_rel(root, child_joinrelids);
+ if (!child_joinrel)
+ child_joinrel = build_child_join_rel(root,
+ child_rel,
+ inner_rel,
+ joinrel,
+ child_restrictlist,
+ child_sjinfo,
+ jointype);
+ else
+ {
+ /*
+ * The join relation already exists. For example, it could happen if
+ * we join two plane tables with partitioned table(s).
+ * Populating this join with additional paths could push out some
+ * previously added paths which could be pointed in a subplans list
+ * of an higher level append.
+ * Of course, we could save such paths before generating new. But it
+ * can increase too much the number of paths in complex queries. It
+ * can be a task for future work.
+ */
+ return NIL;
+ }
+
+ populate_joinrel_with_paths(root,
+ child_rel,
+ inner_rel,
+ child_joinrel,
+ child_sjinfo,
+ child_restrictlist);
+
+ /* Give up if asymmetric partition-wise join is not available */
+ if (child_joinrel->pathlist == NIL)
+ return NIL;
+
+ set_cheapest(child_joinrel);
+ result = lappend(result, child_joinrel);
+ }
+ return result;
+}
+
+static bool
+is_asymmetric_join_feasible(PlannerInfo *root,
+ RelOptInfo *outer_rel,
+ RelOptInfo *inner_rel,
+ JoinType jointype)
+{
+ ListCell *lc;
+
+ if (jointype != JOIN_INNER && jointype != JOIN_LEFT)
+ return false;
+
+ if (IS_OTHER_REL(outer_rel) || IS_OTHER_REL(inner_rel))
+ return false;
+
+ /* Disallow recursive usage of asymmertic join machinery */
+ if (root->join_rel_level == NULL)
+ return false;
+
+ /*
+ * Don't allow asymmetric JOIN of two append subplans.
+ * In the case of a parameterized NL join, a reparameterization procedure
+ * will lead to large memory allocations and a CPU consumption:
+ * each reparameterization will induce subpath duplication, creating new
+ * ParamPathInfo instance and increasing of ppilist up to number of
+ * partitions in the inner. Also, if we have many partitions, each bitmapset
+ * variable will be large and many leaks of such variable (caused by relid
+ * replacement) will highly increase memory consumption.
+ * So, we deny such paths for now.
+ */
+ foreach(lc, inner_rel->pathlist)
+ {
+ if (IsA(lfirst(lc), AppendPath))
+ return false;
+ }
+
+ return true;
+}
+
+void
+try_asymmetric_partitionwise_join(PlannerInfo *root,
+ RelOptInfo *joinrel,
+ RelOptInfo *outer_rel,
+ RelOptInfo *inner_rel,
+ JoinType jointype,
+ JoinPathExtraData *extra)
+{
+ ListCell *lc;
+
+ /*
+ * Try this kind of paths if we allow complex partitionwise joins and we know
+ * we can build this join safely.
+ */
+ if (!enable_partitionwise_join ||
+ !is_asymmetric_join_feasible(root, outer_rel, inner_rel, jointype))
+ return;
+
+ foreach (lc, outer_rel->pathlist)
+ {
+ AppendPath *append_path = lfirst(lc);
+
+ /*
+ * We assume this pathlist keeps at least one AppendPath that
+ * represents partitioned table-scan, symmetric or asymmetric
+ * partition-wise join. Asymmetric join isn't needed if the append node
+ * has only one child.
+ */
+ if (IsA(append_path, AppendPath) &&
+ list_length(append_path->subpaths) > 1)
+ {
+ List **join_rel_level_saved;
+ List *live_childrels = NIL;
+
+ join_rel_level_saved = root->join_rel_level;
+ PG_TRY();
+ {
+ /* temporary disables "dynamic programming" algorithm */
+ root->join_rel_level = NULL;
+
+ live_childrels =
+ extract_asymmetric_partitionwise_subjoin(root,
+ joinrel,
+ append_path,
+ inner_rel,
+ jointype,
+ extra);
+ }
+ PG_FINALLY();
+ {
+ root->join_rel_level = join_rel_level_saved;
+ }
+ PG_END_TRY();
+
+ if (live_childrels != NIL)
+ {
+ /*
+ * Add new append relation. We must choose cheapest paths after
+ * this operation because the pathlist possibly contains
+ * joinrels and appendrels that can be suboptimal.
+ */
+ add_paths_to_append_rel(root, joinrel, live_childrels);
+ set_cheapest(joinrel);
+ }
+
+ break;
+ }
+ }
+}
+
/*
* Construct the SpecialJoinInfo for a child-join by translating
* SpecialJoinInfo for the join between parents. left_relids and right_relids
diff --git a/src/backend/optimizer/plan/setrefs.c b/src/backend/optimizer/plan/setrefs.c
index e50624c465..fccc0685d7 100644
--- a/src/backend/optimizer/plan/setrefs.c
+++ b/src/backend/optimizer/plan/setrefs.c
@@ -281,24 +281,29 @@ set_plan_references(PlannerInfo *root, Plan *plan)
/*
* Adjust RT indexes of AppendRelInfos and add to final appendrels list.
- * We assume the AppendRelInfos were built during planning and don't need
- * to be copied.
+ * The AppendRelInfos are copied, because as a part of a subplan they could
+ * be visited many times in the case of asymmetric join.
*/
foreach(lc, root->append_rel_list)
{
AppendRelInfo *appinfo = lfirst_node(AppendRelInfo, lc);
+ AppendRelInfo *newappinfo;
+
+ /* flat copy is enough since all valuable fields are scalars */
+ newappinfo = (AppendRelInfo *) palloc(sizeof(AppendRelInfo));
+ memcpy(newappinfo, appinfo, sizeof(AppendRelInfo));
/* adjust RT indexes */
- appinfo->parent_relid += rtoffset;
- appinfo->child_relid += rtoffset;
+ newappinfo->parent_relid += rtoffset;
+ newappinfo->child_relid += rtoffset;
/*
* Rather than adjust the translated_vars entries, just drop 'em.
* Neither the executor nor EXPLAIN currently need that data.
*/
- appinfo->translated_vars = NIL;
+ newappinfo->translated_vars = NIL;
- glob->appendRelations = lappend(glob->appendRelations, appinfo);
+ glob->appendRelations = lappend(glob->appendRelations, newappinfo);
}
/* Now fix the Plan tree */
diff --git a/src/backend/optimizer/util/appendinfo.c b/src/backend/optimizer/util/appendinfo.c
index af46f581ac..f4d12f76e1 100644
--- a/src/backend/optimizer/util/appendinfo.c
+++ b/src/backend/optimizer/util/appendinfo.c
@@ -202,7 +202,9 @@ adjust_appendrel_attrs(PlannerInfo *root, Node *node, int nappinfos,
context.appinfos = appinfos;
/* If there's nothing to adjust, don't call this function. */
- Assert(nappinfos >= 1 && appinfos != NULL);
+ /* If there's nothing to adjust, just return a duplication */
+ if (nappinfos == 0)
+ return copyObject(node);
/* Should never be translating a Query tree. */
Assert(node == NULL || !IsA(node, Query));
@@ -490,12 +492,10 @@ adjust_appendrel_attrs_multilevel(PlannerInfo *root, Node *node,
Relids top_parent_relids)
{
AppendRelInfo **appinfos;
- Bitmapset *parent_relids = NULL;
+ Relids parent_relids = NULL;
int nappinfos;
int cnt;
- Assert(bms_num_members(child_relids) == bms_num_members(top_parent_relids));
-
appinfos = find_appinfos_by_relids(root, child_relids, &nappinfos);
/* Construct relids set for the immediate parent of given child. */
@@ -506,8 +506,13 @@ adjust_appendrel_attrs_multilevel(PlannerInfo *root, Node *node,
parent_relids = bms_add_member(parent_relids, appinfo->parent_relid);
}
- /* Recurse if immediate parent is not the top parent. */
- if (!bms_equal(parent_relids, top_parent_relids))
+ /*
+ * Recurse if immediate parent is not the top parent. Keep in mind that in a
+ * case of asymmetric JOIN top_parent_relids can contain relids which aren't
+ * part of an append node.
+ */
+ if (!bms_equal(parent_relids, top_parent_relids) &&
+ !bms_is_subset(parent_relids, top_parent_relids))
node = adjust_appendrel_attrs_multilevel(root, node, parent_relids,
top_parent_relids);
@@ -515,12 +520,13 @@ adjust_appendrel_attrs_multilevel(PlannerInfo *root, Node *node,
node = adjust_appendrel_attrs(root, node, nappinfos, appinfos);
pfree(appinfos);
+ pfree(parent_relids);
return node;
}
/*
- * Substitute child relids for parent relids in a Relid set. The array of
+ * Substitute child relids for parent relids in a Relid set. The array of
* appinfos specifies the substitutions to be performed.
*/
Relids
@@ -565,6 +571,7 @@ adjust_child_relids_multilevel(PlannerInfo *root, Relids relids,
AppendRelInfo **appinfos;
int nappinfos;
Relids parent_relids = NULL;
+ Relids normal_relids = NULL;
Relids result;
Relids tmp_result = NULL;
int cnt;
@@ -579,13 +586,24 @@ adjust_child_relids_multilevel(PlannerInfo *root, Relids relids,
appinfos = find_appinfos_by_relids(root, child_relids, &nappinfos);
/* Construct relids set for the immediate parent of the given child. */
+ normal_relids = bms_copy(child_relids);
for (cnt = 0; cnt < nappinfos; cnt++)
{
AppendRelInfo *appinfo = appinfos[cnt];
parent_relids = bms_add_member(parent_relids, appinfo->parent_relid);
+ normal_relids = bms_del_member(normal_relids, appinfo->child_relid);
}
+ if (bms_is_subset(relids, normal_relids))
+ {
+ /* Nothing to do. Parameters set points to plain relations only. */
+ result = relids;
+ goto cleanup;
+ }
+
+ parent_relids = bms_union(parent_relids, normal_relids);
+
/* Recurse if immediate parent is not the top parent. */
if (!bms_equal(parent_relids, top_parent_relids))
{
@@ -597,10 +615,11 @@ adjust_child_relids_multilevel(PlannerInfo *root, Relids relids,
result = adjust_child_relids(relids, nappinfos, appinfos);
+cleanup:
/* Free memory consumed by any intermediate result. */
- if (tmp_result)
- bms_free(tmp_result);
+ bms_free(tmp_result);
bms_free(parent_relids);
+ bms_free(normal_relids);
pfree(appinfos);
return result;
@@ -715,11 +734,11 @@ AppendRelInfo **
find_appinfos_by_relids(PlannerInfo *root, Relids relids, int *nappinfos)
{
AppendRelInfo **appinfos;
+ int nrooms = bms_num_members(relids);
int cnt = 0;
int i;
- *nappinfos = bms_num_members(relids);
- appinfos = (AppendRelInfo **) palloc(sizeof(AppendRelInfo *) * *nappinfos);
+ appinfos = (AppendRelInfo **) palloc(sizeof(AppendRelInfo *) * nrooms);
i = -1;
while ((i = bms_next_member(relids, i)) >= 0)
@@ -727,10 +746,11 @@ find_appinfos_by_relids(PlannerInfo *root, Relids relids, int *nappinfos)
AppendRelInfo *appinfo = root->append_rel_array[i];
if (!appinfo)
- elog(ERROR, "child rel %d not found in append_rel_array", i);
+ continue;
appinfos[cnt++] = appinfo;
}
+ *nappinfos = cnt;
return appinfos;
}
diff --git a/src/backend/optimizer/util/pathnode.c b/src/backend/optimizer/util/pathnode.c
index cedb3848dd..17e215b72d 100644
--- a/src/backend/optimizer/util/pathnode.c
+++ b/src/backend/optimizer/util/pathnode.c
@@ -4225,7 +4225,14 @@ do { \
MemoryContextSwitchTo(oldcontext);
}
- bms_free(required_outer);
+
+ /*
+ * If adjust_child_relids_multilevel don't do replacements it returns
+ * the original set, not a copy. It is possible in the case of asymmetric
+ * JOIN and child_rel->relids contains relids only of plane relations.
+ */
+ if (required_outer != old_ppi->ppi_req_outer)
+ bms_free(required_outer);
new_path->param_info = new_ppi;
diff --git a/src/backend/optimizer/util/relnode.c b/src/backend/optimizer/util/relnode.c
index 47769cea45..ddf0f5a876 100644
--- a/src/backend/optimizer/util/relnode.c
+++ b/src/backend/optimizer/util/relnode.c
@@ -792,11 +792,8 @@ build_child_join_rel(PlannerInfo *root, RelOptInfo *outer_rel,
AppendRelInfo **appinfos;
int nappinfos;
- /* Only joins between "other" relations land here. */
- Assert(IS_OTHER_REL(outer_rel) && IS_OTHER_REL(inner_rel));
-
- /* The parent joinrel should have consider_partitionwise_join set. */
- Assert(parent_joinrel->consider_partitionwise_join);
+ /* Either of relations must be "other" relation at least. */
+ Assert(IS_OTHER_REL(outer_rel) || IS_OTHER_REL(inner_rel));
joinrel->reloptkind = RELOPT_OTHER_JOINREL;
joinrel->relids = bms_union(outer_rel->relids, inner_rel->relids);
@@ -854,8 +851,11 @@ build_child_join_rel(PlannerInfo *root, RelOptInfo *outer_rel,
joinrel->partexprs = NULL;
joinrel->nullable_partexprs = NULL;
- joinrel->top_parent_relids = bms_union(outer_rel->top_parent_relids,
- inner_rel->top_parent_relids);
+ joinrel->top_parent_relids =
+ bms_union(IS_OTHER_REL(outer_rel) ?
+ outer_rel->top_parent_relids : outer_rel->relids,
+ IS_OTHER_REL(inner_rel) ?
+ inner_rel->top_parent_relids : inner_rel->relids);
/* Compute information relevant to foreign relations. */
set_foreign_rel_properties(joinrel, outer_rel, inner_rel);
@@ -2036,9 +2036,8 @@ build_child_join_reltarget(PlannerInfo *root,
{
/* Build the targetlist */
childrel->reltarget->exprs = (List *)
- adjust_appendrel_attrs(root,
- (Node *) parentrel->reltarget->exprs,
- nappinfos, appinfos);
+ adjust_appendrel_attrs_multilevel(root, (Node *)parentrel->reltarget->exprs,
+ childrel->relids, parentrel->relids);
/* Set the cost and width fields */
childrel->reltarget->cost.startup = parentrel->reltarget->cost.startup;
diff --git a/src/include/optimizer/paths.h b/src/include/optimizer/paths.h
index f1d111063c..a0106dc539 100644
--- a/src/include/optimizer/paths.h
+++ b/src/include/optimizer/paths.h
@@ -109,7 +109,12 @@ extern bool have_join_order_restriction(PlannerInfo *root,
extern bool have_dangerous_phv(PlannerInfo *root,
Relids outer_relids, Relids inner_params);
extern void mark_dummy_rel(RelOptInfo *rel);
-
+extern void try_asymmetric_partitionwise_join(PlannerInfo *root,
+ RelOptInfo *joinrel,
+ RelOptInfo *outer_rel,
+ RelOptInfo *inner_rel,
+ JoinType jointype,
+ JoinPathExtraData *extra);
/*
* equivclass.c
* routines for managing EquivalenceClasses
diff --git a/src/test/regress/expected/partition_join.out b/src/test/regress/expected/partition_join.out
index 27f7525b3e..3eddd9bec3 100644
--- a/src/test/regress/expected/partition_join.out
+++ b/src/test/regress/expected/partition_join.out
@@ -2320,6 +2320,431 @@ SELECT t1.a, t1.c, t2.b, t2.c FROM prt1_adv t1 INNER JOIN prt2_adv t2 ON (t1.a =
375 | 0375 | 375 | 0375
(8 rows)
+--
+-- For asymmetric partition-wise join
+--
+CREATE TABLE prt5 (hkey int, a int, b int) PARTITION BY HASH(hkey);
+CREATE TABLE prt5_p0 PARTITION OF prt5
+ FOR VALUES WITH (modulus 3, remainder 0);
+CREATE TABLE prt5_p1 PARTITION OF prt5
+ FOR VALUES WITH (modulus 3, remainder 1);
+CREATE TABLE prt5_p2 PARTITION OF prt5
+ FOR VALUES WITH (modulus 3, remainder 2);
+CREATE TABLE prt6 (aid int, alabel text) PARTITION BY HASH(aid);
+CREATE TABLE prt6_p0 PARTITION OF prt6
+ FOR VALUES WITH (modulus 2, remainder 0);
+CREATE TABLE prt6_p1 PARTITION OF prt6
+ FOR VALUES WITH (modulus 2, remainder 1);
+CREATE TABLE t5_1 (aid int, alabel text);
+CREATE TABLE t5_2 (bid int, blabel text);
+INSERT INTO prt5 (SELECT x, (x % 1000)::int,
+ ((x+1) % 1000)::int
+ FROM generate_series(1,1000000) x);
+INSERT INTO t5_1 (SELECT x, md5(x::text) FROM generate_series(-200, 1500) x);
+INSERT INTO t5_2 (SELECT x, md5(x::text) FROM generate_series(-200, 1500) x);
+INSERT INTO prt6 (SELECT * FROM t5_1);
+VACUUM ANALYZE prt5,prt6,t5_1,t5_2;
+SET max_parallel_workers_per_gather = 0;
+-- Trivial asymmetric JOIN of partitioned table with a relation
+EXPLAIN (COSTS OFF)
+SELECT *
+ FROM prt5 JOIN t5_1 ON a = aid AND alabel like '%abc%';
+ QUERY PLAN
+-------------------------------------------------------
+ Append
+ -> Hash Join
+ Hash Cond: (prt5_1.a = t5_1.aid)
+ -> Seq Scan on prt5_p0 prt5_1
+ -> Hash
+ -> Seq Scan on t5_1
+ Filter: (alabel ~~ '%abc%'::text)
+ -> Hash Join
+ Hash Cond: (prt5_2.a = t5_1.aid)
+ -> Seq Scan on prt5_p1 prt5_2
+ -> Hash
+ -> Seq Scan on t5_1
+ Filter: (alabel ~~ '%abc%'::text)
+ -> Hash Join
+ Hash Cond: (prt5_3.a = t5_1.aid)
+ -> Seq Scan on prt5_p2 prt5_3
+ -> Hash
+ -> Seq Scan on t5_1
+ Filter: (alabel ~~ '%abc%'::text)
+(19 rows)
+
+-- The same, but appended with UNION ALL
+EXPLAIN (COSTS OFF)
+SELECT * FROM (
+ (SELECT * FROM prt5_p0)
+ UNION ALL
+ (SELECT * FROM prt5_p1)
+ UNION ALL
+ (SELECT * FROM prt5_p2)
+ ) AS sq1
+JOIN t5_1 ON a = aid AND alabel like '%abc%';
+ QUERY PLAN
+-------------------------------------------------------
+ Append
+ -> Hash Join
+ Hash Cond: (prt5_p0.a = t5_1.aid)
+ -> Seq Scan on prt5_p0
+ -> Hash
+ -> Seq Scan on t5_1
+ Filter: (alabel ~~ '%abc%'::text)
+ -> Hash Join
+ Hash Cond: (prt5_p1.a = t5_1.aid)
+ -> Seq Scan on prt5_p1
+ -> Hash
+ -> Seq Scan on t5_1
+ Filter: (alabel ~~ '%abc%'::text)
+ -> Hash Join
+ Hash Cond: (prt5_p2.a = t5_1.aid)
+ -> Seq Scan on prt5_p2
+ -> Hash
+ -> Seq Scan on t5_1
+ Filter: (alabel ~~ '%abc%'::text)
+(19 rows)
+
+-- Don't allow asymmetric JOIN of two partitioned tables.
+EXPLAIN (COSTS OFF)
+SELECT count(*) FROM prt5 JOIN prt6 ON a = aid AND alabel like '%abc%';
+ QUERY PLAN
+-------------------------------------------------------------
+ Aggregate
+ -> Hash Join
+ Hash Cond: (prt5.a = prt6.aid)
+ -> Append
+ -> Seq Scan on prt5_p0 prt5_1
+ -> Seq Scan on prt5_p1 prt5_2
+ -> Seq Scan on prt5_p2 prt5_3
+ -> Hash
+ -> Append
+ -> Seq Scan on prt6_p0 prt6_1
+ Filter: (alabel ~~ '%abc%'::text)
+ -> Seq Scan on prt6_p1 prt6_2
+ Filter: (alabel ~~ '%abc%'::text)
+(13 rows)
+
+SELECT count(*) FROM prt5 JOIN prt6 ON a = aid AND alabel like '%abc%';
+ count
+-------
+ 4000
+(1 row)
+
+-- Check asymmetric JOIN with Subquery
+EXPLAIN (COSTS OFF)
+SELECT count(*) FROM prt5 JOIN (
+ SELECT * FROM prt6 LIMIT 1000
+) AS sq1 ON a = aid AND alabel like '%abc%';
+ QUERY PLAN
+----------------------------------------------------------------------
+ Aggregate
+ -> Append
+ -> Hash Join
+ Hash Cond: (prt5_1.a = sq1.aid)
+ -> Seq Scan on prt5_p0 prt5_1
+ -> Hash
+ -> Subquery Scan on sq1
+ Filter: (sq1.alabel ~~ '%abc%'::text)
+ -> Limit
+ -> Append
+ -> Seq Scan on prt6_p0 prt6_1
+ -> Seq Scan on prt6_p1 prt6_2
+ -> Hash Join
+ Hash Cond: (prt5_2.a = sq1.aid)
+ -> Seq Scan on prt5_p1 prt5_2
+ -> Hash
+ -> Subquery Scan on sq1
+ Filter: (sq1.alabel ~~ '%abc%'::text)
+ -> Limit
+ -> Append
+ -> Seq Scan on prt6_p0 prt6_4
+ -> Seq Scan on prt6_p1 prt6_5
+ -> Hash Join
+ Hash Cond: (prt5_3.a = sq1.aid)
+ -> Seq Scan on prt5_p2 prt5_3
+ -> Hash
+ -> Subquery Scan on sq1
+ Filter: (sq1.alabel ~~ '%abc%'::text)
+ -> Limit
+ -> Append
+ -> Seq Scan on prt6_p0 prt6_7
+ -> Seq Scan on prt6_p1 prt6_8
+(32 rows)
+
+SELECT count(*) FROM prt5 JOIN (SELECT * FROM prt6 LIMIT 1000) AS sq1
+ ON a = aid AND alabel like '%abc%';
+ count
+-------
+ 2000
+(1 row)
+
+-- Asymmetric JOIN of two plane tables and one partitioned
+EXPLAIN (COSTS OFF)
+SELECT count(*)
+ FROM prt5 JOIN t5_1 ON a = aid AND alabel like '%ab%'
+ JOIN t5_2 ON b = bid AND blabel like '%cd%';
+ QUERY PLAN
+------------------------------------------------------------------
+ Aggregate
+ -> Append
+ -> Hash Join
+ Hash Cond: (prt5_1.b = t5_2.bid)
+ -> Hash Join
+ Hash Cond: (prt5_1.a = t5_1.aid)
+ -> Seq Scan on prt5_p0 prt5_1
+ -> Hash
+ -> Seq Scan on t5_1
+ Filter: (alabel ~~ '%ab%'::text)
+ -> Hash
+ -> Seq Scan on t5_2
+ Filter: (blabel ~~ '%cd%'::text)
+ -> Hash Join
+ Hash Cond: (prt5_2.b = t5_2.bid)
+ -> Hash Join
+ Hash Cond: (prt5_2.a = t5_1.aid)
+ -> Seq Scan on prt5_p1 prt5_2
+ -> Hash
+ -> Seq Scan on t5_1
+ Filter: (alabel ~~ '%ab%'::text)
+ -> Hash
+ -> Seq Scan on t5_2
+ Filter: (blabel ~~ '%cd%'::text)
+ -> Hash Join
+ Hash Cond: (prt5_3.b = t5_2.bid)
+ -> Hash Join
+ Hash Cond: (prt5_3.a = t5_1.aid)
+ -> Seq Scan on prt5_p2 prt5_3
+ -> Hash
+ -> Seq Scan on t5_1
+ Filter: (alabel ~~ '%ab%'::text)
+ -> Hash
+ -> Seq Scan on t5_2
+ Filter: (blabel ~~ '%cd%'::text)
+(35 rows)
+
+SELECT count(*)
+ FROM prt5 JOIN t5_1 ON a = aid AND alabel like '%ab%'
+ JOIN t5_2 ON b = bid AND blabel like '%cd%';
+ count
+-------
+ 11000
+(1 row)
+
+-- unable to extract non-partitioned right relation
+EXPLAIN (COSTS OFF)
+SELECT * FROM prt5 RIGHT JOIN t5_1 ON a = aid AND alabel like '%abc%';
+ QUERY PLAN
+-----------------------------------------------
+ Hash Right Join
+ Hash Cond: (prt5.a = t5_1.aid)
+ Join Filter: (t5_1.alabel ~~ '%abc%'::text)
+ -> Append
+ -> Seq Scan on prt5_p0 prt5_1
+ -> Seq Scan on prt5_p1 prt5_2
+ -> Seq Scan on prt5_p2 prt5_3
+ -> Hash
+ -> Seq Scan on t5_1
+(9 rows)
+
+-- left side can be extracted, but no cost benefit
+EXPLAIN (COSTS OFF)
+SELECT * FROM prt5 LEFT JOIN t5_1 ON a = aid AND alabel like '%abc%';
+ QUERY PLAN
+-------------------------------------------------
+ Hash Left Join
+ Hash Cond: (prt5.a = t5_1.aid)
+ -> Append
+ -> Seq Scan on prt5_p0 prt5_1
+ -> Seq Scan on prt5_p1 prt5_2
+ -> Seq Scan on prt5_p2 prt5_3
+ -> Hash
+ -> Seq Scan on t5_1
+ Filter: (alabel ~~ '%abc%'::text)
+(9 rows)
+
+-- validation of the results with/without asymmetric partition-wise join
+SELECT * INTO pg_temp.result01a
+ FROM prt5 JOIN t5_1 ON a = aid AND alabel like '%abc%';
+SELECT * INTO pg_temp.result02a
+ FROM prt5 JOIN t5_1 ON a = aid AND alabel like '%ab%'
+ JOIN t5_2 ON b = bid AND blabel like '%cd%';
+SET enable_partitionwise_join = off;
+SELECT * INTO pg_temp.result01b
+ FROM prt5 JOIN t5_1 ON a = aid AND alabel like '%abc%';
+SELECT * INTO pg_temp.result02b
+ FROM prt5 JOIN t5_1 ON a = aid AND alabel like '%ab%'
+ JOIN t5_2 ON b = bid AND blabel like '%cd%';
+SELECT * FROM pg_temp.result01a EXCEPT SELECT * FROM pg_temp.result01b;
+ hkey | a | b | aid | alabel
+------+---+---+-----+--------
+(0 rows)
+
+SELECT * FROM pg_temp.result02a EXCEPT SELECT * FROM pg_temp.result02b;
+ hkey | a | b | aid | alabel | bid | blabel
+------+---+---+-----+--------+-----+--------
+(0 rows)
+
+SET enable_partitionwise_join = on;
+-- Check reparameterization code when an optimizer have to make two level relids
+-- adjustment.
+SET enable_hashjoin = 'off';
+SET enable_mergejoin = 'off';
+SET enable_material = 'off';
+CREATE TABLE big AS SELECT x AS x FROM generate_series(1,1E4) x;
+CREATE INDEX ON big(x);
+CREATE TABLE small AS SELECT x, -x AS y FROM generate_series(1,100) x;
+CREATE TABLE part_l0 (x int, y int, z int) PARTITION BY HASH (y);
+CREATE TABLE part0_l1 PARTITION OF part_l0 (y)
+ FOR VALUES WITH (modulus 2, remainder 0) PARTITION BY HASH (z);
+CREATE TABLE part0_l2 PARTITION OF part0_l1 (z)
+ FOR VALUES WITH (modulus 2, remainder 0);
+CREATE TABLE part1_l2 PARTITION OF part0_l1 (z)
+ FOR VALUES WITH (modulus 2, remainder 1);
+CREATE TABLE part1_l1 PARTITION OF part_l0 (y)
+ FOR VALUES WITH (modulus 2, remainder 1);
+INSERT INTO part_l0 (x, y, z) (SELECT x,x,x FROM generate_series(1,1E4) x);
+ANALYZE big,small,part_l0;
+-- Parameter have to be reparameterized by a plane relation.
+EXPLAIN (COSTS OFF)
+SELECT small.* FROM small
+ JOIN part_l0 ON small.y = part_l0.y AND small.y + part_l0.y < 10
+ LEFT JOIN big ON big.x = small.x;
+ QUERY PLAN
+-----------------------------------------------------------------------------------------
+ Nested Loop Left Join
+ -> Append
+ -> Nested Loop
+ Join Filter: ((small.y = part_l0_1.y) AND ((small.y + part_l0_1.y) < 10))
+ -> Seq Scan on small
+ -> Seq Scan on part0_l2 part_l0_1
+ -> Nested Loop
+ Join Filter: ((small.y = part_l0_2.y) AND ((small.y + part_l0_2.y) < 10))
+ -> Seq Scan on part1_l2 part_l0_2
+ -> Seq Scan on small
+ -> Nested Loop
+ Join Filter: ((small.y = part_l0_3.y) AND ((small.y + part_l0_3.y) < 10))
+ -> Seq Scan on small
+ -> Seq Scan on part1_l1 part_l0_3
+ -> Index Only Scan using big_x_idx on big
+ Index Cond: (x = (small.x)::numeric)
+(16 rows)
+
+SELECT small.* FROM small
+ JOIN part_l0 ON small.y = part_l0.y AND small.y + part_l0.y < 10
+ LEFT JOIN big ON big.x = small.x;
+ x | y
+---+---
+(0 rows)
+
+-- Parameters have to be reparameterized by plane and partitioned relations.
+EXPLAIN (COSTS OFF)
+SELECT count(*) FROM small
+ JOIN part_l0 ON small.y = part_l0.y AND small.y + part_l0.y < 10
+ LEFT JOIN big ON big.x = small.x OR big.x = part_l0.x;
+ QUERY PLAN
+-----------------------------------------------------------------------------------------------
+ Aggregate
+ -> Nested Loop Left Join
+ -> Append
+ -> Nested Loop
+ Join Filter: ((small.y = part_l0_1.y) AND ((small.y + part_l0_1.y) < 10))
+ -> Seq Scan on small
+ -> Seq Scan on part0_l2 part_l0_1
+ -> Nested Loop
+ Join Filter: ((small.y = part_l0_2.y) AND ((small.y + part_l0_2.y) < 10))
+ -> Seq Scan on part1_l2 part_l0_2
+ -> Seq Scan on small
+ -> Nested Loop
+ Join Filter: ((small.y = part_l0_3.y) AND ((small.y + part_l0_3.y) < 10))
+ -> Seq Scan on small
+ -> Seq Scan on part1_l1 part_l0_3
+ -> Bitmap Heap Scan on big
+ Recheck Cond: ((x = (small.x)::numeric) OR (x = (part_l0.x)::numeric))
+ -> BitmapOr
+ -> Bitmap Index Scan on big_x_idx
+ Index Cond: (x = (small.x)::numeric)
+ -> Bitmap Index Scan on big_x_idx
+ Index Cond: (x = (part_l0.x)::numeric)
+(22 rows)
+
+SELECT count(*) FROM small
+ JOIN part_l0 ON small.y = part_l0.y AND small.y + part_l0.y < 10
+ LEFT JOIN big ON big.x = small.x OR big.x = part_l0.x;
+ count
+-------
+ 0
+(1 row)
+
+DROP TABLE IF EXISTS big,small,part_l0 CASCADE;
+RESET enable_hashjoin;
+RESET enable_mergejoin;
+RESET enable_material;
+RESET max_parallel_workers_per_gather;
+-- Parameterized path examples.
+CREATE TABLE prta (id integer, payload text) PARTITION BY HASH (id);
+CREATE TABLE prta1 PARTITION OF prta FOR VALUES WITH (modulus 2, remainder 0);
+CREATE TABLE prta2 PARTITION OF prta FOR VALUES WITH (modulus 2, remainder 1);
+CREATE UNIQUE INDEX ON prta1 (id);
+CREATE UNIQUE INDEX ON prta2 (id);
+INSERT INTO prta (id, payload)
+ (SELECT *, ('abc' || id)::text AS payload
+ FROM generate_series(1,1) AS id);
+CREATE TABLE prtb (id integer, payload text) PARTITION BY HASH (id);
+CREATE TABLE prtb1 PARTITION OF prtb FOR VALUES WITH (modulus 2, remainder 0);
+CREATE TABLE prtb2 PARTITION OF prtb FOR VALUES WITH (modulus 2, remainder 1);
+CREATE UNIQUE INDEX ON prtb1 (id);
+CREATE UNIQUE INDEX ON prtb2 (id);
+INSERT INTO prtb (id, payload)
+ (SELECT *, ('def' || id)::text AS payload
+ FROM generate_series(1,1000) AS id);
+CREATE TABLE e (id integer, payload text) PARTITION BY HASH (id);
+CREATE TABLE e1 PARTITION OF e FOR VALUES WITH (modulus 2, remainder 0);
+CREATE TABLE e2 PARTITION OF e FOR VALUES WITH (modulus 2, remainder 1);
+INSERT INTO e (id, payload)
+ (SELECT *, ('ghi' || id)::text AS payload
+ FROM generate_series(1,1000) AS id);
+CREATE UNIQUE INDEX ON e1 (id);
+CREATE UNIQUE INDEX ON e2 (id);
+ANALYZE prta,prtb,e;
+EXPLAIN (COSTS OFF)
+SELECT * FROM prta,prtb WHERE prta.id=prtb.id;
+ QUERY PLAN
+-----------------------------------------------------------
+ Append
+ -> Nested Loop
+ -> Seq Scan on prta1 prta_1
+ -> Index Scan using prtb1_id_idx on prtb1 prtb_1
+ Index Cond: (id = prta_1.id)
+ -> Nested Loop
+ -> Seq Scan on prta2 prta_2
+ -> Index Scan using prtb2_id_idx on prtb2 prtb_2
+ Index Cond: (id = prta_2.id)
+(9 rows)
+
+EXPLAIN (COSTS OFF)
+SELECT * FROM prta,prtb,e WHERE prta.id=prtb.id AND prta.id=e.id;
+ QUERY PLAN
+-----------------------------------------------------------------
+ Append
+ -> Nested Loop
+ Join Filter: (prta_1.id = e_1.id)
+ -> Nested Loop
+ -> Seq Scan on prta1 prta_1
+ -> Index Scan using prtb1_id_idx on prtb1 prtb_1
+ Index Cond: (id = prta_1.id)
+ -> Index Scan using e1_id_idx on e1 e_1
+ Index Cond: (id = prtb_1.id)
+ -> Nested Loop
+ Join Filter: (prta_2.id = e_2.id)
+ -> Nested Loop
+ -> Seq Scan on prta2 prta_2
+ -> Index Scan using prtb2_id_idx on prtb2 prtb_2
+ Index Cond: (id = prta_2.id)
+ -> Index Scan using e2_id_idx on e2 e_2
+ Index Cond: (id = prtb_2.id)
+(17 rows)
+
-- semi join
EXPLAIN (COSTS OFF)
SELECT t1.* FROM prt1_adv t1 WHERE EXISTS (SELECT 1 FROM prt2_adv t2 WHERE t1.a = t2.b) AND t1.b = 0 ORDER BY t1.a;
diff --git a/src/test/regress/sql/partition_join.sql b/src/test/regress/sql/partition_join.sql
index d97b5b69ff..4d1dd5bec1 100644
--- a/src/test/regress/sql/partition_join.sql
+++ b/src/test/regress/sql/partition_join.sql
@@ -536,6 +536,186 @@ EXPLAIN (COSTS OFF)
SELECT t1.a, t1.c, t2.b, t2.c FROM prt1_adv t1 INNER JOIN prt2_adv t2 ON (t1.a = t2.b) WHERE t1.b = 0 ORDER BY t1.a, t2.b;
SELECT t1.a, t1.c, t2.b, t2.c FROM prt1_adv t1 INNER JOIN prt2_adv t2 ON (t1.a = t2.b) WHERE t1.b = 0 ORDER BY t1.a, t2.b;
+--
+-- For asymmetric partition-wise join
+--
+CREATE TABLE prt5 (hkey int, a int, b int) PARTITION BY HASH(hkey);
+CREATE TABLE prt5_p0 PARTITION OF prt5
+ FOR VALUES WITH (modulus 3, remainder 0);
+CREATE TABLE prt5_p1 PARTITION OF prt5
+ FOR VALUES WITH (modulus 3, remainder 1);
+CREATE TABLE prt5_p2 PARTITION OF prt5
+ FOR VALUES WITH (modulus 3, remainder 2);
+CREATE TABLE prt6 (aid int, alabel text) PARTITION BY HASH(aid);
+CREATE TABLE prt6_p0 PARTITION OF prt6
+ FOR VALUES WITH (modulus 2, remainder 0);
+CREATE TABLE prt6_p1 PARTITION OF prt6
+ FOR VALUES WITH (modulus 2, remainder 1);
+CREATE TABLE t5_1 (aid int, alabel text);
+CREATE TABLE t5_2 (bid int, blabel text);
+
+INSERT INTO prt5 (SELECT x, (x % 1000)::int,
+ ((x+1) % 1000)::int
+ FROM generate_series(1,1000000) x);
+INSERT INTO t5_1 (SELECT x, md5(x::text) FROM generate_series(-200, 1500) x);
+INSERT INTO t5_2 (SELECT x, md5(x::text) FROM generate_series(-200, 1500) x);
+INSERT INTO prt6 (SELECT * FROM t5_1);
+
+VACUUM ANALYZE prt5,prt6,t5_1,t5_2;
+
+SET max_parallel_workers_per_gather = 0;
+
+-- Trivial asymmetric JOIN of partitioned table with a relation
+EXPLAIN (COSTS OFF)
+SELECT *
+ FROM prt5 JOIN t5_1 ON a = aid AND alabel like '%abc%';
+
+-- The same, but appended with UNION ALL
+EXPLAIN (COSTS OFF)
+SELECT * FROM (
+ (SELECT * FROM prt5_p0)
+ UNION ALL
+ (SELECT * FROM prt5_p1)
+ UNION ALL
+ (SELECT * FROM prt5_p2)
+ ) AS sq1
+JOIN t5_1 ON a = aid AND alabel like '%abc%';
+
+-- Don't allow asymmetric JOIN of two partitioned tables.
+EXPLAIN (COSTS OFF)
+SELECT count(*) FROM prt5 JOIN prt6 ON a = aid AND alabel like '%abc%';
+SELECT count(*) FROM prt5 JOIN prt6 ON a = aid AND alabel like '%abc%';
+
+-- Check asymmetric JOIN with Subquery
+EXPLAIN (COSTS OFF)
+SELECT count(*) FROM prt5 JOIN (
+ SELECT * FROM prt6 LIMIT 1000
+) AS sq1 ON a = aid AND alabel like '%abc%';
+SELECT count(*) FROM prt5 JOIN (SELECT * FROM prt6 LIMIT 1000) AS sq1
+ ON a = aid AND alabel like '%abc%';
+
+-- Asymmetric JOIN of two plane tables and one partitioned
+EXPLAIN (COSTS OFF)
+SELECT count(*)
+ FROM prt5 JOIN t5_1 ON a = aid AND alabel like '%ab%'
+ JOIN t5_2 ON b = bid AND blabel like '%cd%';
+SELECT count(*)
+ FROM prt5 JOIN t5_1 ON a = aid AND alabel like '%ab%'
+ JOIN t5_2 ON b = bid AND blabel like '%cd%';
+
+-- unable to extract non-partitioned right relation
+EXPLAIN (COSTS OFF)
+SELECT * FROM prt5 RIGHT JOIN t5_1 ON a = aid AND alabel like '%abc%';
+-- left side can be extracted, but no cost benefit
+EXPLAIN (COSTS OFF)
+SELECT * FROM prt5 LEFT JOIN t5_1 ON a = aid AND alabel like '%abc%';
+
+-- validation of the results with/without asymmetric partition-wise join
+SELECT * INTO pg_temp.result01a
+ FROM prt5 JOIN t5_1 ON a = aid AND alabel like '%abc%';
+
+SELECT * INTO pg_temp.result02a
+ FROM prt5 JOIN t5_1 ON a = aid AND alabel like '%ab%'
+ JOIN t5_2 ON b = bid AND blabel like '%cd%';
+
+SET enable_partitionwise_join = off;
+
+SELECT * INTO pg_temp.result01b
+ FROM prt5 JOIN t5_1 ON a = aid AND alabel like '%abc%';
+
+SELECT * INTO pg_temp.result02b
+ FROM prt5 JOIN t5_1 ON a = aid AND alabel like '%ab%'
+ JOIN t5_2 ON b = bid AND blabel like '%cd%';
+
+SELECT * FROM pg_temp.result01a EXCEPT SELECT * FROM pg_temp.result01b;
+SELECT * FROM pg_temp.result02a EXCEPT SELECT * FROM pg_temp.result02b;
+
+SET enable_partitionwise_join = on;
+
+-- Check reparameterization code when an optimizer have to make two level relids
+-- adjustment.
+
+SET enable_hashjoin = 'off';
+SET enable_mergejoin = 'off';
+SET enable_material = 'off';
+
+CREATE TABLE big AS SELECT x AS x FROM generate_series(1,1E4) x;
+CREATE INDEX ON big(x);
+CREATE TABLE small AS SELECT x, -x AS y FROM generate_series(1,100) x;
+
+CREATE TABLE part_l0 (x int, y int, z int) PARTITION BY HASH (y);
+CREATE TABLE part0_l1 PARTITION OF part_l0 (y)
+ FOR VALUES WITH (modulus 2, remainder 0) PARTITION BY HASH (z);
+CREATE TABLE part0_l2 PARTITION OF part0_l1 (z)
+ FOR VALUES WITH (modulus 2, remainder 0);
+CREATE TABLE part1_l2 PARTITION OF part0_l1 (z)
+ FOR VALUES WITH (modulus 2, remainder 1);
+CREATE TABLE part1_l1 PARTITION OF part_l0 (y)
+ FOR VALUES WITH (modulus 2, remainder 1);
+INSERT INTO part_l0 (x, y, z) (SELECT x,x,x FROM generate_series(1,1E4) x);
+
+ANALYZE big,small,part_l0;
+
+-- Parameter have to be reparameterized by a plane relation.
+EXPLAIN (COSTS OFF)
+SELECT small.* FROM small
+ JOIN part_l0 ON small.y = part_l0.y AND small.y + part_l0.y < 10
+ LEFT JOIN big ON big.x = small.x;
+SELECT small.* FROM small
+ JOIN part_l0 ON small.y = part_l0.y AND small.y + part_l0.y < 10
+ LEFT JOIN big ON big.x = small.x;
+
+-- Parameters have to be reparameterized by plane and partitioned relations.
+EXPLAIN (COSTS OFF)
+SELECT count(*) FROM small
+ JOIN part_l0 ON small.y = part_l0.y AND small.y + part_l0.y < 10
+ LEFT JOIN big ON big.x = small.x OR big.x = part_l0.x;
+SELECT count(*) FROM small
+ JOIN part_l0 ON small.y = part_l0.y AND small.y + part_l0.y < 10
+ LEFT JOIN big ON big.x = small.x OR big.x = part_l0.x;
+
+DROP TABLE IF EXISTS big,small,part_l0 CASCADE;
+RESET enable_hashjoin;
+RESET enable_mergejoin;
+RESET enable_material;
+RESET max_parallel_workers_per_gather;
+
+-- Parameterized path examples.
+CREATE TABLE prta (id integer, payload text) PARTITION BY HASH (id);
+CREATE TABLE prta1 PARTITION OF prta FOR VALUES WITH (modulus 2, remainder 0);
+CREATE TABLE prta2 PARTITION OF prta FOR VALUES WITH (modulus 2, remainder 1);
+CREATE UNIQUE INDEX ON prta1 (id);
+CREATE UNIQUE INDEX ON prta2 (id);
+INSERT INTO prta (id, payload)
+ (SELECT *, ('abc' || id)::text AS payload
+ FROM generate_series(1,1) AS id);
+
+CREATE TABLE prtb (id integer, payload text) PARTITION BY HASH (id);
+CREATE TABLE prtb1 PARTITION OF prtb FOR VALUES WITH (modulus 2, remainder 0);
+CREATE TABLE prtb2 PARTITION OF prtb FOR VALUES WITH (modulus 2, remainder 1);
+CREATE UNIQUE INDEX ON prtb1 (id);
+CREATE UNIQUE INDEX ON prtb2 (id);
+INSERT INTO prtb (id, payload)
+ (SELECT *, ('def' || id)::text AS payload
+ FROM generate_series(1,1000) AS id);
+
+CREATE TABLE e (id integer, payload text) PARTITION BY HASH (id);
+CREATE TABLE e1 PARTITION OF e FOR VALUES WITH (modulus 2, remainder 0);
+CREATE TABLE e2 PARTITION OF e FOR VALUES WITH (modulus 2, remainder 1);
+INSERT INTO e (id, payload)
+ (SELECT *, ('ghi' || id)::text AS payload
+ FROM generate_series(1,1000) AS id);
+CREATE UNIQUE INDEX ON e1 (id);
+CREATE UNIQUE INDEX ON e2 (id);
+
+ANALYZE prta,prtb,e;
+
+EXPLAIN (COSTS OFF)
+SELECT * FROM prta,prtb WHERE prta.id=prtb.id;
+
+EXPLAIN (COSTS OFF)
+SELECT * FROM prta,prtb,e WHERE prta.id=prtb.id AND prta.id=e.id;
+
-- semi join
EXPLAIN (COSTS OFF)
SELECT t1.* FROM prt1_adv t1 WHERE EXISTS (SELECT 1 FROM prt2_adv t2 WHERE t1.a = t2.b) AND t1.b = 0 ORDER BY t1.a;
--
2.33.0
--------------9DCA5E9A07F91111D4169DAB--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
* [PATCH] Do not check the REPLICATION attribute when running REPACK.
@ 2026-04-20 07:20 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 538+ messages in thread
From: Antonin Houska @ 2026-04-20 07:20 UTC (permalink / raw)
Although REPACK (CONCURRENTLY) uses replication slots, there is no concern
that the slot will leak data of other users because the MAINTAIN privilege on
the table is required anyway. The REPLICATION attribute is also not needed to
prevent REPACK from stealing slots from logical replication, since commit
e76d8c749c introduces a limit on the maximum number of slots used by REPACK.
---
src/backend/commands/repack_worker.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b17edd771e2..e4a4860805b 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -214,7 +214,6 @@ repack_setup_logical_decoding(Oid relid)
/*
* Make sure we can use logical decoding.
*/
- CheckSlotPermissions();
CheckLogicalDecodingRequirements(true);
/*
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 538+ messages in thread
end of thread, other threads:[~2026-04-20 07:20 UTC | newest]
Thread overview: 538+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2009-06-01 17:43 Re: PostgreSQL Developer meeting minutes up Markus Wanner <markus@bluegap.ch>
2009-06-01 18:08 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-06-01 18:35 ` Alvaro Herrera <alvherre@commandprompt.com>
2009-06-01 18:46 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-06-04 09:14 ` Markus Wanner <markus@bluegap.ch>
2009-06-02 06:43 ` Marko Kreen <markokr@gmail.com>
2009-06-02 07:13 ` Marko Kreen <markokr@gmail.com>
2009-06-02 11:48 ` Markus Wanner <markus@bluegap.ch>
2009-06-02 12:46 ` Marko Kreen <markokr@gmail.com>
2009-06-02 14:23 ` Markus Wanner <markus@bluegap.ch>
2009-06-02 14:50 ` Aidan Van Dyk <aidan@highrise.ca>
2009-06-02 15:02 ` Alvaro Herrera <alvherre@commandprompt.com>
2009-06-02 15:19 ` Greg Stark <stark@enterprisedb.com>
2009-06-02 15:08 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-06-02 15:20 ` Marko Kreen <markokr@gmail.com>
2009-06-02 15:44 ` Robert Haas <robertmhaas@gmail.com>
2009-06-02 15:46 ` Markus Wanner <markus@bluegap.ch>
2009-06-02 15:19 ` Markus Wanner <markus@bluegap.ch>
2009-06-02 16:27 ` Ron Mayer <rm_pg@cheapcomplexdevices.com>
2009-06-02 15:34 ` Marko Kreen <markokr@gmail.com>
2009-06-02 16:07 ` Markus Wanner <markus@bluegap.ch>
2009-06-02 16:17 ` Marko Kreen <markokr@gmail.com>
2009-06-03 11:10 ` Markus Wanner <markus@bluegap.ch>
2009-06-03 12:08 ` Greg Stark <stark@enterprisedb.com>
2009-06-03 12:19 ` Andres Freund <andres@anarazel.de>
2009-06-03 14:01 ` Greg Stark <stark@enterprisedb.com>
2009-06-03 14:13 ` Magnus Hagander <magnus@hagander.net>
2009-06-03 14:17 ` Robert Haas <robertmhaas@gmail.com>
2009-06-03 14:18 ` Magnus Hagander <magnus@hagander.net>
2009-06-03 14:26 ` Marko Kreen <markokr@gmail.com>
2009-06-03 14:38 ` Aidan Van Dyk <aidan@highrise.ca>
2009-06-03 15:07 ` Marko Kreen <markokr@gmail.com>
2009-06-03 15:25 ` Aidan Van Dyk <aidan@highrise.ca>
2009-06-03 15:28 ` Marko Kreen <markokr@gmail.com>
2009-06-03 15:52 ` Aidan Van Dyk <aidan@highrise.ca>
2009-06-03 14:36 ` Aidan Van Dyk <aidan@highrise.ca>
2009-06-03 14:20 ` Marko Kreen <markokr@gmail.com>
2009-06-03 14:46 ` Robert Haas <robertmhaas@gmail.com>
2009-06-03 19:33 ` Ron Mayer <rm_pg@cheapcomplexdevices.com>
2009-06-04 09:46 ` Markus Wanner <markus@bluegap.ch>
2009-06-04 21:20 ` Ron Mayer <rm_pg@cheapcomplexdevices.com>
2009-06-05 07:05 ` Markus Wanner <markus@bluegap.ch>
2009-06-05 13:38 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-06-05 13:51 ` Andrew Dunstan <andrew@dunslane.net>
2009-06-05 18:28 ` Aidan Van Dyk <aidan@highrise.ca>
2009-06-05 18:41 ` Andrew Dunstan <andrew@dunslane.net>
2009-06-05 19:33 ` Aidan Van Dyk <aidan@highrise.ca>
2009-06-06 15:41 ` Markus Wanner <markus@bluegap.ch>
2009-06-06 16:42 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-06-06 20:30 ` Markus Wanner <markus@bluegap.ch>
2009-06-13 16:13 ` kris@shannon.id.au
2009-06-06 16:56 ` Andrew Dunstan <andrew@dunslane.net>
2009-06-06 17:22 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-06-06 17:55 ` Mark Mielke <mark@mark.mielke.cc>
2009-06-06 17:59 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-06-06 20:05 ` Andrew Dunstan <andrew@dunslane.net>
2009-06-07 01:20 ` Mark Mielke <mark@mark.mielke.cc>
2009-06-08 08:45 ` Markus Wanner <markus@bluegap.ch>
2009-06-08 12:36 ` Mark Mielke <mark@mark.mielke.cc>
2009-06-06 23:03 ` Markus Wanner <markus@bluegap.ch>
2009-06-07 07:26 ` Nicolas Barbier <nicolas.barbier@gmail.com>
2009-06-08 09:10 ` Markus Wanner <markus@bluegap.ch>
2009-06-08 14:17 ` Markus Wanner <markus@bluegap.ch>
2009-06-06 20:56 ` Markus Wanner <markus@bluegap.ch>
2009-06-05 15:29 ` Robert Haas <robertmhaas@gmail.com>
2009-06-05 15:37 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-06-05 15:59 ` Robert Haas <robertmhaas@gmail.com>
2009-06-05 16:15 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-06-05 16:18 ` Bruce Momjian <bruce@momjian.us>
2009-06-05 16:20 ` Robert Haas <robertmhaas@gmail.com>
2009-06-08 08:56 ` Ron Mayer <rm_pg@cheapcomplexdevices.com>
2009-06-06 18:15 ` Greg Stark <stark@enterprisedb.com>
2009-06-06 23:29 ` Markus Wanner <markus@bluegap.ch>
2009-06-06 15:40 ` Markus Wanner <markus@bluegap.ch>
2009-06-04 08:11 ` Markus Wanner <markus@bluegap.ch>
2009-06-04 08:33 ` Greg Stark <greg.stark@enterprisedb.com>
2009-06-04 09:07 ` Markus Wanner <markus@bluegap.ch>
2009-06-02 11:08 ` Markus Wanner <markus@bluegap.ch>
2009-06-02 11:25 ` Marko Kreen <markokr@gmail.com>
2009-06-02 11:50 ` Markus Wanner <markus@bluegap.ch>
2009-06-02 12:48 ` Aidan Van Dyk <aidan@highrise.ca>
2009-06-02 13:37 ` Markus Wanner <markus@bluegap.ch>
2009-06-02 13:54 ` Aidan Van Dyk <aidan@highrise.ca>
2021-04-02 06:02 [PATCH] Asymmetric partitionwise join. Andrey Lepikhov <a.lepikhov@postgrespro.ru>
2021-04-02 06:02 [PATCH] Asymmetric partitionwise join. Andrey Lepikhov <a.lepikhov@postgrespro.ru>
2021-04-02 06:02 [PATCH] Asymmetric partitionwise join. Andrey Lepikhov <a.lepikhov@postgrespro.ru>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
2026-04-20 07:20 [PATCH] Do not check the REPLICATION attribute when running REPACK. Antonin Houska <ah@cybertec.at>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox