Re: Add --tablespace option to reindexdb

2021-03-01 Thread Mark Dilger
r/statement: REINDEX \(VERBOSE\) TABLE CONCURRENTLY public\.test1;/, + 'reindex concurrently with verbose output'); but I don't see what tests of the --concurrently option have to do with this patch. I'm not saying there is anything wrong with this change, but it seems out of place. Am I m

Re: Add --tablespace option to reindexdb

2021-03-01 Thread Mark Dilger
1, + [ ], + [ qr/cannot move system relation/ ], 'reindex toast index concurrently with tablespace'); # connection strings — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: Add --tablespace option to reindexdb

2021-03-01 Thread Mark Dilger
do here, beware that you are using similar language in the --help, so consider changing that, too. — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: new heapcheck contrib module

2021-02-23 Thread Mark Dilger
> On Feb 17, 2021, at 12:56 PM, Robert Haas wrote: > > On Wed, Feb 17, 2021 at 1:46 PM Mark Dilger > wrote: >> It will reconnect and retry a command one time on error. That should cover >> the case that the connection to the database was merely lost. If the secon

Re: multi-install PostgresNode fails with older postgres versions

2021-04-08 Thread Mark Dilger
> On Apr 7, 2021, at 8:43 AM, Andrew Dunstan wrote: > > > On 4/7/21 1:03 AM, Mark Dilger wrote: >> The v1 patch supported postgres versions back to 8.4, but v2 pushes that >> back to 8.1. >> >> The version of PostgresNode currently committed relies on

Re: pg_amcheck contrib application

2021-04-08 Thread Mark Dilger
> On Apr 7, 2021, at 1:16 PM, Robert Haas wrote: > > On Sun, Apr 4, 2021 at 8:02 PM Mark Dilger > wrote: >> v18-0001 - Finishes work started in commit 3b6c1259f9 that was overlooked >> owing to how I had separated the changes in v17-0002 vs. v17-0003 > > Commi

Re: multi-install PostgresNode fails with older postgres versions

2021-04-07 Thread Mark Dilger
> On Apr 7, 2021, at 12:13 PM, Alvaro Herrera wrote: > > On 2021-Apr-07, Mark Dilger wrote: > >> It's not sufficient to think about postgres versions as "10", "11", >> etc. You have to be able to spin up nodes of any build, like "9

Re: multi-install PostgresNode fails with older postgres versions

2021-04-07 Thread Mark Dilger
per micro release. So you'd have a PostgresNode of type "10" or such, but how does that help? If you have ten different versions of "10" in your test, they all look the same? — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: multi-install PostgresNode fails with older postgres versions

2021-04-07 Thread Mark Dilger
g on the enabled features, the conditions, > what GUC was enabled by default or not, etc. So I end up with this design. > > I really don't want to waste community brain cycles in discussions and useless > reviews. But as far as someone agree to review it, I already have the material

Re: multi-install PostgresNode fails with older postgres versions

2021-04-07 Thread Mark Dilger
t; My limited set of tests are working with versions back to 9.0 so far. > > My 2¢ Hmm, I took a look. I'm not sure that we're working on the same problem, but I might have missed something. — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: multi-install PostgresNode fails with older postgres versions

2021-04-07 Thread Mark Dilger
> On Apr 7, 2021, at 9:26 AM, Jehan-Guillaume de Rorthais > wrote: > > On Wed, 7 Apr 2021 09:08:31 -0700 > Mark Dilger wrote: > >>> On Apr 7, 2021, at 7:37 AM, Jehan-Guillaume de Rorthais > >>> And here is a demo test file: >>> https://gi

Re: pg_amcheck contrib application

2021-04-08 Thread Mark Dilger
> On Apr 8, 2021, at 1:05 PM, Robert Haas wrote: > > On Thu, Apr 8, 2021 at 3:02 PM Mark Dilger > wrote: >> Imagine a toasted attribute with 18 chunks numbered [0..17]. Then we update >> the toast to have only 6 chunks numbered [0..5] except we corruptly keep &g

Re: pg_amcheck contrib application

2021-04-08 Thread Mark Dilger
> On Apr 8, 2021, at 3:11 PM, Robert Haas wrote: > > On Thu, Apr 8, 2021 at 5:21 PM Mark Dilger > wrote: >> All this leads me to believe that we should report the following: >> >> 1) If the total number of chunks retrieved differs from the expected number,

Re: multi-install PostgresNode fails with older postgres versions

2021-04-07 Thread Mark Dilger
> On Apr 7, 2021, at 1:28 PM, Alvaro Herrera wrote: > > On 2021-Apr-07, Mark Dilger wrote: > >> I was commenting on the design to have the PostgresNode derived >> subclass hard-coded to return "10" as the version: >> >>sub version { retur

Re: multi-install PostgresNode fails with older postgres versions

2021-04-07 Thread Mark Dilger
> On Apr 7, 2021, at 2:04 PM, Alvaro Herrera wrote: > > On 2021-Apr-07, Mark Dilger wrote: > >> It seems we're debating between two designs. In the first, each >> PostgresNode function knows about version limitations and has code >> like: >> >>

Re: pg_amcheck contrib application

2021-04-15 Thread Mark Dilger
> On Apr 14, 2021, at 10:17 AM, Robert Haas wrote: > > On Mon, Apr 12, 2021 at 11:06 PM Mark Dilger > wrote: >> It now reports: >> >> # heap table "postgres"."public"."test", block 0, offset 18, attribute 2: >> # toast v

Re: pg_amcheck option to install extension

2021-04-18 Thread Mark Dilger
> On Apr 18, 2021, at 6:19 AM, Andrew Dunstan wrote: > > how about specifying pg_catalog as the schema instead of public? Done. v2-0001-Adding-install-missing-option-to-pg_amcheck.patch Description: Binary data — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The E

Re: multi-install PostgresNode fails with older postgres versions

2021-04-19 Thread Mark Dilger
> any attempt at version compatibility. > > We can revisit compatibility further in the next release. Sounds good. — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: pg_amcheck option to install extension

2021-04-19 Thread Mark Dilger
> On Apr 19, 2021, at 9:32 AM, Andrew Dunstan wrote: > > > On 4/18/21 7:32 PM, Alvaro Herrera wrote: >> On 2021-Apr-18, Andrew Dunstan wrote: >> >>> On 4/17/21 3:43 PM, Mark Dilger wrote: >>>> I'd also like your impressions on whether we're

Re: pg_amcheck option to install extension

2021-04-19 Thread Mark Dilger
d be prepared to make the necessary moves then. This was the request that motivated the move to src/bin. — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: multi-install PostgresNode fails with older postgres versions

2021-04-19 Thread Mark Dilger
> On Apr 19, 2021, at 10:25 AM, Jehan-Guillaume de Rorthais > wrote: > > On Mon, 19 Apr 2021 12:37:08 -0400 > Andrew Dunstan wrote: > >> >> On 4/19/21 10:43 AM, Mark Dilger wrote: >>> >>>> On Apr 19, 2021, at 5:11 AM, Andrew Dunsta

Re: multi-install PostgresNode fails with older postgres versions

2021-04-19 Thread Mark Dilger
sts and review... I did that, too, in the 0002 version of my patch. Perhaps we need to merge your work and mine. — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: pg_amcheck contrib application

2021-04-19 Thread Mark Dilger
> On Apr 19, 2021, at 12:50 PM, Robert Haas wrote: > > On Thu, Apr 15, 2021 at 1:07 PM Mark Dilger > wrote: >> I have added the verb "has" rather than "contains" because "has" is more >> consistent with the phrasing of other similar c

Re: pg_amcheck option to install extension

2021-04-19 Thread Mark Dilger
k and amcheck have to both be installed to work, but I don't think that point of view makes much sense in reality. The computer running the client and the computer running the server are frequently not the same computer. — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: pg_amcheck option to install extension

2021-04-19 Thread Mark Dilger
> On Apr 19, 2021, at 8:06 PM, Michael Paquier wrote: > > On Mon, Apr 19, 2021 at 07:15:23PM -0700, Mark Dilger wrote: >> There is another issue to consider. Installing pg_amcheck in no way >> opens up an avenue of attack that I can see. It is just a client >>

Re: pg_amcheck option to install extension

2021-04-19 Thread Mark Dilger
> On Apr 19, 2021, at 9:22 PM, Michael Paquier wrote: > > On Mon, Apr 19, 2021 at 08:39:06PM -0700, Mark Dilger wrote: >> This is a classic privilege escalation attack. Bob has one >> privilege, and uses it to get another. > > Bob is a superuser, so it has all

Re: Converting contrib SQL functions to new style

2021-04-14 Thread Mark Dilger
up in pg_extension join pg_namespace, and substituted back in. — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: pg_amcheck option to install extension

2021-04-20 Thread Mark Dilger
> On Apr 20, 2021, at 5:54 AM, Robert Haas wrote: > > On Tue, Apr 20, 2021 at 1:31 AM Mark Dilger > wrote: >> I think you are conflating the concept of an operating system adminstrator >> with the concept of the database superuser/owner. > > You should

Re: Privilege boundary between sysadmin and database superuser [Was: Re: pg_amcheck option to install extension]

2021-04-20 Thread Mark Dilger
> On Apr 20, 2021, at 3:19 PM, Tom Lane wrote: > > Mark Dilger writes: >>> On Apr 20, 2021, at 5:54 AM, Robert Haas wrote: >>> On Tue, Apr 20, 2021 at 1:31 AM Mark Dilger >>> wrote: >>>> I think you are conflating the concept of an oper

Privilege boundary between sysadmin and database superuser [Was: Re: pg_amcheck option to install extension]

2021-04-20 Thread Mark Dilger
> On Apr 20, 2021, at 5:54 AM, Robert Haas wrote: > > On Tue, Apr 20, 2021 at 1:31 AM Mark Dilger > wrote: >> I think you are conflating the concept of an operating system adminstrator >> with the concept of the database superuser/owner. > > You should

Re: pg_amcheck option to install extension

2021-04-17 Thread Mark Dilger
. I'd also like your impressions on whether we're likely to move contrib/amcheck into core anytime soon. If so, is it worth adding an option that we'll soon need to deprecate? v1-0001-Adding-install-missing-option-to-pg_amcheck.patch Description: Binary data — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: pg_amcheck contrib application

2021-04-09 Thread Mark Dilger
> On Apr 8, 2021, at 3:11 PM, Robert Haas wrote: > > On Thu, Apr 8, 2021 at 5:21 PM Mark Dilger > wrote: >> All this leads me to believe that we should report the following: >> >> 1) If the total number of chunks retrieved differs from the expected number,

Re: Converting contrib SQL functions to new style

2021-04-14 Thread Mark Dilger
> On Apr 14, 2021, at 2:47 PM, Vik Fearing wrote: > > On 4/14/21 7:36 PM, Tom Lane wrote: >> Mark Dilger writes: >>>> On Apr 13, 2021, at 3:26 PM, Tom Lane wrote: >>>> However I think we may still need an assumption that earthdistance >>>&g

Re: pg_amcheck contrib application

2021-04-12 Thread Mark Dilger
> On Apr 9, 2021, at 1:51 PM, Robert Haas wrote: > > On Fri, Apr 9, 2021 at 2:50 PM Mark Dilger > wrote: >> I think #4, above, requires some clarification. If there are missing >> chunks, the very definition of how large we expect subsequent chunks to be &g

Re: pg_amcheck contrib application

2021-04-22 Thread Mark Dilger
> On Apr 19, 2021, at 5:07 PM, Mark Dilger wrote: > > > >> On Apr 19, 2021, at 12:50 PM, Robert Haas wrote: >> >> On Thu, Apr 15, 2021 at 1:07 PM Mark Dilger >> wrote: >>> I have added the verb "has" rather than "contains"

Re: Improved regular expression error message for backrefs

2021-08-22 Thread Mark Dilger
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

Improved regular expression error message for backrefs

2021-08-22 Thread Mark Dilger
Description: Binary data — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)

2021-08-24 Thread Mark Dilger
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

Re: Another regexp performance improvement: skip useless paren-captures

2021-08-24 Thread Mark Dilger
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.enterprisedb.com The Ent

Re: amcheck/verify_heapam doesn't check for interrupts

2021-08-26 Thread Mark Dilger
l reindexes and vacuums running in backends. It should be just as safe to ctrl-c out of pg_amcheck as out of those two. They all three use fe_utils/cancel.h's setup_cancel_handler(), so I would expect modifying verify_heapam would be enough. — Mark Dilger EnterpriseDB: http://www.enterpr

Re: amcheck/verify_heapam doesn't check for interrupts

2021-08-26 Thread Mark Dilger
> On Aug 26, 2021, at 4:39 PM, Peter Geoghegan wrote: > >> Not any good one that I can see. > > Seems that way. Want to post a patch? Sure. I just posted another unrelated patch for amcheck this morning, so it seems a good day for it :) — Mark Dilger

Re: amcheck/verify_heapam doesn't check for interrupts

2021-08-26 Thread Mark Dilger
> On Aug 26, 2021, at 4:41 PM, Mark Dilger wrote: > >> Seems that way. Want to post a patch? > > Sure. v1-0001-Add-CHECK_FOR_INTERRUPTS-to-verify_heapam.patch Description: Binary data — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: verify_heapam for sequences?

2021-08-26 Thread Mark Dilger
t assumption. v1-0001-WIP-patch-to-support-amcheck-of-sequences.patch.WIP Description: Binary data — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)

2021-08-27 Thread Mark Dilger
re than helpful. Thoughts? [1] https://www.postgresql.org/message-id/17554.1120258001%40sss.pgh.pa.us — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: Use extended statistics to estimate (Var op Var) clauses

2021-08-28 Thread Mark Dilger
her than recomputing them? It's a little messy, since these are the only two functions out of about ten which follow this pattern, so you'd have to pass NULLs into get_restriction_variable() from the other eight callers, but it still looks like that would be a win. — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: Use extended statistics to estimate (Var op Var) clauses

2021-08-28 Thread Mark Dilger
case of only one table end up with a table column compared against itself. You could argue that those people need to fix their queries/generators to not do this sort of thing, but the end user affected by such queries may have little ability to fix it. — Mark Dilger EnterpriseDB: http:

Re: Bug fix for cache lookup failure for statistic_ext type

2021-08-31 Thread Mark Dilger
> On Aug 31, 2021, at 10:50 AM, Tomas Vondra > wrote: > > I've pushed a fix for this. And then a fix for the fix :-( because I forgot > about the rule that role names in regression tests should start with regress_ > prefix, so animals enforcing this failed. Than

Re: Minor pg_amcheck fixes spotted while reading code

2021-08-20 Thread Mark Dilger
gt;<0002-pg_amcheck-test-typofix.patch> These look correct. — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: Use extended statistics to estimate (Var op Var) clauses

2021-08-20 Thread Mark Dilger
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

Re: Use extended statistics to estimate (Var op Var) clauses

2021-08-18 Thread Mark Dilger
to get back to this. — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: reporting TID/table with corruption error

2021-08-19 Thread Mark Dilger
id 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

Re: reporting TID/table with corruption error

2021-08-19 Thread Mark Dilger
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

Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)

2021-08-23 Thread Mark Dilger
at'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 other side of that wall. Does that work? — Mark Dilger EnterpriseD

Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)

2021-08-23 Thread Mark Dilger
s 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

Re: Skipping logical replication transactions on subscriber side

2021-09-02 Thread Mark Dilger
ng data in the table where the conflict arises. These other options are DDL and do not easily come to mind when I read that phrase. — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: Skipping logical replication transactions on subscriber side

2021-09-02 Thread Mark Dilger
? 0001-Adding-tests-of-subscription-errors.patch Description: Binary data — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: [Patch] ALTER SYSTEM READ ONLY

2021-09-07 Thread Mark Dilger
> On Aug 31, 2021, at 5:15 AM, Amul Sul wrote: > > Attached is the rebased version for the latest master head. Hi Amul! Could you please rebase again? — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: [Patch] ALTER SYSTEM READ ONLY

2021-09-09 Thread Mark Dilger
out. If not, a mia culpa saying, "hey, were not terribly safe about this" should be explicit in the comment. — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: [Patch] ALTER SYSTEM READ ONLY

2021-09-09 Thread Mark Dilger
d a timeout as I suggested above, as such a timeout parameter when allowing wal is less clearly useful. That's enough code review for now. Next I will review your regression tests — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: [Patch] ALTER SYSTEM READ ONLY

2021-09-10 Thread Mark Dilger
have to wonder, what exactly is the boolean argument toggling here? I don't feel strongly about this, though, and you don't need to change it. > Apart from this, recently while testing this patch with > pgbench where I have exhausted the connection limit and want to change > the system's prohibited state in between but I was unable to do that, > I wish I could do that using the pg_clt option. How about having a > pg_clt option to alter wal prohibited state? I'd have to review the implementation, but sure, that sounds like a useful ability. — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: [Patch] ALTER SYSTEM READ ONLY

2021-09-10 Thread Mark Dilger
> On Sep 10, 2021, at 8:42 AM, Mark Dilger wrote: > > Take for example a code stanza from heapam.c: > >if (needwal) >CheckWALPermitted(); > >/* NO EREPORT(ERROR) from here till changes are logged */ >START_CRIT_SECTION(); > >

Re: [Patch] ALTER SYSTEM READ ONLY

2021-09-10 Thread Mark Dilger
"immediately" and "will kill the running transaction" which reenforced the impression that this mechanism is heavier handed than it is. — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: [Patch] ALTER SYSTEM READ ONLY

2021-09-14 Thread Mark Dilger
sessions.patch Description: Binary data v34-0010-Test-ALTER-SYSTEM-READ-ONLY-against-cursors.patch Description: Binary data [1] https://www.postgresql.org/message-id/flat/CAP4vRV5gEHFLB7NwOE6_dyHAeVfkvqF8Z_g5GaCQZNgBAE0Frw%40mail.gmail.com#e10861372aec22119b66756ecbac581c — Mark Dilger Enterpr

Re: Postgres perl module namespace

2021-09-08 Thread Mark Dilger
> On Sep 7, 2021, at 9:00 PM, Noah Misch wrote: > > I wondered about using PGXS:: as the namespace for all these modules That immediately suggests perl modules wrapping C code, which is misleading for these. See `man perlxstut` — Mark Dilger EnterpriseDB: http://www.enterpr

Re: Extending amcheck to check toast size and compression

2021-07-14 Thread Mark Dilger
than defining VARLENA_SIZE_LIMIT, but review comments suggested that was less clear. — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: Extending amcheck to check toast size and compression

2021-07-14 Thread Mark Dilger
> 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. Violatio

Re: Another regexp performance improvement: skip useless paren-captures

2021-08-08 Thread Mark Dilger
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

Re: Added schema level support for publication.

2021-08-09 Thread Mark Dilger
d 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

Re: Use extended statistics to estimate (Var op Var) clauses

2021-08-09 Thread Mark Dilger
); 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

Re: Another regexp performance improvement: skip useless paren-captures

2021-08-09 Thread Mark Dilger
o does that, and with a backref, because it dies with "got here". — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: Another regexp performance improvement: skip useless paren-captures

2021-08-09 Thread Mark Dilger
> 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 Dilger Enterp

Re: Another regexp performance improvement: skip useless paren-captures

2021-08-09 Thread Mark Dilger
sted 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 perl, but it seems

Re: Another regexp performance improvement: skip useless paren-captures

2021-08-09 Thread Mark Dilger
expectedly + 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

Re: Another regexp performance improvement: skip useless paren-captures

2021-08-09 Thread Mark Dilger
ere 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

Re: Another regexp performance improvement: skip useless paren-captures

2021-08-09 Thread Mark Dilger
> 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.enterpr

Re: Another regexp performance improvement: skip useless paren-captures

2021-08-09 Thread Mark Dilger
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 implementation detail. — Mark Dilger

Re: Another regexp performance improvement: skip useless paren-captures

2021-08-08 Thread Mark Dilger
. This is a test suite of nearly 1.5 million separate regular expressions. — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Assert triggered during RE_compile_and_cache

2021-08-05 Thread Mark Dilger
[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

Re: Another regexp performance improvement: skip useless paren-captures

2021-08-05 Thread Mark Dilger
, 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] — Mark Dilger Enterpris

Re: Assert triggered during RE_compile_and_cache

2021-08-05 Thread Mark Dilger
esult = '(' . 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

Re: Accidentally dropped constraints: bug?

2021-08-05 Thread Mark Dilger
gt; 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

Re: Assert triggered during RE_compile_and_cache

2021-08-05 Thread Mark Dilger
> 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 '' ~ '()(\1){0}'; + ?column? +-- + t +(1 row) + +select ''

Re: Assert triggered during RE_compile_and_cache

2021-08-08 Thread Mark Dilger
;","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","",""} + 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

Re: Assert triggered during RE_compile_and_cache

2021-08-08 Thread Mark Dilger
-- -(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

Re: Assert triggered during RE_compile_and_cache

2021-08-08 Thread Mark Dilger
> 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

Re: Another regexp performance improvement: skip useless paren-captures

2021-08-08 Thread Mark Dilger
snzqabixqbixqiumpgxdemmxvnsemjxgqoqknrqessmcqmfslfspskqpqxe} (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

Re: Assert triggered during RE_compile_and_cache

2021-08-08 Thread Mark Dilger
> 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 >

Re: Assert triggered during RE_compile_and_cache

2021-08-08 Thread Mark Dilger
> 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 pulled yes

Re: Assert triggered during RE_compile_and_cache

2021-08-08 Thread Mark Dilger
> 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 (c1132aae336c41cf9d316222e525d8d593c2b5d2).

Re: Postgres perl module namespace

2021-08-10 Thread Mark Dilger
ed 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

Re: Postgres perl module namespace

2021-08-10 Thread Mark Dilger
then 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

Re: Added schema level support for publication.

2021-08-11 Thread Mark Dilger
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

Re: Use extended statistics to estimate (Var op Var) clauses

2021-08-11 Thread Mark Dilger
> 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

Re: Use extended statistics to estimate (Var op Var) clauses

2021-08-11 Thread Mark Dilger
> 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 mor

Re: Use extended statistics to estimate (Var op Var) clauses

2021-08-12 Thread Mark Dilger
> 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 express

Bug fix for cache lookup failure for statistic_ext type

2021-08-04 Thread Mark Dilger
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 Description: Binary data — Mark

Re: Another regexp performance improvement: skip useless paren-captures

2021-08-10 Thread Mark Dilger
> 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 this in a day

Re: Use extended statistics to estimate (Var op Var) clauses

2021-08-11 Thread Mark Dilger
rking 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

Re: Use extended statistics to estimate (Var op Var) clauses

2021-08-11 Thread Mark Dilger
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.enterprisedb.com

Fixing WAL instability in various TAP tests

2021-09-24 Thread Mark Dilger
ed commit. That test happens to be stable on my laptop until I change GUC settings to both reduce max_wal_size=32MB and to set wal_consistency_checking=all. Thoughts? — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

<    1   2   3   4   5   6   7   8   9   10   >