Re: [HACKERS] Setting pd_lower in GIN metapage

On Wed, Sep 20, 2017 at 9:19 AM, Amit Kapila wrote: > On Wed, Sep 20, 2017 at 4:25 AM, Michael Paquier > wrote: >> On Wed, Sep 20, 2017 at 12:47 AM, Tom Lane wrote: >>> Amit Kapila writes: On

Re: [HACKERS] SCRAM in the PG 10 release notes

On 9/21/17 14:15, Jeff Janes wrote: > Here is a patch that expands the SCRAM documentation a bit, adds more > explanation how the different options are related, and sets some better > links.  I think now you can get from the release notes to the relevant > documentation and have

Re: [HACKERS] Built-in plugin for logical decoding output

2017-09-23 14:01 GMT-03:00 Alvaro Hernandez : > However, AFAIK, AWS's DMS uses it for production purposes (see > http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_PostgreSQL.html). > It seems a bad idea. AFAICS test_decoding was not designed to be a

Re: [HACKERS] [BUGS] BUG #14825: enum type: unsafe use?

Andrew Dunstan writes: > OK, I think I'm convinced. Here's is the WIP code I put together for the > blacklist. I'm was looking for a place to put the init call, but since > it's possibly not going anywhere I stopped :-) . My initial thought > about substransactions

Re: [HACKERS] [BUGS] BUG #14825: enum type: unsafe use?

On 09/23/2017 03:52 PM, Tom Lane wrote: > Andrew Dunstan writes: >> On 09/23/2017 02:00 PM, Tom Lane wrote: >>> So I'm back to not being sure about the path forward. Maybe it would be >>> all right to say "the value added by ADD VALUE can't be used in the same

[HACKERS] Proposed fix for bug #14826 (the invalid empty array business)

I poked around among the callers of construct_[md_]array() and found at least two more besides ts_lexize() that could build zero-element arrays; one of very ancient standing is in the pg_prepared_statements view. So I think we've got a clear hazard here that justifies changing the behavior of the

Re: [HACKERS] [BUGS] BUG #14825: enum type: unsafe use?

Andrew Dunstan writes: > On 09/23/2017 02:00 PM, Tom Lane wrote: >> So I'm back to not being sure about the path forward. Maybe it would be >> all right to say "the value added by ADD VALUE can't be used in the same >> transaction, period". That's still a step

Re: [HACKERS] Variable substitution in psql backtick expansion

Hello Gerdan, This is an internal address that should not be exposed: postgresql@coelho.net I'm unsure why it gets substituted by the "commitfest application"... When i try apply this patch he failed with a following messenger: It just worked for me on head with git

Re: [HACKERS] [BUGS] BUG #14825: enum type: unsafe use?

On 09/23/2017 02:00 PM, Tom Lane wrote: > I wrote: >> Andrew Dunstan writes: >>> I see what you're saying, but my idea was slightly different. We would >>> only add to the hashtable I had in mind at the bottom AddEnumLabel(). >>> Any other value, whether added in

Re: [HACKERS] [BUGS] BUG #14825: enum type: unsafe use?

I wrote: > Andrew Dunstan writes: >> I see what you're saying, but my idea was slightly different. We would >> only add to the hashtable I had in mind at the bottom AddEnumLabel(). >> Any other value, whether added in the current transaction or not, should >> be

Re: [HACKERS] [BUGS] BUG #14825: enum type: unsafe use?

On 09/23/2017 11:16 AM, Tom Lane wrote: > Andrew Dunstan writes: > >>> The immediate question is do we care to design/implement such a thing >>> post-RC1. I'd have to vote "no". I think the most prudent thing to >>> do is revert 15bc038f9 and then have another

Re: [HACKERS] Rethinking autovacuum.c memory handling

On 9/23/17, 12:36 PM, "Tom Lane" wrote: >"Bossart, Nathan" writes: >> This looks reasonable to me as well. I haven't noticed any issues after >> a couple hours of pgbench with aggressive autovacuum settings, either. > > Thanks for looking. As I'm sure

Re: [HACKERS] Rethinking autovacuum.c memory handling

"Bossart, Nathan" writes: > This looks reasonable to me as well. I haven't noticed any issues after > a couple hours of pgbench with aggressive autovacuum settings, either. Thanks for looking. As I'm sure you realize, what motivated that was not liking the switch into

Re: [HACKERS] Rethinking autovacuum.c memory handling

Michael Paquier writes: > I have spent some time looking at your patch and testing it. This > looks sane. A small comment that I have would be to add an assertion > at the top of perform_work_item to be sure that it is called in the > memory context of AutovacMemCxt.

Re: [HACKERS] Rethinking autovacuum.c memory handling

On 9/23/17, 5:27 AM, "Michael Paquier" wrote: >On Sat, Sep 23, 2017 at 6:09 AM, Tom Lane wrote: >> I notice that autovacuum.c calls autovacuum_do_vac_analyze, and >> thereby vacuum(), in TopTransactionContext. This doesn't seem >> like a terribly

Re: [HACKERS] pgbench regression test failure

Fabien COELHO writes: >> [...] After another week of buildfarm runs, we have a few more cases of >> 3 rows of output, and none of more than 3 or less than 1. So I went >> ahead and pushed your patch. I'm still suspicious of these results, but >> we might as well try to

Re: [HACKERS] Built-in plugin for logical decoding output

On 23/09/17 18:42, Euler Taveira wrote: 2017-09-22 19:28 GMT-03:00 Gregory Brail : We have been working on a project that makes extensive use of logical replication for use inside Apigee (which is a very small part of Google): https://github.com/apigee-labs/transicator

Re: [HACKERS] Built-in plugin for logical decoding output

2017-09-22 19:28 GMT-03:00 Gregory Brail : > We have been working on a project that makes extensive use of logical > replication for use inside Apigee (which is a very small part of Google): > > https://github.com/apigee-labs/transicator > > In order to do this, we had to

Re: [HACKERS] user-defined numeric data types triggering ERROR: unsupported type

Tomas Vondra writes: >>> [ scalarineqsel may fall over when used by extension operators ] > What about using two-pronged approach: > 1) fall back to mid bucket in back branches (9.3 - 10) > 2) do something smarter (along the lines you outlined) in PG11 Sure. We

Re: [HACKERS] [BUGS] BUG #14825: enum type: unsafe use?

Andrew Dunstan writes: > On 09/22/2017 11:19 PM, Tom Lane wrote: >> Yeah, I was considering the same thing over dinner, though I'd phrase >> it oppositely: keep a list of enum type OIDs created in the current >> transaction, so that we could whitelist them. This

Re: [HACKERS] user-defined numeric data types triggering ERROR: unsupported type

On 09/21/2017 04:24 PM, Tom Lane wrote: > Tomas Vondra writes: >> [ scalarineqsel may fall over when used by extension operators ] > > I concur with your thought that we could have > ineq_histogram_selectivity fall back to a "mid bucket" default if > it's working

Re: [HACKERS] OpenFile() Permissions Refactor

On 9/13/17 10:26, David Steele wrote: > Here's a new patch based on your review. Where I had a question I made > a choice as described below: I have committed the changes to the file APIs and a fix for the umask save/restore issue. The mkdir changes didn't really inspire me. Replacing mkdir()

Re: [HACKERS] [BUGS] BUG #14825: enum type: unsafe use?

On 09/22/2017 11:19 PM, Tom Lane wrote: > Andrew Dunstan writes: >> On 09/22/2017 05:46 PM, Tom Lane wrote: >>> I'm not sure if that qualifies as a stop-ship problem, but it ain't >>> good, for sure. We need to look at whether we should revert 15bc038f9 >>> or

Re: [HACKERS] brin_summarize_new_values error checking

Fujii Masao wrote: > On Wed, Jan 27, 2016 at 11:56 AM, Fujii Masao wrote: > > On Mon, Jan 25, 2016 at 4:03 PM, Jeff Janes wrote: > >> In reviewing one of my patches[1], Fujii-san has pointed out that I > >> didn't include checks for being in recovery,

Re: [HACKERS] Rethinking autovacuum.c memory handling

Alvaro Herrera wrote: > One idea I just had is to somehow add it to src/test/modules/brin, and > set up the postmaster in that test with autovacuum_naptime=1s. I'll go > check how feasible that is. (By placing it there we could also verify > that the index does indeed contain the index entries

Re: [HACKERS] Rethinking autovacuum.c memory handling

Tom Lane wrote: > I notice that autovacuum.c calls autovacuum_do_vac_analyze, and > thereby vacuum(), in TopTransactionContext. This doesn't seem > like a terribly great idea, because it doesn't correspond to what > happens during a manually-invoked vacuum. TopTransactionContext > will go away

Re: [HACKERS] [Proposal] Make the optimiser aware of partitions ordering

On Fri, Sep 22, 2017 at 11:09 PM, Robert Haas wrote: > During planning, *every* node has a list of pathkeys associated with > it which represent the presumed output ordering. You can support > ordered append paths without changing any data structures at all; it's > just a

Re: [HACKERS] Rethinking autovacuum.c memory handling

On Sat, Sep 23, 2017 at 6:09 AM, Tom Lane wrote: > I notice that autovacuum.c calls autovacuum_do_vac_analyze, and > thereby vacuum(), in TopTransactionContext. This doesn't seem > like a terribly great idea, because it doesn't correspond to what > happens during a

Re: [HACKERS] Small improvement to compactify_tuples

Hello, Claudio. Thank you for review and confirm of improvement. On 2017-09-23 01:12, Claudio Freire wrote: On Tue, Sep 12, 2017 at 12:49 PM, Sokolov Yura wrote: On 2017-07-21 13:49, Sokolov Yura wrote: On 2017-05-17 17:46, Sokolov Yura wrote: Alvaro Herrera