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

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

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

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.

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.

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

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

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.

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

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: s390x builds on buildfarm

, wondering what is the reason for > > the pause and what is required to resume the builds? > > The OS the builds were running on seems to have reached end of life. > > Please let me know if we can help with getting them updated and resume > > the builds. > > > &

Re: predefined role(s) for VACUUM and ANALYZE

g these other commands, but don't want to regret having drawn the line in the wrong place when later we decide to add more roles like the one you are proposing. — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: predefined role(s) for VACUUM and ANALYZE

ee your patch set get further delayed by things that aren't logically prerequisites. The conversation upthread was useful to determine that they aren't prerequisites, but if anybody wants to explain to me why they are — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: predefined role(s) for VACUUM and ANALYZE

ion granularity sounds useful, but orthogonal, to this feature. — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: why can't a table be part of the same publication as its schema

s intended to future-proof against surprising behavioral changes. — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: why can't a table be part of the same publication as its schema

ind of confusion, but created another kind. Per the docs on this feature: FOR ALL TABLES IN SCHEMA Marks the publication as one that replicates changes for all tables in the specified list of schemas, including tables created in the future. Like you, I wouldn't expect that defin

Re: why can't a table be part of the same publication as its schema

"later in schema, computed then." A user who diligently consults the documentation for one command to discover what "IN SCHEMA" means may fairly, but wrongly, assume it means the same thing in another command. — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: why can't a table be part of the same publication as its schema

bobs_pub. Surely this makes more sense? I'm not a huge fan of the keyword "FUTURE" here, but I found a reference to another database that uses that keyword for what I think is a similar purpose. We should choose *something* for this, though, if we want things to be rational going forward. — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

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

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

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

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

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

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

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

Towards easier AMs: Cleaning up inappropriate use of name "relkind"

date. I decided to keep that work independent of this patch, as the code is logically distinct. v1-0001-Renaming-relkind-as-objtype-where-appropriate.patch Description: Binary data — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: new heapcheck contrib module

s all detected corruptions) does not change, which verifies your observation that verify_heapam is not checking for this. I've attached that as a patch to this email. Note that this patch should be applied atop the v6 patch recently posted in another email. WIP_dilip_kumar_idea.p

doc examples for pghandler

Hi everyone, Would some additional procedure language handler code examples in the documentation be good to add? I've put some together in the attached patch, and can log it to a future commitfest if people think it would be a good addition. Regards, Mark -- Mark Wong 2ndQuadrant - Postg

Re: doc examples for pghandler

On Fri, Jun 12, 2020 at 03:10:20PM -0400, Tom Lane wrote: > Mark Wong writes: > > Would some additional procedure language handler code examples in the > > documentation be good to add? I've put some together in the attached > > patch, and can log it to a future com

Re: doc examples for pghandler

rc/test/modules/, and if you can provide some low-level API > coverage through this module, that's even better. Sounds good to me. Something more like the attached patch? Regards, Mark -- Mark Wong 2ndQuadrant - PostgreSQL Solutions for the Enterprise https://www.2ndQuadrant.com/ di

Re: snowball ASCII stemmer configuration

rated words, but can't find any indication of that, neither in the postgres sources, nor in the snowball sources I pulled from their repo. Is there some architectural separation of stemming from transliteration such that we'd never need to worry about it? If snowball ever published stem

Re: may I help with Perl?

e flaws in the patch even if the TAP tests you write are themselves not accepted into the project. — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: new heapcheck contrib module

, so I think of it as a mere verb phrase and not a full sentence. Making matters even more complicated, portions of the logic in verify_heapam were taken from sections of code that would ereport(), elog(), or Assert() on corruption, and when I took such code, I sometimes also took the comments in unmodified form. That means that my normal commenting rules don't apply, as I'm not the comment author in such cases. — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: new heapcheck contrib module

to see what others think about that. > I strongly agree with hardening backend code so that all the crashes > that Mark has found can be repaired. (We discussed this topic > before[1]: we'd repair all crashes when run with production code, not > all assertion crashes.) I'm g

Re: Towards easier AMs: Cleaning up inappropriate use of name "relkind"

> On Jul 1, 2020, at 2:45 AM, Daniel Gustafsson wrote: > >> On 3 Jun 2020, at 19:05, Mark Dilger wrote: > >> The attached patch cleans this up. > > The gram.y hunks in this patch no longer applies, please submit a rebased > version. I'm marking the entr

Re: Persist MVCC forever - retain history

ically, you'll need to think about the fact that you have TransactionIds in your tables older than what clog knows about. You may want to think about how keeping dead rows around affects index performance. I expect these issues to be less than half what you would need to resolve, though m

Re: factorial function/phase out postfix operators?

> On Jun 30, 2020, at 2:47 PM, Mark Dilger wrote: > > > >> On May 19, 2020, at 4:47 PM, Tom Lane wrote: >> >> I wrote: >>> However, we do have to have a benefit to show those people whose >>> queries we break. Hence my insistence on ha

Re: Towards easier AMs: Cleaning up inappropriate use of name "relkind"

renaming makes sense to me. Those commands work on objects that are >> relkinds, except for one OBJECT_TYPE. So, let's get 0001 patch >> merged. Any objections from others? > > I have been through this one again and applied it as cc35d89. > -- > Michael

Re: Towards easier AMs: Cleaning up inappropriate use of name "relkind"

> On Jul 10, 2020, at 11:00 PM, Michael Paquier wrote: > > On Wed, Jul 01, 2020 at 05:04:19PM -0700, Mark Dilger wrote: >> Most of the work in this patch is mechanical replacement of if/else >> if/else statements which hinge on relkind to switch statements on >>

Refactoring relkind as an enum

re an "invalid" relkind is returned; Ok. > and once > that's in place, replace if tests with switch blocks where it makes > sense to do so. Ok. > > Also, I suggest that this thread is not a good one for this patch. > Subject is entirely not appropriate. Open a new thread perhaps? I've changed the subject line. — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Perl modules for testing/viewing/corrupting/repairing your heap files

00 00 00 00 08 00 00 ===> . . . . . . . . 46 00 00 00 01 00 00 00 ===> p . . . . . . . 00 00 00 00 01 00 00 00 ===> . . . . . . . . 01 00 00 00 00 00 00 00 ===> . . . . . . . . 01 00 00 00 19 46 06 46 ===> . . . . % p l p 43 49 47 06 05 4c 3d 06 ===> g s q l _ v a l 45 40 3d 4a 06 48 15 18 ===> i d a t o r ! $ 06 45 3e 40 45 48 02 46 ===> l i b d i r / p 06 46 43 49 47 06 ===> l p g s q l Is there any interest in this stuff, and if so, where should it live? I'm happy to reorganize this a bit if there is general interest in such a submission. — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: cleaning perl code

7;t understand the prejudice against commas used this way. What is wrong with: $i++, $j++ if defined $k; rather than: if (defined $k) { $i++; $j++; } — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: cleaning perl code

> On Apr 11, 2020, at 9:47 AM, Andrew Dunstan > wrote: > > > On 4/11/20 12:28 PM, Mark Dilger wrote: >> >>> On Apr 11, 2020, at 9:13 AM, Andrew Dunstan >>> wrote: >> Hi Andrew. I appreciate your interest and efforts here. I hope you don&

Re: Add "-Wimplicit-fallthrough" to default flags (was Re: pgsql: Support FETCH FIRST WITH TIES)

gt; > *<"-fallthrough"> > *<"@fallthrough@"> > *<"lint -fallthrough[ \t]*"> > *<"[ \t]*FALLTHR(OUGH|U)[ \t]*"> > > Thoughts? Naturally, I'm +1 for this. — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: Perl modules for testing/viewing/corrupting/repairing your heap files

Not having received any feedback on this, I've dusted the modules off for submission as-is. v1-0001-Adding-HeapFile-related-perl-modules.patch Description: Binary data — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: Perl modules for testing/viewing/corrupting/repairing your heap files

> On Apr 14, 2020, at 6:17 PM, Peter Geoghegan wrote: > > On Wed, Apr 8, 2020 at 3:51 PM Mark Dilger > wrote: >> Recently, as part of testing something else, I had need of a tool to create >> surgically precise corruption within heap pages. I wanted to make the &

Re: Should we add xid_current() or a int8->xid cast?

> On Apr 6, 2020, at 5:14 PM, Thomas Munro wrote: > > On Sun, Apr 5, 2020 at 11:31 AM Thomas Munro wrote: >> On Sun, Apr 5, 2020 at 10:34 AM Mark Dilger >> wrote: >>> The "xid8_" warts are partly motivated by having a type named "xid8", whic

Re: cleaning perl code

> maybe as an extended regex. And a better fix here instead of marking the > fourth group as non-capturing would be simply to get rid of the parens > altogether. The serve no purpose at all. But then you'd have to use something else in position 4, which complicates the code. — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: Adding missing object access hook invocations

> On Apr 19, 2020, at 3:55 PM, Michael Paquier wrote: > > On Thu, Mar 19, 2020 at 11:47:46AM -0700, Mark Dilger wrote: >> On Mar 19, 2020, at 11:30 AM, Mark Dilger >> wrote: >>> Will post v3 shortly. > > Thanks for sending a new version of the patch

new heapcheck contrib module

ib-module.patch Description: Binary data — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: new heapcheck contrib module

that does heap checking. Something with a high level practical focus, > in addition to the low level functions. I'm not saying that Mark > should be required to solve that problem, but it certainly seems worth > considering now. Thanks for your quick response and interest in this submis

Re: new heapcheck contrib module

th the > rootdescend stuff from amcheck. It should be composable. > > The interface you've chosen is a good starting point. But let's not miss an > opportunity to make everything work together. Ok, I'll work in that direction and repost when I have somethi

Re: new heapcheck contrib module

> On Apr 20, 2020, at 12:42 PM, Andres Freund wrote: > > Hi, > > On 2020-04-20 10:59:28 -0700, Mark Dilger wrote: >> I have been talking with Robert about table corruption that occurs >> from time to time. The page checksum feature seems sufficient to >> detec

Re: new heapcheck contrib module

ions, a bgworker based mode that periodically checks your database? The work along those lines is not included in v4, but if it were part of v5, would you have specific design preferences? v4-0001-Adding-verify_heapam-to-amcheck-contrib-module.patch Description: Binary data — Mark Dilger

Re: new heapcheck contrib module

> On Apr 29, 2020, at 11:41 AM, Robert Haas wrote: > > On Wed, Apr 22, 2020 at 10:43 PM Mark Dilger > wrote: >> It's simple enough to extend the tap test a little to check for those >> things. In v3, the tap test skips tests if the page size is not 8k, and

Re: new heapcheck contrib module

> On May 12, 2020, at 5:34 PM, Peter Geoghegan wrote: > > On Mon, May 11, 2020 at 10:21 AM Mark Dilger > wrote: >> 2) amcheck's btree checking functions have been refactored to be able to >> operate in two modes; the original mode in which all errors are report

Re: new heapcheck contrib module

Assertions are only a problem at all because Mark would like to write > tests that involve a selection of truly corrupt data. That's a new > requirement, and one that I have my doubts about. > >>> I'll stick with your example. You're calling >>> Transacti

Re: new heapcheck contrib module

> On May 13, 2020, at 5:36 PM, Peter Geoghegan wrote: > > On Wed, May 13, 2020 at 5:18 PM Mark Dilger > wrote: >> I am not removing any assertions. I do not propose to remove any >> assertions. When I talk about "hardening against assertions", that i

Re: [PATCH] Fix ouside scope t_ctid (ItemPointerData)

mPointerData, not because other aspects of the patch are unacceptable (I'm not ready to even contemplate that yet), but because I'm not sure what your complaint is about. Can you restrict the patch to just address that one issue? — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: new heapcheck contrib module

> On May 14, 2020, at 1:02 PM, Peter Eisentraut > wrote: > > On 2020-05-11 19:21, Mark Dilger wrote: >> 1) A new module, pg_amcheck, which includes a command line client for >> checking a database or subset of a database. Internally it functions by >> query

Re: [PATCH] Fix ouside scope t_ctid (ItemPointerData)

#x27;m still unclear whether you believe this is a bug, or whether you just don't like the naming that is used. — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: [PATCH] Fix ouside scope t_ctid (ItemPointerData)

;ll notice it outputs: y = { { 5, 10 }, 15 } and not the { { 0, 1}, 2 } that you would expect if y were merely pointing at x. — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: factorial function/phase out postfix operators?

argument types. You might need to add explicit type casts. So if we put that in the set of characters disallowed for infix operators, we would only be breaking custom infix operators named that, which seems like less breakage to me than removing postfix operators of all kinds. — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: some grammar refactoring

ed data files are. But a single, consistent design for extra-grammatical error checks could help augment those files fairly well, too. — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: some grammar refactoring

> On May 25, 2020, at 2:55 AM, Peter Eisentraut > wrote: > > On 2020-05-22 18:53, Mark Dilger wrote: >> I like the general direction you are going with this, but the decision in >> v1-0006 to move the error for invalid object types out of gram.y and into

Re: New 'pg' consolidated metacommand patch

> On May 26, 2020, at 4:59 PM, David G. Johnston > wrote: > > On Tue, May 26, 2020 at 4:19 PM Mark Dilger > wrote: > I'd also appreciate +1 and -1 votes on the overall idea, in case this entire > feature, regardless of implementation, is simply something the

Re: New 'pg' consolidated metacommand patch

> On May 27, 2020, at 1:13 AM, Dave Page wrote: > > Hi > > On Wed, May 27, 2020 at 12:19 AM Mark Dilger > wrote: > > I think it makes sense that packagers could put the LIBEXECDIR in the PATH so > that 3rd-party scripts which call pg_ctl, initdb, etc. cont

Re: New 'pg' consolidated metacommand patch

> On May 27, 2020, at 1:50 AM, Magnus Hagander wrote: > > On Wed, May 27, 2020 at 1:19 AM Mark Dilger > wrote: > Hackers, > > Attached is a patch for a `pg' command that consolidates various PostgreSQL > functionality into a single command, along the lines of

Re: New 'pg' consolidated metacommand patch

ds from contrib modules without the "pg" command needing to know anything about them. This, too, is still open to conversation and debate. I'd like to hear from more community members on this. I'm listening. — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: Delaying/avoiding BTreeTupleGetNAtts() call within _bt_compare()

sr/bin 2.4 GHz 8-Core Intel Core i9 32 GB 2667 MHz DDR4 Reading this thread, I think the lack of a performance impact on laptop hardware was expected, but perhaps confirmation that it does not make things worse is useful? Since this patch doesn't seem to do any harm, I would

Re: Expand the use of check_canonical_path() for more GUCs

o-back, with the four that are set by SelectConfigFiles() at the top with comments about why they are special, and the rest after that with comments about why they need or do not need canonicalization. — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: speed up unicode normalization quick check

de_combining_table.pl, and future callers can pass in the numbers they want? Or is there some advantage to having it this way? — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: speed up unicode normalization quick check

> On May 28, 2020, at 8:54 PM, John Naylor wrote: > > On Fri, May 29, 2020 at 5:59 AM Mark Dilger > wrote: >> >>> On May 21, 2020, at 12:12 AM, John Naylor >>> wrote: > >>> very picky in general. As a test, it also successfully finds a &g

Small code cleanup

One line change to remove a duplicate check. v1-0001-Code-cleanup.patch Description: Binary data — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: Small code cleanup

> On Jun 1, 2020, at 8:53 AM, Tom Lane wrote: > > Mark Dilger writes: >> One line change to remove a duplicate check. > > The comment just above this mentions a connection to the "Finish printing > the footer information about a table" stanza below. I thin

Re: Small code cleanup

> On Jun 1, 2020, at 9:59 AM, Tom Lane wrote: > > Mark Dilger writes: >> Yeah, I noticed the `git blame` last night when writing the patch that you >> had originally wrote the code around 2017, and that the duplication was >> introduced in a patch committed by

Re: Command statistics system (cmdstats)

> On Mar 4, 2020, at 7:43 PM, Mark Dilger wrote: > > Hackers, > > as mentioned in [1], I have created an implementation of command counter > statistics very similar in purpose to the one already pending in the > commitfest going by the name "pg_stat_sql"

Re: Command statistics system (cmdstats)

> On Jun 2, 2020, at 9:58 AM, Mark Dilger wrote: > >> >> On Mar 4, 2020, at 7:43 PM, Mark Dilger wrote: >> >> Hackers, >> >> as mentioned in [1], I have created an implementation of command counter >> statistics very similar in purpose

Re: "SELECT ... FROM DUAL" is not quite as silly as it appears

> On Jan 25, 2019, at 5:09 PM, Tom Lane wrote: > > David Rowley writes: >> As far as I can see the patch is ready to go, but I'll defer to Mark, >> who's also listed on the reviewer list for this patch. > > Mark, are you planning to do further review

Re: "SELECT ... FROM DUAL" is not quite as silly as it appears

> On Jan 25, 2019, at 5:09 PM, Tom Lane wrote: > > David Rowley writes: >> As far as I can see the patch is ready to go, but I'll defer to Mark, >> who's also listed on the reviewer list for this patch. > > Mark, are you planning to do further review

Re: "SELECT ... FROM DUAL" is not quite as silly as it appears

> On Jan 27, 2019, at 12:04 PM, Mark Dilger wrote: > > > >> On Jan 25, 2019, at 5:09 PM, Tom Lane wrote: >> >> David Rowley writes: >>> As far as I can see the patch is ready to go, but I'll defer to Mark, >>> who's also listed

Re: more unconstify use

tely pstrdup it such that it might as well have been const. Perhaps we should just clean up this mess rather than unconstifying. mark

Re: Remove Deprecated Exclusive Backup Mode

ackRest is also not right IMHO. Finally, Open Source is about is working together to make the a common project (in this case Poistgres) better - not forcing us to use something else you have written (even if it is good). regards Mark

Re: Remove Deprecated Exclusive Backup Mode

On 26/02/19 5:41 PM, Stephen Frost wrote: Greetings Mark, * Mark Kirkwood (mark.kirkw...@catalyst.net.nz) wrote: ISTM that the onus should be on the patch submitter to provide additions to pg_basebackup that make it as painless as possible for those people *not* using pgBackRest to continue

Re: [HACKERS] kqueue

increased from ~93,000 to ~140,000, ~ 32% increase * system time dropped from ~ 78% to ~ 70%, ~ 8% decrease * user time increased from ~16% to ~ 23%, ~7% increase I don't have any profile data, but I've attached a couple chart showing the processor utilization over a 15 minute interval from the database system. Regards, Mark -- Mark Wong 2ndQuadrant - PostgreSQL Solutions for the Enterprise https://www.2ndQuadrant.com/

Re: making the backend's json parser work in frontend code

> On Jan 29, 2020, at 1:02 PM, Andrew Dunstan > wrote: > > On Wed, Jan 29, 2020 at 4:32 PM Andrew Dunstan > wrote: >> >> >> On 1/28/20 5:28 PM, Mark Dilger wrote: >>> >>> >>>> +# There doesn't seem to be any easy way

Data race in interfaces/libpq/fe-exec.c

ons that we *want* to stop). And relaxed semantics should be free everywhere." And it would be nice to be able to keep running my postgres-using tests under ThreadSanitizer... thanks Mark (*) specifically in a test that kicks off two simultaneous threads whose first action is to open a postgres connection.

<    5   6   7   8   9   10   11   12   >