Re: pg_amcheck contrib application

Noah Misch writes: > On Sat, Mar 13, 2021 at 01:36:11AM -0500, Tom Lane wrote: >> I don't mind updating the perl installations on prairiedog and gaur, >> but Noah might have some difficulty with his AIX flotilla, as I believe >> he's not sysadmin there. > The AIX animals have Perl v5.28.1. hover

Re: pg_amcheck contrib application

On Sat, Mar 13, 2021 at 01:36:11AM -0500, Tom Lane wrote: > Mark Dilger writes: > > On Mar 12, 2021, at 10:22 PM, Tom Lane wrote: > >> Coping with both endiannesses might be painful. > > > Not too bad if the bigint value is zero, as both the low and high 32bits > > will be zero, regardless of e

Re: pg_amcheck contrib application

Mark Dilger writes: > On Mar 12, 2021, at 10:36 PM, Tom Lane wrote: >> You might think about using some symmetric-but-not-zero value, >> 0x01010101 or the like. > I thought about that, but I'm not sure that it proves much more than just > using zero. Perhaps not. I haven't really looked at an

Re: pg_amcheck contrib application

> On Mar 12, 2021, at 10:36 PM, Tom Lane wrote: > > Mark Dilger writes: >> On Mar 12, 2021, at 10:22 PM, Tom Lane wrote: >>> Coping with both endiannesses might be painful. > >> Not too bad if the bigint value is zero, as both the low and high 32bits >> will be zero, regardless of endianne

Re: pg_amcheck contrib application

Mark Dilger writes: > On Mar 12, 2021, at 10:22 PM, Tom Lane wrote: >> Coping with both endiannesses might be painful. > Not too bad if the bigint value is zero, as both the low and high 32bits will > be zero, regardless of endianness. The question is whether that gives up too > much in terms

Re: pg_amcheck contrib application

> On Mar 12, 2021, at 10:28 PM, Mark Dilger > wrote: > > > >> On Mar 12, 2021, at 10:22 PM, Tom Lane wrote: >> >> Mark Dilger writes: >>> On Mar 12, 2021, at 10:16 PM, Noah Misch wrote: hoverfly does configure with PERL=perl64. /usr/bin/prove is from the 32-bit Perl, so

Re: pgbench: option delaying queries till connections establishment?

Thomas Munro writes: > On Sat, Mar 13, 2021 at 4:59 PM Tom Lane wrote: >> Looks reasonable by eyeball. If you'd push it, I can launch >> a gaur run right away. > Done. gaur's gotten through "make" and "make check" cleanly. Unfortunately I expect it will fail at the pg_amcheck test before it r

Re: pg_amcheck contrib application

Hi, On 2021-03-13 01:22:54 -0500, Tom Lane wrote: > Mark Dilger writes: > > On Mar 12, 2021, at 10:16 PM, Noah Misch wrote: > >> hoverfly does configure with PERL=perl64. /usr/bin/prove is from the > >> 32-bit > >> Perl, so I suspect the TAP suites get 32-bit Perl that way. (There's no > >> "

Re: pg_amcheck contrib application

> On Mar 12, 2021, at 10:22 PM, Tom Lane wrote: > > Mark Dilger writes: >> On Mar 12, 2021, at 10:16 PM, Noah Misch wrote: >>> hoverfly does configure with PERL=perl64. /usr/bin/prove is from the 32-bit >>> Perl, so I suspect the TAP suites get 32-bit Perl that way. (There's no >>> "prove6

Re: pg_amcheck contrib application

Mark Dilger writes: > On Mar 12, 2021, at 10:16 PM, Noah Misch wrote: >> hoverfly does configure with PERL=perl64. /usr/bin/prove is from the 32-bit >> Perl, so I suspect the TAP suites get 32-bit Perl that way. (There's no >> "prove64".) Oh, that's annoying. >> This test should unpack the fi

Re: shared-memory based stats collector

Hi, On 2021-03-11 19:22:57 -0800, Andres Freund wrote: > I started changing the patch to address my complaints. I'll try to do > it as an incremental patch ontop of your 0004, but it might become too > unwieldy. Not planning to touch other patches for now (and would be > happy if the first few wer

Re: pg_amcheck contrib application

> On Mar 12, 2021, at 10:16 PM, Noah Misch wrote: > > On Sat, Mar 13, 2021 at 01:07:15AM -0500, Tom Lane wrote: >> I wrote: ... btw, prairiedog (which has a rather old Perl) has a different complaint: Invalid type 'q' in unpack at t/004_verify_heapam.pl line 104. >> >>> Hmm ...

Re: pg_amcheck contrib application

On Sat, Mar 13, 2021 at 01:07:15AM -0500, Tom Lane wrote: > I wrote: > >> ... btw, prairiedog (which has a rather old Perl) has a > >> different complaint: > >> Invalid type 'q' in unpack at t/004_verify_heapam.pl line 104. > > > Hmm ... "man perlfunc" on that system quoth > >q

Re: pg_amcheck contrib application

I wrote: >> ... btw, prairiedog (which has a rather old Perl) has a >> different complaint: >> Invalid type 'q' in unpack at t/004_verify_heapam.pl line 104. > Hmm ... "man perlfunc" on that system quoth >q A signed quad (64-bit) value. >Q An unsigned qu

Re: proposal: schema variables

Hi fresh rebase Pavel schema-variables-20210313.patch.gz Description: application/gzip

Re: New IndexAM API controlling index vacuum strategies

On Tue, Mar 9, 2021 at 2:22 PM Peter Geoghegan wrote: > > On Tue, Mar 2, 2021 at 8:49 PM Masahiko Sawada wrote: > > On Tue, Mar 2, 2021 at 2:34 PM Peter Geoghegan wrote: > > > lazy_vacuum_table_and_indexes() should probably not skip index > > > vacuuming when we're close to exceeding the space a

Re: pg_amcheck contrib application

Mark Dilger writes: > Sorry for painting so many farm animals red this evening. Not to worry. We go through this sort of fire drill regularly when somebody pushes a batch of brand new test code. regards, tom lane

Re: pg_amcheck contrib application

I wrote: > ... btw, prairiedog (which has a rather old Perl) has a > different complaint: > Invalid type 'q' in unpack at t/004_verify_heapam.pl line 104. Hmm ... "man perlfunc" on that system quoth q A signed quad (64-bit) value. Q An unsigned quad value

Re: Parallel INSERT (INTO ... SELECT ...)

On Sat, Mar 13, 2021 at 10:08 AM Tom Lane wrote: > > Greg Nancarrow writes: > > On Fri, Mar 12, 2021 at 5:00 AM Tom Lane wrote: > >> BTW, having special logic for FK triggers in > >> target_rel_trigger_max_parallel_hazard seems quite loony to me. > >> Why isn't that handled by setting appropriat

Re: pg_amcheck contrib application

> On Mar 12, 2021, at 9:08 PM, Tom Lane wrote: > > I wrote: >> Don't almost all of the following tests have the same issue? > > Ah, nevermind, I was looking at an older version of 003_check.pl. > I concur that 24189277f missed only one here. > > Pushed your fix. > > re

Re: pg_amcheck contrib application

I wrote: > Don't almost all of the following tests have the same issue? Ah, nevermind, I was looking at an older version of 003_check.pl. I concur that 24189277f missed only one here. Pushed your fix. regards, tom lane

Re: pg_amcheck contrib application

... btw, prairiedog (which has a rather old Perl) has a different complaint: Invalid type 'q' in unpack at t/004_verify_heapam.pl line 104. regards, tom lane

Re: pg_amcheck contrib application

Mark Dilger writes: > There is another problem of non-portable option ordering in the tests. Don't almost all of the following tests have the same issue? regards, tom lane

Re: pg_amcheck contrib application

> On Mar 12, 2021, at 5:16 PM, Robert Haas wrote: > > Gah, tests are so annoying. :-) There is another problem of non-portable option ordering in the tests. v4-0001-pg_amcheck-Keep-trying-to-fix-the-tests.patch Description: Binary data — Mark Dilger EnterpriseDB: http://www.enterprisedb.c

Re: Parallel INSERT (INTO ... SELECT ...)

Greg Nancarrow writes: > On Fri, Mar 12, 2021 at 5:00 AM Tom Lane wrote: >> BTW, having special logic for FK triggers in >> target_rel_trigger_max_parallel_hazard seems quite loony to me. >> Why isn't that handled by setting appropriate proparallel values >> for those trigger functions? > ... an

Re: [HACKERS] PATCH: Batch/pipelining support for libpq

On 2021-Mar-11, Tom Lane wrote: > I think the changes in pqParseInput3() are broken. You should have > kept the else-structure as-is and inserted the check for "not really > idle" inside the else-clause that reports an error. As it stands, > after successfully processing an asynchronously-receiv

Re: pgbench: option delaying queries till connections establishment?

On Sat, Mar 13, 2021 at 4:59 PM Tom Lane wrote: > Thomas Munro writes: > > Thanks. This seems to work for me on a Mac. I confirmed with nm that > > we don't define or reference any pthread_XXX symbols with > > --disable-thread-safety, and we do otherwise, and the pgbench tests > > pass either w

Re: pgbench: option delaying queries till connections establishment?

Thomas Munro writes: > Thanks. This seems to work for me on a Mac. I confirmed with nm that > we don't define or reference any pthread_XXX symbols with > --disable-thread-safety, and we do otherwise, and the pgbench tests > pass either way. Looks reasonable by eyeball. If you'd push it, I can

Re: pgbench: option delaying queries till connections establishment?

On Sat, Mar 13, 2021 at 4:09 PM Tom Lane wrote: > OK, cool. I don't think it's hard, just do > > if test "$enable_thread_safety" = yes; then > AC_REPLACE_FUNCS(pthread_barrier_wait) > fi > > Probably this check should be likewise conditional: > > AC_SEARCH_LIBS(pthread_barrier_wait, pthread) T

Re: TRUNCATE on foreign table

To Ibrar, Thank you for updating the patch! To Amit, Thank you for checking the patch, and I have confirmed the failure. Now I'm trying to fix it. 2021年3月9日(火) 11:54 Amit Langote : > On Tue, Mar 9, 2021 at 2:24 AM Ibrar Ahmed wrote: > > The patch (pgsql14-truncate-on-foreign-table.v2.patch) d

Re: pgbench: option delaying queries till connections establishment?

Thomas Munro writes: > On Sat, Mar 13, 2021 at 3:47 PM Tom Lane wrote: >> Was any thought given to being able to opt out of this patchset >> to support that configure option? > Oops. The pgbench code was tested under --disable-thread-safety, but > it didn't occur to me that the AC_REPLACE_FUNCS

Re: pgbench: option delaying queries till connections establishment?

On Sat, Mar 13, 2021 at 3:47 PM Tom Lane wrote: > Checking the man pages, it seems that this ancient HPUX version > is using some pre-POSIX API spec in which pthread_cond_init takes a > pthread_condattr_t rather than a pointer to pthread_condattr_t. > Similarly for pthread_mutex_init. Wow. > Whi

Re: Parallel INSERT (INTO ... SELECT ...)

On Fri, Mar 12, 2021 at 9:33 AM houzj.f...@fujitsu.com wrote: > > > On Thu, Mar 11, 2021 at 01:01:42PM +, houzj.f...@fujitsu.com wrote: > > > > I guess to have the finer granularity we'd have to go with > > > > enable_parallel_insert, which then would mean possibly having to > > > > later add

Re: A qsort template

On Fri, Mar 12, 2021 at 7:58 AM Andres Freund wrote: > I wish we had the same for bsearch... :) Glibc already has the definition of the traditional void-based function in /usr/include/bits/stdlib-bsearch.h, so the generated code when the compiler can see the comparator definition is already good

Re: pgbench: option delaying queries till connections establishment?

Thomas Munro writes: > On Mon, Mar 8, 2021 at 3:18 PM Thomas Munro wrote: >> David Rowley kindly tested this for me on Windows and told me how to >> fix one of the macros that had incorrect error checking on that OS. >> So here's a new version. I'm planning to commit 0001 and 0002 soon, >> if th

Re: EXPLAIN/EXPLAIN ANALYZE REFRESH MATERIALIZED VIEW

On Mon, 08 Mar 2021 at 12:28, Bharath Rupireddy wrote: > On Sun, Mar 7, 2021 at 10:13 PM Zhihong Yu wrote: >> Hi, >> >> +* EXPLAIN ANALYZE CREATE TABLE AS or REFRESH MATERIALIZED VIEW >> +* WITH NO DATA is weird. >> >> Maybe it is clearer to spell out WITH NO DATA for both stat

Re: Different compression methods for FPI

On Fri, Mar 12, 2021 at 01:45:47AM -0600, Justin Pryzby wrote: > On Sat, Mar 06, 2021 at 12:29:14PM +0500, Andrey Borodin wrote: > > > 1 марта 2021 г., в 10:03, Justin Pryzby написал(а): > > > > Justin, Michael, thanks for comments! > > > > As far as I understood TODO list for the patch looks as

Re: pg_amcheck contrib application

On Fri, Mar 12, 2021 at 8:04 PM Mark Dilger wrote: > The problem with IPC::Run appears to be real, though I might just need to > wait longer for the farm animals to prove me wrong about that. But there is > a similar symptom caused by an unrelated problem, one entirely my fault and > spotted b

Re: pg_amcheck contrib application

> On Mar 12, 2021, at 3:24 PM, Mark Dilger wrote: > > and the second deals with an apparent problem with IPC::Run shell expanding > an asterisk on some platforms but not others. That second one, if true, > seems like a problem with scope beyond the pg_amcheck project, as > TestLib::command_

Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?

On Sat, Jun 13, 2020 at 11:28 AM Andres Freund wrote: > [PATCH v1 1/2] WIP: Change instr_time to just store nanoseconds, that's > cheaper. Makes a lot of sense. If we do this, I'll need to update pgbench, which just did something similar locally. If I'd been paying attention to this thread I m

Re: GROUP BY DISTINCT

Hi Vik, The patch seems quite ready, I have just two comments. 1) Shouldn't this add another for DISTINCT, somewhere in the documentation? Now the index points just to the SELECT DISTINCT part. 2) The part in gram.y that wraps/unwraps the boolean flag as an integer, in order to stash it in the

Re: pg_amcheck contrib application

> On Mar 12, 2021, at 11:24 AM, Robert Haas wrote: > > On Fri, Mar 12, 2021 at 2:05 PM wrote: >> I think there is a formatting glitch in lines like: >> >> 2/4 relations (50%) 187977/187978 pages (99%), (testdb >> ) >> >> I suppose that last part should show up t

Re: pg_amcheck contrib application

> On Mar 12, 2021, at 2:55 PM, Robert Haas wrote: > > On Fri, Mar 12, 2021 at 5:24 PM Mark Dilger > wrote: >> This does nothing to change the verbiage from contrib/amcheck, but it should >> address the problems discussed here in pg_amcheck's regression tests. > > Committed. Thanks. There a

Re: [HACKERS] GSoC 2017: Foreign Key Arrays

On Fri, Mar 12, 2021 at 11:32:27PM +0200, Mark Rofail wrote: > I have retested the patch on a windows build and it passes the regression > tests thanks to Justin's recommendations. Hopefully, it will pass CI too. > > Changelog: > - v7 (compatible with current master 2021-3-12, > commit 02b5940dbe

Re: pg_amcheck contrib application

On Fri, Mar 12, 2021 at 5:24 PM Mark Dilger wrote: > This does nothing to change the verbiage from contrib/amcheck, but it should > address the problems discussed here in pg_amcheck's regression tests. Committed. -- Robert Haas EDB: http://www.enterprisedb.com

Re: zstd compression for pg_dump

On 1/4/21 11:17 AM, Daniil Zakhlystov wrote: > Hi! > >> On Jan 4, 2021, at 11:04 AM, Andrey Borodin wrote: >> >> Daniil, is levels definition compatible with libpq compression patch? >> +typedef struct Compress { >> +CompressionAlgorithmalg; >> +int level; >> +

Re: pg_amcheck contrib application

> On Mar 12, 2021, at 1:43 PM, Robert Haas wrote: > > On Fri, Mar 12, 2021 at 2:31 PM Robert Haas wrote: >> I'll commit something shortly to address these. > > There are some interesting failures in the test cases on the > buildfarm. One of the tests ($offnum == 13) corrupts the TOAST pointer

Re: Background writer and checkpointer in crash recovery

On Wed, Feb 3, 2021 at 11:11 AM Robert Haas wrote: > I think the way it works right now is stupid and the proposed change > is going in the right direction. We have ample evidence already that > handing off fsyncs to a background process is a good idea, and there's > no reason why that shouldn't b

Re: VACUUM (DISABLE_PAGE_SKIPPING on)

On 1/28/21 2:33 PM, Simon Riggs wrote: > On Thu, 28 Jan 2021 at 12:53, Masahiko Sawada wrote: > >> This entry has been "Waiting on Author" status and the patch has not >> been updated since Nov 30. Are you still planning to work on this? > > Yes, new patch version tomorrow. Thanks for the nudge

Re: pg_amcheck contrib application

On Fri, Mar 12, 2021 at 1:43 PM Robert Haas wrote: > There are some interesting failures in the test cases on the > buildfarm. I wonder if Andrew Dunstan (now CC'd) could configure his crake buildfarm member to run pg_amcheck with the most expensive and thorough options on the master branch (plus

Re: pg_amcheck contrib application

On Fri, Mar 12, 2021 at 2:31 PM Robert Haas wrote: > I'll commit something shortly to address these. There are some interesting failures in the test cases on the buildfarm. One of the tests ($offnum == 13) corrupts the TOAST pointer with a garbage value, expecting to get the message "final toast

Re: documentation fix for SET ROLE

On 3/12/21, 11:14 AM, "Joe Conway" wrote: > On 3/12/21 1:16 PM, Bossart, Nathan wrote: >> My main goal of this thread is to get the RESET ROLE documentation >> fixed. I don't have a terribly strong opinion on documenting these >> special uses of "role". I lean in favor of adding it, but I wouldn

Re: [patch] [doc] Minor variable related cleanup and rewording of plpgsql docs

"David G. Johnston" writes: > I do agree that the delineation of "returns records or not" is not ideal > here. SELECT, then INSERT/UPDATE/DELETE (due to their shared RETURNING > dynamic), then "DML commands", then "DMS exceptions" (these last two > ideally leveraging the conceptual work noted abo

Re: [patch] [doc] Minor variable related cleanup and rewording of plpgsql docs

On Fri, Mar 12, 2021 at 1:36 PM Tom Lane wrote: > Pavel Stehule writes: > > pá 12. 3. 2021 v 21:08 odesílatel Tom Lane napsal: > >> I attach a v3 that I like better, although there's room to disagree > >> about that. > > > I am not sure if people can understand the "optimizable command" term. >

Re: pgbench - add pseudo-random permutation function

On 2021-Mar-13, Thomas Munro wrote: > That doesn't sound like a bad option to me, if it makes this much > simpler. The main modern system without it seems to be MSVC. The > Linux, BSD, Apple, illumos, AIX systems using Clang/GCC with > Intel/AMD/ARM/PowerPC CPUs have it, and the Windows systems

Re: pgbench - add pseudo-random permutation function

On Mon, Mar 8, 2021 at 11:50 PM Fabien COELHO wrote: > > I may have time to become familiar or at least semi-comfortable with all > > that weird math in it by then. > > Yep. > > Generating a parametric good-quality low-cost (but not > cryptographically-secure) pseudo-random permutations on arbitra

Re: [patch] [doc] Minor variable related cleanup and rewording of plpgsql docs

pá 12. 3. 2021 v 21:36 odesílatel Tom Lane napsal: > Pavel Stehule writes: > > pá 12. 3. 2021 v 21:08 odesílatel Tom Lane napsal: > >> I attach a v3 that I like better, although there's room to disagree > >> about that. > > > I am not sure if people can understand the "optimizable command" term

Re: [patch] [doc] Minor variable related cleanup and rewording of plpgsql docs

Pavel Stehule writes: > pá 12. 3. 2021 v 21:08 odesílatel Tom Lane napsal: >> I attach a v3 that I like better, although there's room to disagree >> about that. > I am not sure if people can understand the "optimizable command" term. More > common categories are DML, DDL and SELECT. Maybe it is

Re: [patch] [doc] Minor variable related cleanup and rewording of plpgsql docs

Hi pá 12. 3. 2021 v 21:08 odesílatel Tom Lane napsal: > I looked over the v2 patch. Parts of it seem like improvements but > other parts definitely don't. In particular, I thought you introduced > a great deal of confusion in 43.5.2 (Executing a Command with No Result). > The statement that yo

Re: [patch] [doc] Minor variable related cleanup and rewording of plpgsql docs

I looked over the v2 patch. Parts of it seem like improvements but other parts definitely don't. In particular, I thought you introduced a great deal of confusion in 43.5.2 (Executing a Command with No Result). The statement that you can write a non-result-returning SQL command as-is is true in g

Re: pg_amcheck contrib application

On Fri, Mar 12, 2021 at 1:35 PM Peter Geoghegan wrote: > On Fri, Mar 12, 2021 at 10:32 AM Peter Geoghegan wrote: > > Thank you both, Mark and Robert. This is excellent work! Thanks. > FYI I see these compiler warnings just now: > > pg_amcheck.c:1653:4: warning: ISO C90 forbids mixed declaration

Re: pg_amcheck contrib application

On Fri, Mar 12, 2021 at 2:05 PM wrote: > I think there is a formatting glitch in lines like: > > 2/4 relations (50%) 187977/187978 pages (99%), (testdb > ) > > I suppose that last part should show up trimmed as '(testdb)', right? Actually I think this is intentional.

Re: documentation fix for SET ROLE

On 3/12/21 1:16 PM, Bossart, Nathan wrote: On 3/12/21, 6:35 AM, "Laurenz Albe" wrote: On Fri, 2021-03-12 at 10:16 +0100, I wrote: After sleeping on it, I have come to think that it is excessive to write so much documentation for a feature that is that unimportant. It takes some effort to come

Re: pg_amcheck contrib application

> On 2021.03.12. 19:10 Robert Haas wrote: > > > On Fri, Mar 12, 2021 at 11:41 AM Mark Dilger > wrote: > > In this next patch, your documentation patch has been applied, and the > > whole project has been relocated from contrib/pg_amcheck to > > src/bin/pg_amcheck. > > Committed that way wit

Re: pg_amcheck contrib application

On Fri, Mar 12, 2021 at 10:32 AM Peter Geoghegan wrote: > Thank you both, Mark and Robert. This is excellent work! FYI I see these compiler warnings just now: pg_amcheck.c:1653:4: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] 1653 |DatabaseInfo *dat =

Re: pg_amcheck contrib application

On Fri, Mar 12, 2021 at 10:10 AM Robert Haas wrote: > Committed that way with some small adjustments. Let's see what the > buildfarm thinks. Thank you both, Mark and Robert. This is excellent work! -- Peter Geoghegan

Re: documentation fix for SET ROLE

On 3/12/21, 6:35 AM, "Laurenz Albe" wrote: > On Fri, 2021-03-12 at 10:16 +0100, I wrote: >> After sleeping on it, I have come to think that it is excessive to write >> so much documentation for a feature that is that unimportant. >> >> It takes some effort to come up with a good use case for it. >

Re: Confusing behavior of psql's \e

Laurenz Albe writes: > Done like that in the attached patch version 4. I pushed the race-condition-fixing part of this, since that's an unarguable bug fix and hence seems OK to back-patch. (I added a check on change of file size, because why not.) Attached is the rest, just to keep the cfbot ha

Re: pg_amcheck contrib application

On Fri, Mar 12, 2021 at 11:41 AM Mark Dilger wrote: > In this next patch, your documentation patch has been applied, and the whole > project has been relocated from contrib/pg_amcheck to src/bin/pg_amcheck. Committed that way with some small adjustments. Let's see what the buildfarm thinks. --

Re: [POC] verifying UTF-8 using SIMD instructions

On Fri, Mar 12, 2021 at 9:14 AM Amit Khandekar wrote: > > On my Arm64 VM : > > HEAD : > mixed | ascii > ---+--- > 1091 | 628 > (1 row) > > PATCHED : > mixed | ascii > ---+--- >681 | 119 Thanks for testing! Good, the speedup is about as much as I can hope for using plai

Re: documentation fix for SET ROLE

On Fri, Mar 12, 2021 at 7:35 AM Laurenz Albe wrote: > On Fri, 2021-03-12 at 10:16 +0100, I wrote: > > After sleeping on it, I have come to think that it is excessive to write > > so much documentation for a feature that is that unimportant. > > > > It takes some effort to come up with a good use

Re: documentation fix for SET ROLE

On Fri, 2021-03-12 at 10:16 +0100, I wrote: > After sleeping on it, I have come to think that it is excessive to write > so much documentation for a feature that is that unimportant. > > It takes some effort to come up with a good use case for it. > > I think we can add a few lines to ALTER ROLE,

Re: shared-memory based stats collector

On 2021/03/12 17:24, Kyotaro Horiguchi wrote: At Fri, 12 Mar 2021 15:13:15 +0900, Fujii Masao wrote in On 2021/03/12 13:49, Kyotaro Horiguchi wrote: I noticed that I accidentally removed the launch-suppression feature that is to avoid frequent relaunching. That mechanism is needed on the p

Re: pg_amcheck contrib application

On Fri, Mar 12, 2021 at 12:00 AM Mark Dilger wrote: > Your proposal is used in this next version of the patch, along with a > resolution to the solution to the -D option handling, discussed before, and a > change to make --schema and --exclude-schema options accept "database.schema" > patterns

Re: Self-join optimisation

Hi, thanks for your replies. I've tested the patch and it works for me in the cases where I'd use it. > And explain why your application is doing queries like this, and why it can't be changed to changed to not generate such queries. Reading the thread, it looks like some of the requests for this

Re: [POC] verifying UTF-8 using SIMD instructions

On Tue, 9 Mar 2021 at 17:14, John Naylor wrote: > On Tue, Mar 9, 2021 at 5:00 AM Amit Khandekar wrote: > > Just a quick question before I move on to review the patch ... The > > improvement looks like it is only meant for x86 platforms. > > Actually it's meant to be faster for all platforms, sinc

Re: ?????? unrecognized configuration parameter "plpgsql.check_asserts"

thanks Julien & Pavel it's crystal clear now. thanks again for your kindly help  thanks walker -- Original -- From: "Julien Rouhaud"

Re: non-HOT update not looking at FSM for large tuple update

On Thu, 11 Mar 2021 at 16:16, John Naylor wrote: > > On Thu, Mar 11, 2021 at 9:46 AM Matthias van de Meent > wrote: > > > Regarding the 2% slack logic, could we change it to use increments of > > line pointers instead? That makes it more clear what problem this > > solution is trying to work aro

Re: MultiXact\SLRU buffers configuration

> 11 марта 2021 г., в 20:50, Gilles Darold написал(а): > > > The patch doesn't apply anymore in master cause of error: patch failed: > src/backend/utils/init/globals.c:150 > > > > An other remark about this patch is that it should be mentionned in the > documentation (doc/src/sgml/config.

Re: Do we support upgrade of logical replication?

On Wed, Mar 10, 2021 at 4:03 PM vignesh C wrote: > > Hi, > > I was reviewing logical decoding of two-phase transactions feature, > while reviewing the feature I was checking if there is any impact on > publisher/subscriber upgrade. > > I checked the existing pg_upgrade behaviour with logical repli

Re: 回复： unrecognized configuration parameter "plpgsql.check_asserts"

On Fri, Mar 12, 2021 at 08:12:53PM +0800, Walker wrote: > To get rid of --enable-cassert while configuring, debug_assertions is shown > as off. In this case, ASSERT statement also can't be used, right? No, those are two different things. plpgsql ASSERT are only controlled by plpgsql.check_assert

Re: unrecognized configuration parameter "plpgsql.check_asserts"

pá 12. 3. 2021 v 13:13 odesílatel Walker napsal: > Hi, Pavel > > Thanks for your comments. > > To get rid of --enable-cassert while configuring, debug_assertions is > shown as off. In this case, ASSERT statement also can't be used, right? > no - debug assertions and plpgsql assertions are two ab

?????? unrecognized configuration parameter "plpgsql.check_asserts"

Hi, Pavel Thanks for your comments.  To get rid of --enable-cassert while configuring, debug_assertions is shown as off. In this case, ASSERT statement also can't be used, right? when enable --enable-cassert, can we use plpgsql.check_asserts to control ASSERT statement, and how?  thanks

Re: Parallel INSERT (INTO ... SELECT ...)

On Fri, Mar 12, 2021 at 1:33 PM houzj.f...@fujitsu.com wrote: > > > > The problem is that target_rel_trigger_max_parallel_hazard and its > > > caller think they can use a relcache TriggerDesc field across other > > > cache accesses, which they can't because the relcache doesn't > > > guarantee tha

Re: [Patch] Optimize dropping of relation buffers using dlist

On Fri, Mar 12, 2021 at 12:07 PM tsunakawa.ta...@fujitsu.com wrote: > > From: Kyotaro Horiguchi > > About the patch, it would be better to change the type of > > BUF_DROP_FULL_SCAN_THRESHOLD to uint64, even though the current > > value > > doesn't harm. > > OK, attached, to be prepared for the di

Re: unrecognized configuration parameter "plpgsql.check_asserts"

pá 12. 3. 2021 v 11:54 odesílatel Walker napsal: > Hi, hackers > > Due to configure with parameter --enable-cassert, the debug_assertions is > on by default, as follows: > postgres=# show debug_assertions; > debug_assertions > --- > on > > Because of pgbench performance testing, I

Re: Allow batched insert during cross-partition updates

‐‐‐ Original Message ‐‐‐ On Friday, March 12, 2021 3:45 AM, Amit Langote wrote: > On Thu, Mar 11, 2021 at 8:36 PM gkokola...@pm.me wrote: > > > On Thursday, March 11, 2021 9:42 AM, Amit Langote amitlangot...@gmail.com > > wrote: > > > > > On Wed, Mar 10, 2021 at 9:30 PM Georgios gko

unrecognized configuration parameter "plpgsql.check_asserts"

Hi, hackers Due to configure with parameter --enable-cassert, the debug_assertions is on by default, as follows: postgres=# show debug_assertions; debug_assertions --- on Because of pgbench performance testing, I need to disable the assert function. Following the doc below, I

Re: [HACKERS] Custom compression methods

I think these names need to be more specific. +typedef enum CompressionId +{ +PGLZ_COMPRESSION_ID = 0, +LZ4_COMPRESSION_ID = 1 + CompressionId, PGLZ_COMPRESSION_ID, LZ4_COMPRESSION_ID are also being used by Andrey's WAL compression patch. I suggested he use a prefix, but your pat

Re: pgbench - add pseudo-random permutation function

Hello Dean, The implementation looks plausible too, though it adds quite a large amount of new code. A significant part of this new code the the multiply-modulo implementation, which can be dropped if we assume that the target has int128 available, and accept that the feature is not availab

Re: [HACKERS] Custom compression methods

On Fri, Mar 12, 2021 at 2:12 PM Dilip Kumar wrote: > > On Fri, Mar 12, 2021 at 10:45 AM Justin Pryzby wrote: > > > > On Thu, Mar 11, 2021 at 12:25:26PM -0600, Justin Pryzby wrote: > > > On Wed, Mar 10, 2021 at 08:28:58PM -0600, Justin Pryzby wrote: > > > > This includes a patch to use pkgconfig,

Re: [HACKERS] logical decoding of two-phase transactions

On Fri, Mar 12, 2021 at 2:29 PM Peter Smith wrote: > > On Fri, Mar 12, 2021 at 4:07 PM vignesh C wrote: > > Hi Vignesh, > > Thanks for the review comments. > > But can you please resend it with each feedback enumerated as 1. 2. > 3., or have some other clear separation for each comment. > > (Beca

RE: Parallel INSERT (INTO ... SELECT ...)

> On Fri, Mar 12, 2021 at 6:10 AM Justin Pryzby > wrote: > > Note also this CF entry > > https://commitfest.postgresql.org/32/2987/ > > | Allow setting parallel_workers on partitioned tables > > +/* > + * PartitionedOptions > + * Contents of rd_options for partit

Re: documentation fix for SET ROLE

On Thu, 2021-03-11 at 22:30 +, Bossart, Nathan wrote: > On 3/11/21, 12:11 PM, "David G. Johnston" wrote: > > The minor bit of documentation pseudo-redundancy doesn’t bother me if I > > accept > > they are there own separate thing. The fact that set role and set session > > authorization ar

Re: Removing unneeded self joins

The following review has been posted through the commitfest application: make installcheck-world: not tested Implements feature: not tested Spec compliant: not tested Documentation:not tested I've built and tested this, and it seems to function correctly to me. One qu

Re: [HACKERS] logical decoding of two-phase transactions

On Fri, Mar 12, 2021 at 4:07 PM vignesh C wrote: Hi Vignesh, Thanks for the review comments. But can you please resend it with each feedback enumerated as 1. 2. 3., or have some other clear separation for each comment. (Because everything is mushed together I am not 100% sure if your comment t

Re: HotStandbyActive() issue in postgres

On 2021/03/12 11:14, Hao Wu wrote: Hi hackers, When we enable hot standby, HotStandbyActive() returns true on hot standby. Then, we promote the hot standby, the SHM variable `XLogCtl->SharedHotStandbyActive` remains true. So, HotStandbyActive() still returns true until the next call of `XLOG

Re: [HACKERS] Custom compression methods

On Fri, Mar 12, 2021 at 10:45 AM Justin Pryzby wrote: > > On Thu, Mar 11, 2021 at 12:25:26PM -0600, Justin Pryzby wrote: > > On Wed, Mar 10, 2021 at 08:28:58PM -0600, Justin Pryzby wrote: > > > This includes a patch to use pkgconfig, in an attempt to build on mac, > > > which > > > currently fail

Re: shared-memory based stats collector

At Fri, 12 Mar 2021 15:13:15 +0900, Fujii Masao wrote in > On 2021/03/12 13:49, Kyotaro Horiguchi wrote: > > I noticed that I accidentally removed the launch-suppression feature > > that is to avoid frequent relaunching. That mechanism is needed on > > the postmaster side. I added PgArchIsSuppr

Re: [PATCH] Disable bgworkers during servers start in pg_upgrade

On Wed, Jan 27, 2021 at 02:41:32PM +0100, Jehan-Guillaume de Rorthais wrote: > > On Wed, 27 Jan 2021 11:25:11 +0100 > Denis Laxalde wrote: > > > Andres Freund a écrit : > > > > I wonder if we could > > > > > > a) set default_transaction_read_only to true, and explicitly change it > > >in t

  1   2   >