EATE ROLE command may now fail if the creating role has
insufficient privilege on the roles so listed. Such failures were
not possible before, since the CREATEROLE privilege was always
sufficient.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Oct 1, 2021, at 6:15 AM, Alvaro Herrera wrote:
>
> On 2021-Sep-30, Mark Dilger wrote:
>
>> The solution is simple enough: stop using HEAP_RELOPT_NAMESPACES when
>> parsing reloptions for views and instead create a
>> VIEW_RELOPT_NAMESPACES array which doe
> On Oct 3, 2021, at 10:04 AM, Mark Dilger wrote:
>
>> On Oct 2, 2021, at 10:32 AM, Peter Geoghegan wrote:
>>
>> On Sat, Oct 2, 2021 at 4:49 AM PG Bug reporting form
>> wrote:
>>> Although you can add --exclude-relation=*.pg_temp*.*, this behaviour di
or ShareLock on relation 16406 of database 16384; blocked
by process 9555.
HINT: See server log for query details.
ERROR: cannot check index "t_idx"
DETAIL: Index is not valid.
[1] + exit 1 psql -c "CREATE INDEX CONCURRENTLY t_idx ON t(i);"
If Peter agrees that this is n
> On Oct 4, 2021, at 10:58 AM, Peter Geoghegan wrote:
>
> On Mon, Oct 4, 2021 at 8:10 AM Mark Dilger
> wrote:
>>> There is another issue, that maybe should be discussed separately (or
>>> this thread could be renamed to "... on checking specific relatio
hing other than a silent success is needed to
let them know what is going on.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Oct 4, 2021, at 4:28 PM, Mark Dilger wrote:
>
> pg_amcheck -i idx1 -i idx2 -i idx3
I forgot to mention: There's a continuum between `pg_amcheck -a` which checks
everything in all databases of the cluster, and `pg_amcheck -i just_one_index`.
There are any number of c
say that a deadlock is possible, merely that the function may return with
an error. I was totally content to get an error back, since errors are how the
verify_nbtree functions communicate everything else, and the handler for those
functions is already prepared to deal with the error messages
ck or less can be acquired on database objects
during recovery.
It doesn't get as far as btree_index_mainfork_expected(). So I am changing
pg_amcheck to filter out indexes when pg_is_in_recovery() is true and
relpersistence='u'. Does that sound right to you?
—
Mark Dilger
E
le creation:
superuser
+---> alice
+---> charlie
+---> diane
+---> bob
It makes sense that alice can take ownership of diane and drop charlie, but not
that bob can do so. Nor should charlie be able to transfer ownership of diane
to alice. Nor should charlie be able to drop hi
> On Oct 5, 2021, at 9:58 AM, Peter Geoghegan wrote:
>
> I apologize to Mark.
I took no offense. Actually, I owe you a thank-you for having put so much
effort into debating the behavior with me. I think the patch to fix bug #17212
will be better for it.
(And thanks to Rober
> On Oct 5, 2021, at 10:14 AM, Stephen Frost wrote:
>
> What does the “ownership” concept actually buy us then?
DROP ... CASCADE.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Oct 5, 2021, at 10:20 AM, Stephen Frost wrote:
>
> Greetings,
>
> On Tue, Oct 5, 2021 at 13:17 Mark Dilger wrote:
> > On Oct 5, 2021, at 10:14 AM, Stephen Frost wrote:
> >
> > What does the “ownership” concept actually buy us then?
>
> DROP ...
other stuff, then dropping the role cascade
means dropping the other stuff.
Could you elaborate more on the difference between object management and
consistency as it applies to this issue?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
reviewing!
I expect to post a new version shortly.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
hecking options should be automatically downgraded under circumstances
where they cannot be applied
3) unlogged relations during replication are by definition not corrupt
I think #1 and #3 are unsurprising enough that they need no documentation
update. #2 is slightly surprising (at least to me)
tinguish between statements
like X SHALL DO Y and X SHALL DO NOTHING BUT Y. I don't know if the spec
contains a concept of roles owning other roles, and if not, does it forbid that
concept? I should think that if that concept is a postgres extension not
present in the spec, then
re, and now it just downgrades the check. This is
hardly tautological. I'm only willing to post a patch with that change because
I can see a practical argument that somebody might run that as a cron job and
they don't want the cron job failing when the database happens to go into
recovery. But again, not at all tautological.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
x27;d say that's irrelevant. I'm not
proposing to change what REVOKE does. If not, could you clarify? Did I
misunderstand?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
or something that fundamentally doesn't make
> any sense?
The user may not know that the system has changed.
For example, if I see errors in the logs suggesting corruption in a relation
named "mark" and run pg_amcheck --relation=mark, I expect that to check the
relation. If that
hat say what Vertica does. I found
some Enterprise DB docs about what Advanced Server does (or course, since I
work here.) I don't see much else.
You have quoted me parts of the spec about what REVOKE is supposed to do, and I
have responded about why I don't see the connection to DROP ROLE...CASCADE.
Are there any other references to either the spec or how other common databases
handle this?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ffect how we go about designing these things.
>
> A lot of my disagreements around this stuff (especially with Mark)
> seem to stem from this basic understanding of things, in one way or
> another.
I think the disagreements are about something else.
Talking about pg_amcheck "checking
> On Oct 6, 2021, at 2:45 PM, Mark Dilger wrote:
>
> and db3 is in recovery.
> they're scattered across different databases, some in recovery, some not.
What I mean here is that, since pg_amcheck might run for many hours, and
database may start in recovery but then exit
emporary table named
"xyzacountngo" and that gets skipped because it's a temp table, I don't know
what feedback the user should get. That's a thorny user interfaces question,
not a corruption checking question, and I don't think you need to weigh in
unless you want to. I'll most likely go with whatever is the simplest to code
and/or most similar to what is currently in the tree, because I don't see any
knock-down arguments one way or the other.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
'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
> On Oct 6, 2021, at 10:48 PM, Bharath Rupireddy
> wrote:
>
> Hi Mark, thanks for this work. I'm late to be here in this thread,
> please note that I didn't go through the entire thread as it is quite
> long for me to read.
Thanks for joining.
> I have a q
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
Is there an issue with the ODBC Source downloads today?
The source download URL isn't working:
https://www.postgresql.org/ftp/odbc/versions/src/
Thanks, Mark
Thanks All!
From: Kashif Zeeshan
Sent: Tuesday, June 11, 2024 7:55 AM
To: Fahar Abbas
Cc: Mark Hill ; pgsql-hackers@lists.postgresql.org
Subject: Re: ODBC Source Downloads Missing
EXTERNAL
On Tue, Jun 11, 2024 at 4:52 PM Fahar Abbas
mailto:syed.fahar.ab...@gmail.com>> wrote:
Hell
ng to keep the table small enough to fit in the
Postgres buffer pool. I also have results from tables that are much larger
than memory, and even in that case the problem can be reproduced.
--
Mark Callaghan
mdcal...@gmail.com
801 - 900 of 1161 matches
Mail list logo
