xplicit, it is hard for others to get
behind your proposal.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
*/
What work do you believe the word "mainly" does in that paragraph? The
presence of the word "mainly" rather than "only" somewhat cuts against your
argument that we should only be counting tuples that get inserted without
aborting.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
up | n_dead_tup | n_tup_ins | n_ins_since_vacuum
++---+
2 | 8 |10 | 10
(1 row)
If we went with your suggestion, I think the final n_ins_since_vacuum
column would be 2. Do you think the n_tup_ins should also be 2? Should
those
're at v34 already, and the
> recent changes were mostly cosmetic. Does anyone object to me polishing
> and pushing those parts?
>
Kirill may have addressed my concerns in the latest version. I have not
had time for another review. Tomas, would you still like to review and
pu
mily_properties(opno, opfamily, isorderby,
&op_strategy,
+ NULL,/* don't need
cmptype */
&op_lefttype,
&op_r
;
seems fine. There are no other callers as yet.
You have made me a bit paranoid that, in future, we might add additional
callers who are not anticipating the error. Should we solve that with a
more complete code comment, or do you think refactoring is in order?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ews. These were v21-0011 and v21-0012, except that
> I'm combining the switch from strategies to compare types (which was in
> v21-0006 or so) with the removal of the btree requirements.
>
v21.2-0004-* is ready for commit.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Tue, Mar 4, 2025 at 6:05 AM Mark Dilger
wrote:
> But then I tried:
>
> +DO $$
> +DECLARE
> + a jsonb := '{"": 6, "NU": [{"": [[3]]}, [6], [2], "bCi"], "aaf": [-6,
> -8]}'::jsonb;
> +BEGIN
> + WHILE
t assignment
which suggests the plpgsql parser does not recognize a."NU" as we'd
expect. Any thoughts on this?
I notice there are no changes in src/interfaces/ecpg/test, which concerns
me. The sqljson.pgc and sqljson_jsontable.pgc files are already testing
json handling in ecpg; perhaps just extend those a bit?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
-6, "__": [""], "YMb":
-22}'::jsonb;
SELECT COUNT(*) FROM tbl WHERE j @> '{"853": -60, "pjx": "",
"TGLUG_jxmrggv": null}'::jsonb;
SELECT COUNT(*) FROM tbl WHERE j @>
'"D3BDA069074174vx48A37IVHWVXLUP9382542ypsl1465pixtryzCBgrkkhrvCC_BDDFat
> On Feb 21, 2025, at 12:16 PM, Mark Dilger
> wrote:
>
> The pgbench script is not corrupting anything overtly, so this looks to
> either be a bug in gin or a bug in the check.
I suspected the AccessShareLock taken by verify_gin() might be too weak, and
u
> On Feb 21, 2025, at 9:07 AM, Mark Dilger wrote:
>
> I infer that you intend to make v34-0004, v34-0006, and v35-0001 apply
> cleanly without the other patches and commit it that way. If that is
> correct, be advised that I'm doing a review and will respond back shortl
be
advised that I'm doing a review and will respond back shortly, maybe in a few
hours.
—
Mark Dilger
+001 (360) 271-8498
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
g back
several versions.
How about we fix this now? I threw this together in a hurry, and might have
screwed it up, so please check carefully. If you like this, we should go at
least one more round of making sure this has thorough regression testing, but
just to get your feedback, this can b
> On Nov 27, 2024, at 4:57 AM, Peter Eisentraut wrote:
>
> On 26.11.24 15:27, Andrew Dunstan wrote:
>> On 2024-11-19 Tu 6:26 PM, Mark Dilger wrote:
>>>> On Nov 16, 2024, at 9:10 AM, Kirill Reshke wrote:
>>>>
>>>> Hi! Can we please have a
ed 1 (wstat 256, 0x100)
Failed 1/272 subtests
The first part of your patch which checks the xmin_status seems ok at first
glance.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Nov 16, 2024, at 9:10 AM, Kirill Reshke wrote:
>
> Hi! Can we please have a rebased version of this patch series?
Sorry for the delay, and thanks for your interest. I will try to get around to
rebasing in the next few days.
—
Mark Dilger
EnterpriseDB: http://www.enterprised
ndex AM strategy numbers and
> RowCompareType (with some small extensions). This is what this
> patch does.
As the patch author, obviously this is the one I chose. The "small extensions"
are just to handle "no such value" type cases.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ch series, and it also
> makes the affected code areas simpler and more consistent and robust.
>
Thanks for the review!
Yes, I found the existing use of a btree strategy number rather than a boolean
"reverse" flag made using the code from other index AMs needlessly harder. I
a
struct; that didn't
> seem necessary.
Good catch. I agree with the change.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Aug 26, 2024, at 5:21 AM, Peter Eisentraut wrote:
>
> On 21.08.24 21:25, Mark Dilger wrote:
>> The next twenty patches are a mix of fixes of various layering
>> violations, such as not allowing non-core index AMs from use in replica
>> identity full, or for sp
> On Aug 21, 2024, at 12:34 PM, Kirill Reshke wrote:
>
> Hi! Why is the patch attached as .tar.bz2? Usually raw patches are sent
> here...
I worried the patch set, being greater than 1 MB, might bounce or be held up in
moderation.
—
Mark Dilger
EnterpriseDB: http://www.ente
ouple
arguments to represent where and how the size class bits are to be stored, and
where the length itself is stored? I doubt you need to sacrifice any
performance gains of this patch to make that happen. You'd just need to
restructure the patch.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
. Prior to the corrupting action the values were
all unique.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
detected. At least, rerunning the test after
adjusting the expected output, I no longer see problems.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On May 17, 2024, at 12:10 PM, Mark Dilger
> wrote:
>
>> Amcheck with checkunique option does check uniqueness violation between
>> pages. But it doesn't warranty detection of cross page uniqueness violations
>> in extremely rare cases when the first eq
conclude that the uniqueness checking code is broken. Can you take a look?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On May 17, 2024, at 3:11 AM, Alexander Korotkov wrote:
>
> On Mon, May 13, 2024 at 4:42 AM Alexander Korotkov
> wrote:
>> On Mon, May 13, 2024 at 12:23 AM Alexander Korotkov
>> wrote:
>>> On Sat, May 11, 2024 at 4:13 AM Mark Dilger
>>> wrote:
>
clearly used.
So the behavior at that point is changing between the old and new versions of
the code, and I think I'm within reason to ask if it was wrong before the
patch, wrong after the patch, or something else? Is this a bug being
introduced, being fixed, or ... ?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ds. If anybody refactored the struct they
might not notice that the need to reorder this initialization, and depending on
various factors including compiler flags they might not get an error.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
skey, offset);
and thereafter. Now, the rightpage of state->target is created, checked, and
free'd, and then the old state->target gets processed in the downlink check and
thereafter. This is either introducing a bug, or fixing one, but the commit
message is totally a
oes implement those two functions and does use the
TBMIterateResult *tbmres argument, yes. I would deal with the issue in very
much the same way that your patches modify heapam. I don't really have any
additional comments about that.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
synchronous feedback per block. Thus, this table AM function
> must change its meaning.
>
> I think the way the patches are split up could be improved. I will
> think more about this. There are also probably a few mistakes with
> which comments are updated in whi
> On Jan 29, 2024, at 7:35 AM, Isaac Morland wrote:
>
> On Mon, 29 Jan 2024 at 10:31, Mark Dilger
> wrote:
>
> -Infinity for refactoring the entire codebase and backpatching.
>
> I don't think anybody is proposing re-working the existing codebase. I
>
> On Jan 29, 2024, at 7:03 AM, Jelte Fennema-Nio wrote:
>
> So my suggestion is for people to respond with -1, -0.5, +-0, +0.5, or
> +1 to indicate support against/for the change.
-1 for me.
-Infinity for refactoring the entire codebase and backpatching.
—
Mark Dilger
Enterp
> On Jan 8, 2024, at 5:41 AM, Mark Dilger wrote:
>
> The /r modifier defeats the purpose of the patch, at least for my perl
> version, perl 5, version 28, subversion 1 (v5.28.1). With just the /aeg
> modifier, it works fine.
Nevermind. I might be wrong about that. I did
purpose of the patch, at least for my perl
version, perl 5, version 28, subversion 1 (v5.28.1). With just the /aeg
modifier, it works fine.
--
Mark Dilger
uld at least refactor to pass the
minimum amount of state information through the table AM API.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
loptions for tables and indexes.
This could use some regression tests to exercise the custom reloptions.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
e server itself, all the test infrastructure can use a
single, shared solution.
As for the implementation, I just briefly scanned the patch.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
f a privilege
deescalation than a privilege escalation, so where's the risk? That's not a
rhetorical question. Is there a risk here? Or are we just concerned that most
users will set up replication with superuser or some other high-privilege user,
and we're trying to protect them from the consequences of that choice?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
icious content into the publication. I
think you are focused on all the bad actors on the subscription-side database
and what they can do to each other. That's also valid, but I get the
impression that you're losing sight of the risk posed by malicious publishers.
Or maybe you ar
ike
> use constant ROWCOUNT => 17;
> so I just made it a variable.
Seems fair. I certainly don't mind.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ondering if you had a particular client use case in mind when you added this
block?
The new function pg_encrypted_in() appears totally untested, but I have to
wonder if that's because we're not round-trip testing pg_dump with column
encryption...? The code coverage in pg_dump looks fai
EZE shaves 10-12% off the tests. I didn't
> change that, but we also fire off a psql for each tuple for heap_page_items(),
> with offset $N no less. That seems to be another 500ms.
I don't recall the reasoning. Feel free to optimize the tests.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ges a bit.
>
> - Assorted cosmetic and comment changes.
>
> I think this is easier to follow and more nearly correct, but what do
> you (and others) think?
Thanks, Robert. Quickly skimming over this patch, it looks like something
reviewable. Your changes to t/004_verify_heapam
> On Feb 22, 2023, at 10:49 AM, Jeff Davis wrote:
>
> On Wed, 2023-02-22 at 09:27 -0800, Mark Dilger wrote:
>> Another option is to execute under the intersection of their
>> privileges, where both the definer and the invoker need the
>> privileges in order for t
still preventing either party from hijacking privileges of the other.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Feb 11, 2023, at 1:54 PM, Mark Dilger wrote:
>
> Here are some observations
I should mention, src/sgml/html/libpq-exec.html needs clarification:
> paramFormats[]Specifies whether parameters are text (put a zero in the array
> entry for the corresponding parameter) o
e perl tap tests you've included appear to do
this (except indirectly when calling test_client); grep'ing for the libpq error
message "parameter with forced encryption is not to be encrypted" in the tests
has no matches. Is it just not possible? I thought you'd m
end (intentionally or otherwise) and add some tables from the
> "locally_controlled_stuff" schema, we'll refuse to replicate that into
> our eponymous schema.
That example is good, though I don't see how "filters" are better than
roles+privileges. Care to elaborate?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ason why one patch should both split owner
> from run-as user and also allow the owner to be a non-superuser. That
> seems like two different efforts to me.
I don't have a concrete problem with your patch, and wouldn't object if you
committed it. My concerns were more how you were phrasing things, but it seems
not worth any additional conversation, because it's probably a distinction
without a difference.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ogically only
touching the lefthand side, so you should then have a (nonsuperuser-creator,
nonsuperuser-owner) pair. But you don't. You go the apparently needless extra
step of just squashing them together. I just don't see why it needs to be like
that.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
s
> supposed to defend himself against Alice, and Bob doesn't even seem to
> be trying. Maybe we should rename the users to Samson and Delilah? :-)
No, Atahualpa and Pizarro.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
to give responsibility for
> those objects to different and especially mutually untrusting users?
When public repositories of data, such as the IANA whois database, publish
their data via postgres publications.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
aving Charlie, not Bob, as the "run-as" user helps somewhere
right around (D).
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
es. One advantage of Jeff's idea of using a server object
rather than a string is that it becomes more plausibly safe to allow the
subscription owner to make changes to that attribute of the subscription.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
do, because at some
point in the future we might extend what things are allowed in that string, and
we have to keep everything that contemplates that string in sync. I may have
been overly hesitant to tackle that problem. Or maybe I just ran short of
round tuits.
—
Mark Dilger
ckly
switched my focus elsewhere.
> , and (b) what people think of (1)-(3) above
There are different ways of solving (1), and Jeff and I discussed them in Dec
2021. My recollection was that idea (3) was the cleanest. Other ideas might
be simpler than (3), or they may just appear simpler bu
> On Jan 10, 2023, at 9:26 AM, Mark Dilger wrote:
>
>-- Cryptographically connected to the encrypted record
>patient_id BIGINT NOT NULL,
>patient_ssn CHAR(11),
>
>-- The encrypted record
>patient_record TEXT ENCRYPTED WITH (colu
e such "salt"ing (again, maybe
the wrong word) because I'm just trying to discuss the general feature, not get
into the weeds about which cryptographic algorithm to select.
Thoughts?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
he
> amcheck/pg_amcheck tests.
Ok, I can confirm that. I find the assertion
Assert(epoch != (uint32)-1);
a bit simpler to reason about, but either way, I agree it is a bug. Thanks for
finding this.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
id 0 gets used.
Thanks
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
#x27;);
+ random_normal
+---
+ NaN
+(1 row)
+
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Nov 28, 2022, at 12:33 PM, Mark Dilger
> wrote:
>
>> Isn't this just GRANT .. WITH SET FALSE, INHERIT FALSE, ADMIN TRUE? That
>> should allow role administration, without actually granting membership in
>> that role, yet, right?
>
> Can yo
mean here? Are you inventing a new syntax?
+GRANT bob TO alice WITH SET FALSE, INHERIT FALSE, ADMIN TRUE;
+ERROR: syntax error at or near "SET"
+LINE 1: GRANT bob TO alice WITH SET FALSE, INHERIT FALSE, ADMIN TRUE...
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
bout how hard it is to
de-conflate role membership from role administration, and maybe that's a
non-starter for reasons I don't recall at the moment. I expect Robert has
already contemplated that idea and instead proposed this patch for good
reasons. Robert?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ng tools can tell when
Alice circumvents these settings. Without that bit, the whole thing is inane.
Why make Alice jump through hoops that you are explicitly allowing her to jump
through? Apparently the answer is that you can point a high speed camera at
the hoops.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
herself, so she gets the behavior she wants? I'm confused now
about who controls these settings.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
articular CREATEROLE
> user by revoking the implicit grants with CASCADE.
>
> But since this implicit grant has, and must have, the bootstrap
> superuser as grantor, it is also only reasonable that superusers get
> to determine what options are used when creating that grant, rather
> than leaving that up to the CREATEROLE user.
Yes, this all makes sense, but does it entail that the CREATE ROLE command must
behave differently on the basis of a setting?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
't rather that it always work one way or always
the other. It's just to say that I don't want it to work differently based on
some poorly advertised property of the role executing the command.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
h is well written. Patch 0004 feels like something that won't get
committed. The INHERITCREATEDROLES and SETCREATEDROLES in 0004 seems clunky.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
test also disables autovacuum, so a background auto-analyze
shouldn't be running. Maybe that's why you haven't seen amcheck fall over?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
rticle rather than skipping down to that
section.
I hope it helps
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
e privileges, it sounds like you mean
privileges on the publishing database. But then you talk about CREATE
SUBSCRIPTION granting privileges, which would necessarily be on the subscriber
database. Can you clarify what you have in mind?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
comment to remove mention of the
> Asserts. I also tried to form the comment in a way that's more
> understandable about why we always write a "0" in "INSERT 0 ".
Your wording is better. +1
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ve documentation) and later return a copy of the
slot's tuple sans any "system columns" (also per the above documentation) and
that's when the core code breaks. It's not the TAM that is broken here, not
according to the interface's documentation as I read it. Am I reading it wrong?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ackendStartup(port=0x7f9edc804080) at postmaster.c:4252:3
frame #25: 0x00010c690d0e postgres`ServerLoop at postmaster.c:1745:7
frame #26: 0x00010c68e23a postgres`PostmasterMain(argc=8,
argv=0x7f9edac06440) at postmaster.c:1417:11
frame #27: 0x00010c565249 postgres`main(
bobs_pub. Surely this makes more sense?
I'm not a huge fan of the keyword "FUTURE" here, but I found a reference to
another database that uses that keyword for what I think is a similar purpose.
We should choose *something* for this, though, if we want things to be rational
going forward.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
"later in schema, computed then." A user who
diligently consults the documentation for one command to discover what "IN
SCHEMA" means may fairly, but wrongly, assume it means the same thing in
another command.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ind of confusion, but
created another kind. Per the docs on this feature:
FOR ALL TABLES IN SCHEMA
Marks the publication as one that replicates changes for all tables in the
specified list of schemas, including tables created in the future.
Like you, I wouldn't expect that defin
s intended to
future-proof against surprising behavioral changes.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ion
granularity sounds useful, but orthogonal, to this feature.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ee your patch set get further delayed by things that aren't
logically prerequisites. The conversation upthread was useful to determine
that they aren't prerequisites, but if anybody wants to explain to me why they
are
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
g these other commands, but don't want
to regret having drawn the line in the wrong place when later we decide to add
more roles like the one you are proposing.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
en it's not another backend, but our own, and we'd want to debug why
we're pinning the same page twice (or more) while replaying wal. Otherwise,
maybe it's a race condition with some other process that transiently pins a
buffer and occasionally causes this code to panic?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
t comments down-thread seem reasonable, so I suspect a new
patch will be needed. Would you like to author it, or would you prefer that I,
as the guilty party, do so?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ot
asking the community to accept the TAM back as a patch. The freedom I'm
talking about is the freedom to design and implement such a third-party TAM
without seeking community approval of the TAM's merits.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
nt, but what about a TAM that wants to
route different tuples to different pages? The "current_buf" isn't enough
information, and there's no void *extra field, so you're just sunk.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
In what sense does this made-up TAM conflict with mvcc and wal? It doesn't
have all the features of heap, but that's not the same thing as violating mvcc
or breaking wal.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
lause or appending no clause. Since the user can do this anyway, what's the
security implication in some syntactic sugar?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Jun 15, 2022, at 8:18 PM, Andres Freund wrote:
>
> Hi,
>
> On 2022-06-15 20:10:30 -0700, Mark Dilger wrote:
>>> On Jun 15, 2022, at 7:30 PM, Andres Freund wrote:
>>>> But it's up to the TAM what it wants to do with that boolean, if in fact it
&g
just trying to leverage the existing tests as much
as I can without having to reinvent tests to cover "chicago", and then reinvent
again to cover "detroit", and so forth.
If you develop enough TAMs in parallel, and go with the "using heap" solution,
you eventually
ble with the new one. I'm left no choices but to
copy my data over, loose my data, or abort the command. None of those are OK
options for me.
I'm open to different solutions. If a simple callback like
relation_supports_cluster(Relation rel) is too simplistic, and more parameters
with mo
> On Jun 15, 2022, at 7:21 PM, Mark Dilger wrote:
>
>> If a user does that for a table that doesn't support clustering, well, I
>> don't
>> see what's gained by not erroring out.
>
> Perhaps they want to give the TAM information about which in
> On Jun 15, 2022, at 7:14 PM, Andres Freund wrote:
>
> Hi,
>
> On 2022-06-15 19:07:50 -0700, Mark Dilger wrote:
>>> On Jun 15, 2022, at 6:55 PM, Andres Freund wrote:
>>>
>>> I think nothing would happen in this case - only pre-clustered tables ge
he target is
pre-clustered, and both will run against the table if the user has run an ALTER
TABLE..CLUSTER ON. Now, we could try to catch that latter command with a
utility hook, but since the VACUUM FULL is still problematic, it seems cleaner
to just add the callback I am proposi
> On Jun 15, 2022, at 6:01 PM, Andres Freund wrote:
>
> Hi,
>
> On 2022-06-15 17:21:56 -0700, Mark Dilger wrote:
>> While developing various Table Access Methods, I have wanted a callback for
>> determining if CLUSTER (and VACUUM FULL) should be run against a tab
tomers, etc., and for a given piece of DDL that
you want to release you only want to say which TAMs not to use, not to nail
down which TAM must be used.
Thoughts? I'll hold off posting a patch until the general idea is debated.
[*] It takes some extra work to get the TAP tests to play al
ay not be clustered" interface overly
simplistic?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
1 - 100 of 978 matches
Mail list logo
