Re: [HACKERS] pg_stop_backup(wait_for_archive := true) on standby server

On Tue, Jul 18, 2017 at 1:28 PM, Stephen Frost wrote: > Masahiko, Michael, > > * Masahiko Sawada (sawada.m...@gmail.com) wrote: >> > This is beginning to shape. >> >> Sorry, I missed lots of typo in the last patch. All comments from you >> are incorporated into the attached latest patch and I've c

Re: [HACKERS] Patch: Add --no-comments to skip COMMENTs with pg_dump

On Tue, Jul 18, 2017 at 3:45 AM, David Fetter wrote: > The one I run into frequently is in a proprietary fork, RDS Postgres. > It'll happily dump out COMMENT ON EXTENSION plpgsq IS ... > which is great as far as it goes, but errors out when you try to > reload it. > > While bending over backwards

Re: [HACKERS] hash index on unlogged tables doesn't behave as expected

On Tue, Jul 18, 2017 at 4:18 AM, Amit Kapila wrote: > Thanks. Do you have any suggestion for back-branches? As of now, it > fails badly with below kind of error: > > test=> SELECT * FROM t_u_hash; > ERROR: could not open file "base/16384/16392": No such file or directory > > It is explained in

Re: [HACKERS] New partitioning - some feedback

On 07/07/2017 02:02 AM, Mark Kirkwood wrote: > I'd prefer *not* to see a table and its partitions all intermixed in the > same display (especially with nothing indicating which are partitions) - > as this will make for unwieldy long lists when tables have many > partitions. Also it would be good if

Re: [HACKERS] pg_stop_backup(wait_for_archive := true) on standby server

Masahiko, Michael, * Masahiko Sawada (sawada.m...@gmail.com) wrote: > > This is beginning to shape. > > Sorry, I missed lots of typo in the last patch. All comments from you > are incorporated into the attached latest patch and I've checked it > whether there is other typos. Please review it. I'

Re: [HACKERS] hash index on unlogged tables doesn't behave as expected

On Mon, Jul 17, 2017 at 10:21 PM, Michael Paquier wrote: > On Mon, Jul 17, 2017 at 6:02 PM, Robert Haas wrote: >> It seems to me that this area might benefit from a broader rethink. >> It's not very nice to impose a restriction that init forks can only be >> constructed using log_newpage(); on th

[HACKERS] Re: Oddity in error handling of constraint violation in ExecConstraints for partitioned tables

On Mon, Jul 10, 2017 at 5:44 PM, Robert Haas wrote: > The posted patches look OK to me. Barring developments, I will commit > them on 2017-07-17, or send another update by then. Committed them. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sen

Re: [HACKERS] Patch: Add --no-comments to skip COMMENTs with pg_dump

On Thu, Jun 01, 2017 at 10:05:09PM -0400, Tom Lane wrote: > Robert Haas writes: > > On Tue, May 30, 2017 at 8:55 PM, David G. Johnston > > wrote: > >>> Having --no-comments seems generally useful to me, in any case. > > >> It smacks of being excessive to me. > > > It sounds perfectly sensible t

Re: [HACKERS] Something for the TODO list: deprecating abstime and friends

> On Jul 17, 2017, at 3:12 PM, Tom Lane wrote: > > Mark Dilger writes: >>> On Jul 17, 2017, at 2:14 PM, Tom Lane wrote: >>> Well, if you or somebody is willing to do the legwork, I'd be on board >>> with a plan that says that every 68 years we redefine the origin of >>> abstime. I imagine it

Re: [HACKERS] GSoC 2017: Foreign Key Arrays

There is a generic definition for any array added as part of https://commitfest.postgresql.org/10/708/ (it may be the reason for the duplicate error). I am not sure what your change is but I would review the above just in case. There is also a defect with a misleading error that is still being trig

Re: [HACKERS] Pluggable storage

On Mon, Jul 17, 2017 at 1:24 PM, Alexander Korotkov wrote: > It's probably depends on particular storage (once we have pluggable > storages). Some storages would have additional level of indirection while > others wouldn't. Agreed. Like kill_prior_tuple, it's an optional capability, and where im

Re: [HACKERS] GSoC 2017: Foreign Key Arrays

On Wed, Jul 12, 2017 at 12:53 AM, Alvaro Herrera wrote: > > We have one opclass for each type combination -- int4 to int2, int4 to > int4, int4 to int8, etc. You just need to add the new strategy to all > the opclasses. I tried this approach by manually declaring the operator multiple of time

Re: [HACKERS] Something for the TODO list: deprecating abstime and friends

> On Jul 17, 2017, at 3:56 PM, Tom Lane wrote: > > Mark Dilger writes: >> On Jul 17, 2017, at 3:12 PM, Tom Lane wrote: >>> Now, this should mostly work conveniently, except that we have >>> +/-infinity (NOEND_ABSTIME/NOSTART_ABSTIME) to deal with ... It might >>> be saner to just desupport +/-

Re: [HACKERS] Something for the TODO list: deprecating abstime and friends

Mark Dilger writes: > On Jul 17, 2017, at 3:12 PM, Tom Lane wrote: >> Now, this should mostly work conveniently, except that we have >> +/-infinity (NOEND_ABSTIME/NOSTART_ABSTIME) to deal with ... It might >> be saner to just desupport +/-infinity for abstime. > I don't use those values, so it i

Re: [HACKERS] Something for the TODO list: deprecating abstime and friends

> On Jul 17, 2017, at 3:12 PM, Tom Lane wrote: > > Mark Dilger writes: >>> On Jul 17, 2017, at 2:14 PM, Tom Lane wrote: >>> Well, if you or somebody is willing to do the legwork, I'd be on board >>> with a plan that says that every 68 years we redefine the origin of >>> abstime. I imagine it

Re: [HACKERS] Patch: Add --no-comments to skip COMMENTs with pg_dump

The following review has been posted through the commitfest application: make installcheck-world: not tested Implements feature: tested, passed Spec compliant: not tested Documentation:tested, passed It's a very simple change and I have not to complain about source and

Re: [HACKERS] Something for the TODO list: deprecating abstime and friends

Mark Dilger writes: >> On Jul 17, 2017, at 2:14 PM, Tom Lane wrote: >> Well, if you or somebody is willing to do the legwork, I'd be on board >> with a plan that says that every 68 years we redefine the origin of >> abstime. I imagine it could be done so that currently-stored abstime >> values r

Re: [HACKERS] Something for the TODO list: deprecating abstime and friends

> On Jul 17, 2017, at 2:14 PM, Tom Lane wrote: > > Mark Dilger writes: >>> On Jul 17, 2017, at 12:54 PM, Mark Dilger wrote: >> On Jul 15, 2017, at 3:00 PM, Tom Lane wrote: The types abstime, reltime, and tinterval need to go away, or be reimplemented, sometime well before 2038 when

Re: [HACKERS] Something for the TODO list: deprecating abstime and friends

Mark Dilger writes: >> On Jul 17, 2017, at 12:54 PM, Mark Dilger wrote: > On Jul 15, 2017, at 3:00 PM, Tom Lane wrote: >>> The types abstime, reltime, and tinterval need to go away, or be >>> reimplemented, sometime well before 2038 when they will overflow. >> These types provide a 4-byte datat

Re: [HACKERS] segfault in HEAD when too many nested functions call

On 17/07/2017 16:57, Andres Freund wrote: > The latter obviously isn't ready, but might make clearer what I'm > thinking about. It did for me, and FWIW I like this approach. > If we were to go this route we'd have to probably move > the callback assignment into the ExecInit* routines, and possibl

Re: [HACKERS] Pluggable storage

On Mon, Jul 17, 2017 at 7:51 PM, Peter Geoghegan wrote: > On Mon, Jul 17, 2017 at 3:22 AM, Alexander Korotkov > wrote: > > I think that "retail index tuple deletion" is the feature which could > give > > us some advantages even independently from pluggable storages. For > example, > > imagine v

Re: [HACKERS] Something for the TODO list: deprecating abstime and friends

> On Jul 17, 2017, at 12:54 PM, Mark Dilger wrote: > > >> On Jul 15, 2017, at 3:00 PM, Tom Lane wrote: >> >> The types abstime, reltime, and tinterval need to go away, or be >> reimplemented, sometime well before 2038 when they will overflow. >> It's not too soon to start having a plan for th

Re: [HACKERS] PgFDW connection invalidation by ALTER SERVER/ALTER USER MAPPING

Kyotaro HORIGUCHI writes: > This is the revased and revised version of the previous patch. A few more comments: * Per the spec for CacheRegisterSyscacheCallback, a zero hash value means to flush all associated state. This isn't handling that case correctly. Even when you are given a specific ha

Re: [HACKERS] Something for the TODO list: deprecating abstime and friends

> On Jul 15, 2017, at 3:00 PM, Tom Lane wrote: > > The types abstime, reltime, and tinterval need to go away, or be > reimplemented, sometime well before 2038 when they will overflow. > It's not too soon to start having a plan for that, especially seeing > that it seems to take a decade or more

Re: [HACKERS] Why have we got both largeobject and large_object test files?

Stephen Frost writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> I happened to notice that the regression tests contain both >> largeobject.sql and large_object.sql. This seems at best confusing and at >> worst a source of mistakes. The second file was added in March by commit >> ff992c074, has

Re: [HACKERS] More flexible LDAP auth search filters?

On Mon, Jul 17, 2017 at 6:47 PM, Mark Cave-Ayland < mark.cave-ayl...@ilande.co.uk> wrote: > On 17/07/17 13:09, Magnus Hagander wrote: > > Hi Magnus, > > Great to hear from you! It has definitely been a while... > Indeed. You should spend more time on these lists :P > > > Generally you find

Re: [HACKERS] Why have we got both largeobject and large_object test files?

Tom, * Tom Lane (t...@sss.pgh.pa.us) wrote: > I happened to notice that the regression tests contain both > largeobject.sql and large_object.sql. This seems at best confusing and at > worst a source of mistakes. The second file was added in March by commit > ff992c074, has never been touched by

Re: [HACKERS] Pluggable storage

On Mon, Jul 17, 2017 at 3:22 AM, Alexander Korotkov wrote: > I think that "retail index tuple deletion" is the feature which could give > us some advantages even independently from pluggable storages. For example, > imagine very large table with only small amount of dead tuples. In this > case,

Re: [HACKERS] hash index on unlogged tables doesn't behave as expected

On Mon, Jul 17, 2017 at 6:02 PM, Robert Haas wrote: > It seems to me that this area might benefit from a broader rethink. > It's not very nice to impose a restriction that init forks can only be > constructed using log_newpage(); on the other hand, it is also not > very nice that Amit's patch need

Re: [HACKERS] More flexible LDAP auth search filters?

On 17/07/17 13:09, Magnus Hagander wrote: Hi Magnus, Great to hear from you! It has definitely been a while... > Generally you find that you will be given the option to set the > attribute for the default search filter of the form > "(attribute=username)" which defaults to uid for UN

Re: [HACKERS] Multi column range partition table

On 17 July 2017 at 16:34, Robert Haas wrote: > On Sun, Jul 16, 2017 at 6:40 AM, Dean Rasheed > wrote: >> Technically, anything that can be done using INCLUSIVE/EXCLUSIVE can >> also be done using using MINVALUE/MAXVALUE, by artificially adding >> another partitioning column and making it unbound

Re: [HACKERS] Something for the TODO list: deprecating abstime and friends

On Mon, Jul 17, 2017 at 11:37 AM, Michael Paquier wrote: > Exactly, having an exact deprecation policy would be nice. Of course > this depends on the feature we are talking about. pg_dump for example > supports servers older than what community still supports. But in most > cases, like in core dat

Re: [HACKERS] hash index on unlogged tables doesn't behave as expected

On Sat, Jul 15, 2017 at 4:25 AM, Michael Paquier wrote: > On Sat, Jul 15, 2017 at 6:27 AM, Ashutosh Sharma > wrote: >> I do agree with Amit. I think hash index is slightly trickier (in >> terms of how it is organised) than other indexes and that could be the >> reason for maintaining common code

[HACKERS] Why have we got both largeobject and large_object test files?

I happened to notice that the regression tests contain both largeobject.sql and large_object.sql. This seems at best confusing and at worst a source of mistakes. The second file was added in March by commit ff992c074, has never been touched by any other commit, and is only 8 lines long. Was ther

Re: [HACKERS] Unportable use of select for timeouts in PostgresNode.pm

Andrew Dunstan writes: > I've been trying to get to the bottom of a nasty hang in buildfarm > member jacana when running the pg_ctl TAP test. This test used to work, > and was last known to work on June 22nd. > My attention has become focussed on this change in commit de3de0afd: > - #

Re: [HACKERS] Something for the TODO list: deprecating abstime and friends

On Sun, Jul 16, 2017 at 10:27 PM, Greg Stark wrote: > On 15 July 2017 at 23:00, Tom Lane wrote: > >> While it's too late in the v10 cycle to do anything very meaningful >> about this now, I am tempted to strengthen the deprecation notice's >> wording from "might disappear" to "will disappear". >

Re: [HACKERS] Multi column range partition table

On Sun, Jul 16, 2017 at 6:40 AM, Dean Rasheed wrote: > Technically, anything that can be done using INCLUSIVE/EXCLUSIVE can > also be done using using MINVALUE/MAXVALUE, by artificially adding > another partitioning column and making it unbounded above/below, but > that would really just be a hack

Re: [HACKERS] AdvanceXLInsertBuffer vs. WAL segment compressibility

On Thu, Jul 6, 2017 at 3:48 PM, Heikki Linnakangas wrote: > On 07/03/2017 06:30 PM, Chapman Flack wrote: >> Although it's moot in the straightforward approach of re-zeroing in >> the loop, it would still help my understanding of the system to know >> if there is some subtlety that would have broke

Re: [HACKERS] Something for the TODO list: deprecating abstime and friends

On Sun, Jul 16, 2017 at 1:03 PM, Tom Lane wrote: > Or in other words, I don't want to go from > "might disappear" in vN to gone in vN+1 with no intermediate state. I see no problem with that. First, we remove things all the time with no deprecation warning at all when we judge that they are dead

Re: [HACKERS] Unportable use of select for timeouts in PostgresNode.pm

On Mon, Jul 17, 2017 at 4:48 PM, Andrew Dunstan wrote: > This is a usage that is known not to work in Windows - IIRC we > eliminated such calls from our C programs at the time of the Windows > port - and it seems to me very likely to be the cause of the hang. > Instead I think we should use the us

Re: [HACKERS] AdvanceXLInsertBuffer vs. WAL segment compressibility

On Fri, Jun 23, 2017 at 6:08 AM, Chapman Flack wrote: > Well, gzip was doing pretty well; it could get a 16 MB segment file down > to under 27 kB, or less than 14 bytes for each of 2000 pages, when a page > header is what, 20 bytes, it looks like? I'm not sure how much better > I'd expect a (non-c

Re: [HACKERS] segfault in HEAD when too many nested functions call

Hi, On 2017-07-17 00:26:29 -0700, Andres Freund wrote: > I'm less convinced of that, due to the overhead argument. I think > there's a couple ways around that however: > > 1) We could move ExecProcNode() to be callback based. The first time a >node is executed a "wrapper" function is called

[HACKERS] Unportable use of select for timeouts in PostgresNode.pm

I've been trying to get to the bottom of a nasty hang in buildfarm member jacana when running the pg_ctl TAP test. This test used to work, and was last known to work on June 22nd. My attention has become focussed on this change in commit de3de0afd: - # Wait a second before retrying.

Re: [HACKERS] pg_restore failed for foreign key constraint

Neha Sharma writes: > I am getting the below error while restoring data having foreign key > constraint. > [edb@localhost bin]$ ./createdb test1 > [edb@localhost bin]$ ./pg_restore -d test1 -c -e a.dump > pg_restore: [archiver (db)] Error while PROCESSING TOC: > pg_restore: [archiver (db)] Error

Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)

Hi, I am attaching a patch for predicate locking in gin index. Regards, Shubham Sent with Mailtrack On 11 July 2017 at 19:10, Shubham Barai wrote: > Project: Exp

Re: [HACKERS] parallelize queries containing initplans

On Tue, Mar 28, 2017 at 7:25 AM, Amit Kapila wrote: > On Thu, Mar 16, 2017 at 2:34 AM, Kuntal Ghosh > wrote: >> On Tue, Mar 14, 2017 at 3:20 PM, Amit Kapila wrote: >>> Based on that idea, I have modified the patch such that it will >>> compute the set of initplans Params that are required below

Re: [HACKERS] More flexible LDAP auth search filters?

On Mon, Jul 17, 2017 at 1:23 AM, Stephen Frost wrote: > > * Magnus Hagander (mag...@hagander.net) wrote: > > On Sun, Jul 16, 2017 at 11:05 PM, Stephen Frost > wrote: > > > I'd suggest that we try to understand why Kerberos couldn't be used in > > > that environment. I suspect in at least some c

Re: [HACKERS] More flexible LDAP auth search filters?

On Sun, Jul 16, 2017 at 7:58 PM, Mark Cave-Ayland < mark.cave-ayl...@ilande.co.uk> wrote: > On 16/07/17 00:08, Thomas Munro wrote: > > > On Fri, Jul 14, 2017 at 11:04 PM, Magnus Hagander > wrote: > >> On Thu, Jul 13, 2017 at 9:31 AM, Thomas Munro > >> wrote: > >>> A post on planet.postgresql.org

Re: [HACKERS] [WIP] Zipfian distribution in pgbench

Hello, Is this bias expected from the drawing method, say because it is approximated and the approximation is weak at some points, or is there an issue with its implementation, says some shift which gets smoothed down for higher indexes? I have checked paper where such implementation was pr

Re: [HACKERS] [WIP] Zipfian distribution in pgbench

> On 17 Jul 2017, at 13:51, Fabien COELHO wrote: > > > Is this bias expected from the drawing method, say because it is approximated > and the approximation is weak at some points, or is there an issue with its > implementation, says some shift which gets smoothed down for higher indexes? >

Re: [HACKERS] [WIP] Zipfian distribution in pgbench

Ok, so you did not get the large bias for i=3. Strange. I got large bias for i=3 and theta > 1 even with a million outcomes, Ok. So this is similar to what I got. Is this bias expected from the drawing method, say because it is approximated and the approximation is weak at some points, or

Re: [HACKERS] 10beta1/m68k: static assertion failed: "MAXALIGN too small to fit int32"

Re: Heikki Linnakangas 2017-05-18 <5b9085c2-2c18-e5e3-c340-c07d11a9c...@iki.fi> > > Please go ahead, I don't think I have online access to a m68k machine. > > (It got demoted to an unofficial port some time ago and the old Debian > > porter machines got taken down). > > Ok, pushed, let's see if th

[HACKERS] pg_restore failed for foreign key constraint

Hi, I am getting the below error while restoring data having foreign key constraint. ./psql postgres psql (10beta2) Type "help" for help. postgres=# create user test; CREATE ROLE postgres=# create schema test; CREATE SCHEMA postgres=# grant all on SCHEMA test to test; GRANT postgres=# set search

Re: [HACKERS] [WIP] Zipfian distribution in pgbench

Hello Fabien,On 14 Jul 2017, at 17:51, Fabien COELHO wrote:Ok, so you did not get the large bias for i=3. Strange.I got large bias for i=3 and theta > 1 even with a million outcomes, but for theta < 1 (I have tested on theta = 0.1 and 0.3) it showed quite good results.I am att

Re: [HACKERS] Pluggable storage

On Sun, Jul 16, 2017 at 3:58 AM, Peter Geoghegan wrote: > I strongly agree. I simply don't understand how you can adopt UNDO for > MVCC, and yet expect to get a benefit commensurate with the effort > without also implementing "retail index tuple deletion" first. > Pursuing UNDO this way has the s

Re: [HACKERS] segfault in HEAD when too many nested functions call

Hi, On 2017-07-15 11:22:37 -0400, Tom Lane wrote: > The thread drifted off without any resolution, but clearly we need to > do something before 10.0 final. We need to do something, I'm less convinced that it's really v10 specific :/ > "SELECT so()" has a nontrivial targetlist so we end up runni