[HACKERS] psql - add ability to test whether a variable exists

Hello, As a follow-up to the \if patch by Corey Huinker, here is a proposal to allow testing whether a client-side variable exists in psql. The syntax is as ugly as the current :'var' and :"var" things, but ISTM that this is the only simple option to have a working SQL-compatible syntax wit

Re: [HACKERS] Variable substitution in psql backtick expansion

Hello Tom, ... I'm still not sure that there's any use case for the string versions ("9.6.4" etc). If somebody's doing comparisons, they probably want the numeric version, but somebody might want to print the string version in an error message e.g. \if \echo this thing doesn't work on :VER

Re: [HACKERS] MAIN, Uncompressed?

On 26/08/17 12:18, Simon Riggs wrote: On 25 August 2017 at 20:53, Tom Lane wrote: Greg Stark writes: I think this is a particularly old piece of code and we're lucky the default heuristics have served well for all this time because I doubt many people fiddle with these storage attributes. Th

Re: [HACKERS] Pluggable storage

On Wed, Aug 23, 2017 at 11:59 PM, Amit Kapila wrote: > On Wed, Aug 23, 2017 at 11:05 AM, Haribabu Kommi > wrote: > > > > > > On Mon, Aug 21, 2017 at 7:25 PM, Amit Kapila > > wrote: > >> > >> On Mon, Aug 21, 2017 at 12:58 PM, Haribabu Kommi > >> wrote: > >> > > >> > On Sun, Aug 13, 2017 at 5:17

Re: [HACKERS] visual studio 2017 build support

On Fri, Aug 25, 2017 at 11:27 PM, Christian Ullrich wrote: > * On 2017-06-21 02:06, Haribabu Kommi wrote: > > Thanks for the review. Here I attached an updated patch with README update. >> > > Hello, > Thanks for the review. > the most recent update to VS 2017, version 15.3, now identifies as

Re: [HACKERS] MAIN, Uncompressed?

On 25 August 2017 at 20:53, Tom Lane wrote: > Greg Stark writes: >> I think this is a particularly old piece of code and we're lucky the >> default heuristics have served well for all this time because I doubt >> many people fiddle with these storage attributes. The time may have >> come to come

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 Tue, Aug 22, 2017 at 4:58 AM, Daniel Verite wrote: > For the record, attached are the collname that initdb now creates > in pg_collation, when compiled successively with all current > versions of ICU (49 to 59), versus what 10beta2 did. > > There are still a few names that get dropped along the

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

On Thu, Aug 24, 2017 at 12:59 AM, Michael Paquier wrote: > Robert, Amit and other folks working on extending the existing > partitioning facility would be in better position to answer that, but > I would think that we should have something as flexible as possible, > and storing a list of relation

Re: [HACKERS] Variable substitution in psql backtick expansion

On Fri, Aug 25, 2017 at 6:43 PM, Tom Lane wrote: > Robert Haas writes: >> On Fri, Aug 25, 2017 at 6:09 PM, Tom Lane wrote: >>> ... I'm still not sure that there's any use case for the >>> string versions ("9.6.4" etc). > >> If somebody's doing comparisons, they probably want the numeric >> vers

Re: [HACKERS] Variable substitution in psql backtick expansion

Robert Haas writes: > On Fri, Aug 25, 2017 at 6:09 PM, Tom Lane wrote: >> ... I'm still not sure that there's any use case for the >> string versions ("9.6.4" etc). > If somebody's doing comparisons, they probably want the numeric > version, but somebody might want to print the string version i

Re: [HACKERS] Variable substitution in psql backtick expansion

On Fri, Aug 25, 2017 at 6:09 PM, Tom Lane wrote: > My question was more about how much of a use-case there is for these > values if there's no expression language yet. On reflection though, > you can use either expr-in-backticks or a server query to make > comparisons, so there's at least some us

Re: [HACKERS] Variable substitution in psql backtick expansion

Robert Haas writes: > I am attempting to understand the status of this patch. It looks like > the patch that was the original subject of this thread was committed > as f833c847b8fa4782efab45c8371d3cee64292d9b on April 1st by Tom, who > was its author. Subsequently, a new patch not obviously relat

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

Robert Haas writes: > On Fri, Aug 25, 2017 at 5:12 PM, Tom Lane wrote: >> Here's a reviewed version of the second patch. I fixed one bug >> (wrong explain group nesting) and made some additional cosmetic >> improvements beyond the struct relocation. > The capitalization of TupleSortInstrumentat

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

On Fri, Aug 25, 2017 at 5:12 PM, Tom Lane wrote: > Robert Haas writes: >> On Fri, Aug 25, 2017 at 2:54 PM, Tom Lane wrote: >>> Hmm, I'm not sure why SortInstrumentation belongs naturally to >>> tuplesort.h but putting an array of them there would be a "gross >>> abstraction violation". Perhaps

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

Robert Haas writes: > On Fri, Aug 25, 2017 at 2:54 PM, Tom Lane wrote: >> Hmm, I'm not sure why SortInstrumentation belongs naturally to >> tuplesort.h but putting an array of them there would be a "gross >> abstraction violation". Perhaps it would help to rename >> struct SharedSortInfo to Sort

Re: [HACKERS] Variable substitution in psql backtick expansion

On Sun, May 21, 2017 at 11:37 AM, Fabien COELHO wrote: >> This patch has trivial implementation - and there are not any objection to >> used new variable names. >> >> 1. there was not any problem with patching, compiling >> 2. all regress tests passed >> 3. no problems with doc build >> >> I'll ma

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

On 8/25/17 3:26 PM, Robert Haas wrote: On Fri, Aug 25, 2017 at 3:21 PM, David Steele wrote: No problem. I'll base it on your commit to capture any changes you made. Thanks, but you incorporated everything I wanted in response to my first review -- so I didn't tweak it any further. Thank yo

Re: [HACKERS] MAIN, Uncompressed?

Greg Stark writes: > I think this is a particularly old piece of code and we're lucky the > default heuristics have served well for all this time because I doubt > many people fiddle with these storage attributes. The time may have > come to come up with a better UI for the storage attributes beca

Re: [HACKERS] MAIN, Uncompressed?

On 25 August 2017 at 19:59, Simon Riggs wrote: > > On 25 August 2017 at 14:08, Tom Lane wrote: > > > Maybe, but the use case seems mighty narrow. > > JSON blobs between 2kB and 8160 bytes are very common. > > String length is maybe a poisson distribution, definitely not uniform. But JSON blobs

[HACKERS] Release plans: near-term update releases, and 10.0

There are a couple of embarrassing regressions in this month's minor releases: * parallel pg_restore crashes with -L (cf commit b1c2d76a2); affects 9.3 and up * walsender with a connected client won't shut down (cf commit b51c8efc6); affects 9.4 only Given that these bugs were discovered so

Re: [HACKERS] Patch: add --if-exists to pg_recvlogical

On Sun, May 21, 2017 at 3:04 PM, Rosser Schwarz wrote: > While doing some scripting around pg_recvlogical at $work, I found a need > for $subject. Attached, find a patch to that effect. > > I tried simply to mirror the logic used elsewhere. I don't think there's > anything controversial here, but

Re: [HACKERS] Crash on promotion when recovery.conf is renamed

On Sat, Apr 8, 2017 at 10:05 AM, David Steele wrote: > On 3/28/17 1:21 AM, Tsunakawa, Takayuki wrote: >> From: Michael Paquier [mailto:michael.paqu...@gmail.com] >>> Okay. I got the message, and I agree with what you say here. You are right >>> by the way, the error messages just use "two-phase fi

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

On Fri, Aug 25, 2017 at 3:21 PM, David Steele wrote: > No problem. I'll base it on your commit to capture any changes you made. Thanks, but you incorporated everything I wanted in response to my first review -- so I didn't tweak it any further. -- Robert Haas EnterpriseDB: http://www.enterpris

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

On 8/25/17 3:13 PM, Robert Haas wrote: > On Fri, Aug 25, 2017 at 3:10 PM, David Steele wrote: >> >> Robert said he would commit this so I expect he'll do that if he doesn't >> have any objections to the changes. >> >> Robert, if you would prefer me to submit this to the CF I'm happy to do so. > >

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

On Fri, Aug 25, 2017 at 3:10 PM, David Steele wrote: > On 8/24/17 7:36 PM, Michael Paquier wrote: >> >> True as well. The patch looks good to me. If a committer does not show >> up soon, it may be better to register that in the CF and wait. I am >> not sure that adding an open item is suited, as d

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

On 8/24/17 7:36 PM, Michael Paquier wrote: > > True as well. The patch looks good to me. If a committer does not show > up soon, it may be better to register that in the CF and wait. I am > not sure that adding an open item is suited, as docs have the same > problem on 9.6. Robert said he would c

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

On Fri, Aug 25, 2017 at 2:54 PM, Tom Lane wrote: >> I think moving SharedSortInfo into tuplesort.h would be a gross >> abstraction violation, but moving SortInstrumentation into tuplesort.h >> seems like a modest improvement. > > Hmm, I'm not sure why SortInstrumentation belongs naturally to > tup

Re: [HACKERS] MAIN, Uncompressed?

On 25 August 2017 at 14:08, Tom Lane wrote: > Simon Riggs writes: >> On 25 August 2017 at 13:21, Tom Lane wrote: >>> If you know compression isn't useful, but you don't want to fail on >>> wide values, then "external" should serve the purpose. > >> Well, almost. External toasts at 2048-ish bytes

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

Robert Haas writes: > On Fri, Aug 25, 2017 at 2:01 PM, Tom Lane wrote: >> I looked through this a little, and feel uncomfortable with the division >> of typedefs between execnodes.h and tuplesort.h. I'm inclined to push >> struct SortInstrumentation, and maybe also SharedSortInfo, into >> tuples

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

On Fri, Aug 25, 2017 at 2:01 PM, Tom Lane wrote: > Robert Haas writes: >> On another note, here's a second patch applying on top of my earlier >> patch to push down Limit through Gather and Gather Merge. > > I looked through this a little, and feel uncomfortable with the division > of typedefs be

Re: [HACKERS] expanding inheritance in partition bound order

On Mon, Aug 21, 2017 at 2:10 AM, Amit Langote wrote: > [ new patches ] I am failing to understand the point of separating PartitionDispatch into PartitionDispatch and PartitionTableInfo. That seems like an unnecessary multiplication of entities, as does the introduction of PartitionKeyInfo. I a

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

Christian Ullrich writes: > The buildfarm says that sorting is frequently done case-sensitively: Given that it's Friday evening in Europe, I'm betting Michael is gone for the day. In the interests of getting the buildfarm back to green, I'll see if I can fix this. regard

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

Robert Haas writes: > On another note, here's a second patch applying on top of my earlier > patch to push down Limit through Gather and Gather Merge. I looked through this a little, and feel uncomfortable with the division of typedefs between execnodes.h and tuplesort.h. I'm inclined to push st

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

On Fri, Aug 25, 2017 at 1:31 PM, Tom Lane wrote: > Robert Haas writes: >> Awesome. What's the business with enable_hashagg in the regression test >> stuff? > > Just relocating that "reset" so that it only affects the test case it's > needed for. (I think the 0-worker test was inserted in the w

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

Robert Haas writes: > Awesome. What's the business with enable_hashagg in the regression test > stuff? Just relocating that "reset" so that it only affects the test case it's needed for. (I think the 0-worker test was inserted in the wrong place.) regards, tom lane -

Re: [HACKERS] Update comment in ExecPartitionCheck

On Tue, Jul 4, 2017 at 4:55 AM, Etsuro Fujita wrote: > This comment in an error handling in ExecPartitionCheck(): > > if (!ExecCheck(resultRelInfo->ri_PartitionCheckExpr, econtext)) > { > char *val_desc; > Relationorig_rel = rel; > > /* See the comment abo

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

Robert Haas writes: > The point I was trying to make is that if you retroactively change the > cost of a path after you've already done add_path(), it's too late to > change your mind about whether to keep the path. At least according > to my current understanding, that's the root of this problem

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

On Fri, Aug 25, 2017 at 1:18 PM, Tom Lane wrote: > v4, with a test case and some more comment-polishing. I think this > is committable. Awesome. What's the business with enable_hashagg in the regression test stuff? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgr

Re: [HACKERS] Range Merge Join v1

Hi Jeff, Fast range joins are very nice to have, thank you for working on this. I've been doing a somewhat related thing recently, trying to teach the merge join executor to perform full joins on comparison clauses [1]. I have some comments after reading your patch: * At the moment, "mergejo

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

v4, with a test case and some more comment-polishing. I think this is committable. regards, tom lane diff --git a/src/backend/executor/execParallel.c b/src/backend/executor/execParallel.c index ce47f1d..ad9eba6 100644 --- a/src/backend/executor/execParallel.c +++ b/src/ba

Re: [HACKERS] paths in partitions of a dummy partitioned table

On Thu, Jul 6, 2017 at 11:35 AM, Ashutosh Bapat wrote: > If a partitioned table is proven dummy, set_rel_pathlist() doesn't mark the > partition relations dummy and thus doesn't set any (dummy) paths in the > partition relations. The lack of paths in the partitions means that we can > not use part

Re: [HACKERS] [RFC] What would be difficult to make data models pluggable for making PostgreSQL a multi-model database?

This may be interesting... they implement cypher (unfortunately they had to fork in order to have cypher be a first class query language with SQL). https://github.com/bitnine-oss/agensgraph On Mon, Aug 21, 2017 at 12:44 AM Chris Travers wrote: > On Sun, Aug 20, 2017 at 4:10 AM, MauMau wrote:

Re: [HACKERS] subscription worker signalling wal writer too much

On Mon, Jul 3, 2017 at 11:26 PM, Jeff Janes wrote: > My understanding is that you can't start on a new file until the old file is > completely synced, because the book keeping can currently only handle one > file at a time. So if you signal the wal writer to do the sync, you would > just end up i

Re: [HACKERS] assorted code cleanup

On Mon, Aug 21, 2017 at 1:11 AM, Michael Paquier wrote: > On Fri, Aug 18, 2017 at 1:56 AM, Peter Eisentraut > wrote: >> Here are a few assorted patches I made while working on the stdbool set, >> cleaning up various pieces of dead code and weird styles. >> >> - Drop excessive dereferencing of fun

Re: [HACKERS] locale problem of bgworker: logical replication launcher and worker process

On 8/25/17 05:14, Ioseph Kim wrote: > I resolved this problem. > > This problem is that dgettext() function use codeset of database's lc_ctype. > > below database's lc_ctype is C, but locale is ko_KR.UTF8. Thank you for following up. As you have discovered, that combination of locale settings d

Re: [HACKERS] obsolete code in pg_upgrade

On 8/25/17 04:00, Christoph Berg wrote: > Re: Peter Eisentraut 2017-08-24 > <8aa00f15-144e-e793-750e-d1d6876d6...@2ndquadrant.com> >> On 8/23/17 09:36, Robert Haas wrote: >>> I think I agree. It seems to me that the version of pg_upgrade >>> shipped with release N only needs to support upgrades t

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

On Sun, Aug 20, 2017 at 11:25 PM, Etsuro Fujita wrote: >> I agree, but I wonder if we ought to make it work first using the >> existing APIs and then add these new APIs as an optimization. > > I'm not sure that's a good idea because that once we support INSERT > tuple-routing for foreign partition

Re: [HACKERS] PoC: full merge join on comparison clause

Here is a new version of the patch, rebased to 749c7c41 and with some cosmetic changes. -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company diff --git a/contrib/postgres_fdw/postgres_fdw.c b/contrib/postgres_fdw/postgres_fdw.c index d77c2a70e4..

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

On Mon, Aug 21, 2017 at 5:08 AM, Amit Kapila wrote: > Thanks for acknowledging the idea. I have written a patch which > implements the above idea. At this stage, it is merely to move the > discussion forward. Few things which I am not entirely happy about > this patch are: > > (a) To skip genera

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

On Fri, Aug 25, 2017 at 12:05 PM, Tom Lane wrote: > Hm. It seemed pretty reliable for me, but we already know that the > parallel machinery is quite timing-sensitive. I think we'd better > incorporate a regression test case into the committed patch so we > can see what the buildfarm thinks. I'l

Re: [HACKERS] Proposal: global index

On Fri, Aug 25, 2017 at 6:52 AM, Ildar Musin wrote: > I agree with you that garbage collection after partitions drop could be a > major downside of single index scheme. On the other hand not all > partitioning use-cases imply dropping partitions. What worries me about > global unique index built o

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

Robert Haas writes: > I had the same thought. Done in the attached revision of your > version. I couldn't consistently reproduce the failure you saw -- it > failed for me only about 1 time in 10 -- but I don't think it's > failing any more with this version. Hm. It seemed pretty reliable for m

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

On Fri, Aug 25, 2017 at 11:15 AM, Tom Lane wrote: > The problem I exhibited with the updated patch could probably be resolved > if the top level logic in a parallel worker knows about tuples_needed > and doesn't try to pull more than that from its subplan. So what you're > describing isn't just a

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

Robert Haas writes: > However, there's another opportunity for optimization here, which is > the Limit -> Gather -> Anything case. A worker which has itself > generated enough tuples to fill the limit can certainly stop working, > but right now it doesn't know that. The patch I posted before did

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

On Fri, Aug 25, 2017 at 9:24 AM, Tom Lane wrote: > Basically, this argument is that we should contort the code in order > to avoid tail recursion, rather than assuming the compiler will turn > that recursion into iteration, even in cases where there is really > zero evidence that we should be worr

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

Amit Kapila writes: > On Fri, Aug 25, 2017 at 7:35 PM, Tom Lane wrote: >> it would be stupid to put a filter on that node rather than its >> children, but I see this in both nodeGather.c and nodeGatherMerge.c: >> >> gatherstate->ps.qual = >> ExecInitQual(node->plan.qual, (PlanState *) gatherstate

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

Robert Haas writes: > I'm inclined to commit both of these after a little more testing and > self-review, but let me know if anyone else wants to review first. Attached is an updated version of the first patch, which I rebased over 3f4c7917b, improved a bunch of the comments for, and fixed a coup

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

On Fri, Aug 25, 2017 at 7:35 PM, Tom Lane wrote: > Robert Haas writes: >> I'm inclined to commit both of these after a little more testing and >> self-review, but let me know if anyone else wants to review first. > > Looking through the first one, I wondered whether we needed to > check for a qua

Re: [HACKERS] Not listed as committer

* Magnus Hagander (mag...@hagander.net) wrote: > On Fri, Aug 25, 2017 at 3:47 PM, Michael Meskes > wrote: > > I just committed a patch that is listed in the CF and had to put > > somebody (I chose you Bruce :)) in as a committer because I was not > > listed. Do I have to register somewhere? > > >

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

Robert Haas writes: > I'm inclined to commit both of these after a little more testing and > self-review, but let me know if anyone else wants to review first. Looking through the first one, I wondered whether we needed to check for a qual expression on Gather or GatherMerge. It seems like it wo

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

* Michael Meskes wrote: The v3 patch looks good to me. I've changed this patch status to Ready for Committer. Thank you all, committed. The buildfarm says that sorting is frequently done case-sensitively: *** 1,2 - josh 1.00 10.00 Ram 00.00 21.00 --- 1,2 Ram 11

Re: [HACKERS] Not listed as committer

On Fri, Aug 25, 2017 at 3:47 PM, Michael Meskes wrote: > All, > > I just committed a patch that is listed in the CF and had to put > somebody (I chose you Bruce :)) in as a committer because I was not > listed. Do I have to register somewhere? > Ha, that's interesting. Should be fixed now, plea

Re: [HACKERS] Proposal: global index

On Fri, Aug 25, 2017 at 12:15 PM, Petr Jelinek wrote: > On 25/08/17 10:28, Chris Travers wrote: > > > > > > On Thu, Aug 24, 2017 at 9:44 PM, Andres Freund > > wrote: > > > > Hi, > > > > On 2017-08-18 12:12:58 +0300, Ildar Musin wrote: > > > While we've been

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

On Aug 25, 2017 10:45 PM, "Michael Meskes" wrote: > > > The v3 patch looks good to me. I've changed this patch status to Ready > > for Committer. > > Thank you all, committed. Thank you very much. Regards, Vinayak Pokale

[HACKERS] Not listed as committer

All, I just committed a patch that is listed in the CF and had to put somebody (I chose you Bruce :)) in as a committer because I was not listed. Do I have to register somewhere? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Post

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

> The v3 patch looks good to me. I've changed this patch status to Ready > for Committer. Thank you all, 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 dot org VfL

Re: [HACKERS] visual studio 2017 build support

* On 2017-06-21 02:06, Haribabu Kommi wrote: Thanks for the review. Here I attached an updated patch with README update. Hello, the most recent update to VS 2017, version 15.3, now identifies as "14.11" rather than "14.10" in the output of nmake /?. Simply adding this value to the two place

Re: [HACKERS] Tuple-routing for certain partitioned tables not working as expected

On Wed, Aug 23, 2017 at 4:55 AM, Etsuro Fujita wrote: > Agreed, but I'd vote for fixing this in v10 as proposed; I agree that just > ripping the CheckValidResultRel checks out entirely is not a good idea, but > that seems OK to me at least as a fix just for v10. I'm still not on-board with having

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

Robert Haas writes: > On Thu, Aug 24, 2017 at 2:24 PM, Tom Lane wrote: >> I'd have been okay with changing the entire function if it could still be >> doing all cases the same way. But the exception for merge-append (and >> probably soon other cases) means you still end up with a readability >>

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

On Thu, Aug 24, 2017 at 2:24 PM, Tom Lane wrote: > I'd have been okay with changing the entire function if it could still be > doing all cases the same way. But the exception for merge-append (and > probably soon other cases) means you still end up with a readability > problem. I don't really ag

Re: [HACKERS] MAIN, Uncompressed?

Simon Riggs writes: > On 25 August 2017 at 13:21, Tom Lane wrote: >> If you know compression isn't useful, but you don't want to fail on >> wide values, then "external" should serve the purpose. > Well, almost. External toasts at 2048-ish bytes whereas Main toasts at > 8160 bytes. > The rows are

Re: [HACKERS] MAIN, Uncompressed?

On 25 August 2017 at 13:21, Tom Lane wrote: > Simon Riggs writes: >> Main is roughly what is wanted, yet it always tries to compress. If >> you already know that won't be useful it should be possible to turn >> compression off. > > If you know compression isn't useful, but you don't want to fail

Re: [HACKERS] MAIN, Uncompressed?

Simon Riggs writes: > Main is roughly what is wanted, yet it always tries to compress. If > you already know that won't be useful it should be possible to turn > compression off. If you know compression isn't useful, but you don't want to fail on wide values, then "external" should serve the purp

Re: [HACKERS] MAIN, Uncompressed?

On 25 August 2017 at 12:24, Tom Lane wrote: > Simon Riggs writes: >> It looks like we need a new Column Storage option for MAIN, Uncompressed. >> We have these Column Storage options >> Plain - inline only, uncompressed >> Main - inline until external as last resort, compressible >> External - ex

Re: [HACKERS] MAIN, Uncompressed?

Simon Riggs writes: > It looks like we need a new Column Storage option for MAIN, Uncompressed. > We have these Column Storage options > Plain - inline only, uncompressed > Main - inline until external as last resort, compressible > External - external, uncompressed > Extended - external, compress

Re: [HACKERS] Explicit relation name in VACUUM VERBOSE log

On Thu, Aug 24, 2017 at 11:35 PM, Tom Lane wrote: > Alvaro Herrera writes: >> Michael Paquier wrote: >>> Hm. I am not sure what you have in mind here. > >> I'm thinking that this data is useful to analyze as a stream of related >> events, rather than as individual data points. Grepping logs in o

Re: [HACKERS] Proposal: global index

Hi, On 24.08.2017 22:44, Andres Freund wrote: Hi, On 2017-08-18 12:12:58 +0300, 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

Re: [HACKERS] Proposal: global index

On 25/08/17 10:28, Chris Travers wrote: > > > On Thu, Aug 24, 2017 at 9:44 PM, Andres Freund > wrote: > > Hi, > > On 2017-08-18 12:12:58 +0300, Ildar Musin wrote: > > While we've been developing pg_pathman extension one of the most > frequent > > que

Re: [HACKERS] More replication race conditions

On 24/08/17 19:54, Tom Lane wrote: > sungazer just failed with > > pg_recvlogical exited with code '256', stdout '' and stderr 'pg_recvlogical: > could not send replication command "START_REPLICATION SLOT "test_slot" > LOGICAL 0/0 ("include-xids" '0', "skip-empty-xacts" '1')": ERROR: > replica

[HACKERS] MAIN, Uncompressed?

It looks like we need a new Column Storage option for MAIN, Uncompressed. We have these Column Storage options Plain - inline only, uncompressed Main - inline until external as last resort, compressible External - external, uncompressed Extended - external, compressible So there is no option for

Re: [HACKERS] Thoughts on unit testing?

On Thu, Aug 24, 2017 at 9:07 AM, Torsten Zuehlsdorff < mailingli...@toco-domains.de> wrote: > > > On 13.08.2017 21:19, Peter Geoghegan wrote: > >> On Thu, Aug 10, 2017 at 2:53 PM, Thomas Munro >> wrote: >> >>> The current regression tests, isolation tests and TAP tests are very >>> good (though I

Re: [HACKERS] CONNECTION LIMIT and Parallel Query don't play well together

On 24 August 2017 at 11:15, Peter Eisentraut wrote: > Here is a slightly updated patch for consideration in the upcoming > commit fest. Hi Peter, I just had a quick glance over this and wondered about 2 things. 1. Why a GUC and not a new per user option so it can be configured differently for d

Re: [HACKERS] locale problem of bgworker: logical replication launcher and worker process

Thanks for reply. I resolved this problem. This problem is that dgettext() function use codeset of database's lc_ctype. below database's lc_ctype is C, but locale is ko_KR.UTF8. I made a new database with lc_ctype is ko_KR.UTF8. this problem is resolved. work logs are here. (10) post

Re: [HACKERS] Proposal: global index

On Thu, Aug 24, 2017 at 9:44 PM, Andres Freund wrote: > Hi, > > On 2017-08-18 12:12:58 +0300, 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 ext

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

On 2017/08/25 17:13, Masahiko Sawada wrote: On Fri, Aug 25, 2017 at 4:27 PM, vinayak wrote: On 2017/08/25 16:18, Masahiko Sawada wrote: On Fri, Aug 25, 2017 at 2:57 PM, vinayak wrote: Hi Sawada-san, On 2017/08/25 11:07, Masahiko Sawada wrote: On Fri, Aug 18, 2017 at 5:20 PM, vinayak wr

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

On Fri, Aug 25, 2017 at 4:27 PM, vinayak wrote: > > > On 2017/08/25 16:18, Masahiko Sawada wrote: >> >> On Fri, Aug 25, 2017 at 2:57 PM, vinayak >> wrote: >>> >>> Hi Sawada-san, >>> >>> >>> On 2017/08/25 11:07, Masahiko Sawada wrote: On Fri, Aug 18, 2017 at 5:20 PM, vinayak wrote:

Re: [HACKERS] Re: [COMMITTERS] pgsql: Fix bug that can cause walsender not to terminating at shutdown.

On Fri, Aug 25, 2017 at 3:36 PM, Alvaro Herrera wrote: > Andres Freund wrote: >> Fix bug that can cause walsender not to terminating at shutdown. >> >> When backpatching c6c333436 I (Andres Freund) mis-resolved a conflict >> in the 9.4 branch. Unfortunately that leads to walsenders waiting >> fore

Re: [HACKERS] obsolete code in pg_upgrade

Re: Peter Eisentraut 2017-08-24 <8aa00f15-144e-e793-750e-d1d6876d6...@2ndquadrant.com> > On 8/23/17 09:36, Robert Haas wrote: > > I think I agree. It seems to me that the version of pg_upgrade > > shipped with release N only needs to support upgrades to release N, > > not older releases. There's

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

On 2017/08/25 16:18, Masahiko Sawada wrote: On Fri, Aug 25, 2017 at 2:57 PM, vinayak wrote: Hi Sawada-san, On 2017/08/25 11:07, Masahiko Sawada wrote: On Fri, Aug 18, 2017 at 5:20 PM, vinayak wrote: On 2017/06/20 17:35, vinayak wrote: Hi Sawada-san, On 2017/06/20 17:22, Masahiko Sawada

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

On Fri, Aug 25, 2017 at 2:57 PM, vinayak wrote: > Hi Sawada-san, > > > On 2017/08/25 11:07, Masahiko Sawada wrote: >> >> On Fri, Aug 18, 2017 at 5:20 PM, vinayak >> wrote: >>> >>> On 2017/06/20 17:35, vinayak wrote: Hi Sawada-san, On 2017/06/20 17:22, Masahiko Sawada wrote: >>

[HACKERS] WIP: Separate log file for extension

Attached is a draft patch to allow extension to write log messages to a separate file. It introduces a concept of a "log stream". The extension's shared library gets its stream assigned by calling this function from _PG_init() my_stream_id = get_log_stream("my_extension", &my_log_stream);