Re: [HACKERS] [PATCH] Logical decoding timeline following take II

It's unlikely this will get in as a standalone patch, so I'm closing the CF entry for it as RwF https://commitfest.postgresql.org/11/779/ It is now being tracked as part of logical decoding on standby at https://commitfest.postgresql.org/12/788/ in thread "Logical decoding on standby", which be

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

Hello, I think it's really time we seriously considered adding some flow control logic, though. Yeah, maybe. I'd be interested to see a fully worked out proposal for that. I agree that designing a fuller proposal before including individual parts would be great and result in a more consis

Re: [HACKERS] GIN non-intrusive vacuum of posting tree

> 28 нояб. 2016 г., в 20:31, Andrew Borodin написал(а): > > This patch solved a problem encountered by Evgeniy Efimkin and > Vladimir Borodin from Yandex.Mail. > > and eventually deleting some of data. This testbed showed VACUUM > holding inserts for up to tenths of seconds. They claim that pro

Re: [HACKERS] Tackling JsonPath support

2016-11-29 7:34 GMT+01:00 Christian Convey : > On Mon, Nov 28, 2016 at 9:28 PM, Pavel Stehule > wrote: > >> We now support XPath function - JSONPath is similar to XPath - it is >> better for user, because have to learn only one language. >> > > I'm not sure I understand. > > Are you suggesting th

Re: [HACKERS] Tackling JsonPath support

On Mon, Nov 28, 2016 at 9:28 PM, Pavel Stehule wrote: > We now support XPath function - JSONPath is similar to XPath - it is > better for user, because have to learn only one language. > I'm not sure I understand. Are you suggesting that we use XPath, not JSONPath, as our language for json-path

Re: [HACKERS] Tackling JsonPath support

2016-11-29 4:00 GMT+01:00 David G. Johnston : > On Mon, Nov 28, 2016 at 7:38 PM, Christian Convey < > christian.con...@gmail.com> wrote: > >> On Mon, Nov 28, 2016 at 6:26 PM, Nico Williams >> wrote: >> >>> While XPath is expressive and compact, XSLT >>> is rather verbose; jq is as expressive as X

Re: [HACKERS] GiST support for UUIDs

On Mon, Nov 28, 2016 at 4:04 PM, Tom Lane wrote: > > What I would suggest is that you forget the union hack and just use > memcmp in all the comparison functions. It's not likely to be worth > the trouble to try to get those calls to be safely aligned. The > only place where you need go to any t

Re: [HACKERS] Tackling JsonPath support

2016-11-29 2:50 GMT+01:00 Christian Convey : > On Mon, Nov 28, 2016 at 11:23 AM, Nico Williams > wrote: > ... > >> JSON Path is not expressive enough (last I looked) and can be mapped >> onto jq if need be anyways. >> > > ​Hi Nico, > > Could you please clarify what you mean by "not expressive eno

Re: [HACKERS] Proposal : For Auto-Prewarm.

Sorry I took some time on this please find latest patch with addressed review comments. Apart from fixes for comments I have introduced a new GUC variable for the pg_autoprewarm "buff_dump_interval". So now we dump the buffer pool metadata at every buff_dump_interval secs. Currently buff_dump_inter

Re: [HACKERS] UNDO and in-place update

On Mon, Nov 28, 2016 at 11:01 PM, Robert Haas wrote: > On Sun, Nov 27, 2016 at 10:44 PM, Amit Kapila wrote: >> On Mon, Nov 28, 2016 at 4:50 AM, Robert Haas wrote: >>> Well, my original email did contain a discussion of the need for >>> delete-marking. I said that you couldn't do in-place update

[HACKERS] Thinko in set_rel_consider_parallel()

The following looks like a thinko, which fixed in attached: -Oid proparallel = func_parallel(... +charproparallel = func_parallel(... Thanks, Amit diff --git a/src/backend/optimizer/path/allpaths.c b/src/backend/optimizer/path/allpaths.c index e42ef

Re: [HACKERS] Mention column name in error messages

On Mon, Nov 7, 2016 at 10:26 AM, Franck Verrot wrote: > > > On Sun, Nov 6, 2016 at 1:13 PM, Tom Lane wrote: >> >> > The original intent of that patch tried to cover the case where we >> > insert >> > records >> > made of dozens columns sharing the same type definition, and trying to >> > understa

Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

On Fri, Nov 18, 2016 at 2:51 AM, Michael Paquier wrote: > On Thu, Nov 17, 2016 at 8:12 AM, Robert Haas wrote: >> So, the problem isn't Darwin-specific. I experimented with this on >> Linux and found Linux does the same thing with libpgcommon_srv.a that >> macOS does: a file in the archive that i

Re: [HACKERS] Renaming of pg_xlog and pg_clog

On Tue, Nov 22, 2016 at 8:35 PM, Haribabu Kommi wrote: > Hi Craig, > > This is a gentle reminder. > > you assigned as reviewer to the current patch in the 11-2016 commitfest. > But you haven't shared your review yet. Please share your review about > the patch. This will help us in smoother operati

Re: [HACKERS] Forbid use of LF and CR characters in database and role names

On Fri, Nov 25, 2016 at 4:41 PM, Michael Paquier wrote: > On Fri, Nov 25, 2016 at 4:02 PM, Ideriha, Takeshi > wrote: >> I applied your fixed patch and new one, and confirmed the applied source >> passed the tests successfully. And I also checked manually the error >> messages were emitted succe

Re: [HACKERS] Quorum commit for multiple synchronous replication.

On Mon, Nov 28, 2016 at 8:03 PM, Masahiko Sawada wrote: > On Sat, Nov 26, 2016 at 10:27 PM, Michael Paquier > wrote: >> On Tue, Nov 15, 2016 at 7:08 PM, Masahiko Sawada >> wrote: >>> Attached latest version patch incorporated review comments. After more >>> thought, I agree and changed the valu

Re: [HACKERS] WAL consistency check facility

On Wed, Nov 16, 2016 at 2:15 AM, Michael Paquier wrote: > On Tue, Nov 15, 2016 at 7:50 AM, Kuntal Ghosh > wrote: >> I've modified the guc parameter name as wal_consistency_check (little >> hesitant for a participle in suffix :) ). Also, updated the sgml and >> variable name accordingly. > > The c

Re: [HACKERS] pg_dump, pg_dumpall and data durability

On Mon, Nov 14, 2016 at 6:07 PM, Michael Paquier wrote: > On Mon, Nov 14, 2016 at 6:04 PM, Albe Laurenz wrote: >> Michael Paquier wrote: >>> Meh. I forgot docs and --help output updates. >> >> Looks good, except that you left the "N" option in the getopt_long >> call for pg_dumpall. I fixed that

Re: [HACKERS] Re: [sqlsmith] FailedAssertion("!(XLogCtl->Insert.exclusiveBackup)", File: "xlog.c", Line: 10200)

On Thu, Nov 17, 2016 at 1:18 PM, Michael Paquier wrote: > On Mon, Nov 7, 2016 at 6:18 PM, Kyotaro HORIGUCHI > wrote: >> I will mark this as "Ready for Committer". > > I have just noticed that Robert has switched this patch to "needs > review" by mistake (I think that there was a mistake with anot

Re: [HACKERS] Fix checkpoint skip logic on idle systems by tracking LSN progress

On Tue, Nov 22, 2016 at 6:27 PM, Kyotaro HORIGUCHI wrote: > I have marked this as ready for committer again. And moved to next CF for now. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/

Re: [HACKERS] pgsql: Add putenv support for msvcrt from Visual Studio 2013

On Wed, Nov 16, 2016 at 12:45 PM, Christian Ullrich wrote: > I also did a debug build with 1+2+4 that came in at 84 μs/iteration. Moved to next CF. Christian, perhaps this patch should have an extra round of reviews? -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.

Re: [HACKERS] Proposal: scan key push down to heap [WIP]

On 2016-11-28 09:55:00 -0500, Robert Haas wrote: > I think we should go with this approach. I don't think it's a good > idea to have the heapam layer know about executor slots. I agree that that's not pretty. > Even though > it's a little sad to pass up an opportunity for a larger performance >

Re: [HACKERS] Re: BUG #13755: pgwin32_is_service not checking if SECURITY_SERVICE_SID is disabled

On Tue, Nov 22, 2016 at 1:58 PM, Tsunakawa, Takayuki wrote: > From: Craig Ringer [mailto:cr...@2ndquadrant.com] >> You meant CheckTokenMembership(). > > Yes, my typo in the mail. > >> The proposed patch does need to be checked with: > > I understood you meant by "refuse to run" that postgres.exe f

Re: [HACKERS] Time to up bgwriter_lru_maxpages?

On Tue, Nov 29, 2016 at 6:20 AM, Jim Nasby wrote: > On 11/28/16 11:53 AM, Joshua D. Drake wrote: >> >> On 11/28/2016 11:40 AM, Jim Nasby wrote: >>> >>> With current limits, the most bgwriter can do (with 8k pages) is 1000 >>> pages * 100 times/sec = 780MB/s. It's not hard to exceed that with >>> m

Re: [HACKERS] Proposal: scan key push down to heap [WIP]

On Mon, Nov 28, 2016 at 8:25 PM, Robert Haas wrote: > I think we should go with this approach. I don't think it's a good > idea to have the heapam layer know about executor slots. Even though > it's a little sad to pass up an opportunity for a larger performance > improvement, this improvement i

Re: [HACKERS] Tackling JsonPath support

On Mon, Nov 28, 2016 at 08:00:46PM -0700, David G. Johnston wrote: > IMO jq is considerably closer to XSLT than XPath - which leads me to figure > that since xml has both that JSON can benefit from jq and json-path. I'm > not inclined to dig too deep here but I'd rather take jq in the form of > "p

Re: [HACKERS] Tackling JsonPath support

On Mon, Nov 28, 2016 at 7:38 PM, Christian Convey < christian.con...@gmail.com> wrote: > On Mon, Nov 28, 2016 at 6:26 PM, Nico Williams > wrote: > >> While XPath is expressive and compact, XSLT >> is rather verbose; jq is as expressive as XSLT, but with the compact >> verbosity of XPath. >> > > I

Re: [HACKERS] Tackling JsonPath support

On Mon, Nov 28, 2016 at 06:38:55PM -0800, Christian Convey wrote: > On Mon, Nov 28, 2016 at 6:26 PM, Nico Williams > wrote: > > > > Thanks for the explanation. It sounds like your original point was NOT > that json-path isn't sufficient for "${specific use X}". The only uses of SQL w/ JSON I've

Re: [HACKERS] Tackling JsonPath support

On Mon, Nov 28, 2016 at 6:26 PM, Nico Williams wrote: > On Mon, Nov 28, 2016 at 05:50:40PM -0800, Christian Convey wrote: > > On Mon, Nov 28, 2016 at 11:23 AM, Nico Williams > > wrote: > > ... > > > JSON Path is not expressive enough (last I looked) and can be mapped > > > onto jq if need be any

Re: [HACKERS] Tackling JsonPath support

On Mon, Nov 28, 2016 at 05:50:40PM -0800, Christian Convey wrote: > On Mon, Nov 28, 2016 at 11:23 AM, Nico Williams > wrote: > ... > > JSON Path is not expressive enough (last I looked) and can be mapped > > onto jq if need be anyways. > > Hi Nico, > > Could you please clarify what you mean by "

[HACKERS] Corner-case improvement to eqjoinsel_semi

There's a complaint in bug #14438 about poor estimation of join size for a semijoin whose inner side is empty. I think the root of it is that, having no statistics for the empty table, eqjoinsel_semi distrusts its estimate of the number of distinct values on the inner side, and falls back to a con

Re: [HACKERS] Tackling JsonPath support

On Mon, Nov 28, 2016 at 11:23 AM, Nico Williams wrote: ... > JSON Path is not expressive enough (last I looked) and can be mapped > onto jq if need be anyways. > ​Hi Nico, Could you please clarify what you mean by "not expressive enough"? I ask because I've been struggling to identify clear re

Re: [HACKERS] Fix comment in build_simple_rel

On 2016/11/29 3:57, Alvaro Herrera wrote: > Amit Langote wrote: >> Attached fixes reference in a comment to a non-existent function: >> >> s/GetRelationInfo/get_relation_info/g > > Thanks, pushed. get_relation_info() itself had been neglected when this > responsibility was added onto it; I added

Re: [HACKERS] Improving RLS planning

Tom, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > * Dean Rasheed (dean.a.rash...@gmail.com) wrote: > >> +1 for that terminology and no renaming of fields. > > > Agreed. > > Here's an updated version of the RLS planning patch that gets rid of > the incorrect interaction wit

Re: [HACKERS] matview incremental maintenance

On Mon, Jun 17, 2013 at 07:41:15AM -0700, Kevin Grittner wrote: > Since there seems to be interest in discussing incremental > maintenance of materialized views *now*, I'm starting this thread > to try to avoid polluting unrelated threads with the discussion.  I > don't intend to spend a lot of tim

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

Andrew Dunstan writes: > On 11/28/2016 04:07 PM, Tom Lane wrote: >> ... We've generally refrained from inventing any control flow >> metacommands for psql > I think it's really time we seriously considered adding some flow > control logic, though. Yeah, maybe. I'd be interested to see a fully

[HACKERS] Types gbtreekey32 and gbtreekey16 aren't adequately aligned

contrib/btree_gist declares type gbtreekey32 without any particular alignment spec, which means it defaults to 4-byte ("integer") alignment. However, btree_interval.c supposes that it can map a pair of intervals onto that storage. Since an interval contains a float8, that means we end up trying to

Re: [HACKERS] patch: function xmltable

Pavel Stehule wrote: > Here is updated patch without default namespace support (and without XPath > expression transformation). > > Due last changes in parser > https://github.com/postgres/postgres/commit/906bfcad7ba7cb3863fe0e2a7810be8e3cd84fbd > I had to use c_expr on other positions ( xmlnames

Re: [HACKERS] [BUG?] pg_event_trigger_ddl_commands() error with ALTER TEXT SEARCH CONFIGURATION

2016-11-28 21:32 GMT+03:00 Robert Haas : > > You might need to add this patch to https://commitfest.postgresql.org/ > so that it doesn't get forgotten. > > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company I added the patch to https://commitfest.postg

Re: [HACKERS] GiST support for UUIDs

Adam Brusselback writes: > [ btree_gist_uuid_7.patch ] I spent awhile looking at this. I have exactly no faith that it won't crash on alignment-picky hardware, because this declaration: union pg_uuid_t { unsigned char data[UUID_LEN]; uint64 v64[2]; }; is not the same as the exi

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

On 11/28/2016 04:07 PM, Tom Lane wrote: ... We've generally refrained from inventing any control flow metacommands for psql I think it's really time we seriously considered adding some flow control logic, though. I'm mildly tired of either jumping through hoops to get around the lack or ha

Re: [HACKERS] Tackling JsonPath support

On 28/11/16 18:57, Christian Convey wrote: > > On Mon, Nov 28, 2016 at 9:47 AM, Pavel Stehule > wrote > > > I thought by adding my first implementation to "contrib", we could make > this functionality available to end-users, even before there was a consensu

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

> > > As far as the original problem goes, I wonder whether what you really >> want isn't a \quit command that lets you specify psql's exit code. >> > > The ability to specify an exit code was part of the brainstorming, yes. But with it was the ability to conditionally quit. > Actually, I'm seein

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

On Mon, Nov 28, 2016 at 2:07 PM, Tom Lane wrote: > Corey Huinker writes: > > On Mon, Nov 28, 2016 at 2:03 PM, Fabien COELHO > wrote: > There's no reason to assume a-priori that this patch creates either naming > conventions or semantics (e.g. what is suitable as a boolean expression) > that we'

Re: [HACKERS] Time to up bgwriter_lru_maxpages?

On 11/28/16 11:53 AM, Joshua D. Drake wrote: On 11/28/2016 11:40 AM, Jim Nasby wrote: With current limits, the most bgwriter can do (with 8k pages) is 1000 pages * 100 times/sec = 780MB/s. It's not hard to exceed that with modern hardware. Should we increase the limit on bgwriter_lru_maxpages?

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

Corey Huinker writes: > On Mon, Nov 28, 2016 at 2:03 PM, Fabien COELHO wrote: >> I'm wondering if an simplistic interpreted \if \elsif/\else \fi would make >> more sense: > The problem is that \if \elsif \else \fi is anything but simplistic, and > would be a vastly bigger change. Detecting neste

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

On Mon, Nov 28, 2016 at 2:03 PM, Fabien COELHO wrote: > > Hello Corey, > > This patch adds two very simple psql commands: \quit_if and \quit_unless. >> > > A few comments about the feature design: > > I'm unsure about the name, esp with '_'. There are some \lo_* commands, > but others rely on pas

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

2016-11-28 20:03 GMT+01:00 Fabien COELHO : > > Hello Corey, > > This patch adds two very simple psql commands: \quit_if and \quit_unless. >> > > A few comments about the feature design: > > I'm unsure about the name, esp with '_'. There are some \lo_* commands, > but others rely on pasted words (\

Re: [HACKERS] Patch to implement pg_current_logfile() function

Le 28/11/2016 à 18:54, Karl O. Pinc a écrit : > Hi Gilles, > > On Sun, 27 Nov 2016 21:54:46 +0100 > Gilles Darold wrote: > >> I've attached the v15 of the patch that applies your changes/fixes and >> remove the call to strtok(). > I like the idea of replacing the strtok() call with sscanf() > but

Re: [HACKERS] Time to up bgwriter_lru_maxpages?

On 11/28/2016 11:40 AM, Jim Nasby wrote: With current limits, the most bgwriter can do (with 8k pages) is 1000 pages * 100 times/sec = 780MB/s. It's not hard to exceed that with modern hardware. Should we increase the limit on bgwriter_lru_maxpages? Considering a single SSD can do 70% of that l

Re: [HACKERS] Time to up bgwriter_lru_maxpages?

Hi, On Mon, 2016-11-28 at 11:40 -0800, Jim Nasby wrote: > With current limits, the most bgwriter can do (with 8k pages) is 1000  > pages * 100 times/sec = 780MB/s. It's not hard to exceed that with  > modern hardware. Should we increase the limit on bgwriter_lru_maxpages? +1 for that. I've seen

Re: [HACKERS] Wrong order of tests in findDependentObjects()

I wrote: > Jim Nasby writes: >> I can't think of any reason you'd want the current behavior. > But I think fixing it to not recurse to extensions during temp namespace > cleanup might not be very hard. I'll take a look. Here's a draft patch for that. Rather than sticking yet another special as

[HACKERS] Time to up bgwriter_lru_maxpages?

With current limits, the most bgwriter can do (with 8k pages) is 1000 pages * 100 times/sec = 780MB/s. It's not hard to exceed that with modern hardware. Should we increase the limit on bgwriter_lru_maxpages? -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, D

Re: [HACKERS] Tackling JsonPath support

On Mon, Nov 28, 2016 at 05:56:41PM +0100, Pavel Stehule wrote: > Dne 28. 11. 2016 17:26 napsal uživatel "David Fetter" : > > There's another option we should also consider: jq > > . It's available under a > > PostgreSQL-compatible license, and has had a LOT of work

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

Hello Corey, This patch adds two very simple psql commands: \quit_if and \quit_unless. A few comments about the feature design: I'm unsure about the name, esp with '_'. There are some \lo_* commands, but others rely on pasted words (\crosstabview, \errverbose, ...). I'm wondering if an si

Re: [HACKERS] Fix comment in build_simple_rel

Amit Langote wrote: > Attached fixes reference in a comment to a non-existent function: > > s/GetRelationInfo/get_relation_info/g Thanks, pushed. get_relation_info() itself had been neglected when this responsibility was added onto it; I added an entry there too. -- Álvaro Herrera

Re: [HACKERS] Dynamic shared memory areas

On Wed, Nov 23, 2016 at 7:07 AM, Thomas Munro wrote: > Those let you create an area in existing memory (in a DSM segment, > traditional inherited shmem). The in-place versions will stlll create > DSM segments on demand as required, though I suppose if you wanted to > prevent that you could with d

Re: [HACKERS] Tackling JsonPath support

I wonder what it might take to integrate jq[1] (via libjq) with PostgreSQL... The internal representation of JSON data is bound to be completely different, no doubt, but jq is a fantastic language, akin to XPath and XSLT combined, but with nice syntax. [1] https://stedolan.github.io/jq (note: jq

Re: [HACKERS] Mail thread references in commits

On 11/28/2016 09:49 AM, Alvaro Herrera wrote: Magnus Hagander wrote: I don't really read perl enough to take it apart. But http://git.kernel.org/cgit/git/git.git/tree/gitweb/gitweb.perl is the code (we're probably on an older version). I'm guessing it's coming out of format_log_line ( http://

Re: [HACKERS] [BUG?] pg_event_trigger_ddl_commands() error with ALTER TEXT SEARCH CONFIGURATION

On Sun, Nov 27, 2016 at 1:59 PM, Artur Zakirov wrote: > Thank you for answers. > > 2016-11-19 21:28 GMT+03:00 Michael Paquier : >> On Thu, Nov 17, 2016 at 1:17 PM, Alvaro Herrera >> wrote: >>> It's a bug. You're right that we need to handle the object class >>> somewhere. Perhaps I failed to re

Re: [HACKERS] Autovacuum breakage from a734fd5d1

On Mon, Nov 28, 2016 at 12:18 PM, Tom Lane wrote: > Robert Haas writes: >> I don't believe we should be so scared of the possibility of a serious >> bug that can't be found through any of the ways we normally test that >> we aren't willing to fix problems we can readily foresee. I grant >> that

Re: [HACKERS] Tackling JsonPath support

On Mon, Nov 28, 2016 at 9:47 AM, Pavel Stehule wrote > > > I thought by adding my first implementation to "contrib", we could make > this functionality available to end-users, even before there was a > consensus about what PG's "official" JSON-related operators should have for > syntax and semanti

Re: [HACKERS] Patch to implement pg_current_logfile() function

Hi Gilles, On Sun, 27 Nov 2016 21:54:46 +0100 Gilles Darold wrote: > I've attached the v15 of the patch that applies your changes/fixes and > remove the call to strtok(). I like the idea of replacing the strtok() call with sscanf() but I see problems. It won't work if log_filename begins with

Re: [HACKERS] Tackling JsonPath support

On Mon, Nov 28, 2016 at 9:40 AM, Pavel Stehule wrote: ​...​ > > ​Hi Pavel, > > > > Can you clarify what you meant? I *think* you're saying: > > > > * It's not important for me to match the syntax/semantics of the > json-path implementations found in MySQL / Oracle / DB2 / ​MS SQL Server, > and >

[HACKERS] PSQL commands: \quit_if, \quit_unless

This patch adds two very simple psql commands: \quit_if and \quit_unless. Each takes an optional string parameter and evaluates it for truthiness via ParseVariableBool(). If a true-ish value is passed to \quit_if, psql will behave as if the user had input \quit. \quit_unless will do nothing if t

Re: [HACKERS] Tackling JsonPath support

On Mon, Nov 28, 2016 at 5:20 AM, Pavel Stehule wrote: ... > Incremental work is great idea - I like this this style. Instead contrib, > you can use public repository on github. Minimally for first stage is > better to live outside core - you are not restricted by PostgreSQL > development process.

[HACKERS] GIN non-intrusive vacuum of posting tree

Hi hackers! Here is a patch with more concurrency-friendly vacuum of GIN. ===Short problem statement=== Currently GIN vacuum during cleaning posting tree can lock this tree for a long time without real need. ===Problem statement=== Vacuum of posting tree (function ginVacuumPostingTree() in ginva

Re: [HACKERS] UNDO and in-place update

On Sun, Nov 27, 2016 at 10:44 PM, Amit Kapila wrote: > On Mon, Nov 28, 2016 at 4:50 AM, Robert Haas wrote: >> Well, my original email did contain a discussion of the need for >> delete-marking. I said that you couldn't do in-place updates when >> indexed columns were modified unless the index AM

Re: [HACKERS] Tackling JsonPath support

On Mon, Nov 28, 2016 at 5:20 AM, Pavel Stehule wrote: ​...​ > Con: "JSON path expression" is a recurring them in the *grammars* of >> user-facing operators in [1], [2], [3], and [4]. But it doesn't >> necessarily follow that the function implemented in Step 2 will provide >> useful infrastructur

Re: [HACKERS] pg_dump / copy bugs with "big lines" ?

I just wrote: > The big advantage of your v3 patch is that it can be backpatched without > fear of breaking ABI, so I've struggled to maintain that property in my > changes. We can further tweak in HEAD-only; for example change the API > to use Size instead of int. I think that would be desirabl

Re: [HACKERS] HASH_CHUNK_SIZE vs malloc rounding

Thomas Munro writes: > I bet other allocators also do badly with "32KB plus a smidgen". To > minimise overhead we'd probably need to try to arrange for exactly > 32KB (or some other power of 2 or at least factor of common page/chunk > size?) to arrive into malloc, which means accounting for both

Re: [HACKERS] Autovacuum breakage from a734fd5d1

Robert Haas writes: > I don't believe we should be so scared of the possibility of a serious > bug that can't be found through any of the ways we normally test that > we aren't willing to fix problems we can readily foresee. I grant > that there are some situations where fixing a problem might in

Re: [HACKERS] Wrong order of tests in findDependentObjects()

Jim Nasby writes: > On 11/27/16 10:15 AM, Tom Lane wrote: >> Yeah, I was wondering about that yesterday --- that comment mentions >> the case of temporary objects, but it only fixes the problem while the >> script runs. Maybe there should be a separate test for "we're doing >> temporary-object cl

Re: [HACKERS] pg_dump / copy bugs with "big lines" ?

Daniel Verite wrote: > And in enlargeStringInfo() the patch adds this: > /* >* Maximum size for strings with allow_long=true. >* It must not exceed INT_MAX, as the StringInfo routines >* expect offsets into the buffer to fit into an int. >*/ > const int

Re: [HACKERS] Tackling JsonPath support

Dne 28. 11. 2016 17:26 napsal uživatel "David Fetter" : > > On Sun, Nov 27, 2016 at 11:50:30AM -0500, Christian Convey wrote: > > >From looking at other databases' docs, it seems like the behavior of > > various JSON-related operators / functions are described partially in terms > > of a "json path

Re: [HACKERS] A bug of psql completion

Kyotaro HORIGUCHI writes: > I noticed that the psql completion code for "ALTER TABLE x ALTER > [COLUMN] x DROP" is wrong. It works as the following > =# alter table x alter x drop > [nothing suggested] > =# alter table x table x alter x drop > DEFAULT NOT NULL > The attached patch fixes it

Re: [HACKERS] Alternative MATERIALIZED VIEW design and implementation with history table and other features

On Sat, Nov 26, 2016 at 04:13:19PM -0600, Jim Nasby wrote: > On 11/22/16 9:11 PM, Nico Williams wrote: > >But we needed a method for recording deltas from REFRESHes, and that's > >not supported. So I coded up my own version of materialized views, in > >PlPgSQL, that does provide a history feature.

Re: [HACKERS] Tackling JsonPath support

On Sun, Nov 27, 2016 at 11:50:30AM -0500, Christian Convey wrote: > >From looking at other databases' docs, it seems like the behavior of > various JSON-related operators / functions are described partially in terms > of a "json path expression": > > * In Oracle, "JSON_TABLE", "JSON_exists_column"

Re: [HACKERS] [PATCH] pgpassfile connection option

Hello Julian, I've adressed those spacing errors. Ok. You are right, if pgpassfile_used is true, it SHOULD be defined, I just like to be careful whenever I'm working with strings. But I guess in this scenario I can trust the caller and omit those checks. Good. Patch looks ok, applies, c

Re: [HACKERS] [PATCH] ALTER DEFAULT PRIVILEGES with GRANT/REVOKE ON SCHEMAS

Just sending the same patch but rebase with current master (it was broken for gram.y after new commits). Best regards, diff --git a/doc/src/sgml/ref/alter_default_privileges.sgml b/doc/src/sgml/ref/alter_default_privileges.sgml index 04064d3..7745792 100644 *** a/doc/src/sgml/ref/alter_default_pri

Re: [HACKERS] Proposal: scan key push down to heap [WIP]

On Mon, Nov 28, 2016 at 4:30 AM, Dilip Kumar wrote: > On Sat, Nov 19, 2016 at 6:48 PM, Dilip Kumar wrote: >> patch1: Original patch (heap_scankey_pushdown_v1.patch), only >> supported for fixed length datatype and use heap_getattr. >> >> patch2: Switches memory context in HeapKeyTest + Store tupl

Re: [HACKERS] UNDO and in-place update

On Sun, Nov 27, 2016 at 09:19:06AM +0530, Amit Kapila wrote: > At this point, index scan for value 2 will find index tuple of step-1 > (2) and will conclude 2,def as a right tuple, but actually, that is > wrong as the step-1 (2) index tuple should not be visible to the user. > Do you also this as a

Re: [HACKERS] Mail thread references in commits

Magnus Hagander wrote: > I don't really read perl enough to take it apart. But > http://git.kernel.org/cgit/git/git.git/tree/gitweb/gitweb.perl is the code > (we're probably on an older version). I'm guessing it's coming out of > format_log_line ( > http://git.kernel.org/cgit/git/git.git/tree/gitw

Re: [HACKERS] Declarative partitioning - another take

Here are some comments on 0003 patch. 1. In ALTER TABLE documentation we should refer to CREATE TABLE documentation for partition_bound_spec syntax, similar ADD table_constraint note. 2. I think, "of the target table" is missing after all the ... constraints + match. Also, it must have all t

Re: [HACKERS] User-defined Operator Pushdown and Collations

On Sun, Nov 27, 2016 at 11:50 AM, Tom Lane wrote: > Paul Ramsey writes: > > On Sun, Nov 27, 2016 at 9:31 AM, Tom Lane wrote: > >> Why doesn't hs_fdw.h have a collation? > > > I think I'm missing something, I cannot find a file like that anywhere. > > I was referring to the variable shown in you

Re: [HACKERS] [PATCH] pgpassfile connection option

Fabien Coelho wrote: A few detailed comments: Beware of spacing: . "if(" -> "if (" (2 instances) . " =='\0')" -> " == '\0')" (at least one instance) Elsewhere: + if (conn->pgpassfile_used && conn->password_needed && conn->result && + conn->pgpassfile && conn->pgpassfile[0]!='\0' && IS

Re: [HACKERS] Tackling JsonPath support

2016-11-27 17:50 GMT+01:00 Christian Convey : > From looking at other databases' docs, it seems like the behavior of > various JSON-related operators / functions are described partially in terms > of a "json path expression": > > * In Oracle, "JSON_TABLE", "JSON_exists_column", "JSON_value_column"

Re: [HACKERS] make default TABLESPACE belong to target table.

On Sat, Nov 26, 2016 at 9:46 PM, Tom Lane wrote: > Amit Kapila writes: >> What will such a storage parameter (default_tablespace) mean at table >> level and how it will different from existing default_tablespace? I >> think the usage asked by Amos is quite genuine, but not sure if >> introducing

Re: [HACKERS] pg_dump / copy bugs with "big lines" ?

Alvaro Herrera wrote: > I propose to rename allow_long to huge_ok. "Huge" is the terminology > used by palloc anyway. I'd keep makeLongStringInfo() and > initLongStringInfo() though as interface, because using Huge instead of > Long there looks strange. Not wedded to that, though (parti

Re: [HACKERS] proposal: session server side variables

Hi 2016-11-28 10:39 GMT+01:00 Artur Zakirov : > On 28.11.2016 10:42, Pavel Stehule wrote: > >> >> next update - setattr, getattr functions are working now >> >> notes, comments? >> >> Regards >> >> Pavel >> >> > It is interesting! > > Do you have plans to support also table variables? For example

Re: [HACKERS] Mail thread references in commits

On Mon, Nov 28, 2016 at 3:36 AM, Tom Lane wrote: > Magnus Hagander writes: > > Ok, we now have it. https://postgr.es/m/messageid will redirect to that > > messageid in the main archives. > > I pushed a patch using this new convention: > https://git.postgresql.org/gitweb/?p=postgresql.git;a=commi

Re: [HACKERS] Quorum commit for multiple synchronous replication.

On Sat, Nov 26, 2016 at 10:27 PM, Michael Paquier wrote: > On Tue, Nov 15, 2016 at 7:08 PM, Masahiko Sawada > wrote: >> Attached latest version patch incorporated review comments. After more >> thought, I agree and changed the value of standby priority in quorum >> method so that it's not set 1

Re: [HACKERS] Physical append-only tables

On Mon, Nov 28, 2016 at 9:05 AM, Jim Nasby wrote: > On 11/24/16 8:18 AM, Bruce Momjian wrote: >>> >>> What if we used BRIN to find heap pages where the new row was in the >>> page BRIN min/max range, and the heap page had free space. Only if >>> that >>> fails do we put is somewhere e

Re: [HACKERS] Push down more full joins in postgres_fdw

On 2016/11/24 21:45, Etsuro Fujita wrote: On 2016/11/22 18:28, Ashutosh Bapat wrote: The comments should explain why is the assertion true. +/* Shouldn't be NIL */ +Assert(tlist != NIL); I noticed that I was wrong; in the Assertion the tlist can be empty. An example for such

Re: [HACKERS] Radix tree for character conversion

Hello. I'll be off line until at least next Monday. So I move this to the next CF by myself. At Wed, 09 Nov 2016 17:38:53 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20161109.173853.77274443.horiguchi.kyot...@lab.ntt.co.jp> > Hello, thank you for polishing this. > > At Wed, 9 Nov

Re: [HACKERS] asynchronous execution

Hello, I cannot respond until next Monday, so I move this to the next CF by myself. At Tue, 15 Nov 2016 20:25:13 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20161115.202513.268072050.horiguchi.kyot...@lab.ntt.co.jp> > Hello, this is a maintenance post of reased patches. > I added

[HACKERS] Fix comment in build_simple_rel

Attached fixes reference in a comment to a non-existent function: s/GetRelationInfo/get_relation_info/g Thanks, Amit diff --git a/src/backend/optimizer/util/relnode.c b/src/backend/optimizer/util/relnode.c index deef560..d5326e6 100644 --- a/src/backend/optimizer/util/relnode.c +++ b/src/backend/

[HACKERS] A bug of psql completion

Hello. I noticed that the psql completion code for "ALTER TABLE x ALTER [COLUMN] x DROP" is wrong. It works as the following =# alter table x alter x drop [nothing suggested] =# alter table x table x alter x drop DEFAULT NOT NULL The attached patch fixes it. -- Kyotaro Horiguchi NTT Open

Re: [HACKERS] proposal: session server side variables

On 28.11.2016 10:42, Pavel Stehule wrote: next update - setattr, getattr functions are working now notes, comments? Regards Pavel It is interesting! Do you have plans to support also table variables? For example, like this: create type composite_type_2 as (a int, b text); create variable

Re: [HACKERS] Proposal: scan key push down to heap [WIP]

On Mon, Nov 28, 2016 at 3:00 PM, Dilip Kumar wrote: > As promised, I have taken the performance with TPCH benchmark and > still result are quite good. However this are less compared to older > version (which was exposing expr ctx and slot to heap). > > Query Head [1] Patch3

  1   2   >