Re: suggest to rename enable_incrementalsort

On 2020-07-02 17:25, James Coleman wrote: I think the change makes a lot of sense. The only reason I had it as enable_incrementalsort in the first place was trying to broadly following the existing GUC names, but as has already been pointed out, there's a lot of variation there, and my version of

Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions

On Tue, Jun 30, 2020 at 5:20 PM Amit Kapila wrote: > > On Tue, Jun 30, 2020 at 10:13 AM Dilip Kumar wrote: > > > > On Tue, Jun 30, 2020 at 9:20 AM Amit Kapila wrote: > > > > > > Can't we name the last parameter as 'commit_lsn' as that is how > > > documentation in the patch spells it and it soun

Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions

On Sat, Jul 4, 2020 at 11:35 AM Amit Kapila wrote: > > On Tue, Jun 30, 2020 at 5:20 PM Amit Kapila wrote: > > > > Let me know what you think about the above changes. > > > > I went ahead and made few changes in > 0005-Implement-streaming-mode-in-ReorderBuffer which are explained > below. I have

Re: Parallell hashjoin sometimes ignores temp_tablespaces

On Fri, Jul 3, 2020 at 11:02 PM Tom Lane wrote: > Magnus Hagander writes: > > On Fri, Jul 3, 2020 at 7:06 PM Tom Lane wrote: > >> Shouldn't that be inserting MyDatabaseTableSpace? I see no other places > >> anywhere that are forcing temp stuff into pg_default like this. > > > Yeah, looking at

Re: proposal - function string_to_table

pá 5. 6. 2020 v 13:55 odesílatel Pavel Stehule napsal: > Hi > > čt 4. 6. 2020 v 11:49 odesílatel movead...@highgo.ca > napsal: > >> +{ oid => '2228', descr => 'split delimited text', >> + proname => 'string_to_table', prorows => '1000', proretset => 't', >> + prorettype => 'text', proargtypes

Re: doc: vacuum full, fillfactor, and "extra space"

> On 28 Mar 2020, at 11:23, Amit Kapila wrote: > > On Wed, Jan 29, 2020 at 9:10 PM Peter Eisentraut > wrote: >> >> On 2020-01-20 06:30, Justin Pryzby wrote: >> >> About your patch, I don't think this is clearer. The fillfactor stuff >> is valid to be mentioned, but the way it's being proposed

Re: psql - improve test coverage from 41% to 88%

> On 24 Mar 2020, at 15:47, David Steele wrote: > This patch no longer applies: http://cfbot.cputube.org/patch_27_2262.log > > CF entry has been updated to Waiting on Author. This patch hasn't been updated and still doesn't apply, do you intend to rebase it during this commitfest or should we m

Re: [Patch] Invalid permission check in pg_stats for functional indexes

> On 25 Mar 2020, at 15:52, David Steele wrote: > On 12/26/19 6:46 PM, Tom Lane wrote: >> Awhile back I wrote: >>> Actually ... maybe we don't need to change the view definition at all, >>> but instead just make has_column_privilege() do something different >>> for indexes than it does for other

Re: Online verification of checksums

> On 6 Apr 2020, at 23:15, Michael Banck wrote: > Probably we need to take a step back; This patch has been Waiting on Author since the last commitfest (and no longer applies as well), and by the sounds of the thread there are some open issues with it. Should it be Returned with Feedback to be

Re: TAP tests and symlinks on Windows

On 7/3/20 10:11 AM, Peter Eisentraut wrote: > On 2020-06-30 14:13, Michael Paquier wrote: >> Attached is an updated patch, where I have tried to use a better >> wording in all the code paths involved. > > This new patch doesn't work for me on MSYS2 yet. > > It fails right now in 010_pg_basebackup

Re: proposal: schema variables

her changes >> > >> >> You seem to forget attaching the rebased patch. >> > > I am sorry > > attached. > fresh rebase Regards Pavel > Pavel > > >> -- >> With Regards, >> Amit Kapila. >> EnterpriseDB: http://www.enterprisedb.com >> > schema-variables-20200705.patch.gz Description: application/gzip

Re: Built-in connection pooler

Thank your for your help. On 05.07.2020 07:17, Jaime Casanova wrote: You should also allow cursors without the WITH HOLD option or there is something i'm missing? Yes, good point. a few questions about tainted backends: - why the use of check_primary_key() and check_foreign_key() in contrib/

Re: [Patch] Invalid permission check in pg_stats for functional indexes

Daniel Gustafsson writes: > This patch still hasn't progressed since Tom's draft patch, is anyone still > interested in pursuing it or should we close it for now? It seems clearly reasonable to me to close the CF item as RWF, expecting that a new one can be made whenever somebody re-tackles this

Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions

On Tue, Jun 30, 2020 at 10:13 AM Dilip Kumar wrote: > > On Tue, Jun 30, 2020 at 9:20 AM Amit Kapila wrote: > > > > On Mon, Jun 29, 2020 at 4:24 PM Dilip Kumar wrote: > > > > > > On Mon, Jun 22, 2020 at 4:30 PM Amit Kapila > > > wrote: > > > > > > > > > > > > Other than above tests, can we some

Re: Ideas about a better API for postgres_fdw remote estimates

Greetings, * Tom Lane (t...@sss.pgh.pa.us) wrote: > In <1116564.1593813...@sss.pgh.pa.us> I wrote: > > I wonder whether someday we ought to invent a new API that's more > > suited to postgres_fdw's needs than EXPLAIN is. It's not like the > > remote planner doesn't know the number we want; it jus

Re: SQL/JSON: JSON_TABLE

On Mon, Mar 23, 2020 at 08:33:34PM +0300, Nikita Glukhov wrote: > On 23.03.2020 19:24, Pavel Stehule wrote: > > This patch needs rebase > > Attached 43rd version of the patches based on the latest (v47) SQL/JSON > functions patches. It looks like this needs to be additionally rebased - I will set

Re: range_agg

On Sat, Apr 11, 2020 at 09:36:37AM -0700, Paul A Jungwirth wrote: > On Fri, Apr 10, 2020 at 8:44 PM Paul A Jungwirth > wrote: > > Thanks, and thanks for your v17 also. Here is a patch building on that > > and adding support for anycompatiblemultirange. > > Here is a v19 that just moved the multi

Re: Inlining of couple of functions in pl_exec.c improves performance

I wrote: > I attach your original 0003 here (it still applies, with some line > offsets). That's just so the cfbot doesn't get confused about what > it's supposed to test now. Pushed that part now, too. BTW, the first test run I did on this (on x86_64) was actually several percent *slower* than

Re: SQL/JSON: functions

On Mon, Mar 23, 2020 at 08:28:52PM +0300, Nikita Glukhov wrote: > Attached 47th version of the patches. The patch checker/cfbot says this doesn't apply ; could you send a rebasified version ? -- Justin

Re: Persist MVCC forever - retain history

On 05.07.2020 08:48, Mitar wrote: Hi! On Fri, Jul 3, 2020 at 12:29 AM Konstantin Knizhnik wrote: Did you read this thread: https://www.postgresql.org/message-id/flat/78aadf6b-86d4-21b9-9c2a-51f1efb8a499%40postgrespro.ru I have proposed a patch for supporting time travel (AS OF) queries. But

Re: Ideas about a better API for postgres_fdw remote estimates

Stephen Frost writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> * Rather than adding a core-server feature, the remote-end part of the new >> API should be a function installed by an extension (either postgres_fdw >> itself, or a new extension "postgres_fdw_remote" or the like). > I'm trying to

Re: Default gucs for EXPLAIN

I think this got ample review, so I've set it to "Waiting". -- Justin

Re: Ideas about a better API for postgres_fdw remote estimates

Greetings, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > >> * Rather than adding a core-server feature, the remote-end part of the new > >> API should be a function installed by an extension (either postgres_fdw > >> itself, or a new e

Re: Persist MVCC forever - retain history

Konstantin Knizhnik schrieb am 05.07.2020 um 19:31: I am surprised that you are saying you didn't feel big interest. My reading of the thread is the opposite, that there was quite some interest, but that there are technical challenges to overcome. So you gave up on that work? No, I have not gave

Re: range_agg

On Sun, Jul 5, 2020 at 12:11 PM Paul A Jungwirth wrote: > > Just knowing that arrays are > something we do this for is enough to hunt for clues, but if anyone > can point me more directly to code that will help me do it for > multiranges, I'd be appreciative. It looks like expandeddatum.h is wher

Re: proposal: possibility to read dumped table's name from file

so 27. 6. 2020 v 14:55 odesílatel vignesh C napsal: > On Thu, Jun 11, 2020 at 1:07 PM Pavel Stehule > wrote: > > > > Thank you for comments, attached updated patch > > > > Few comments: > +invalid_filter_format(char *message, char *filename, char *line, int > lineno) > +{ > + char *d

Re: proposal: possibility to read dumped table's name from file

st 1. 7. 2020 v 23:24 odesílatel Justin Pryzby napsal: > On Thu, Jun 11, 2020 at 09:36:18AM +0200, Pavel Stehule wrote: > > st 10. 6. 2020 v 0:30 odesílatel Justin Pryzby > napsal: > > > > + /* ignore empty rows */ > > > > +

Re: Ideas about a better API for postgres_fdw remote estimates

Stephen Frost writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> 2. Wedging this into EXPLAIN would be quite ugly, because (at least >> as I envision it) the output would have just about nothing to do with >> any existing EXPLAIN output. > This is a better argument for not making it part of EXPL

Re: proposal: possibility to read dumped table's name from file

On Wed, Jul 01, 2020 at 04:24:52PM -0500, Justin Pryzby wrote: > On Thu, Jun 11, 2020 at 09:36:18AM +0200, Pavel Stehule wrote: > > st 10. 6. 2020 v 0:30 odesílatel Justin Pryzby > > napsal: > > > > + /* ignore empty rows */ > > > > +

Re: [Patch] Invalid permission check in pg_stats for functional indexes

> On 5 Jul 2020, at 16:16, Tom Lane wrote: > > Daniel Gustafsson writes: >> This patch still hasn't progressed since Tom's draft patch, is anyone still >> interested in pursuing it or should we close it for now? > > It seems clearly reasonable to me to close the CF item as RWF, > expecting that

Re: proposal: possibility to read dumped table's name from file

ne 5. 7. 2020 v 22:31 odesílatel Justin Pryzby napsal: > On Wed, Jul 01, 2020 at 04:24:52PM -0500, Justin Pryzby wrote: > > On Thu, Jun 11, 2020 at 09:36:18AM +0200, Pavel Stehule wrote: > > > st 10. 6. 2020 v 0:30 odesílatel Justin Pryzby > napsal: > > > > > +

Re: Binary support for pgoutput plugin

> On 2 Jul 2020, at 18:41, Dave Cramer wrote: > > rebased Thanks! The new version of 0001 patch has a compiler warning due to mixed declarations and code: worker.c: In function ‘slot_store_data’: worker.c:366:5: error: ISO C90 forbids mixed declarations and code [-Werror=declaration-after-sta

Re: vacuum verbose detail logs are unclear; log at *start* of each stage

> On 24 Mar 2020, at 22:58, Tom Lane wrote: > The really fundamental problem with this is that you are trying to make > the server do what is properly the client's job, namely format messages > nicely. Please read the message style guidelines [1], particularly > the bit about "Formatting", which

Can I use extern "C" in an extension so I can use C++?

I'm writing a small extension, and I'm trying to use C++ constructs. I'm not actually doing anything that needs C++, but I *really* like declaring variables when I first initialize them (for example), and I also *really* like warning-free compiles. The C++ compiler is mangling the names so they ar

Re: Online checksums verification in the backend

> On 5 Apr 2020, at 13:17, Julien Rouhaud wrote: > On Sun, Apr 05, 2020 at 08:01:36PM +0900, Masahiko Sawada wrote: >> Thank you for updating the patch! The patch looks good to me. >> >> I've marked this patch as Ready for Committer. I hope this patch will >> get committed to PG13. > Thanks a l

Re: Binary support for pgoutput plugin

On 2020-Jul-05, Daniel Gustafsson wrote: > > On 2 Jul 2020, at 18:41, Dave Cramer wrote: > > > > rebased > > Thanks! The new version of 0001 patch has a compiler warning due to mixed > declarations and code: > > worker.c: In function ‘slot_store_data’: > worker.c:366:5: error: ISO C90 forbids

Re: Binary support for pgoutput plugin

> On 5 Jul 2020, at 23:11, Alvaro Herrera wrote: > > On 2020-Jul-05, Daniel Gustafsson wrote: > >>> On 2 Jul 2020, at 18:41, Dave Cramer wrote: >>> >>> rebased >> >> Thanks! The new version of 0001 patch has a compiler warning due to mixed >> declarations and code: >> >> worker.c: In functi

Re: Can I use extern "C" in an extension so I can use C++?

Isaac Morland writes: > I'm writing a small extension, and I'm trying to use C++ constructs. I'm > not actually doing anything that needs C++, but I *really* like declaring > variables when I first initialize them (for example), and I also *really* > like warning-free compiles. Well, you could ge

Re: Can I use extern "C" in an extension so I can use C++?

On Sun, 5 Jul 2020 at 18:07, Tom Lane wrote: > Isaac Morland writes: > > I'm writing a small extension, and I'm trying to use C++ constructs. I'm > > not actually doing anything that needs C++, but I *really* like declaring > > variables when I first initialize them (for example), and I also *re

Re: Can I use extern "C" in an extension so I can use C++?

Isaac Morland writes: > On Sun, 5 Jul 2020 at 18:07, Tom Lane wrote: >> Something like the attached works for me; what problem are you having >> *exactly*? > I've attached a .cpp file. My example wrapped the Postgres #include's, the PG_MODULE_MAGIC call, and the PG_FUNCTION_INFO_V1 call(s) in e

Re: Default setting for enable_hashagg_disk (hash_mem)

On Sat, Jul 4, 2020 at 1:54 PM Jeff Davis wrote: > I agree that it's good to wait for actual problems. But the challenge > is that we can't backport an added GUC. Are there other, backportable > changes we could potentially make if a lot of users have a problem with > v13 after release? I doubt t

Re: Postgres Windows build system doesn't work with python installed in Program Files

On Sat, Jul 04, 2020 at 09:17:52PM +0200, Juan José Santamaría Flecha wrote: > Going through the open items in the commitfest, I see that this patch has > not been pushed. It still applies and solves the warning so, I am marking > it as RFC. Thanks, applied. I was actually waiting to see if you h

Re: A patch for get origin from commit_ts.

On Sat, Jul 04, 2020 at 06:01:28PM +0800, movead...@highgo.ca wrote: > I make a patch as Michael Paquier described that use a new function to > return transactionid and origin, and I add a origin version to > pg_last_committed_xact() too, now it looks like below: +SELECT pg_replication_origin_cr

Re: Can I use extern "C" in an extension so I can use C++?

On Sun, 5 Jul 2020 at 18:49, Tom Lane wrote: > > My example wrapped the Postgres #include's, the PG_MODULE_MAGIC call, > and the PG_FUNCTION_INFO_V1 call(s) in extern "C" { ... }. I'm pretty > sure you need to do all three of those things to get a working result > without mangled external functi

Re: TAP tests and symlinks on Windows

On Sun, Jul 05, 2020 at 08:18:46AM -0400, Andrew Dunstan wrote: > On 7/3/20 10:11 AM, Peter Eisentraut wrote: >> I think all of this is still a bit too fragile it needs further >> consideration. Indeed. I would need a MSYS2 environment to dig into that. This looks trickier than what I am used to

Re: Include access method in listTables output

On Sun, Jul 05, 2020 at 07:13:10AM +0530, vignesh C wrote: > I'm not sure if we should include showViews, I had seen that the > access method was not getting selected for view. +1. These have no physical storage, so you are looking here for relkinds that satisfy RELKIND_HAS_STORAGE(). -- Michael

Re: Creating a function for exposing memory usage of backend process

On Fri, Jul 3, 2020 at 7:33 PM Fujii Masao wrote: Thanks for your review! I like more specific name like pg_backend_memory_contexts. Agreed. When I was trying to add this function as statistics function, I thought that naming pg_stat_getbackend_memory_context() might make people regarded i

Re: A patch for get origin from commit_ts.

>+SELECT pg_replication_origin_create('test_commit_ts: get_origin_1'); >+SELECT pg_replication_origin_create('test_commit_ts: get_origin_2'); >+SELECT pg_replication_origin_create('test_commit_ts: get_origin_3'); > >Why do you need three replication origins to test three times the same >pattern?

Re: Cleanup - adjust the code crossing 80-column window limit

On Fri, Jul 3, 2020 at 1:32 PM Peter Eisentraut wrote: > > On 2020-07-01 09:00, Amul Sul wrote: > > Attached patch makes an adjustment to ipc.c code to be in the 80-column > > window. > > I can see an argument that this makes the code a bit easier to read, but > making code fit into 80 columns doe

RE: archive status ".ready" files may be created too early

Hello, Horiguchi-san Thank you for your comment and patch. At Thursday, June 25, 2020 3:36 PM(JST), "Kyotaro Horiguchi " wrote in > I think we don't need most of that shmem stuff. XLogWrite is called I wanted no more shmem stuff too, but other ideas need more lock that excludes inserter and w

Re: Cache lookup errors with functions manipulation object addresses

On Fri, Jul 03, 2020 at 12:34:39PM +0200, Daniel Gustafsson wrote: > No objections from me after skimming over the updated patchset. I still > maintain that the format_operator_extended comment should be amended to > include > that it can return NULL and not alwatys palloced string, but that's it

Re: Cleanup - adjust the code crossing 80-column window limit

> > Is there a test case covering this part of the code(I'm not sure if > one exists in the regression test suite)? > If no, can we add one? > I observed that the code areas this patch is trying to modify are pretty much generic and are being called from many places. The code basically handles exi

Re: proposal: possibility to read dumped table's name from file

ne 5. 7. 2020 v 22:37 odesílatel Pavel Stehule napsal: > > > ne 5. 7. 2020 v 22:31 odesílatel Justin Pryzby > napsal: > >> On Wed, Jul 01, 2020 at 04:24:52PM -0500, Justin Pryzby wrote: >> > On Thu, Jun 11, 2020 at 09:36:18AM +0200, Pavel Stehule wrote: >> > > st 10. 6. 2020 v 0:30 odesílatel Ju

"tuple concurrently updated" in pg_restore --jobs

I hit this issue intermittently (roughly half the time) while working with a patch David submitted, and finally found a recipe to reproduce it on an unpatched v12 instance. I was surprised to see pg_restore -j2 is restoring ACLs in pre-data in parallel. Note different session IDs and PIDs: 2020-

Re: proposal - function string_to_table

ne 5. 7. 2020 v 13:30 odesílatel Pavel Stehule napsal: > > > pá 5. 6. 2020 v 13:55 odesílatel Pavel Stehule > napsal: > >> Hi >> >> čt 4. 6. 2020 v 11:49 odesílatel movead...@highgo.ca >> napsal: >> >>> +{ oid => '2228', descr => 'split delimited text', >>> + proname => 'string_to_table', pror

Re: archive status ".ready" files may be created too early

Hello, Matsumura-san. At Mon, 6 Jul 2020 04:02:23 +, "matsumura@fujitsu.com" wrote in > Hello, Horiguchi-san > > Thank you for your comment and patch. > > At Thursday, June 25, 2020 3:36 PM(JST), "Kyotaro Horiguchi > " wrote in > > I think we don't need most of that shmem stuff. XL

Re: track_planning causing performance regression

On 2020/07/04 12:22, Pavel Stehule wrote: pá 3. 7. 2020 v 13:02 odesílatel Fujii Masao mailto:masao.fu...@oss.nttdata.com>> napsal: On 2020/07/03 16:02, Pavel Stehule wrote: > > > pá 3. 7. 2020 v 8:57 odesílatel Fujii Masao mailto:masao.fu...@oss.nttdata.com>

Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions

On Sun, Jul 5, 2020 at 4:47 PM Dilip Kumar wrote: > > On Sat, Jul 4, 2020 at 11:35 AM Amit Kapila wrote: > > > > > 9. > > +ReorderBufferHandleConcurrentAbort(ReorderBuffer *rb, ReorderBufferTXN > > *txn, > > { > > .. > > + ReorderBufferToastReset(rb, txn); > > + if (specinsert != NULL) > > + Reo

Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions

On Mon, Jul 6, 2020 at 11:31 AM Amit Kapila wrote: > > On Sun, Jul 5, 2020 at 4:47 PM Dilip Kumar wrote: > > > > On Sat, Jul 4, 2020 at 11:35 AM Amit Kapila wrote: > > > > > > > > 9. > > > +ReorderBufferHandleConcurrentAbort(ReorderBuffer *rb, ReorderBufferTXN > > > *txn, > > > { > > > .. > > >

Re: Creating a function for exposing memory usage of backend process

On 2020/07/06 12:12, torikoshia wrote: On Fri, Jul 3, 2020 at 7:33 PM Fujii Masao wrote: Thanks for your review! I like more specific name like pg_backend_memory_contexts. Agreed. When I was trying to add this function as statistics function, I thought that naming pg_stat_getbackend_mem