Re: Adding skip scan (including MDAM style range skip scan) to nbtree

few days ago. I have not encountered any of the problems that I had been encountering previously. That's not proof, but I was hitting these failures pretty consistently before the patches. I have no objection. — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: Adding skip scan (including MDAM style range skip scan) to nbtree

000103030c00 help + 0 18 dyld0x00018eb17154 start + 2476 This looks sufficiently different from the assertion mentioned on the other thread to be worth posting here. — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company _skipscan2.sql Description: application/sql

Re: Cygwin support

What are the economics of this? I used PostgreSQL and Cygwin 25 years ago and am amazed it is still a thing. How much effort is it to support PostgreSQL on Cygwin? How many actual users are using PostgreSQL on cygwin in production? (I should hope none!) I would say it is something that should be a

Re: n_ins_since_vacuum stats for aborted transactions

xplicit, it is hard for others to get behind your proposal. — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: n_ins_since_vacuum stats for aborted transactions

*/ 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

Re: n_ins_since_vacuum stats for aborted transactions

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: Amcheck verification of GiST and GIN

'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

Re: Index AM API cleanup

mily_properties(opno, opfamily, isorderby, &op_strategy, + NULL,/* don't need cmptype */ &op_lefttype, &op_r

Re: Index AM API cleanup

; 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

Re: Index AM API cleanup

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

Re: SQL:2023 JSON simplified accessor support

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

Re: SQL:2023 JSON simplified accessor support

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

Re: Amcheck verification of GiST and GIN

-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

Re: Amcheck verification of GiST and GIN

> 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

Re: Amcheck verification of GiST and GIN

> 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

Re: Amcheck verification of GiST and GIN

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

Re: New buildfarm animals with FIPS mode enabled

but I'm really dubious that it's worth > > > the work. > > > > Agreed. > > This means that unless Mark is willing to install OpenSSL 3 from source, > these buildfarm animals are not viable. I'll wait for Mark to confirm, > but given the number

Re: New buildfarm animals with FIPS mode enabled

ersions ship with OpenSSL 1.1, > though of course OpenSSL 3 could be installed on them. Should I just > delete these requests? I’m away from my desk until later this week so I don’t recall whether Ubuntu with FIPS is supposed to work. If someone already knows I’m ok with deleting them. Otherwise I will double check soon… Regards, Mark

Re: New buildfarm animals with FIPS mode enabled

ned that all up. Regards, Mark

Re: Index AM API cleanup

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

CVE-2024-10979 - Does this affect Postgres built without --with-perl option?

Does the CVE-2024-10979 affect Postgres that is NOT built with the --with-perl option? Thanks, Mark

Re: Index AM API cleanup

> 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

Re: cannot freeze committed xmax

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

Re: Index AM API cleanup

> 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

RE: FW: Building Postgres 17.0 with meson

resolved external symbol errors (see below.) I checked a few of the symbols and they appear in the Postgres source without the "_72" text on the end. Is it getting "72" from the version of icu4c I'm using, 72.1? Anyone know how to prevent these errors? Thanks, Mar

RE: FW: Building Postgres 17.0 with meson

95 bytes 0 Dir(s) 210,974,670,848 bytes free I don't know why meson cannot find the OpenSSL installation I've specified via the options: extra_lib_dirs extra_include_dirs Thanks, Mark Build started at 2024-11-13T09:37:45.113951 Main binary: C:\Python\Python310\python.exe Bu

FW: Building Postgres 17.0 with meson

Srinath is in India I believe and not available currently. Does anybody have any idea why meson is not finding the paths I'm specifying with the -Dextra_lib_dirs and -Dextra_include_dirs? See below. Thanks, Mark From: Mark Hill Sent: Wednesday, November 6, 2024 10:33 AM To: 'Sri

Building Postgres 17.0 with meson

tions. How do I specify to meson that I want it to use the versions of those 3 software packages that I have built e.g. the openssl I want it to use is located in D:\Postgres-Builds\OpenSSL\OpenSSL-Install\OpenSSL-3.1.6-wx6 and similar locations for icu and zlib? Thanks, Mark

Re: Index AM API cleanup

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

RE: msvc directory missing in PostgreSQL 17.0

Thanks Bill! Do you have a sample meson command for building that you could share? Thanks, Mark From: Bill Smith Sent: Friday, October 18, 2024 4:11 PM To: Mark Hill Cc: pgsql-hackers@lists.postgresql.org Subject: Re: msvc directory missing in PostgreSQL 17.0 EXTERNAL On Oct 18, 2024

msvc directory missing in PostgreSQL 17.0

ef.pl does. How do we build Postgres for Windows using Visual Studio? Thanks, Mark

Re: Index AM API cleanup

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

Re: Index AM API cleanup

struct; that didn't > seem necessary. Good catch. I agree with the change. — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: pl/pgperl Patch for adding $_FN detail just like triggers have for $_TD

On 8/30/24 16:12, Andrew Dunstan wrote: Sorry for empty reply. Errant finger hit send. No problem. So anyway... my main point is to highlight this: On 2024-08-29 Th 5:50 PM, Mark Murawski wrote: And then in this hypothetical situation -- magic ensues, and you're left with

Re: pl/pgperl Patch for adding $_FN detail just like triggers have for $_TD

On 8/29/24 16:54, Andrew Dunstan wrote: On 2024-08-29 Th 1:01 PM, Mark Murawski wrote: On 8/29/24 11:56, Andrew Dunstan wrote: On 2024-08-28 We 5:53 PM, Mark Murawski wrote: Hi Hackers! This would be version v1 of this feature Basically, the subject says it all: pl/pgperl Patch for

Re: pl/pgperl Patch for adding $_FN detail just like triggers have for $_TD

On 8/29/24 11:56, Andrew Dunstan wrote: On 2024-08-28 We 5:53 PM, Mark Murawski wrote: Hi Hackers! This would be version v1 of this feature Basically, the subject says it all: pl/pgperl Patch for being able to tell which function you're in. This is a hashref so it will be possib

Re: pl/pgperl Patch for adding $_FN detail just like triggers have for $_TD

Sorry!  I'm having email delivery issues.  I thought the first few didn't go through.  I'm working through email DKMS problems where we were incompatible with the mailing list. It sounds like it's fixed now! Sorry for the spam! On 8/28/24 18:38, Tom Lane wrote: We don't really need four cop

pl/pgperl Patch for adding $_FN detail just like triggers have for $_TD

Hi Hackers! This would be version v1 of this feature Basically, the subject says it all: pl/pgperl Patch for being able to tell which function you're in. This is a hashref so it will be possible to populate new and exciting other details in the future as the need arises This also greatly imp

pl/pgperl Patch for adding $_FN detail just like triggers have for $_TD

Hi Hackers! This would be version v1 of this feature Basically, the subject says it all: pl/pgperl Patch for being able to tell which function you're in. This is a hashref so it will be possible to populate new and exciting other details in the future as the need arises This also greatly imp

pl/pgperl Patch for adding $_FN detail just like triggers have for $_TD

Hi Hackers! This would be version v1 of this feature Basically, the subject says it all: pl/pgperl Patch for being able to tell which function you're in. This is a hashref so it will be possible to populate new and exciting other details in the future as the need arises This also greatly imp

pl/pgperl Patch for adding $_FN detail just like triggers have for $_TD

Hi Hackers! This would be version v1 of this feature Basically, the subject says it all: pl/pgperl Patch for being able to tell which function you're in. This is a hashref so it will be possible to populate new and exciting other details in the future as the need arises This also greatly imp

Re: Index AM API cleanup

> 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

Re: Index AM API cleanup

> 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

Re: debugging what might be a perf regression in 17beta2

A writeup for the benchmark results is here - https://smalldatum.blogspot.com/2024/07/postgres-17beta2-vs-sysbench-looking.html pg17beta2 and pg17beta1 look good so far On Mon, Jul 8, 2024 at 10:49 AM MARK CALLAGHAN wrote: > My results have too much variance so this is a false alarm. One da

Re: debugging what might be a perf regression in 17beta2

wrote: > On Sat, 6 Jul 2024 at 15:11, MARK CALLAGHAN wrote: > > On small servers I have at home I can reproduce the problem without > concurrent queries and 17beta2 is 5% to 10% slower there. > > > > The SQL statement for the scan microbenchmark is: > > SELECT * from

debugging what might be a perf regression in 17beta2

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

RE: ODBC Source Downloads Missing

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

ODBC Source Downloads Missing

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

Re: XLog size reductions: Reduced XLog record header size for PG17

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

Re: commitfest.postgresql.org is no longer fit for purpose

On 20/05/2024 06:56, Mark Cave-Ayland wrote: In general you find that a series consists of 2 parts: 1) a set of refactorings to enable a new feature and 2) the new feature itself. Even if the details of 2) are still under discussion, often it is possible to merge 1) fairly quickly which also

Re: commitfest.postgresql.org is no longer fit for purpose

the review process, making the initial review barrier that little bit higher. ATB, Mark.

Re: [PATCH] Improve amcheck to also check UNIQUE constraint in btree index.

. Prior to the corrupting action the values were all unique. — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: [PATCH] Improve amcheck to also check UNIQUE constraint in btree index.

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

Re: [PATCH] Improve amcheck to also check UNIQUE constraint in btree index.

> 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

Re: [PATCH] Improve amcheck to also check UNIQUE constraint in btree index.

conclude that the uniqueness checking code is broken. Can you take a look? — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: [PATCH] Improve amcheck to also check UNIQUE constraint in btree index.

> 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: >

Re: [PATCH] Improve amcheck to also check UNIQUE constraint in btree index.

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

Re: [PATCH] Improve amcheck to also check UNIQUE constraint in btree index.

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

Re: [PATCH] Improve amcheck to also check UNIQUE constraint in btree index.

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

CVE's addressed in next update

Do we know, is it posted anywhere on the postgresql.org site what CVE's will be addressed in the next round up updates to Postgres which should come out next Thursday, May 9th, 2024? Thanks, Mark

Re: BitmapHeapScan streaming read user and prelim refactoring

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

Re: BitmapHeapScan streaming read user and prelim refactoring

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

Re: Should we remove -Wdeclaration-after-statement?

> 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 >

Re: Should we remove -Wdeclaration-after-statement?

> 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

Re: Guiding principle for dropping LLVM versions?

up the 4 or 6 under my name... Regards, Mark

Re: Escape output of pg_amcheck test

> 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

Re: Escape output of pg_amcheck test

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

Re: Table AM Interface Enhancements

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

Re: Table AM Interface Enhancements

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

Re: Regression on pg_restore to 16.0: DOMAIN not available to SQL function

On Fri, 3 Nov 2023, Tom Lane wrote: > Mark Hills writes: > > On Fri, 3 Nov 2023, Tom Lane wrote: > >> However, then it's not clear why it would've worked > >> in 15.4 which does the same thing. I wonder whether you are > >> using this function in a

Re: Regression on pg_restore to 16.0: DOMAIN not available to SQL function

On Fri, 3 Nov 2023, Tom Lane wrote: > Mark Hills writes: > > I'm having errors restoring with pg_restore to v16.0, it appears to be a > > regression or bug. The same file restored to v15.4 without problem. > > > During the restore: > > > pg_restore:

Regression on pg_restore to 16.0: DOMAIN not available to SQL function

se 15.4 for this one-off task so will have to kick this can down the road. But I think it worth reporting that something in 16.0 appears to be failing on valid data (or maybe there is an incompatibility with a dump from 13.5?) Thanks -- Mark $ export DUMP="$HOME/tmp/production.pgdum

Re: LLVM 16 (opaque pointers)

fedora in the buildfarm... > > +1. It's good to test old LTS distros, but Fedora releases have a > short shelf life by design. I'll start retiring those old Fedora ones I have. :) Regards, Mark

Re: LLVM 16 (opaque pointers)

On Tue, Oct 24, 2023 at 10:17:22AM +1300, Thomas Munro wrote: > On Tue, Oct 24, 2023 at 4:27 AM Mark Wong wrote: > > I haven't gotten around to disabling llvm on any of my animals with llvm > > < 7 yet. Do you still want to hold on that? > > Yes, please disable -

Re: LLVM 16 (opaque pointers)

15.0.7 AlmaLinux 9.2 whiting: 6.0.0 Ubuntu 18.04.5 LTS vimba: 6.0.0 Ubuntu 18.04.5 LTS splitfin: 10.0.0 Ubuntu 20.04.6 LTS rudd: 10.0.0 Ubuntu 20.04.6 LTS turbot: 14.0.0 Ubuntu 22.04.3 LTS shiner: 14.0.0 Ubuntu 22.04.3 LTS ziege: 16.0.6 CentOS Stream 8 chevrotain: 11.0.1 Debian GNU/Linux 11 Regards, Mark

Re: LLVM 16 (opaque pointers)

-llvm > > was literally just turned on, so there is no reason to think that this > > would have worked before or this work is relevant. Strange though -- > > we must be able to JIT further than that on s390x because we have > > crash reports in other threads (ie we made it pa

pg*.dll and *.pdb files in psqlODBC have no version numbers

sion numbers? I checked earlier build and the same holds for ODBC 12.02.0000. Thanks, Mark

Re: Buildfarm failures on urocryon

t; Urocryon has been failing for the last 17 days. > > I think ICU libraries need to be installed in urocryon to fix this issue. Oops, that's when I upgraded the build farm client (from v14 to v17). I think it's fixed now... Regards, Mark

Re: Let's make PostgreSQL multi-threaded

On Mon, Jun 12, 2023 at 5:17 PM Heikki Linnakangas wrote: > On 10/06/2023 21:01, Hannu Krosing wrote: > > On Mon, Jun 5, 2023 at 4:52 PM Heikki Linnakangas > wrote: > > <<>> > > > * The backend code would be more complex. > > -- this is still the case > > I don't quite buy that. A multi-threade

Re: benchmark results comparing versions 15.2 and 16

s was with glibc). Low cardinality inputs were more > like 2.5x. > > I believe that ICU is faster than glibc in general -- even with > TRUST_STRXFRM enabled. But the TRUST_STRXFRM thing is bound to be the > most important factor here, by far. > > -- > Peter Geoghegan > -- Mark Callaghan mdcal...@gmail.com

Re: benchmark results comparing versions 15.2 and 16

Results for 16 beta1 are similar to what I shared above: * no regressions * a few queries are >= 1.5 times faster which make the read-only transaction >= 1.5 times faster http://smalldatum.blogspot.com/2023/05/postgres-16beta1-looks-good-vs-sysbench.html -- Mark Callaghan mdcal...@gmail.com

Re: benchmark results comparing versions 15.2 and 16

-> Index Scan using sbtest1_pkey on sbtest1 (cost=0.44..589.80 rows=10068 width=121) (actual time=0.024..3.478 rows=10001 loops=1) Index Cond: ((id >= 1000) AND (id <= 1001)) Planning Time: 0.039 ms Execution Time: 18.265 ms -- Mark Callaghan mdcal...@gmail.com

Re: benchmark results comparing versions 15.2 and 16

On Fri, May 19, 2023 at 4:04 PM Andres Freund wrote: > With "yet to see any significant changes" do you mean that the runs are > comparable with earlier runs, showing the same regression? Or that the > regression vanished? Or ...? > I mean that I might be chasing noise and the mean+stddev for th

Re: benchmark results comparing versions 15.2 and 16

On Tue, May 9, 2023 at 10:36 AM MARK CALLAGHAN wrote: > > > On Fri, May 5, 2023 at 10:01 PM MARK CALLAGHAN wrote: > >> I have two more runs of the benchmark in progress so we will have 3 >> results for each of the test cases to confirm that the small regressions &

Re: Large files for relations

On Fri, May 12, 2023 at 4:02 PM Thomas Munro wrote: > On Sat, May 13, 2023 at 4:41 AM MARK CALLAGHAN wrote: > > Repeating what was mentioned on Twitter, because I had some experience > with the topic. With fewer files per table there will be more contention on > the per-inode mut

Re: Large files for relations

t; anyway, right?), but perhaps that could depend on a GUC. Likewise for > base backup. Etc. Then someone concerned about hitting the 16TB > limit on ext4 could opt out. Or something like that. It seems funny > though, that's exactly the user who should want this feature (they > have 16,000 relation segment files). > > > -- Mark Callaghan mdcal...@gmail.com

Re: benchmark results comparing versions 15.2 and 16

On Fri, May 5, 2023 at 10:01 PM MARK CALLAGHAN wrote: > I have two more runs of the benchmark in progress so we will have 3 > results for each of the test cases to confirm that the small regressions > are repeatable. > They get similar results. Then I tried Linux perf but the hiera

Re: benchmark results comparing versions 15.2 and 16

in <= 16G. But that is a problem for another day. The IPS vs time graphs are not a flat line, but I am not ready to pursue that as problem unless it shows multi-second write-stalls (fortunately it does not). -- Mark Callaghan mdcal...@gmail.com

benchmark results comparing versions 15.2 and 16

ibench.beelink.pg16b.1u.1tno.1g/all.html#summary r5) 4 tables, 4 clients - https://mdcallag.github.io/reports/23_05_04_ibench.beelink.pg16b.4u.1tno.1g/all.html#summary r6) 1 table, 4 clients - https://mdcallag.github.io/reports/23_05_04_ibench.beelink.pg16b.4u.1tyes.1g/all.html#summary --

Re: [PATCH] Allow Postgres to pick an unused port to listen

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

Re: running logical replication as the subscription owner

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

Re: running logical replication as the subscription owner

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

Re: real/float example for testlibpq3

On Mon, Mar 20, 2023 at 01:37:57PM -0400, Gregory Stark (as CFM) wrote: > On Mon, 23 Jan 2023 at 11:54, Mark Wong wrote: > fficient way to communicate useful information. > > > > Yeah, I will try to cover all the data types we ship. :) I'll keep at > > it and d

FW: uuid-ossp source or binaries for Windows

installed. The uuid-ossp source located here: ftp://ftp.ossp.org/pkg/lib/uuid/uuid-1.6.2.tar.gz is Unix-specific. Is there uuid-ossp source download for Windows or are uuid-ossp prebuilt binaries for Windows available? Thanks, Mark -Original Message----- From: Mark Hill Sent: Wednesday

Re: BUG: Postgres 14 + vacuum_defer_cleanup_age + FOR UPDATE + UPDATE

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

Re: Transparent column encryption

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

Re: BUG: Postgres 14 + vacuum_defer_cleanup_age + FOR UPDATE + UPDATE

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

Re: HOT chain validation in verify_heapam()

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

Re: Non-superuser subscription owners

> 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

Re: Non-superuser subscription owners

still preventing either party from hijacking privileges of the other. — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

  1   2   3   4   5   6   7   8   9   10   >