Re: [HACKERS] Extracting fields from 'infinity'::TIMESTAMP[TZ]

On 17.11.2015 09:09, Vitaly Burovoy wrote: I suppose behavior of monotonic values (julian, century, decade, isoyear, millennium and year) should be the same as for epoch (which obviously also monotonic value). Proposed patch has that behavior: +/-infinity for epoch, julian, century, decade,

Re: [HACKERS] proposal: multiple psql option -c

On Tue, Nov 17, 2015 at 10:13 PM, Tom Lane wrote: > 1. -c no longer implies --no-psqlrc. That's a backwards incompatibility, > but very easy to explain and very easy to work around. > > 2. You can have multiple -c and/or -f. Each -c is processed in > the traditional way, ie,

Re: CustomScan in a larger structure (RE: [HACKERS] CustomScan support on readfuncs.c)

On Mon, Nov 16, 2015 at 9:03 PM, Kouhei Kaigai wrote: > I guess we will put a pointer to static ExtensibleNodeMethods structure > on ForeignScan, CustomScan, CustomScanState and etc... I think that makes it confusing. What I'd prefer to do is have only the name stored in

Re: [HACKERS] Parallel Seq Scan

On Wed, Nov 18, 2015 at 12:48 AM, Amit Kapila wrote: >> I suggest that we instead fix ExecParallelFinish() to be idempotent. >> Add a "bool finished" flag to ParallelExecutorInfo and return at once >> if it's already set. Get rid of the exposed >>

Re: [HACKERS] [DESIGN] ParallelAppend

On Tue, Nov 17, 2015 at 4:59 PM, Thom Brown wrote: > On 17 November 2015 at 20:08, Robert Haas wrote: >> On Tue, Nov 17, 2015 at 4:26 AM, Thom Brown wrote: >> >>> However, the first parallel seq scan shows it getting 170314 rows. >>>

Re: [HACKERS] Bug in numeric multiplication

Dean Rasheed writes: > On 17 November 2015 at 23:57, Tom Lane wrote: >> I'm not sure that it's provably okay though. The loose ends are to show >> that div[qi] can't overflow an int during the divisor-subtraction step >> and that "outercarry"

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

Hi, I just started looking this over a bit. The first thing I noticed is that it adds a dependency on Archive::Tar which isn't already used anywhere else. Did anybody check whether this exists back in 5.8 installations? Why is "recovery" added to ALWAYS_SUBDIRS in src/test/Makefile instead of

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On 2015-11-18 16:21, Alvaro Herrera wrote: Hi, I just started looking this over a bit. The first thing I noticed is that it adds a dependency on Archive::Tar which isn't already used anywhere else. Did anybody check whether this exists back in 5.8 installations? Apparently it did not yet

Re: [HACKERS] [DESIGN] ParallelAppend

On Wed, Nov 18, 2015 at 7:25 AM, Amit Kapila wrote: > Don't we need the startup cost incase we need to build partial paths for > joinpaths like mergepath? > Also, I think there are other cases for single relation scan where startup > cost can matter like when there are

Re: [HACKERS] Using quicksort for every external sort run

On Wed, Aug 19, 2015 at 7:24 PM, Peter Geoghegan wrote: Hi Peter, Your most recent versions of this patch series (not the ones on the email I am replying to) give a compiler warning: tuplesort.c: In function 'mergeruns': tuplesort.c:2741: warning: unused variable 'memNowUsed'

Re: [HACKERS] LLVM miscompiles numeric.c access to short numeric var headers

Fwiw it looks like the LLVM folk think this is an asan bug. https://llvm.org/bugs/show_bug.cgi?id=25550 It looks like the fix is that the compiler should avoid this optimization if the code is being compiled with instrumentation. This worries me a bit but I think our code is safe as the Datum

Re: [HACKERS] [PATCH] SQL function to report log message

On Mon, Nov 16, 2015 at 5:41 PM, Peter Eisentraut wrote: > On 11/16/15 5:10 PM, Tom Lane wrote: >> Peter Eisentraut writes: >>> On 11/15/15 9:50 PM, Craig Ringer wrote: I'd prefer to omit fields if explicitly assigned to NULL. You can always use

Re: [HACKERS] pglogical_output - a general purpose logical decoding output plugin

W dniu 12.11.2015, czw o godzinie 22∶23 +0800, użytkownik Craig Ringer napisał: > Hi all > > Here's an updated pglogical_output patch. > > Selected changes since v1: > >     - add json protocol output support >     - fix encoding comparisons to use parsed encoding not string name >     - import

Re: [HACKERS] Freeze avoidance of very large table.

On Tue, Nov 17, 2015 at 10:32 PM, Masahiko Sawada wrote: > > Attached latest v24 patch. > I've changed patch so that just adding frozen bit into visibility map. > So the size of patch is almost half of previous one. > Should there be an Assert in visibilitymap_get_status

Re: [HACKERS] proposal: multiple psql option -c

> 1. -c no longer implies --no-psqlrc. That's a backwards incompatibility, > but very easy to explain and very easy to work around. > > This can be very surprising change. Can we disable it temporary by some environment variable? like NOPSQLRC ? > 2. You can have multiple -c and/or -f. Each

Re: [HACKERS] proposal: multiple psql option -c

Pavel Stehule writes: >> 1. -c no longer implies --no-psqlrc. That's a backwards incompatibility, >> but very easy to explain and very easy to work around. > This can be very surprising change. Can we disable it temporary by some > environment variable? like NOPSQLRC ?

Re: [HACKERS] proposal: multiple psql option -c

2015-11-18 21:17 GMT+01:00 Tom Lane : > Pavel Stehule writes: > >> 1. -c no longer implies --no-psqlrc. That's a backwards > incompatibility, > >> but very easy to explain and very easy to work around. > > > This can be very surprising change. Can we

Re: [HACKERS] Minor comment improvement to create_foreignscan_plan

On Tue, Nov 17, 2015 at 9:29 PM, Etsuro Fujita wrote: > On 2015/11/18 2:57, Robert Haas wrote: >> On Sun, Nov 15, 2015 at 9:25 PM, Etsuro Fujita >> wrote: >>> >>> Oops, I've found another one. I think we should update a comment in >>>

Re: [HACKERS] Freeze avoidance of very large table.

On Wed, Nov 18, 2015 at 11:18 AM, Jeff Janes wrote: > > I get an error when running pg_upgrade from 9.4 to 9.6-this > > error while copying relation "mediawiki.archive" > ("/tmp/data/base/16414/21043_vm" to > "/tmp/data_fm/base/16400/21043_vm"): No such file or directory

Re: [HACKERS] Patch: Implement failover on libpq connect level.

On Tue, Nov 17, 2015 at 3:20 PM, Peter Eisentraut wrote: > On 11/6/15 3:59 PM, Robert Haas wrote: >> So, I really wonder why we're not happy with the ability to substitute >> out just the host and IP. > > One of my concerns is that the proposed URLs are not valid URLs anymore >

Re: [HACKERS] proposal: multiple psql option -c

On Wed, Nov 18, 2015 at 3:17 PM, Tom Lane wrote: > Pavel Stehule writes: >>> 1. -c no longer implies --no-psqlrc. That's a backwards incompatibility, >>> but very easy to explain and very easy to work around. > >> This can be very surprising change.

Re: [HACKERS] Additional role attributes && superuser review

On Wed, Nov 18, 2015 at 10:06 PM, Michael Paquier wrote: > > > On Wed, Sep 30, 2015 at 8:11 PM, Stephen Frost wrote: > > * Heikki Linnakangas (hlinn...@iki.fi) wrote: > >> I agree with Robert's earlier point that this needs to be split into > >>

Re: [HACKERS] Additional role attributes && superuser review

On Wed, Sep 30, 2015 at 8:11 PM, Stephen Frost wrote: > * Heikki Linnakangas (hlinn...@iki.fi) wrote: >> I agree with Robert's earlier point that this needs to be split into >> multiple patches, which can then be reviewed and discussed >> separately. Pending that, I'm going to

Re: [HACKERS] [DESIGN] ParallelAppend

On Sat, Nov 14, 2015 at 3:39 AM, Robert Haas wrote: > > On Thu, Nov 12, 2015 at 12:09 AM, Kouhei Kaigai wrote: > > I'm now designing the parallel feature of Append... > > > > Here is one challenge. How do we determine whether each sub-plan > > allows

Re: [HACKERS] Bug in numeric multiplication

On 17 November 2015 at 23:57, Tom Lane wrote: > After thinking some more about what this is doing, it seems to me that > we could avoid changing div[qi + 1] at all here, and instead deal with > leftover dividend digits by shoving them into the floating-point part of > the

Re: [HACKERS] Proposal: "Causal reads" mode for load balancing reads without stale data

Hi, Here is a new version of the patch with a few small improvements: 1. Adopted the term '[read] lease', replacing various hand-wavy language in the comments and code. That seems to be the established term for this approach[1]. 2. Reduced the stalling time on failure. When things go wrong

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Tue, Nov 17, 2015 at 7:52 PM, Kyotaro HORIGUCHI wrote: > Oops. > > At Tue, 17 Nov 2015 19:40:10 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI > wrote in > <20151117.194010.17198448.horiguchi.kyot...@lab.ntt.co.jp> >> Hello,

[HACKERS] Feature or bug: getting "Inf"::timestamp[tz] by "regular" value

Hackers! I'm writing another patch for timestamps and while I tried to cover corner-cases I found out there is an ability to get "Infinity"::timestamptz via defining it by a specific (but not "Infinity") value: postgres=# SELECT '294277-01-09 04:00:54.775806+00'::timestamptz; -- OK

[HACKERS] PostgreSQL super HA (High Availability) conception for 9.5+

Hello, Foreword: Unfortunately, I have no time to read the mailing lists and attend events like PostgreSQL and NoSQL. Some of the ideas came from MongoDB and Cassandra. The inspiration was the pg_rewind. There is little new here, it’s a wish-list put together, considering what could be possible

[HACKERS] SPI and transactions

Hello, SPI was originally developed for execution SQL statements from C user defined functions in context of existed transaction. This is why it is not possible to execute any transaction manipulation statement (BEGIN, COMMIT, PREPARE,...) using SPI_execute:SPI_ERROR_TRANSACTION is returned.

Re: [HACKERS] [COMMITTERS] pgsql: Add pg_audit, an auditing extension

On 10 June 2015 at 14:41, Noah Misch wrote: > On Tue, Jun 09, 2015 at 03:54:59PM -0400, David Steele wrote: >> I've certainly had quite the experience as a first-time contributor >> working on this patch. Perhaps I bit off more than I should have and I >> definitely managed to

Re: [HACKERS] Feature or bug: getting "Inf"::timestamp[tz] by "regular" value

Vitaly Burovoy writes: > I'm writing another patch for timestamps and while I tried to cover > corner-cases I found out there is an ability to get > "Infinity"::timestamptz via defining it by a specific (but not > "Infinity") value: > postgres=# SELECT '294277-01-09

Re: [HACKERS] Using quicksort for every external sort run

On Wed, Nov 18, 2015 at 11:29 PM, Peter Geoghegan wrote: > Other systems expose this explicitly, and, as I said, say in an > unqualified way that a multi-pass merge should be avoided. Maybe the > warning isn't the right way of communicating that message to the DBA > in detail,

Re: [HACKERS] COPY (INSERT/UPDATE/DELETE .. RETURNING ..)

On 2015-11-16 08:24, Michael Paquier wrote: On Sun, Nov 1, 2015 at 2:49 AM, Marko Tiikkaja wrote: Attached is a patch for being able to do $SUBJECT without a CTE. The reasons this is better than a CTE version are: 1) It's not obvious why a CTE version works but a plain one

Re: [HACKERS] Using quicksort for every external sort run

On Wed, Nov 18, 2015 at 6:29 PM, Peter Geoghegan wrote: > In principle, I have no problem with doing that. Through testing, I > cannot see any actual upside, though. Perhaps I just missed something. > Even 8MB is enough to avoid the multipass merge in the event of a >

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Wed, Nov 18, 2015 at 01:21:45PM -0200, Alvaro Herrera wrote: > In my days of Perl, it was starting to become frowned upon to call > subroutines without parenthesizing arguments. Is that no longer the > case? I've not witnessed those frowns. > Because I notice there are many places in this

[HACKERS] Add numeric_trim(numeric)

Hi, Here's a patch for the second function suggested in 5643125e.1030...@joh.to. This is my first patch trying to do anything with numerics, so please be gentle. I'm sure it's full of stupid. January's commit fest, feedback welcome, yada yada.. .m *** a/doc/src/sgml/func.sgml ---

Re: [HACKERS] INSERT ... ON CONFLICT documentation clean-up patch

On 2015-11-10 14:28:16 -0800, Peter Geoghegan wrote: > Attached revision (rebase) of your modified version of my patch (the > modification you provided privately) has the following notable > changes: We might want do a bit further word-smithing, but it does indeed seem better to me this way. As

Re: [HACKERS] Getting sorted data from foreign server for merge join

On Tue, Nov 17, 2015 at 8:33 AM, Ashutosh Bapat wrote: >> Although I'm usually on the side of marking things as extern whenever >> we find it convenient, I'm nervous about doing that to >> make_canonical_pathkey(), because it has side effects. Searching the >>

[HACKERS] Add scale(numeric)

Hi, As suggested in 5643125e.1030...@joh.to, here's a patch for extracting the scale out of a numeric. This is 2016-01 CF material, but if someone wants to bas^H^H^Hsay nice things in the meanwhile, feel free. .m *** a/doc/src/sgml/func.sgml --- b/doc/src/sgml/func.sgml ***

Re: [HACKERS] Trivial heap_finish_speculative() error message inaccuracy

On 2015-11-18 23:50:30 +0100, Andres Freund wrote: > Let's rather rip those function names out. Unless somebody protests I'm > going to do so in 9.5/master. Done. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

[HACKERS] warning: HS_KEY redefined (9.5 beta2)

Google says this was present in beta1. ( http://www.postgresql.org/message-id/5596a162.30...@dunslane.net) Still seems broken, at least for me. Built with Perl 5.22. uname -m = x86_64 uname -r = 2.6.32-504.12.2.el6.x86_64

Re: [HACKERS] Additional role attributes && superuser review

Michael, Thanks for the review! * Michael Paquier (michael.paqu...@gmail.com) wrote: > Patch needs a rebase, some catalog OIDs and there was a conflict in misc.c > (see attached for the rebase. none of the comments mentioning issues are > fixed by it). Done (did it a bit differently from what

Re: [HACKERS] Trivial heap_finish_speculative() error message inaccuracy

On 2015-11-03 19:14:44 -0800, Peter Geoghegan wrote: > On Tue, Nov 3, 2015 at 7:10 PM, Tom Lane wrote: > > This seems like a fine teaching moment in which to point out our > > longstanding error message style guideline that says not to put > > names of C functions into error

Re: [HACKERS] Bug in numeric multiplication

I wrote: > I'm kind of stuck on that too. I did some experimentation by tracking > maximum values of outercarry in the regression tests (including > numeric_big) and did not see it get larger than a couple hundred thousand, > ie more or less INT_MAX/NBASE. But I don't have an argument as to why

Re: [HACKERS] Parallel Seq Scan

On Tue, Nov 17, 2015 at 1:21 AM, Bert wrote: > Hey, > > I've just pulled and compiled the new code. > I'm running a TPC-DS like test on different PostgreSQL installations, but > running (max) 12queries in parallel on a server with 12cores. > I've configured max_parallel_degree

Re: [HACKERS] proposal: LISTEN *

Hi 2015-11-19 4:40 GMT+01:00 Marko Tiikkaja : > Hi, > > I've in the past wanted to listen on all notification channels in the > current database for debugging purposes. But recently I came across > another use case. Since having multiple postgres backends listening for >

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

On 2015/11/19 12:34, Robert Haas wrote: On Tue, Nov 17, 2015 at 9:30 PM, Etsuro Fujita wrote: I suppose you (and KaiGai-san) are probably right, but I really fail to see it actually doing that. Noted, but let's do it that way and move on. It would be a shame if

Re: [HACKERS] Using quicksort for every external sort run

Hi Jeff, On Wed, Nov 18, 2015 at 10:31 AM, Jeff Janes wrote: > tuplesort.c: In function 'mergeruns': > tuplesort.c:2741: warning: unused variable 'memNowUsed' That was caused by a last-minute change to the mulitpass warning message. I forgot to build at -O2, and missed

[HACKERS] proposal: LISTEN *

Hi, I've in the past wanted to listen on all notification channels in the current database for debugging purposes. But recently I came across another use case. Since having multiple postgres backends listening for notifications is very inefficient (one Thursday I found out 30% of our CPU

[HACKERS] Re: [COMMITTERS] pgsql: Improve vcregress.pl's handling of tap tests for client programs

On Thu, Nov 19, 2015 at 12:51 PM, Andrew Dunstan wrote: > Improve vcregress.pl's handling of tap tests for client programs > > The target is now named 'bincheck' rather than 'tapcheck' so that it > reflects what is checked instead of the test mechanism. Some of the > logic

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Thu, Nov 19, 2015 at 12:21 AM, Alvaro Herrera wrote: > > Hi, I just started looking this over a bit. The first thing I noticed > is that it adds a dependency on Archive::Tar which isn't already used > anywhere else. Did anybody check whether this exists back in 5.8

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

On Tue, Nov 17, 2015 at 9:30 PM, Etsuro Fujita wrote: > I suppose you (and KaiGai-san) are probably right, but I really fail to see > it actually doing that. Noted, but let's do it that way and move on. It would be a shame if we didn't end up with a working FDW join

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

On Tue, Nov 17, 2015 at 8:47 PM, Kouhei Kaigai wrote: > The attached patch is the portion cut from the previous EPQ recheck > patch. Thanks, committed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

On Tue, Nov 17, 2015 at 10:22 PM, Kouhei Kaigai wrote: > Apart from EPQ rechecks, the above aggressive push-down idea allows to send > contents of multiple relations to the remote side. In this case, ForeignScan > needs to have multiple sub-plans. > > For example, please

[HACKERS] Re: [COMMITTERS] pgsql: Improve vcregress.pl's handling of tap tests for client programs

On 11/18/2015 10:58 PM, Michael Paquier wrote: On Thu, Nov 19, 2015 at 12:51 PM, Andrew Dunstan > wrote: Improve vcregress.pl 's handling of tap tests for client programs The target is now named 'bincheck'

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

On 2015/11/10 17:02, Amit Langote wrote: > On 2015/10/29 23:22, Syed, Rahila wrote: >> Please find attached an updated patch. > > A few more comments on v6: I backed up a little, studied the proposal and the patch in little some more detail. Here are still more comments - Going through the

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

On 2015/11/19 16:18, Amit Langote wrote: > I'm marking this as "Waiting on author" in the commitfest app. Also, let's > hear from more people. Well, it seems Michael beat me to it. Thanks, Amit -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] Additional role attributes && superuser review

On Thu, Nov 19, 2015 at 7:10 AM, Stephen Frost wrote: > * Michael Paquier (michael.paqu...@gmail.com) wrote: >> It seems weird to not have a dedicated role for pg_switch_xlog. > > I didn't add a pg_switch_xlog default role in this patch series, but > would be happy to do so if that's the

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

On Thu, Nov 19, 2015 at 4:30 PM, Amit Langote wrote: > On 2015/11/19 16:18, Amit Langote wrote: >> I'm marking this as "Waiting on author" in the commitfest app. Also, let's >> hear from more people. > > Well, it seems Michael beat me to it. Yeah, some other folks

Re: [HACKERS] Minor comment improvement to create_foreignscan_plan

On 2015/11/19 5:29, Robert Haas wrote: On Tue, Nov 17, 2015 at 9:29 PM, Etsuro Fujita wrote: On 2015/11/18 2:57, Robert Haas wrote: On Sun, Nov 15, 2015 at 9:25 PM, Etsuro Fujita wrote: Oops, I've found another one. I think we