Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Sat, Mar 18, 2017 at 5:40 AM, Robert Haas wrote: > On Fri, Mar 17, 2017 at 9:15 AM, Ashutosh Bapat > wrote: >> This set of patches fixes both of those things. > > 0001 changes the purpose of a function and then 0007 renames it. It >

[HACKERS] Re: Improve OR conditions on joined columns (common star schema problem)

On 3/16/17 11:54 AM, David Steele wrote: On 2/14/17 4:03 PM, Tom Lane wrote: Jim Nasby writes: On 2/14/17 1:18 PM, Tom Lane wrote: One point that could use further review is whether the de-duplication algorithm is actually correct. I'm only about 95% convinced by

Re: [HACKERS] PinBuffer() no longer makes use of strategy

On 3/16/17 12:48 PM, David Steele wrote: This patch looks pretty straight forward and applies cleanly and compiles at cccbdde. It's not a straight revert, though, so still seems to need review. Jim, do you know when you'll have a chance to look at that? Yes. Compiles and passes for me as

Re: [HACKERS] background sessions

On 15/03/17 17:58, Robert Haas wrote: > On Wed, Mar 15, 2017 at 6:43 AM, Pavel Stehule > wrote: >> I don't understand - CHECK_FOR_INTERRUPTS called from executor implicitly. > > True. So there shouldn't be any problem here. I'm confused as can be > about what you want

Re: [HACKERS] createlang/droplang deprecated

Magnus Hagander writes: >> 2017-03-18 14:00 GMT+01:00 Peter Eisentraut >> : >>> I just noticed that createlang and droplang have been listed as >>> deprecated since PG 9.1. >>> Do we dare remove them? > (I'd extend it to all the

Re: [HACKERS] logical replication apply to run with sync commit off by default

On 07/03/17 06:23, Petr Jelinek wrote: > Hi, > > there has been discussion at the logical replication initial copy thread > [1] about making apply work with sync commit off by default for > performance reasons and adding option to change that per subscription. > > Here I propose patch to

[HACKERS] Re: [COMMITTERS] pgsql: Add TAP tests for password-based authentication methods.

On Fri, Mar 17, 2017 at 6:37 PM, Heikki Linnakangas wrote: > Add TAP tests for password-based authentication methods. > > Tests all combinations of users with MD5, plaintext and SCRAM verifiers > stored in pg_authid, with plain 'password', 'md5' and 'scram' >

[HACKERS] createlang/droplang deprecated

I just noticed that createlang and droplang have been listed as deprecated since PG 9.1. Do we dare remove them? -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list

Re: [HACKERS] logical replication access control patches

Hi, I went over this patch set, don't really have all that much to say except it looks good for the most part (details inline). On 16/03/17 02:54, Peter Eisentraut wrote: > New patch set based on the discussions. I have dropped the PUBLICATION > privilege patch. The patches are also reordered

Re: [HACKERS] createlang/droplang deprecated

2017-03-18 14:00 GMT+01:00 Peter Eisentraut < peter.eisentr...@2ndquadrant.com>: > I just noticed that createlang and droplang have been listed as > deprecated since PG 9.1. > > Do we dare remove them? > +1 Pavel > > -- > Peter Eisentraut http://www.2ndQuadrant.com/ > PostgreSQL

Re: [HACKERS] createlang/droplang deprecated

On Sat, Mar 18, 2017 at 3:09 PM, Pavel Stehule wrote: > > > 2017-03-18 14:00 GMT+01:00 Peter Eisentraut com>: > >> I just noticed that createlang and droplang have been listed as >> deprecated since PG 9.1. >> >> Do we dare remove them?

Re: [HACKERS] Allow interrupts on waiting standby

Michael Paquier writes: > Both things are fixed in the new version attached. I have added as > well this patch to the next commit fest: > https://commitfest.postgresql.org/13/977/ Couple of thoughts on this patch --- 1. Shouldn't WaitExceedsMaxStandbyDelay's

[HACKERS] Removing binaries (was: createlang/droplang deprecated)

Magnus Hagander writes: >> 2017-03-18 14:00 GMT+01:00 Peter Eisentraut < peter.eisentr...@2ndquadrant.com>: >>> I just noticed that createlang and droplang have been listed as >>> deprecated since PG 9.1. >>> Do we dare remove them? > (I'd extend it to all the non-prefixed

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

On Fri, Mar 17, 2017 at 2:18 PM, Corey Huinker wrote: > >> > \set x 'arg1 arg2' >> >> > \if false >> > \cmd_that_takes_exactly_two_args :x >> > \endif >> >> Yeah, throwing errors for bad arguments would also need to be suppressed. >> >>

Re: [HACKERS] createlang/droplang deprecated

On Sat, Mar 18, 2017 at 11:29 AM, Tom Lane wrote: > Magnus Hagander writes: >>> 2017-03-18 14:00 GMT+01:00 Peter Eisentraut >>> : I just noticed that createlang and droplang have been listed as deprecated since

Re: [HACKERS] New CORRESPONDING clause design

2017-03-18 19:12 GMT+01:00 Tom Lane : > Pavel Stehule writes: > > 2017-03-18 18:32 GMT+01:00 Tom Lane : > >> I definitely don't see a reason for CORRESPONDING to track locations of > >> name list elements when no other name list

Re: [HACKERS] [PATCH] Use $ parameters as replacement characters for pg_stat_statements

Robert Haas writes: > On Mon, Mar 13, 2017 at 6:05 PM, Tom Lane wrote: >> I wonder if it would improve matters to use $n, but starting with the >> first number after the actual external Param symbols in the query. > That sounds pretty sensible,

Re: [HACKERS] Other formats in pset like markdown, rst, mediawiki

2017-03-12 19:21 GMT+01:00 Jan Michálek : > > > 2017-03-10 9:43 GMT+01:00 Jan Michálek : > >> >> >> 2017-03-09 20:10 GMT+01:00 Peter Eisentraut < >> peter.eisentr...@2ndquadrant.com>: >> >>> This is looking pretty neat. I played around with it a

Re: [HACKERS] free space map and visibility map

On Fri, Mar 17, 2017 at 9:37 PM, Jeff Janes wrote: > With some intensive crash-recovery testing, I've run into a situation where > I get some bad table bloat. There will be large swaths of the table which > are empty (all results from heap_page_items other than lp are

Re: [HACKERS] [PATCH] SortSupport for macaddr type

On Tue, Mar 14, 2017 at 3:25 AM, Heikki Linnakangas wrote: > Looks straightforward at a quick read-through. I have just a couple of > questions. How much of the performance gain comes from avoiding the > FunctionCallInvoke overhead, by simply having SortSupport with a comparison

[HACKERS] Re: new set of psql patches for loading (saving) data from (to) text, binary files

Hi > > > There's a whitespace-only hunk that shouldn't be included. > > > > > > I don't agree with the single-column/single-row restriction on these. > I > > > can certainly see a case where someone might want to, say, dump out a > > > bunch of binary integers into a file for later processing. >

Re: [HACKERS] Removing binaries (was: createlang/droplang deprecated)

Magnus Hagander writes: > createuser, dropuser - definitely pollutes the namespace, people do > sometimes try them for the wrong thing. Unlike the db ones they do add > value though -- I don't think we have a psql way of in a single command > doing what --pwprompt on

Re: [HACKERS] free space map and visibility map

On Sat, Mar 18, 2017 at 2:09 PM, Masahiko Sawada wrote: > On Fri, Mar 17, 2017 at 9:37 PM, Jeff Janes wrote: > > With some intensive crash-recovery testing, I've run into a situation > where > > I get some bad table bloat. There will be large swaths

Re: [HACKERS] background sessions

On Sat, Mar 18, 2017 at 10:59 AM, Petr Jelinek wrote: >> shm_redirect_to_shm_mq() wasn't really designed to be used this way; >> it's designed for use by the worker, not the process that launched it. >> If an error occurs while output is redirected, bad things will

Re: [HACKERS] New CORRESPONDING clause design

2017-03-18 18:32 GMT+01:00 Tom Lane : > Pavel Stehule writes: > > 2017-03-18 17:50 GMT+01:00 Tom Lane : > >> I'm not impressed by using A_Const for the members of the CORRESPONDING > >> name list. That's not a clever solution,

Re: [HACKERS] wait events for disk I/O

On Sat, Mar 18, 2017 at 5:15 PM, Robert Haas wrote: > On Fri, Mar 17, 2017 at 10:01 AM, Rushabh Lathia > wrote: > > I tried to cover all the suggestion in the attached latest patch. > > Committed. I reworded the documentation entries, renamed a

Re: [HACKERS] Composite IS NULL again, this time with plpgsql

Andrew Gierth writes: > This obviously happens because plpgsql is storing the variable as an > expanded list of fields rather than as a single composite datum, and > rebuilding the datum value when it needs to be passed to SQL for > evaluation. Without an "isnull"

Re: [HACKERS] New CORRESPONDING clause design

2017-03-18 17:50 GMT+01:00 Tom Lane : > Pavel Stehule writes: > > I have not any objection - I'll mark this patch as ready for commiter > > I took a quick look through this and noted that it fails to touch > ruleutils.c, which means that dumping of

Re: [HACKERS] New CORRESPONDING clause design

Pavel Stehule writes: > 2017-03-18 18:32 GMT+01:00 Tom Lane : >> I definitely don't see a reason for CORRESPONDING to track locations of >> name list elements when no other name list productions do. It might be >> worth proposing a followon patch to

[HACKERS] Composite IS NULL again, this time with plpgsql

This came up recently on irc: create type t1 as (a integer, b integer); create type t2 as (p t1, q t1); create function null_t2() returns t2 language sql as $f$ select null::t2; $f$; Now consider the following plpgsql: declare v t2; begin v := null_t2(); raise info 'v is null = %', v is

Re: [HACKERS] [POC] A better way to expand hash indexes.

On Thu, Mar 16, 2017 at 10:55 PM, David Steele wrote: > It does apply with fuzz on 2b32ac2, so it looks like c11453c and > subsequent commits are the cause. They represent a fairly substantial > change to hash indexes by introducing WAL logging so I think you should >

Re: [HACKERS] New CORRESPONDING clause design

Pavel Stehule writes: > 2017-03-18 17:50 GMT+01:00 Tom Lane : >> I'm not impressed by using A_Const for the members of the CORRESPONDING >> name list. That's not a clever solution, that's a confusing kluge, >> because it's a complete violation of the

Re: [HACKERS] [PATCH v1] Add and report the new "in_hot_standby" GUC pseudo-variable.

On Saturday, March 18, 2017 3:33:16 AM EDT Michael Paquier wrote: > On Sat, Mar 18, 2017 at 2:56 AM, Elvis Pranskevichus wrote: > > Currently, clients wishing to know when the server exits hot standby > > have to resort to polling, which is often suboptimal. > > > > This adds

Re: [HACKERS] mat views stats

Jim Mlodgenski writes: > After digging into things further, just making refresh report the stats > for what is it basically doing simplifies and solves it and it is > something we can back patch if that the consensus. See the attached > patch. I've pushed this into HEAD with

Re: [HACKERS] New CORRESPONDING clause design

Pavel Stehule writes: > I have not any objection - I'll mark this patch as ready for commiter I took a quick look through this and noted that it fails to touch ruleutils.c, which means that dumping of views containing CORRESPONDING certainly doesn't work. Also, the

Re: [HACKERS] Renaming of pg_xlog and pg_clog

On Fri, Mar 17, 2017 at 11:03 PM, Michael Paquier wrote: > On Fri, Mar 17, 2017 at 10:58 PM, Robert Haas wrote: >> Fine! I've committed the pg_clog renaming, but I'd really like to >> draw the line here. I'm not going to commit the pg_subtrans

Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan

On 16/03/17 17:15, David Steele wrote: > On 2/1/17 3:59 PM, Pavel Stehule wrote: >> Hi >> >> 2017-01-24 21:33 GMT+01:00 Pavel Stehule > >: >> >> Perhaps that's as simple as renaming all the existing _ns_* >>

Re: [HACKERS] PATCH: Configurable file mode mask

On Wed, Mar 15, 2017 at 3:00 AM, Tsunakawa, Takayuki wrote: > I'm on David's side, too. I don't postmaster to always scan all files at > startup. +1. Even just doing it during crash recovery, it can take a regrettably long time on machines with tons of

Re: [HACKERS] createlang/droplang deprecated

On Sat, Mar 18, 2017 at 6:13 PM, Robert Haas wrote: > On Sat, Mar 18, 2017 at 11:29 AM, Tom Lane wrote: > > Magnus Hagander writes: > >>> 2017-03-18 14:00 GMT+01:00 Peter Eisentraut < > peter.eisentr...@2ndquadrant.com>: > I

Re: [HACKERS] [PATCH] SortSupport for macaddr type

On Sat, Mar 18, 2017 at 2:54 PM, Peter Geoghegan wrote: > This seems fine to me, especially > because it lets us compare macaddr using simple 3-way unsigned int > comparisons, which isn't otherwise the case. Out of idle curiosity, I decided to generate disassembly of both

Re: [HACKERS] pageinspect and hash indexes

On Sat, Mar 18, 2017 at 1:34 PM, Amit Kapila wrote: > On Sat, Mar 18, 2017 at 12:12 AM, Ashutosh Sharma > wrote: >> On Fri, Mar 17, 2017 at 10:54 PM, Jeff Janes wrote: >>> While trying to figure out some bloating in the

Re: [HACKERS] wait events for disk I/O

On Fri, Mar 17, 2017 at 10:01 AM, Rushabh Lathia wrote: > I tried to cover all the suggestion in the attached latest patch. Committed. I reworded the documentation entries, renamed a few of the wait events to make things more consistent, put all three lists in rigorous

Re: [HACKERS] ANALYZE command progress checker

Hi Vinayak, Here are couple of review comments that may need your attention. 1. Firstly, I am seeing some trailing whitespace errors when trying to apply your v3 patch using git apply command. [ashu@localhost postgresql]$ git apply pg_stat_progress_analyze_v3.patch

Re: [HACKERS] [PATCH v1] Add and report the new "in_hot_standby" GUC pseudo-variable.

On Sat, Mar 18, 2017 at 2:56 AM, Elvis Pranskevichus wrote: > Currently, clients wishing to know when the server exits hot standby > have to resort to polling, which is often suboptimal. > > This adds the new "in_hot_standby" GUC variable that is reported via a >

Re: [HACKERS] pageinspect and hash indexes

On Sat, Mar 18, 2017 at 12:12 AM, Ashutosh Sharma wrote: > On Fri, Mar 17, 2017 at 10:54 PM, Jeff Janes wrote: >> While trying to figure out some bloating in the newly logged hash indexes, >> I'm looking into the type of each page in the index. But I

Re: [HACKERS] pageinspect and hash indexes

On Sat, Mar 18, 2017 at 1:42 AM, Tom Lane wrote: > Ashutosh Sharma writes: >> Basically, when we started working on WAL for hash index, we found >> that WAL routine 'XLogReadBufferExtended' does not expect a page to be >> completely zero page else it

Re: [HACKERS] Microvacuum support for Hash Index

On Fri, Mar 17, 2017 at 8:34 PM, Ashutosh Sharma wrote: > On Fri, Mar 17, 2017 at 6:13 PM, Amit Kapila wrote: >> On Fri, Mar 17, 2017 at 12:27 PM, Ashutosh Sharma >> wrote: >>> On Fri, Mar 17, 2017 at 8:20 AM, Amit Kapila

Re: [HACKERS] Patch to improve performance of replay of AccessExclusiveLock

On 16 March 2017 at 09:52, David Rowley wrote: > I was just trying to verify if it was going to do the correct thing in > regards to subtransactions and I got a little confused at the comments at > the top of StandbyAcquireAccessExclusiveLock(): > > * We record the

Re: [HACKERS] Patch to improve performance of replay of AccessExclusiveLock

On 16 March 2017 at 19:08, Amit Kapila wrote: > On Thu, Mar 16, 2017 at 6:01 AM, Simon Riggs wrote: >> On 8 March 2017 at 10:02, David Rowley wrote: >>> On 8 March 2017 at 01:13, Simon Riggs

Re: [HACKERS] Patch to improve performance of replay of AccessExclusiveLock

On 16 March 2017 at 09:52, David Rowley wrote: >> Seemed easier to write it than explain further. Please see what you think. > > > Thanks. I had been looking for some struct to store the flag in. I'd not > considered just adding a new global variable. As Amit says,

Re: [HACKERS] Two phase commit in ECPG

> Yes. I added two-phase commit test to "make check" test schedule > while > adding new two type of test. Thank you, committed. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes