Re: psql - add SHOW_ALL_RESULTS option

Bonjour Michaël, I was running a long query this morning and wondered why the cancellation was suddenly broken. So I am not alone, and here you are with already a solution :) So, studying through 3a51306, this stuff has changed the query execution from a sync PQexec() to an async

Re: Add ORDER BY to stabilize tablespace test for partitioned index

On Fri, Apr 9, 2021 at 1:30 PM Pavel Borisov wrote: > > Hi, hackers! > I noticed the Peter's commit 7e3c54168d9ec058cb3c9d47f8105b1d32dc8ceb that > stabilizes certain tests by adding ORDER BY clause in tests and remember that > I saw the same error in tablespaces test for creation of

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

On Mon, Dec 14, 2020 at 8:27 PM Amit Kapila wrote: > > 2. > + /* > + * Flags are determined from the state of the transaction. We know we > + * always get PREPARE first and then [COMMIT|ROLLBACK] PREPARED, so if > + * it's already marked as committed then it has to be COMMIT PREPARED (and > + *

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

On Fri, Apr 9, 2021 at 12:33 PM Peter Smith wrote: > > On Mon, Dec 14, 2020 at 8:27 PM Amit Kapila wrote: > > > > 2. > > + /* > > + * Flags are determined from the state of the transaction. We know we > > + * always get PREPARE first and then [COMMIT|ROLLBACK] PREPARED, so if > > + * it's

Postgresql 13 supported on Solaris 11 O/S on SPARC hardware?

Dear Postgresql community: We are wondeing if Postgresql 13 is supported on Solaris 11 O/S on SPARC hardware? The latest version of Postgresql we can download for Solaris SPARC seems to be Postgresql 12:PostgreSQL: Solaris packages | | | | PostgreSQL: Solaris packages | | | Are

Re: buildfarm instance bichir stuck

On Wed, Apr 7, 2021 at 7:31 PM Robins Tharakan wrote: > Correct. This is easily reproducible on this test-instance, so let me know if > you want me to test a patch. >From your description it sounds like signals are not arriving at all, rather than some more complicated race. Let's go back to

Re: buildfarm instance bichir stuck

On Fri, 9 Apr 2021 at 16:12, Thomas Munro wrote: > From your description it sounds like signals are not arriving at all, > rather than some more complicated race. Let's go back to basics... > what does the attached program print for you? I see: > > tmunro@x1:~/junk$ cc test-signalfd.c >

Add ORDER BY to stabilize tablespace test for partitioned index

Hi, hackers! I noticed the Peter's commit 7e3c54168d9ec058cb3c9d47f8105b1d32dc8ceb that stabilizes certain tests by adding ORDER BY clause in tests and remember that I saw the same error in tablespaces test for creation of partitioned index. It comes very rarely and test fails on inverted order of

Re: pgsql: Move tablespace path re-creation from the makefiles to pg_regres

On Wed, Mar 24, 2021 at 07:56:59PM -0700, Noah Misch wrote: > That would entail forbidding various shell metacharacters in @testtablespace@. > One could avoid imposing such a restriction by adding a mkdir() function to > regress.c and writing it like: > > CREATE FUNCTION mkdir(text) >RETURNS

Re: psql - add SHOW_ALL_RESULTS option

Attached v2 does as you suggest. There is not a single test of "ctrl-c" which would have caught this trivial and irritating regression. ISTM that a TAP test is doable. Should one be added? -- Fabien.

Re: Postgresql 13 supported on Solaris 11 O/S on SPARC hardware?

On Fri, Apr 9, 2021 at 9:38 AM Peter Lee wrote: > Dear Postgresql community: > > We are wondeing if Postgresql 13 is supported on Solaris 11 O/S on SPARC > hardware? > > The latest version of Postgresql we can download for Solaris SPARC seems > to be Postgresql 12: > PostgreSQL: Solaris packages

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

On Fri, Apr 9, 2021 at 6:40 PM Amit Kapila wrote: > > On Fri, Apr 9, 2021 at 12:33 PM Peter Smith wrote: > > > > On Mon, Dec 14, 2020 at 8:27 PM Amit Kapila wrote: > > > > > > 2. > > > + /* > > > + * Flags are determined from the state of the transaction. We know we > > > + * always get PREPARE

Re: SSL negotiation error on massive connect/disconnect

On 2021-03-01 17:22, Maxim Orlov wrote: Hi! I have primary server on port 55942 and two standbys on 55943 and 55944. Then use connection string like "postgresql://127.0.0.1:55942,127.0.0.1:55943,127.0.0.1:55944/postgres" to connect to the servers via psql. Everything works perfectly no matter

Re: Small typo in guc.c

On Fri, Apr 9, 2021 at 12:42 PM Michael Paquier wrote: > > On Fri, Apr 09, 2021 at 09:13:04AM +, Daniel Westermann (DWE) wrote: > > there is a small typo in guc.c. Attached patch fixes this. > > Indeed, there is. I'll apply and backpatch if there are no > objections. We seem to have started

Re: SQL:2011 PERIODS vs Postgres Ranges?

On 4/8/21 7:40 PM, Paul A Jungwirth wrote: On Thu, Apr 8, 2021 at 7:22 AM David Steele wrote: Paul, you can submit to the next CF when you are ready with a new patch. Thanks David! I've made a lot of progress but still need to finish support for CASCADE on temporal foreign keys. I've been

Re: Small typo in guc.c

On Fri, Apr 09, 2021 at 09:13:04AM +, Daniel Westermann (DWE) wrote: > there is a small typo in guc.c. Attached patch fixes this. Indeed, there is. I'll apply and backpatch if there are no objections. -- Michael signature.asc Description: PGP signature

Re: Small typo in guc.c

On Fri, Apr 9, 2021 at 11:13 AM Daniel Westermann (DWE) wrote: > > Hi, > > there is a small typo in guc.c. Attached patch fixes this. Applied, thanks! -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/

Re: Lots of incorrect comments in nodeFuncs.c

David Rowley writes: > I wanted something more like /* ... so we must never set a collation > */ but that put the line longer than 80. I thought wrapping to a 2nd > line was excessive, so I shortened it to that. LGTM. regards, tom lane

Re: psql - add SHOW_ALL_RESULTS option

On Fri, Apr 09, 2021 at 08:47:07AM +0200, Fabien COELHO wrote: > Yep, it looks much better. I found it strange that the later did a reset but > was not doing the set. > > Attached v2 does as you suggest. Close enough. I was thinking about this position of the attached, which is more consistent

check_function_bodies: At least the description seems wrong, since we have prodedures

Hi, check_function_bodies has this description: postgres=# select short_desc from pg_settings where name = 'check_function_bodies'; short_desc --- Check function bodies during CREATE FUNCTION. (1 row) This is

Re: Replication slot stats misgivings

On Wed, Apr 7, 2021 at 2:51 PM vignesh C wrote: > > That is not required, I have modified it. > Attached v4 patch has the fixes for the same. > Few comments: 0001 -- 1. The first patch includes changing char datatype to NameData datatype for slotname. I feel this can be a separate patch

Re: Asymmetric partition-wise JOIN

On 11/30/20 7:43 PM, Anastasia Lubennikova wrote: This entry was inactive during this CF, so I've marked it as returned with feedback. Feel free to resubmit an updated version to a future commitfest. Attached version is rebased on current master and fixes problems with complex parameterized

Re: Simplify backend terminate and wait logic in postgres_fdw test

On Thu, Apr 8, 2021 at 6:27 PM Bharath Rupireddy wrote: > > On Thu, Apr 8, 2021 at 5:28 PM Michael Paquier wrote: > > > > On Thu, Apr 08, 2021 at 04:55:22PM +0530, Bharath Rupireddy wrote: > > > With the recent commit aaf0432572 which introduced a waiting/timeout > > > capability for

Re: [PATCH] force_parallel_mode and GUC categories

On Thu, Apr 8, 2021 at 10:17:18PM -0500, Justin Pryzby wrote: > On Fri, Apr 09, 2021 at 10:50:53AM +0900, Michael Paquier wrote: > > On Sat, Apr 03, 2021 at 08:25:46PM -0500, Justin Pryzby wrote: > > > Forking this thread > > >

Small typo in guc.c

Hi, there is a small typo in guc.c. Attached patch fixes this. Regards Danieldiff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c index 090abdad8b..46f1d6406f 100644 --- a/src/backend/utils/misc/guc.c +++ b/src/backend/utils/misc/guc.c @@ -1320,7 +1320,7 @@ static struct

Re: Add ORDER BY to stabilize tablespace test for partitioned index

> > > I noticed the Peter's commit 7e3c54168d9ec058cb3c9d47f8105b1d32dc8ceb > that stabilizes certain tests by adding ORDER BY clause in tests and > remember that I saw the same error in tablespaces test for creation of > partitioned index. It comes very rarely and test fails on inverted order of

Re: pgsql: autovacuum: handle analyze for partitioned tables

Could we get this pushed sooner rather than later? The buildfarm is showing a wide variety of intermittent failures on HEAD, and it's hard to tell how many of them trace to this one bug. regards, tom lane

Another small guc.c fix

Hi, all "short_desc" end with a dot, except these: - Prefetch referenced blocks during recovery - Prefetch blocks that have full page images in the WAL Attached patch adds a dot to these as well. Regards Danieldiff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c index

Re: TRUNCATE on foreign table

On 2021/04/09 12:33, Kohei KaiGai wrote: 2021年4月8日(木) 22:14 Fujii Masao : On 2021/04/08 22:02, Kohei KaiGai wrote: Anyway, attached is the updated version of the patch. This is still based on the latest Kazutaka-san's patch. That is, extra list for ONLY is still passed to FDW. What about

Re: TRUNCATE on foreign table

On Fri, Apr 9, 2021 at 7:06 PM Fujii Masao wrote: > > > 4. Tab-completion for TRUNCATE should be updated so that also > > foreign tables are displayed. > > > > It will be good to have. > > Patch attached. Tab completion patch LGTM and it works as expected. With Regards, Bharath

Old Postgresql version on i7-1165g7

Good day, hackers. I've got HP ProBook 640g8 with i7-1165g7. I've installed Ubuntu 20.04 LTS on it and started to play with PostgreSQL sources. Occasinally I found I'm not able to `make check` old Postgresql versions. At least 9.6 and 10. They are failed at the initdb stage in the call to

Re: TRUNCATE on foreign table

On 2021/04/09 11:05, Zhihong Yu wrote: On Thu, Apr 8, 2021 at 6:47 PM Bharath Rupireddy mailto:bharath.rupireddyforpostg...@gmail.com>> wrote: On Thu, Apr 8, 2021 at 6:44 PM Fujii Masao mailto:masao.fu...@oss.nttdata.com>> wrote: > The followings are the open items and discussion

Re: check_function_bodies: At least the description seems wrong, since we have prodedures

On 04/09/21 08:11, Daniel Westermann (DWE) wrote: > At least the description should mention procedures. > Even the parameter name seems not to be correct anymore. Thoughts? It's possible the parameter name also appears in documentation for out-of-tree PLs, as each PL's validator function

Re: [PATCH] Add --create-only option to pg_dump/pg_dumpall

Hi, I have reviewed and tested the patch. Following are a few comments. 1. The main objective of this patch is to get the dump which consists of SQLs related to CREATEDB only. I have tested the patch and it generates a proper dump file. But my concern is, it should execute the code which is

Re: TRUNCATE on foreign table

On Fri, Apr 9, 2021 at 7:06 PM Fujii Masao wrote: > > > 2. Currently when the same foreign table is specified multiple times > > in the command, the extra information only for the foreign table found > > first is collected. For example, when "TRUNCATE ft, ONLY ft" is executed, > >

Re: TRUNCATE on foreign table

2021年4月9日(金) 22:51 Fujii Masao : > > On 2021/04/09 12:33, Kohei KaiGai wrote: > > 2021年4月8日(木) 22:14 Fujii Masao : > >> > >> On 2021/04/08 22:02, Kohei KaiGai wrote: > Anyway, attached is the updated version of the patch. This is still > based on the latest Kazutaka-san's patch. That

Re: PANIC: wrong buffer passed to visibilitymap_clear

Hi, On 2021-04-09 16:27:12 -0700, Peter Geoghegan wrote: > They're both VACUUM ANALYZE. They must be, because the calls to > visibilitymap_clear PANIC (they don't ERROR) -- the failing > visibilitymap_clear() call must occur inside a critical section, and > all such calls are made within heapam.c

Re: pgsql: autovacuum: handle analyze for partitioned tables

Hi, On 2021-04-09 11:54:30 -0400, Alvaro Herrera wrote: > On 2021-Apr-09, Tom Lane wrote: > > > Could we get this pushed sooner rather than later? The buildfarm > > is showing a wide variety of intermittent failures on HEAD, and it's > > hard to tell how many of them trace to this one bug. > >

Re: pgsql: autovacuum: handle analyze for partitioned tables

Hello On 2021-Apr-09, Andres Freund wrote: > I assume this is also the likely explanation for / fix for: > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink=2021-04-08%2016%3A03%3A03 > > ==3500389== VALGRINDERROR-BEGIN > ==3500389== Invalid read of size 8 > ==3500389==at

Re: PANIC: wrong buffer passed to visibilitymap_clear

On 2021-04-09 16:27:39 -0700, Andres Freund wrote: > Just looking at the code in heap_update: I'm a bit confused about > RelationGetBufferForTuple()'s vmbuffer and vmbuffer_other > arguments. It looks like it's not at all clear which of the two > arguments will have the vmbuffer for which of the

Re: SQL-standard function body

On Fri, Apr 09, 2021 at 12:09:43PM -0400, Tom Lane wrote: > Finally, 0003 might be a bit controversial: it changes the stored > prosrc for new-style SQL functions to be the query text of the CREATE > FUNCTION command. The main argument I can see being made against this > is that it'll bloat the

Re: pgsql: autovacuum: handle analyze for partitioned tables

On Fri, Apr 09, 2021 at 05:31:55PM -0400, Alvaro Herrera wrote: > On 2021-Apr-09, Robert Haas wrote: > > > Does this need to worry about new partitions getting attached to a > > partitioned table, or old ones getting detached? (Maybe it does > > already, not sure.) > > Good question. It does

Re: [CLOBBER_CACHE]Server crashed with segfault 11 while executing clusterdb

On 2021-Mar-25, Amul Sul wrote: > Ok, in the attached patch, I have added the inline function to rel.h, and for > that, I end up including smgr.h to rel.h. I tried to replace all rel->rd_smgr > by RelationGetSmgr() function and removed the RelationOpenSmgr() call from > the nearby to it which I

Re: pgsql: Add libpq pipeline mode support to pgbench

On 2021-Mar-17, Daniel Verite wrote: > Fabien COELHO wrote: > > > For consistency with the existing \if … \endif, ISTM that it could have > > been named \batch … \endbatch or \pipeline … \endpipeline? > > "start" mirrors "end". To me, the analogy with \if-\endif is not > obvious. >

Re: pgsql: Move tablespace path re-creation from the makefiles to pg_regres

On Fri, Apr 09, 2021 at 03:00:31PM +0900, Michael Paquier wrote: > I have compiled a simple patch that uses a SQL function for the base > tablespace directory creation, that I have tested on Linux and MSVC. > I am still not sure if people would prefer this approach over what's > on HEAD. So if

Re: Binary search in ScalarArrayOpExpr for OR'd constant arrays

On 4/9/21 1:21 AM, David Rowley wrote: > On Fri, 9 Apr 2021 at 09:32, Tomas Vondra > wrote: >> >> I ran the same set of benchmarks on the v6, which I think should be >> mostly identical to what was committed. I extended the test a bit to >> test table with 0, 1, 5 and 1000 rows, and also with

Re: Avoid unnecessary table open/close for TRUNCATE foo, foo, foo; kind of commands

On Fri, Apr 9, 2021 at 9:23 PM Fujii Masao wrote: > On 2021/04/10 0:39, Amul Sul wrote: > > On Fri, Apr 9, 2021 at 8:51 PM Bharath Rupireddy > > wrote: > >> > >> Hi, > >> > >> While checking the ExecuteTruncate code for the FOREIGN TRUNCATE > >> feature, I saw that we filter out the duplicate

Re: pgsql: autovacuum: handle analyze for partitioned tables

On 4/9/21 11:45 PM, Justin Pryzby wrote: > On Fri, Apr 09, 2021 at 05:31:55PM -0400, Alvaro Herrera wrote: >> On 2021-Apr-09, Robert Haas wrote: >> >>> Does this need to worry about new partitions getting attached to a >>> partitioned table, or old ones getting detached? (Maybe it does >>>

PANIC: wrong buffer passed to visibilitymap_clear

Buildfarm members spurfowl[1] and thorntail[2] have each shown $SUBJECT once in the past two days. The circumstances are not quite the same; spurfowl's failure is in autovacuum while thorntail's is in a manual VACUUM command. Still, it seems clear that there's a recently-introduced bug here

Re: pgsql: autovacuum: handle analyze for partitioned tables

On Fri, Apr 09, 2021 at 06:16:59PM -0400, Alvaro Herrera wrote: > On 2021-Apr-09, Justin Pryzby wrote: > > > One data point: we do DETACH/ATTACH tables during normal operation, before > > type-promoting ALTERs, to avoid worst-case disk use, and to avoid locking > > the > > table for a long time.

Re: PANIC: wrong buffer passed to visibilitymap_clear

Hi, On 2021-04-09 18:40:27 -0400, Tom Lane wrote: > Buildfarm members spurfowl[1] and thorntail[2] have each shown $SUBJECT > once in the past two days. The circumstances are not quite the same; > spurfowl's failure is in autovacuum while thorntail's is in a manual > VACUUM command. Still, it

Re: PANIC: wrong buffer passed to visibilitymap_clear

On Fri, Apr 9, 2021 at 3:40 PM Tom Lane wrote: > Buildfarm members spurfowl[1] and thorntail[2] have each shown $SUBJECT > once in the past two days. The circumstances are not quite the same; > spurfowl's failure is in autovacuum while thorntail's is in a manual > VACUUM command. Still, it

Re: Replication slot stats misgivings

On Thu, Apr 8, 2021 at 7:30 PM Amit Kapila wrote: > > On Wed, Apr 7, 2021 at 2:51 PM vignesh C wrote: > > > > @@ -4069,6 +4069,24 @@ pgstat_read_statsfiles(Oid onlydb, bool > permanent, bool deep) > * slot follows. > */ > case 'R': > + /* > + * There is a remote scenario where one of the

Re: pgsql: autovacuum: handle analyze for partitioned tables

On 2021-Apr-09, Robert Haas wrote: > Does this need to worry about new partitions getting attached to a > partitioned table, or old ones getting detached? (Maybe it does > already, not sure.) Good question. It does not. I suppose you could just let that happen automatically -- I mean, next

Re: pgsql: autovacuum: handle analyze for partitioned tables

Andres Freund writes: > On 2021-04-09 11:54:30 -0400, Alvaro Herrera wrote: >> Pushed now, thanks. > I assume this is also the likely explanation for / fix for: > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink=2021-04-08%2016%3A03%3A03 > ==3500389== VALGRINDERROR-BEGIN >

Re: pgsql: autovacuum: handle analyze for partitioned tables

On 2021-Apr-09, Justin Pryzby wrote: > One data point: we do DETACH/ATTACH tables during normal operation, before > type-promoting ALTERs, to avoid worst-case disk use, and to avoid locking the > table for a long time. It'd be undesirable (but maybe of no great > consequence) > to trigger an

Re: Table refer leak in logical replication

I added this as an Open Item. https://wiki.postgresql.org/index.php?title=PostgreSQL_14_Open_Items=revision=35895=35890 https://www.postgresql.org/message-id/flat/OS0PR01MB6113BA0A760C9964A4A0C5C2FB769%40OS0PR01MB6113.jpnprd01.prod.outlook.com#2fc410dff5cd27eea357ffc17fc174f2 On Tue, Apr 06, 2021

Re: Replication slot stats misgivings

On Fri, Apr 9, 2021 at 4:13 PM Amit Kapila wrote: > > 2. > @@ -2051,6 +2054,17 @@ ReorderBufferProcessTXN(ReorderBuffer *rb, > ReorderBufferTXN *txn, > rb->begin(rb, txn); > } > > + /* > + * Update total transaction count and total transaction bytes, if > + * transaction is streamed or

Re: Replication slot stats misgivings

On Sat, Apr 10, 2021 at 9:50 AM Amit Kapila wrote: > > On Fri, Apr 9, 2021 at 4:13 PM Amit Kapila wrote: > > > > 2. > > @@ -2051,6 +2054,17 @@ ReorderBufferProcessTXN(ReorderBuffer *rb, > > ReorderBufferTXN *txn, > > rb->begin(rb, txn); > > } > > > > + /* > > + * Update total transaction

Re: Avoid unnecessary table open/close for TRUNCATE foo, foo, foo; kind of commands

On 2021/04/10 0:39, Amul Sul wrote: On Fri, Apr 9, 2021 at 8:51 PM Bharath Rupireddy wrote: Hi, While checking the ExecuteTruncate code for the FOREIGN TRUNCATE feature, I saw that we filter out the duplicate relations specified in the TRUNCATE command. But before skipping the duplicates,

Re: check_function_bodies: At least the description seems wrong, since we have prodedures

Chapman Flack writes: > On 04/09/21 08:11, Daniel Westermann (DWE) wrote: >> At least the description should mention procedures. >> Even the parameter name seems not to be correct anymore. Thoughts? > It's possible the parameter name also appears in documentation for > out-of-tree PLs, as each

Re: Avoid unnecessary table open/close for TRUNCATE foo, foo, foo; kind of commands

On Fri, Apr 9, 2021 at 9:23 PM Fujii Masao wrote: > > > > On 2021/04/10 0:39, Amul Sul wrote: > > On Fri, Apr 9, 2021 at 8:51 PM Bharath Rupireddy > > wrote: > >> > >> Hi, > >> > >> While checking the ExecuteTruncate code for the FOREIGN TRUNCATE > >> feature, I saw that we filter out the

Re: SQL-standard function body

On 4/9/21 12:09 PM, Tom Lane wrote: > One could make an argument, therefore, for holding off 0003 until > there's more support for execution-time error cursors. I don't > think we should though, for two reasons: > 1. It'd be better to keep the pg_proc representation of new-style > SQL functions

Avoid unnecessary table open/close for TRUNCATE foo, foo, foo; kind of commands

Hi, While checking the ExecuteTruncate code for the FOREIGN TRUNCATE feature, I saw that we filter out the duplicate relations specified in the TRUNCATE command. But before skipping the duplicates, we are just opening the relation, then if it is present in the already seen relids, then closing it

Re: Avoid unnecessary table open/close for TRUNCATE foo, foo, foo; kind of commands

On Fri, Apr 9, 2021 at 8:51 PM Bharath Rupireddy wrote: > > Hi, > > While checking the ExecuteTruncate code for the FOREIGN TRUNCATE > feature, I saw that we filter out the duplicate relations specified in > the TRUNCATE command. But before skipping the duplicates, we are just > opening the

Re: pgsql: autovacuum: handle analyze for partitioned tables

On 2021-Apr-09, Tom Lane wrote: > Could we get this pushed sooner rather than later? The buildfarm > is showing a wide variety of intermittent failures on HEAD, and it's > hard to tell how many of them trace to this one bug. Pushed now, thanks. -- Álvaro Herrera Valdivia, Chile "Digital

Re: [GSoC] Metrics and Monitoring for pgagroal

Hi Junduo, On 4/9/21 11:53 AM, Junduo Dong wrote: I'm Junduo Dong, a 22-year-old studying at China University of Geosciences. I would like to participate in the project "pgagroal: Metrics and monitoring" on page "https://wiki.postgresql.org/wiki/GSoC_2021; for GSoC 2021. Attachment is the

Re: psql - add SHOW_ALL_RESULTS option

On 2021-Apr-08, Fabien COELHO wrote: > It is definitely a open item. I'm not sure where you want to add it… > possibly the "Pg 14 Open Items" wiki page? I tried but I do not have enough > privileges, if you can do it please proceed. I added an entry in the next CF > in the bugfix section. User

Re: SQL-standard function body

Julien Rouhaud writes: > On Thu, Apr 08, 2021 at 04:54:56PM +0900, Michael Paquier wrote: >> Indeed, I agree that enforcing the availability of querystring >> everywhere sounds like a sensible thing to do in terms of consistency, >> and that's my impression when I scanned the parallel execution

Processing btree walks as a batch to parallelize IO

$SUBJECT is still a very loosely formed idea, so forgive lack of detail or things I've likely missed, but I wanted to get it out there to see if it sounded at all intriguing to people. Background: One of the big problems with non-local storage such as AWS EBS volumes or a SAN is that in a large

Re: psql - add SHOW_ALL_RESULTS option

Yep, it looks much better. I found it strange that the later did a reset but was not doing the set. Attached v2 does as you suggest. Close enough. I was thinking about this position of the attached, which is more consistent with the rest. Given the structural complexity of the function,

Re: Reference Leak with type

Michael Paquier writes: > On Tue, Apr 06, 2021 at 11:09:13AM +0530, Rohit Bhogate wrote: >> I found the below reference leak on master. > Thanks for the report. This is indeed a new problem as of HEAD, Just for the record, it's not new. The issue is (I think) that the tupledesc refcount

Re: Nicer error when connecting to standby with hot_standby=off

On Wed, Mar 24, 2021 at 9:43 PM Fujii Masao wrote: > > > > On 2021/03/24 22:06, James Coleman wrote: > > That looks good to me. Thanks for working on this. > > Thanks! I pushed the patch. > > Regards, > > -- > Fujii Masao > Advanced Computing Technology Center > Research and Development

Re: pg_amcheck contrib application

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

Re: truncating timestamps on arbitrary intervals

On 30.03.21 18:50, John Naylor wrote: On Sat, Mar 27, 2021 at 1:06 PM Justin Pryzby > wrote: > > The current docs seem to be missing a "synopsis", like > > + > +date_trunc(stride, timestamp, origin) > + The attached - adds a synopsis - adds a bit more

Re: WIP: WAL prefetch (another approach)

On Fri, Apr 9, 2021 at 3:37 PM Justin Pryzby wrote: > Here's some little language fixes. Thanks! Done. I rewrote the gibberish comment that made you say "XXX: what?". Pushed. > BTW, before beginning "recovery", PG syncs all the data dirs. > This can be slow, and it seems like the slowness is

Re: WIP: WAL prefetch (another approach)

On Sat, Apr 10, 2021 at 08:27:42AM +1200, Thomas Munro wrote: > On Fri, Apr 9, 2021 at 3:37 PM Justin Pryzby wrote: > > Here's some little language fixes. > > Thanks! Done. I rewrote the gibberish comment that made you say > "XXX: what?". Pushed. > > > BTW, before beginning "recovery", PG

Re: pgsql: autovacuum: handle analyze for partitioned tables

On Fri, Apr 9, 2021 at 11:54 AM Alvaro Herrera wrote: > On 2021-Apr-09, Tom Lane wrote: > > Could we get this pushed sooner rather than later? The buildfarm > > is showing a wide variety of intermittent failures on HEAD, and it's > > hard to tell how many of them trace to this one bug. > >

Re: Another small guc.c fix

On Fri, Apr 9, 2021 at 11:53 PM Daniel Westermann (DWE) wrote: > all "short_desc" end with a dot, except these: > > - Prefetch referenced blocks during recovery > - Prefetch blocks that have full page images in the WAL Pushed, thanks.

Re: WIP: WAL prefetch (another approach)

On Sat, Apr 10, 2021 at 8:37 AM Justin Pryzby wrote: > Did you see this? > https://www.postgresql.org/message-id/GV0P278MB0483490FEAC879DCA5ED583DD2739%40GV0P278MB0483.CHEP278.PROD.OUTLOOK.COM > > I meant to mail you so you could include it in the same commit, but forgot > until now. Done,

Re: pg_amcheck contrib application

On Fri, Apr 9, 2021 at 2:50 PM Mark Dilger wrote: > I think #4, above, requires some clarification. If there are missing chunks, > the very definition of how large we expect subsequent chunks to be is > ill-defined. I took a fairly conservative approach to avoid lots of bogus > complaints

Re: Processing btree walks as a batch to parallelize IO

On 4/9/21 7:33 PM, James Coleman wrote: > $SUBJECT is still a very loosely formed idea, so forgive lack of detail > or things I've likely missed, but I wanted to get it out there to see if > it sounded at all intriguing to people.  > > Background: One of the big problems with non-local storage

Re: libpq debug log

On 2021-Apr-02, Tom Lane wrote: > Alvaro Herrera writes: > > On 2021-Apr-02, Tom Lane wrote: > >> +1, but the comment could be more specific. Maybe like "In regress mode, > >> suppress the length of ErrorResponse and NoticeResponse messages --- the F > >> (file name) field, in particular, can