Re: [HACKERS] Re: ICU collation variant keywords and pg_collation entries (Was: [BUGS] Crash report for some ICU-52 (debian8) COLLATE and work_mem values)

On 8/17/17 23:13, Noah Misch wrote: >> I haven't read anything since that has provided any more clarity about >> what needs changing here. I will entertain concrete proposals about the >> specific points above (considering any other issues under discussion to >> be PG11 material), but in the

Re: [HACKERS] [PATCH] Pattern based listeners for asynchronous messaging (LISTEN/NOTIFY)

On Tue, Aug 1, 2017 at 8:13 AM, Markus Sintonen wrote: > This patch adds an ability to use patterns in LISTEN commands. Patch uses > 'SIMILAR TO' patterns for matching NOTIFY channel names >

Re: [HACKERS] Update low-level backup documentation to match actual behavior

On 8/18/17 3:00 PM, Robert Haas wrote: > > If you update the patch I'll apply it to 11 and 10. Attached is the updated patch. I didn't like the vague "there can be some issues on the server if it crashes during the backup" so I added a new paragraph at the appropriate step to give a more

Re: [HACKERS] possible encoding issues with libxml2 functions

Hi 2017-08-08 2:10 GMT+02:00 Noah Misch : > On Wed, Apr 05, 2017 at 10:53:39PM +0200, Pavel Stehule wrote: > > 2017-03-17 4:23 GMT+01:00 Noah Misch : > > > On Sun, Mar 12, 2017 at 10:26:33PM +0100, Pavel Stehule wrote: > > > > 2017-03-12 21:57 GMT+01:00 Noah

Re: [HACKERS] [PATCH] Push limit to sort through a subquery

> > 1. The header comment for pass_down_bound() could mention "one or more > levels of subqueries" rather than "a subquery". > Fixed 2. The first of the comments in the function body appears to have a > whitespace issue that needs to be fixed manually or, better yet, > addressed by pgindent. >

Re: [HACKERS] expanding inheritance in partition bound order

On Fri, Aug 18, 2017 at 1:17 AM, Ashutosh Bapat wrote: > 0004 patch in partition-wise join patchset has code to expand > partition hierarchy. That patch is expanding inheritance hierarchy in > depth first manner. Robert commented that instead of depth first >

Re: [HACKERS] HISTIGNORE for psql

Hello, On Fri, 18 Aug 2017, Vesa-Matti J Kari wrote: > A quick patch is attached. Not sure about the quality, hacked this > together in about four hours, trying to figure out how to do it correctly > the PostgreSQL way. Sorry, I guess I have written too many Python scripts. I no longer

Re: [HACKERS] HISTIGNORE for psql

Hello, On Thu, 17 Aug 2017, Pavel Stehule wrote: > 2017-08-17 9:23 GMT+02:00 Vesa-Matti J Kari : > > Bash has HISTIGNORE feature that allows you to exclude certain commands > from the command history (e.g. shutdown, reboot, rm *). > > Would it make any

Re: [HACKERS] Update low-level backup documentation to match actual behavior

On Fri, Aug 18, 2017 at 2:58 PM, David Steele wrote: > OK, but I was trying to make it very clear that this backup method only > works on a primary. If you think the text is in the first paragraph is > enough then I'm willing to go with that, though. Yeah, I think the text

Re: [HACKERS] Update low-level backup documentation to match actual behavior

Robert, Thanks for reviewing! On 8/18/17 2:45 PM, Robert Haas wrote: > - the next WAL segment. The reason for the switch is to arrange for > + the next WAL segment when run on a primary. On a standby you can call > + pg_switch_wal on the primary to perform a manual > + switch.

Re: [HACKERS] recovery_target_time = 'now' is not an error but still impractical setting

On Fri, Aug 18, 2017 at 4:39 AM, Piotr Stefaniak wrote: > On 2017-08-17 11:24, Simon Riggs wrote: >> Your suggestion of "furthest" is already the default behaviour. >> >> Why are you using 'now'? Why would you want to pick a randomly >> selected end time? > > The idea

Re: [HACKERS] [Proposal] Allow users to specify multiple tables in VACUUM commands

On Fri, Aug 18, 2017 at 1:56 AM, Michael Paquier wrote: > + /* > +* We have already checked the column list in vacuum(...), > +* but the columns may have disappeared since then. If > +* this happens, emit a nice warning

Re: [HACKERS] Update low-level backup documentation to match actual behavior

- the next WAL segment. The reason for the switch is to arrange for + the next WAL segment when run on a primary. On a standby you can call + pg_switch_wal on the primary to perform a manual + switch. + The reason for the switch is to arrange for Tacking on "when run on a

[HACKERS] Segmentation Fault during pg_restore using '--use-list' and '--jobs'

Hi all, I'm facing a 'segmentation fault' error using '--use-list' and '--jobs' options after update to 9.5.8. We generate a list ignoring some 'TABLE DATA' toc for a selective restore. See the test case below: cat < /tmp/test_restore.dump.list -- rebuild database cat

Re: [HACKERS] Hash Functions

On Fri, Aug 18, 2017 at 1:12 PM, amul sul wrote: > I have a small query, what if I want a cache entry with extended hash > function instead standard one, I might require that while adding > hash_array_extended function? Do you think we need to extend > lookup_type_cache() as

Re: [HACKERS] Hash Functions

On Fri, Aug 18, 2017 at 8:49 AM, Robert Haas wrote: > On Wed, Aug 16, 2017 at 5:34 PM, Robert Haas > wrote: > > Attached is a quick sketch of how this could perhaps be done (ignoring > > for the moment the relatively-boring opclass pushups). > >

Re: [HACKERS] Add support for tuple routing to foreign partitions

On Thu, Aug 17, 2017 at 4:27 AM, Etsuro Fujita wrote: > I think that would be much more efficient than INSERTing tuples into the > remote server one by one. What do you think about that? I agree, but I wonder if we ought to make it work first using the existing APIs

Re: [HACKERS] Add support for tuple routing to foreign partitions

On Thu, Aug 17, 2017 at 7:58 AM, Etsuro Fujita wrote: >> The description seems to support only COPY to a foreign table from a >> file, but probably we need the support other way round as well. This >> looks like a feature (support copy to and from a foreign table) to

Re: [HACKERS] Stats for triggers on partitioned tables not shown in EXPLAIN ANALYZE

On Fri, Aug 18, 2017 at 1:15 AM, Noah Misch wrote: > The above-described topic is currently a PostgreSQL 10 open item. Robert, > since you committed the patch believed to have created it, you own this open > item. If some other commit is more relevant or if this does not

Re: [HACKERS] [PATCH] Push limit to sort through a subquery

On Fri, Aug 18, 2017 at 11:42 AM, Douglas Doole wrote: > Thanks for the feedback on my original patch Robert. Here's an updated patch > that will tunnel through multiple SubqueryScanStates. Seems reasonable. I have some assorted nitpicks. 1. The header comment for

Re: [HACKERS] why not parallel seq scan for slow functions

On Fri, 18 Aug 2017 at 4:48 PM, Amit Kapila wrote: > On Thu, Aug 17, 2017 at 2:45 PM, Dilip Kumar > wrote: > > On Thu, Aug 17, 2017 at 2:09 PM, Dilip Kumar > wrote: > >> > >> Either we can pass "num_gene" to merge_clump or

Re: [HACKERS] Proposal : For Auto-Prewarm.

On Fri, Aug 18, 2017 at 2:23 AM, Mithun Cy wrote: > 1. Hang in apw_detach_shmem. > +/* > + * Clear our PID from autoprewarm shared state. > + */ > +static void > +apw_detach_shmem(int code, Datum arg) > +{ > + LWLockAcquire(_state->lock, LW_EXCLUSIVE); > + if

Re: [HACKERS] [PATCH] Push limit to sort through a subquery

Thanks for the feedback on my original patch Robert. Here's an updated patch that will tunnel through multiple SubqueryScanStates. - Doug Salesforce On Thu, Aug 17, 2017 at 6:33 PM Robert Haas wrote: > On Thu, Aug 17, 2017 at 11:36 AM, Douglas Doole

Re: [HACKERS] Quorum commit for multiple synchronous replication.

On Thu, Aug 17, 2017 at 1:13 AM, Michael Paquier wrote: > I had in mind a ereport(WARNING) in create_syncrep_config. Extra > thoughts/opinions welcome. I think for v10 we should just document the behavior we've got; I think it's too late to be whacking things around

Re: [HACKERS] Proposal: global index

Erikjan Rijkers wrote: > On 2017-08-18 11:12, Ildar Musin wrote: > > Hi hackers, > > > > While we've been developing pg_pathman extension one of the most > > frequent questions we got from our users was about global index > > support. We cannot provide it within an extension. And I couldn't find

Re: [HACKERS] Proposal: global index

Ildar Musin wrote: > While we've been developing pg_pathman extension one of the most frequent > questions we got from our users was about global index support. We cannot > provide it within an extension. And I couldn't find any recent discussion > about someone implementing it. So I'm thinking

Re: [HACKERS] Proposal: global index

On 2017-08-18 11:12, Ildar Musin wrote: Hi hackers, While we've been developing pg_pathman extension one of the most frequent questions we got from our users was about global index support. We cannot provide it within an extension. And I couldn't find any recent discussion about someone

Re: [HACKERS] Proposal: global index

Hi Chris, On 18.08.2017 16:15, Chris Travers wrote: I would really like to see global indexes. It would make things a lot easier for things like unique constraints across table inheritance trees. On Fri, Aug 18, 2017 at 11:12 AM, Ildar Musin

Re: [HACKERS] Add support for tuple routing to foreign partitions

On Fri, Aug 18, 2017 at 05:10:29PM +0900, Etsuro Fujita wrote: > On 2017/08/17 23:48, David Fetter wrote: > >On Thu, Aug 17, 2017 at 05:27:05PM +0900, Etsuro Fujita wrote: > >>On 2017/07/11 6:56, Robert Haas wrote: > >>>On Thu, Jun 29, 2017 at 6:20 AM, Etsuro Fujita >

Re: [HACKERS] Proposal: global index

I would really like to see global indexes. It would make things a lot easier for things like unique constraints across table inheritance trees. On Fri, Aug 18, 2017 at 11:12 AM, Ildar Musin wrote: > Hi hackers, > > While we've been developing pg_pathman extension one of

[HACKERS] [PROPOSAL] Text search configuration extension

Hello hackers! I'm working on a new approach in text search configuration and want to share my thought with community in order to get some feedback and maybe some new ideas. Nowadays we can't configure text search engine in Postgres for some useful scenarios such as multi-language search or

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

On Fri, Apr 7, 2017 at 10:51 PM, Claudio Freire wrote: > Indeed they do, and that's what motivated this patch. But I'd need > TB-sized tables to set up something like that. I don't have the > hardware or time available to do that (vacuum on bloated TB-sized > tables can

Re: [HACKERS] Parallel Hash take II

On Wed, Aug 2, 2017 at 10:06 PM, Thomas Munro wrote: > On Tue, Aug 1, 2017 at 1:11 PM, Andres Freund wrote: >> WRT the main patch: > > Thanks for the review. I will respond soon, but for now I just wanted > to post a rebased version (no

Re: [HACKERS] why not parallel seq scan for slow functions

On Thu, Aug 17, 2017 at 2:45 PM, Dilip Kumar wrote: > On Thu, Aug 17, 2017 at 2:09 PM, Dilip Kumar wrote: >> >> Either we can pass "num_gene" to merge_clump or we can store num_gene >> in the root. And inside merge_clump we can check. Do you see some

Re: [HACKERS] [BUGS] [postgresql 10 beta3] unrecognized node type: 90

On Fri, Aug 18, 2017 at 3:50 AM, Tom Lane wrote: > I wrote: >> Ah-hah, I see my dromedary box is one of the ones failing, so I'll >> have a look there. I can't reproduce it on my other machines. > > OK, so this is a whole lot more broken than I thought :-(. > > Bear in mind

Re: [HACKERS] Create replication slot in pg_basebackup if requested and not yet present

Hi, On Tue, Aug 15, 2017 at 02:14:58PM -0700, Jeff Janes wrote: > On Sun, Apr 9, 2017 at 4:22 AM, Michael Banck > wrote: > > Rebased, squashed and slighly edited version attached. I've added this > > to the 2017-07 commitfest now as well: > > > >

[HACKERS] Proposal: global index

Hi hackers, While we've been developing pg_pathman extension one of the most frequent questions we got from our users was about global index support. We cannot provide it within an extension. And I couldn't find any recent discussion about someone implementing it. So I'm thinking about giving

Re: [HACKERS] recovery_target_time = 'now' is not an error but still impractical setting

On 2017-08-17 11:24, Simon Riggs wrote: > Your suggestion of "furthest" is already the default behaviour. > > Why are you using 'now'? Why would you want to pick a randomly > selected end time? The idea in both cases was to stop the recovery in order to prevent the standby from selecting new

Re: [HACKERS] ECPG: WHENEVER statement with DO CONTINUE action

On 2017/06/20 17:35, vinayak wrote: Hi Sawada-san, On 2017/06/20 17:22, Masahiko Sawada wrote: On Tue, Jun 20, 2017 at 1:51 PM, vinayak wrote: On 2017/06/12 13:09, vinayak wrote: Hi, On 2017/06/10 12:23, Vinayak Pokale wrote: Thank you for your reply On

Re: [HACKERS] recovery_target_time = 'now' is not an error but still impractical setting

On 18 August 2017 at 07:30, Michael Paquier wrote: > On Thu, Aug 17, 2017 at 6:24 PM, Simon Riggs wrote: >> On 15 August 2017 at 15:37, Piotr Stefaniak >> wrote: >> >>> One thing I tried was a combination of

Re: [HACKERS] [PROPOSAL] Use SnapshotAny in get_actual_variable_range

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: tested, passed Documentation:tested, passed Oops, missed those checkboxes. Sorry for the noise. Here's

Re: [HACKERS] Add support for tuple routing to foreign partitions

On 2017/08/17 23:48, David Fetter wrote: On Thu, Aug 17, 2017 at 05:27:05PM +0900, Etsuro Fujita wrote: On 2017/07/11 6:56, Robert Haas wrote: On Thu, Jun 29, 2017 at 6:20 AM, Etsuro Fujita wrote: So, I dropped the COPY part. Ouch. I think we should try to

Re: [HACKERS] [PROPOSAL] Use SnapshotAny in get_actual_variable_range

The following review has been posted through the commitfest application: make installcheck-world: tested, failed Implements feature: tested, failed Spec compliant: tested, failed Documentation:tested, failed Hi! I've looked into the patch. There is not so much of the

Re: [HACKERS] recovery_target_time = 'now' is not an error but still impractical setting

On Thu, Aug 17, 2017 at 6:24 PM, Simon Riggs wrote: > On 15 August 2017 at 15:37, Piotr Stefaniak > wrote: > >> One thing I tried was a combination of recovery_target_action = >> 'shutdown' and recovery_target_time = 'now'. The result is

Re: [HACKERS] Proposal : For Auto-Prewarm.

On Wed, Aug 16, 2017 at 2:08 AM, Robert Haas wrote: > On Fri, Jul 14, 2017 at 8:17 AM, Mithun Cy wrote: >> [ new patch ] > It's quite possible that in making all of these changes I've > introduced some bugs, so I think this needs some testing

Re: [HACKERS] expanding inheritance in partition bound order

On 18 August 2017 at 10:55, Amit Langote wrote: > On 2017/08/18 4:54, Robert Haas wrote: >> On Thu, Aug 17, 2017 at 8:39 AM, Ashutosh Bapat >> wrote: >>> [2] had a patch with some changes to the original patch you posted. I >>>