'd like to know what
the spec says about it before going any further with this discussion.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
So, one of them
must be wrong. You've just replied that the spec is mute on the subject of #1.
Is there any support in the spec for claiming that #2 is wrong?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
;
> DROP ROLE bob CASCADE;
>
> then the command "REVOKE bob FROM A CASCADE;" is run and shouldn't throw
> an exception.
Right, and this will be run. It's just that other stuff, like dropping owned
objects, will also be run. I'm not seeing a prohibition
I'm curious to know whether your patch set has a solution.
Possibly, but I have stopped adding new topics to this particular patch set, as
I'm already getting requests to break it into separate sets and email threads.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
other database vendors go the way I'm
proposing, and we're the only ones with this ugly wart that you have to use a
different syntax for roles than for everything else? We'll be supporting that
ugly wart for years and years to come, and look ridiculous, and rightly so. I
don't want to invent an ugly wart unless I'm completely forced to do so.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
e new
owner of bobs_schema? Do you assign it to the database owner? What do you do?
And whatever you say we should do, how is that more spec compliant than what I
propose we do? I would expect the argument against X performing X+Y would cut
against anything you suggest as much as it cuts against what I suggest.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
if I can find that again.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Oct 7, 2021, at 12:31 PM, Mark Dilger wrote:
>
> Let me see if I can find that again.
12.6
::=
DROP ROLE
Syntax Rules
1) Let R be the role identified by the specified .
General Rules
1) Let A be any identified by a role authorization
descriptor as having been grante
l, then
you'd say that DROP ROLE bob CASCADE wasn't supposed to fail either. (Failing
is the unexpected action Y that I expected your rule to prohibit.)
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ze rather than defining
VARLENA_SIZE_LIMIT, but review comments suggested that was less clear.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Jul 14, 2021, at 7:57 AM, Mark Dilger wrote:
>
> so no valid toast pointer should contain a va_rawsize field greater than
> MaxAllocSize
... nor should any valid toast pointer contain a va_extinfo field encoding a
va_extsize greater than va_rawsize - VARHDRSZ.
Violations
back before pursuing anything of that
sort.
The relevant code exists back as far as the 9_4_STABLE branch, where commit
b89e151054a from 2014 first appears.
v1-0001-No-longer-ignoring-failures-on-file-close.patch
Description: Binary data
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Jul 15, 2021, at 1:03 PM, Mark Dilger wrote:
>
> Skipping some writes while not others easily creates a variety of failures,
> and for brevity I won't post a patch to demonstrate that here.
If anybody is curious, one common error I see when simulating a close()
> On Jul 15, 2021, at 1:51 PM, Mark Dilger wrote:
>
> one common error I see
Another common error is of the form
ERROR: could not map filenode "base/16384/16413" to relation OID
resulting from a ddl statement having not been written correctly, I think.
This, t
them. If lucky, the attempt to replay the changes will
abort because they don't make sense, but I've demonstrated to my own
satisfaction that nothing prevents silent data loss if the failure to write
changes happens to destroy a complete rather than partial change.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ion into
+* it.
src/bin/pg_basebackup/pg_basebackup.c contains word wrap changes like the above
which would better be left to a different commit, if done at all.
+ if (state.manifest_file !=NULL)
Need a space after !=
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
g code, but
> that seems difficult to avoid.
I was only imagining having a callback for injecting manifests or recovery
configurations. It is not necessary that this be done in the current patch
set, or perhaps ever.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ly. Even then, having now
studied CreateBackupStreamer a bit more, the idea seems less appealing than it
did initially. I don't think it makes things any cleaner when only supporting
tar, and maybe not even when supporting multiple formats, so I'll withdraw the
suggestion.
—
Mark
's not to do with this patch, but if we're tightening up the use
of strtol in frontend tools, maybe we can use the identical logic in both
places.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
o far as I am aware. I would very much like
more eyeballs on this patch, and if anybody sees why this is an insufficient
solution, please speak up. But it's not as if I punted the security issue down
the road to some ill-defined future patch. On the contrary, this patch both
creates the
ent triggers may be used to
implement an auditing system, and we wouldn't want pg_database_security to be
enough privilege to circumvent the auditing system.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
user, will see a behavior change. I'm not super happy
with that, but I think it is better than the GUC based solution. Event
triggers owned by a superuser continue to work as they do now. Event triggers
owned by a non-superuser cannot be used to force a privileged user to run a
command tha
as superuser, as pg_network_security, or whatever. This might also be
used to secure operations on indexes over user defined functions. If the index
operation is run in this mode, the index operation could throw an error rather
than performing a function maliciously embedded inside the index function call.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ng actions performed by pg_network_security
members. On the other hand, if pg_network_security can also set the GUC, then
pg_network_security can circumvent audit logging that pg_database_security put
in place. What's the point in having these as separate roles if they can
circumvent each
> On Jul 23, 2021, at 1:57 PM, Mark Dilger wrote:
>
> What's the point in having these as separate roles if they can circumvent
> each other's authority?
That was probably too brief a reply, so let me try again. If the GUC
circumvents the event trigger, then my an
> On Jul 23, 2021, at 2:04 PM, Mark Dilger wrote:
>
> If the GUC merely converts the event trigger into an error, then you have the
> problem that the customer can create event triggers which the service
> provider will need to disable (because they cause the service provider
d to do" means. For instance, if Alice is only allowed to enable or
disable connections to the database, and she disables them, then she has
prevented Bob from, for example, creating tables, something which Bob is
otherwise allowed to do, because without the ability to connect, he cannot
crea
[1] https://www.postgresql.org/message-id/214052.1627331086%40sss.pgh.pa.us
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
cryptic messages are produced for other object types that
follow this pattern, maybe that should be a separate thread.
[1]
https://www.postgresql.org/message-id/acbc4035-5be6-9efd-fb37-1d61b8c35ea5%402ndquadrant.com
[2]
https://www.postgresql.org/message-id/ed24d725-1b8c-ed25-19c6-61410
AUTHORIZATION;
+DROP ROLE temp_role;
I believe this case simply has not had any test coverage, as I don't see any
way the current code would ever work. It treats the Oid of the statistics
object as a type, which it is not.
v1-0001-Fix-cache-lookup-error-in-ownership-check.patch
Descripti
atch=) at
regexp.c:351:7 [opt]
[1] https://www.postgresql.org/message-id/2219936.1628115334%40sss.pgh.pa.us
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Aug 5, 2021, at 1:38 PM, Mark Dilger wrote:
>
> +select 'vyrlvyrlwvqko' ~ '(?:(?:((.((\2)\1.){0,0}?';
I've boiled it down a bit more:
+select '' ~ '()\1{0}';
+ ?column?
+--
+ t
+(1 row)
+
+select '' ~ '()
ed]
RE_execute(dat=, dat_len=31, nmatch=0, pmatch=0x)
at regexp.c:322:10 [opt]
frame #16: 0x000104242c50 postgres`textregexne [inlined]
RE_compile_and_execute(text_re=, dat=, dat_len=31,
cflags=19, collation=, nmatch=0, pmatch=) at
regexp.c:357 [opt]
—
M
' . rand_string() . ']' if ($dice == 22);
return '[^' . rand_string() . ']' if ($dice == 23);
if ($dice < 60)
{
my $result = '(' . rand_rgx($depth+1) . ')';
$max_capture++;
return $result;
}
return '(?:' . rand_rgx($depth+1) . ')' if ($dice < 70);
return '(?=' . rand_rgx($depth+1) . ')' if ($dice == 71);
return '(?!' . rand_rgx($depth+1) . ')' if ($dice == 72);
return '(?<=' . rand_rgx($depth+1) . ')' if ($dice == 73);
return '(?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
about this:
> DROP COLUMN [ IF EXISTS ]
> This form drops a column from a table. Indexes and table constraints
> involving the column will be automatically dropped as well.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
quot;,"","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","",""}
+ regexp_split_to_array
+--
+ {jdpveoarcnsarcnsarcnszieqbqbqbqbiufdlywphbnrxtdoboouuzcqiqmenj}
I'm not sure what *should* be returned here, only that it is a behavioral
change.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
x27;ircecpbgyiggvtruqgxzigxzigxzisdbkuhbkuhrvl',
'(((.)))(?:(\3))[^\f]');
regexp_matches
-(0 rows)
+ {g,g,g,g}
+(1 row)
select regexp_matches('fhgxnvbvjaej', '(((.)).)((\3)((.)))', 'csx');
- regexp_matches
-
-(0 rows)
+ regexp_matches
+---
+ {vb,v,v,vj,v,j,j}
+(1 row)
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Aug 8, 2021, at 10:15 AM, Mark Dilger wrote:
>
> But these next two look to me correct before the patch and wrong after:
>
> select regexp_matches('ircecpbgyiggvtruqgxzigxzigxzisdbkuhbkuhrvl',
> '(((.)))(?:(\3))[^\f]');
> regexp_matches
&g
> On Aug 8, 2021, at 10:29 AM, Tom Lane wrote:
>
> Mark Dilger writes:
>> Applying your to master changes
>> the outcome of some regular expression queries, but I *think* it changes
>> them for the better.
>
> [ squint... ] You sure you applied the pa
> On Aug 8, 2021, at 10:32 AM, Mark Dilger wrote:
>
> I'm not sure what you mean by "as-committed". Did you commit one of these
> recently?
Nevermind, I see the commit now.
I'll rerun my tests with the new master. I was still using the code that I
> On Aug 8, 2021, at 10:34 AM, Mark Dilger wrote:
>
> I'll rerun my tests with the new master. I was still using the code that I
> pulled yesterday.
I am now testing REL_13_STABLE (ba9f665a4413f855bbf4b544481db326f7b9bd73) vs
master (c1132aae336c41cf9d316222e525d8d593c2b5
-
+ {snfwbvxeesnzqabixqbixqiumpgxdemmxvnsemjxgqoqknrqessmcqmfslfspskqpqxe}
(1 row)
The pattern matches any double character. I would expect it to match the "ee",
the "mm" and the "ss" in the text. With the patched code, it matches nothing.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
aster. This
is a test suite of nearly 1.5 million separate regular expressions.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
est it any further unless
you have something in particular you'd like me to focus on.
Thanks again for working on this.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
superuser privileges and then we can revisit this issue and loosen the
requirement in a subsequent commit.
What do you think?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
$whereclause1 = sprintf($where1, $a, $b);
print("
select actual, estimated, abs(actual - estimated) AS misestimate
from check_estimated_rows('select * from $tblname where $whereclause1');");
}
foreach my $where2 (keys %wherepattern2)
{
my $whereclause1 = sprintf($where2, $a, $b, $a, $c);
print("
select actual, estimated, abs(actual - estimated) AS misestimate
from check_estimated_rows('select * from $tblname where $whereclause1');");
}
foreach my $where3 (keys %wherepattern3)
{
my $whereclause1 = sprintf($where3, $a, $b, $a, $c, $c, $a);
print("
select actual, estimated, abs(actual - estimated) AS misestimate
from check_estimated_rows('select * from $tblname where $whereclause1');");
}
}
}
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
);
+server closed the connection unexpectedly
+ This probably means the server terminated abnormally
+ before or while processing the request.
+connection to server was lost
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
hours ago, and I can't seem to break it. There are pre-existing
problems in the regex code, but this doesn't seem to add any new breakage.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
lity of nested parens.
Ugg. That means our code throws an error where perl does not, pretty well
negating my point above. If we're already throwing an error for this type of
thing, I agree we should be consistent about it. My personal preference would
have been to do the same thing as
> On Aug 9, 2021, at 5:14 PM, Mark Dilger wrote:
>
>our $match;
>if ('foo' =~ m/((.)(??{ die; })){0}(..)/)
I left in a stray variable. A prior version of this script was assigning to
$match where it now has die. Sorry for any confusion.
—
Mark Dil
s capturing. This example also
does that, and with a backref, because it dies with "got here".
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Aug 9, 2021, at 6:17 PM, Mark Dilger wrote:
>
> Well, this doesn't die either:
Meaning it doesn't die in the part of the pattern qualified by {0} either. It
does die in the other part. Sorry again for the confusion.
—
Mark Dilger
EnterpriseDB: http://www.e
---
+ f
+(1 row)
I ran a lot of tests with the patch, and the asserts have all cleared up, but I
don't know how to think about the user facing differences. If we had a good
reason for raising an error for these back-references, maybe that'd be fine,
but it seems to just be an implemen
> On Aug 9, 2021, at 7:20 PM, Tom Lane wrote:
>
> So I took another look at the code, and it doesn't seem that hard
> to make it act this way. The attached passes regression, but
> I've not beat on it with random strings.
I expect to get back around to testing thi
n if we ever wanted to have official packages for non-test purposes, we
could start another namespace under PostgreSQL.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
agers wanted something that was unlikely to collide.
Publishing on CPAN would be the way to claim the namespace.
What's the purpose of this idea then? If there isn't one, I'd rather just keep
the current names.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
modify pub1, not even with respect to user2's own table.
user1 can modify its own publication except for adding someone else's table.
This seems correct to me.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
B >= A or not B <> B or B = B
But there are plenty that got worse without that, such as the following
examples:
better:25, worse:39: A < B and A < B or B > A
better:10, worse:48: A < B and A < C
better:10, worse:54: A < B and A < C or C > A
I'll go test random data designed to have mcv lists of significance
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Aug 11, 2021, at 7:51 AM, Mark Dilger wrote:
>
> I'll go test random data designed to have mcv lists of significance
Done. The data for column_i is set to floor(random()^i*20). column_1
therefore is evenly distributed between 0..19, with successive columns weighted
ying the patch. I'm going to dig deeper into those to see
if that conclusion survives bumping up the size of the dataset. It will take
quite some time to run the tests with a huge dataset, but I don't see how else
to investigate this.
—
Mark Dilger
EnterpriseDB: http://www.e
se more closely.
Yeah, I'm working on a correlated stats test as I write this. I'll get back to
you when I have results.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Aug 11, 2021, at 3:48 PM, Mark Dilger wrote:
>
> I'm working on a correlated stats test as I write this. I'll get back to you
> when I have results.
Ok, the tests showed no statistically significant regressions. All tests
included the same sorts of whereclause
e to
get back to this.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
age. The guts of
the corruption check would be shared between the two interfaces. I haven't
tried writing a patch yet, but it seems the patch shouldn't be terribly
complicated.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
T t_oid oid,
OUT t_data bytea
Should it also return the full page? That would be quite verbose (an extra 8k
per row), but it could be fed into any of pageinspect's functions for further
analysis.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
h
cases. In other cases, I don't much see the point.
It seems that sampling the fraction of rows where (A op B) is true for any
given op would be more helpful.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
gt;<0002-pg_amcheck-test-typofix.patch>
These look correct.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
shing-regular-expression-backref-errors.patch
Description: Binary data
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
see anything about whether
backreferences are allowed within pcre assertions, but I know that perl itself
does allow them. So maybe the error text used by other implementations is
irrelevant?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
with two distinct approaches being used.
I'm confused. This patch set doesn't come within a country mile of CREATEROLE.
Why should this patch set have to coordinate with that one? I'm not arguing
with you -- merely asking what I'm misunderstanding?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ecome superusers are on the other side of the wall.
That's fine. I'd have to rework the patch a bit, but conceptually that seems
doable. We could also say that non-superusers who are members of privileged
roles (pg_execute_server_programs, pg_signal_backend, etc) are likewise on the
#x27;s a bug fix then
> shouldn't it be separated and back-patched..?
It is already a patch waiting for commit.
Discussion:
https://www.postgresql.org/message-id/1F238937-7CC2-4703-A1B1-6DC225B8978A%40enterprisedb.com
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
parens.patch
I've beaten on this with random patterns and it seems to hold up just fine. I
have also reviewed the diffs and, for the patterns where the output changes,
everything looks correct. I can't find anything wrong with this patch.
—
Mark Dilger
EnterpriseDB: http://www.ente
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
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
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
> 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:
>
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 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
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
. Prior to the corrupting action the values were
all unique.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
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
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
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
ion
granularity sounds useful, but orthogonal, to this feature.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
s intended to
future-proof against surprising behavioral changes.
—
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
"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
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
> 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
> 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
struct; that didn't
> seem necessary.
Good catch. I agree with the change.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
date. I decided to keep that work independent of this
patch, as the code is logically distinct.
v1-0001-Renaming-relkind-as-objtype-where-appropriate.patch
Description: Binary data
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
s all detected corruptions) does not change, which
verifies your observation that verify_heapam is not checking for this. I've
attached that as a patch to this email. Note that this patch should be applied
atop the v6 patch recently posted in another email.
WIP_dilip_kumar_idea.p
rated words, but
can't find any indication of that, neither in the postgres sources, nor in the
snowball sources I pulled from their repo. Is there some architectural
separation of stemming from transliteration such that we'd never need to worry
about it? If snowball ever published stem
e
flaws in the patch even if the TAP tests you write are themselves not accepted
into the project.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
, so I think of it
as a mere verb phrase and not a full sentence.
Making matters even more complicated, portions of the logic in verify_heapam
were taken from sections of code that would ereport(), elog(), or Assert() on
corruption, and when I took such code, I sometimes also took the comments in
unmodified form. That means that my normal commenting rules don't apply, as
I'm not the comment author in such cases.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
uessing that hardening the backend would be a separate patch? Or did you
want that as part of this one?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Jul 1, 2020, at 2:45 AM, Daniel Gustafsson wrote:
>
>> On 3 Jun 2020, at 19:05, Mark Dilger wrote:
>
>> The attached patch cleans this up.
>
> The gram.y hunks in this patch no longer applies, please submit a rebased
> version. I'm marking the entr
ically, you'll need to think about the fact that you have TransactionIds
in your tables older than what clog knows about.
You may want to think about how keeping dead rows around affects index
performance.
I expect these issues to be less than half what you would need to resolve,
though m
701 - 800 of 980 matches
Mail list logo
