Re: [HACKERS] ANALYZE command progress checker

On 3/6/17 12:49 AM, Michael Paquier wrote: On Sat, Mar 4, 2017 at 5:33 AM, David Steele wrote: I think the idea of a general progress view is very valuable and there are a ton of operations it could be used for: full table scans, index rebuilds, vacuum, copy, etc.

Re: [HACKERS] Gather Merge

På torsdag 09. mars 2017 kl. 18:09:45, skrev Robert Haas >: On Thu, Mar 9, 2017 at 11:25 AM, Rushabh Lathia wrote: > I don't see this failure with the patch. Even I forced the gather merge > in the above query and

Re: [HACKERS] Parallel Append implementation

On 10 March 2017 at 12:33, Ashutosh Bapat wrote: > On Fri, Mar 10, 2017 at 11:33 AM, Ashutosh Bapat > wrote: >>> >>> But as far as code is concerned, I think the two-list approach will >>> turn out to be less simple if we derive

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

2017-03-09 20:10 GMT+01:00 Peter Eisentraut < peter.eisentr...@2ndquadrant.com>: > This is looking pretty neat. I played around with it a bit. There are > a couple of edge cases that you need to address, I think. > Thanks, original code is very synoptical and and well prepared for adding new

Re: [HACKERS] Gather Merge

On Fri, Mar 10, 2017 at 1:44 PM, Andreas Joseph Krogh wrote: > På torsdag 09. mars 2017 kl. 18:09:45, skrev Robert Haas < > robertmh...@gmail.com>: > > On Thu, Mar 9, 2017 at 11:25 AM, Rushabh Lathia > wrote: > > I don't see this failure with the

Re: [HACKERS] Parallel Append implementation

On 10 March 2017 at 14:05, Ashutosh Bapat wrote: >> The need for >> num_workers=-1 will still be there for partial plans, because we need >> to set it to -1 once a worker finishes a plan. >> > > IIRC, we do that so that no other workers are assigned to it when >

Re: [HACKERS] PassDownLimitBound for ForeignScan/CustomScan [take-2]

Hello, On Wed, March 1, 2017 7:21 pm, Kouhei Kaigai wrote: >> I've looked at the patch, and as I'm not that familiar with the >> pg-sourcecode, >> customs and so on, this isn't a review, more like food for thought and >> all >> should be taken with a grain of salt. :) >> >> So here are a few

Re: [HACKERS] Need a builtin way to run all tests faster manner

On 3/7/17 9:52 PM, Magnus Hagander wrote: There have also on and off been discussions about building arbitrary patches as they are sent to the mailinglists. Doing that without any committer (or other trusted party) as a filter is a completely different challenge of course, given that it

Re: [HACKERS] Parallel Append implementation

>>> >>> I think there is some merit in separating out non-parallel and >>> parallel plans within the same array or outside it. The current logic >>> to assign plan to a worker looks at all the plans, unnecessarily >>> hopping over the un-parallel ones after they are given to a worker. If >>>

Re: [HACKERS] REINDEX CONCURRENTLY 2.0

On Wed, Mar 8, 2017 at 4:12 PM, Andres Freund wrote: > Can you come up with an halfway realistic scenario why an index oid, not > a table, constraint, sequence oid, would be relied upon? Is there an implication for SIREAD locks? Predicate locks on index pages include the

Re: [HACKERS] Partitioned tables and relfilenode

On 2017/03/08 22:36, Robert Haas wrote: > On Wed, Mar 8, 2017 at 5:36 AM, Amit Langote wrote: >>> -rel = mtstate->resultRelInfo->ri_RelationDesc; >>> +nominalRTE = rt_fetch(node->nominalRelation, estate->es_range_table); >>> +nominalRel = heap_open(nominalRTE->relid, NoLock); >>> >>>

Re: [HACKERS] REINDEX CONCURRENTLY 2.0

On Fri, Mar 10, 2017 at 9:36 PM, Thomas Munro wrote: > On Wed, Mar 8, 2017 at 4:12 PM, Andres Freund wrote: >> Can you come up with an halfway realistic scenario why an index oid, not >> a table, constraint, sequence oid, would be relied upon? >

Re: [HACKERS] Gather Merge

På fredag 10. mars 2017 kl. 09:53:47, skrev Rushabh Lathia < rushabh.lat...@gmail.com >:     On Fri, Mar 10, 2017 at 1:44 PM, Andreas Joseph Krogh > wrote: På torsdag 09. mars 2017 kl. 18:09:45, skrev Robert Haas

Re: [HACKERS] Gather Merge

On Fri, Mar 10, 2017 at 2:33 PM, Andreas Joseph Krogh wrote: > På fredag 10. mars 2017 kl. 09:53:47, skrev Rushabh Lathia < > rushabh.lat...@gmail.com>: > > > > On Fri, Mar 10, 2017 at 1:44 PM, Andreas Joseph Krogh > wrote: >> >> På torsdag 09. mars 2017

Re: [HACKERS] New CORRESPONDING clause design

Yes, you are correct it should to work on CORRESPONDING clause case. SQL 20nn standard draft only said each query to be of the same degree in a case of set operation without corresponding clause. The attached patch is corrected as such .I add those new test case to regression test too Regards

Re: [HACKERS] Gather Merge

På fredag 10. mars 2017 kl. 10:09:22, skrev Rushabh Lathia < rushabh.lat...@gmail.com >:     On Fri, Mar 10, 2017 at 2:33 PM, Andreas Joseph Krogh > wrote: [...] The execution-plan seems (unsurprisingly) to depend

Re: [HACKERS] [PATCH]: fix bug in SP-GiST box_ops

On 10.03.2017 02:13, Tels wrote: I can't comment on the code, but the grammar on the comments caught my eye: +/* Can any range from range_box does not extend higher than this argument? */ +static bool +overLower2D(RangeBox *range_box, Range *query) +{ + return FPle(range_box->left.low,

Re: [HACKERS] Should we cacheline align PGXACT?

On Wed, Mar 1, 2017 at 6:44 PM, Ashutosh Sharma wrote: > On Wed, Mar 1, 2017 at 5:29 PM, Simon Riggs wrote: > > > > On 1 March 2017 at 04:50, Ashutosh Sharma wrote: > >> > >> On Tue, Feb 28, 2017 at 11:44 PM, Simon Riggs

Re: [HACKERS] Gather Merge

On Fri, Mar 10, 2017 at 2:42 PM, Andreas Joseph Krogh wrote: > På fredag 10. mars 2017 kl. 10:09:22, skrev Rushabh Lathia < > rushabh.lat...@gmail.com>: > > > > On Fri, Mar 10, 2017 at 2:33 PM, Andreas Joseph Krogh > wrote: >> >> [...] >> The

Re: [HACKERS] [PATCH] Teach Catalog.pm how many attributes there should be per DATA() line

Jeff Janes writes: > On Thu, Mar 9, 2017 at 3:20 PM, Robert Haas wrote: > >> Committed. Hopefully this doesn't contain any Perl bits that are >> sufficiently new as to cause problems for our older BF members ... I >> guess we'll see. > > Bad luck

Re: [HACKERS] Gather Merge

On Fri, Mar 10, 2017 at 4:09 PM, Kuntal Ghosh wrote: > On Fri, Mar 10, 2017 at 3:04 PM, Rushabh Lathia > wrote: > > > > > > On Fri, Mar 10, 2017 at 2:42 PM, Andreas Joseph Krogh < > andr...@visena.com> > > wrote: > >> > >> På fredag 10. mars

Re: [HACKERS] rename pg_log directory?

On 03/09/2017 11:25 PM, Bruce Momjian wrote: "data" and "base" where chosen because it is a "data-base", but with the pg_ prefixes it would be a pg_data_pg_base. ;-) Haha, I had not spotted that one despite always naming my data directory "data" while developing. Fun little tidbit there.

Re: [HACKERS] Page Scan Mode in Hash Index

Hi, Ashutosh! I've assigned to review this patch. At first, I'd like to notice that I like idea and general design. Secondly, patch set don't apply cleanly to master. Please, rebase it. On Tue, Feb 14, 2017 at 8:27 AM, Ashutosh Sharma wrote: > 1)

Re: [HACKERS] Gather Merge

På fredag 10. mars 2017 kl. 10:34:48, skrev Rushabh Lathia < rushabh.lat...@gmail.com >:     On Fri, Mar 10, 2017 at 2:42 PM, Andreas Joseph Krogh > wrote: På fredag 10. mars 2017 kl. 10:09:22, skrev Rushabh Lathia

Re: [HACKERS] Upgrading postmaster's log messages about bind/listen errors

Moin, On Thu, March 9, 2017 11:43 pm, Tom Lane wrote: > Robert Haas writes: >> On Thu, Mar 9, 2017 at 4:01 PM, Joe Conway wrote: >>> On 03/09/2017 12:27 PM, Tom Lane wrote: For good measure I also added a DEBUG1 log message reporting

Re: [HACKERS] Adding support for Default partition in partitioning

>I agree that adding a new partition should not move any data out of the default. It's easy enough to set up a monitor to watch for data existing in the >default. Perhaps also adding a column to pg_partitioned_table that contains the oid of the default partition so it's easier to identify from a

Re: [HACKERS] Report the number of skipped frozen pages by manual VACUUM

On 3/10/17 5:08 AM, Masahiko Sawada wrote: BTW, I think there's already a function that handles the pluralization for you. IIRC it's one of the things you can add to an ereport() call. What is the function name? A quick `git grep plural` shows errdetail_plural and errmsg_plural. -- Jim Nasby,

Re: [HACKERS] PATCH: Batch/pipelining support for libpq

Hi, I notice that PQsetSingleRowMode() doesn't work when getting batch results. The function is documented as: " int PQsetSingleRowMode(PGconn *conn); This function can only be called immediately after PQsendQuery or one of its sibling functions, before any other operation on the

Re: [HACKERS] PATCH: psql show index with type info

* Robert Haas (robertmh...@gmail.com) wrote: > On Mon, Mar 6, 2017 at 9:30 AM, Stephen Frost wrote: > > * Amos Bird (amosb...@gmail.com) wrote: > >> Well, the prefix is used to differentiate other \d commands, like > >> this, > > > > Ah, ok, fair enough. > > > > Should we

Re: [HACKERS] Should buffer of initialization fork have a BM_PERMANENT flag

On 10.03.2017 04:00, Michael Paquier wrote: On Thu, Mar 9, 2017 at 10:25 PM, Artur Zakirov wrote: I think this is good fixes. I've checked them. And in my opinion they are correct. The code also is good. Having something with conflicts is not nice, so attached is a

Re: [HACKERS] Write Ahead Logging for Hash Indexes

On Fri, Mar 10, 2017 at 8:02 AM, Amit Kapila wrote: > I was thinking that we will use REGBUF_NO_IMAGE flag as is used in > XLOG_HEAP2_VISIBLE record for heap buffer, that will avoid any extra > I/O and will make it safe as well. I think that makes registering the >

Re: [HACKERS] GSOC Introduction / Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions

[including Mengxing Liu in response, for reasons that should become obvious below...] Hi George, On Thu, Mar 9, 2017 at 6:49 PM, George Papadrosou wrote: > my name is George Papadrosou, this is my first semester as > graduate student at Georgia Tech and would like to

Re: [HACKERS] Write Ahead Logging for Hash Indexes

On Fri, Mar 10, 2017 at 7:08 AM, Amit Kapila wrote: > On Fri, Mar 10, 2017 at 8:49 AM, Robert Haas wrote: >> On Thu, Mar 9, 2017 at 9:34 PM, Amit Kapila wrote: >>> Do we really need to set LSN on this page (or mark it

Re: [HACKERS] tzdata2017a breaks timestamptz regression test

Tom Lane wrote: > For the cases involving the America/Santiago zone, I'm a bit inclined > to just switch that to America/New_York, which seems much less likely > to get fooled with by IANA. But I'm wondering if Alvaro had a specific > reason for using the Santiago zone in those test cases. No,

Re: [HACKERS] WIP: Faster Expression Processing v4

I have also looked at the 0002 and 0003 patches, and they seem OK, but they are obviously not of much use without 0004. What is your ambition for getting 0004 reviewed and committed for PG10? -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support,

Re: [HACKERS] rename pg_log directory?

On Fri, Mar 10, 2017 at 11:23:54AM +0100, Andreas Karlsson wrote: > On 03/09/2017 11:25 PM, Bruce Momjian wrote: > >"data" and "base" where chosen because it is a "data-base", but with the > >pg_ prefixes it would be a pg_data_pg_base. ;-) > > Haha, I had not spotted that one despite always

Re: [HACKERS] New CORRESPONDING clause design

Hi 2017-03-10 12:55 GMT+01:00 Pavel Stehule : > > > 2017-03-10 10:13 GMT+01:00 Surafel Temesgen : > >> Yes, you are correct it should to work on CORRESPONDING clause case. SQL >> 20nn standard draft only said each query to be of the same degree in

Re: [HACKERS] Write Ahead Logging for Hash Indexes

On Fri, Mar 10, 2017 at 6:21 PM, Robert Haas wrote: > On Fri, Mar 10, 2017 at 7:08 AM, Amit Kapila wrote: >> On Fri, Mar 10, 2017 at 8:49 AM, Robert Haas wrote: >>> On Thu, Mar 9, 2017 at 9:34 PM, Amit Kapila

Re: [HACKERS] WIP: Faster Expression Processing v4

On 3/7/17 19:14, Andres Freund wrote: >> Why shouldn't the function itself also depend on the components of its >> return type? > Because that'd make it impossible to change the return type components - > if the return type is baked into the view that's necessary, but for a > "freestanding

Re: [HACKERS] Upgrading postmaster's log messages about bind/listen errors

Greetings, * Tels (nospam-pg-ab...@bloodgate.com) wrote: > On Thu, March 9, 2017 11:43 pm, Tom Lane wrote: > > Robert Haas writes: > >> On Thu, Mar 9, 2017 at 4:01 PM, Joe Conway wrote: > >>> +1 for making it LOG instead of DEBUG1 > > > >> I would tend

Re: [HACKERS] Re: proposal - psql: possibility to specify sort for describe commands, when size is printed

On Fri, Mar 10, 2017 at 5:16 PM, Stephen Frost wrote: > * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > > On 2/24/17 16:32, Pavel Stehule wrote: > > > set EXTENDED_DESCRIBE_SORT size_desc > > > \dt+ > > > \l+ > > > \di+ > > > > > > Possible

Re: [HACKERS] Re: proposal - psql: possibility to specify sort for describe commands, when size is printed

On 3/10/17 09:57, Pavel Stehule wrote: > PREFERRED_SORT_COLUMNS > and PREFERRED_SORT_DIRECTION ? I think the name "preferred" implies that it will be ignored if it's not found or something like that, but I don't think that's what you are implementing. -- Peter Eisentraut

Re: [HACKERS] Gather Merge

Error coming from create_gather_merge_plan() from below condition: if (memcmp(sortColIdx, gm_plan->sortColIdx, numsortkeys * sizeof(AttrNumber)) != 0) elog(ERROR, "GatherMerge child's targetlist doesn't match GatherMerge"); Above condition checks the sort column

Re: [HACKERS] Re: proposal - psql: possibility to specify sort for describe commands, when size is printed

On 2/24/17 16:32, Pavel Stehule wrote: > set EXTENDED_DESCRIBE_SORT size_desc > \dt+ > \l+ > \di+ > > Possible variants: schema_table, table_schema, size_desc, size_asc I can see this being useful, but I think it needs to be organized a little better. Sort key and sort

Re: [HACKERS] Re: proposal - psql: possibility to specify sort for describe commands, when size is printed

* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 2/24/17 16:32, Pavel Stehule wrote: > > set EXTENDED_DESCRIBE_SORT size_desc > > \dt+ > > \l+ > > \di+ > > > > Possible variants: schema_table, table_schema, size_desc, size_asc > > I can see this being useful,

Re: [HACKERS] Re: proposal - psql: possibility to specify sort for describe commands, when size is printed

2017-03-10 16:05 GMT+01:00 Peter Eisentraut < peter.eisentr...@2ndquadrant.com>: > On 3/10/17 09:57, Pavel Stehule wrote: > > PREFERRED_SORT_COLUMNS > > and PREFERRED_SORT_DIRECTION ? > > I think the name "preferred" implies that it will be ignored if it's not > found or something like that, but

Re: [HACKERS] Should we cacheline align PGXACT?

Hi, > > I agree. Probably Simon's patch for reducing pgxact access could negate > regression in pgxact alignment patch. > Ashutosh, could please you run read-write and read-only tests when both > these patches applied? I already had the results with both the patches applied. But, as I was not

Re: [HACKERS] Automatic cleanup of oldest WAL segments with pg_receivexlog

On 3/9/17 17:03, Michael Paquier wrote: > Having something like --limit-retained-segments partially addresses > it, as long as there is a way to define an automatic mode, based on > statvfs() obviously. But that is not portable/usable enough, as we have determined, I think. Have you looked into

Re: [HACKERS] PATCH: Configurable file mode mask

Peter, * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 2/28/17 20:58, David Steele wrote: > > This patch introduces a new initdb param, -u/-file-mode-mask, and a new > > GUC, file_mode_mask, to allow the default mode of files and directories > > in the $PGDATA directory to be

Re: [HACKERS] Parallel Append implementation

After giving more thought to our discussions, I have have used the Bitmapset structure in AppendPath as against having two lists one for partial and other for non-partial paths. Attached is the patch v6 that has the required changes. So accumulate_append_subpath() now also prepares the bitmapset

Re: [HACKERS] Index usage for elem-contained-by-const-range clauses

Hi, Pritam! I've assigned to review this patch. On Thu, Feb 23, 2017 at 2:17 AM, Pritam Baral wrote: > The topic has been previously discussed[0] on the -performance mailing > list, > about four years ago. > > In that thread, Tom suggested[0] the planner could be made

Re: [HACKERS] Re: proposal - psql: possibility to specify sort for describe commands, when size is printed

2017-03-10 15:16 GMT+01:00 Stephen Frost : > * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > > On 2/24/17 16:32, Pavel Stehule wrote: > > > set EXTENDED_DESCRIBE_SORT size_desc > > > \dt+ > > > \l+ > > > \di+ > > > > > > Possible variants:

Re: [HACKERS] some dblink refactoring

On 3/8/17 00:10, Tsunakawa, Takayuki wrote: > I changed the status to ready for committer. The patch applied cleanly, > passed the regression test (make installcheck in contrib/dblink/), and the > code looks perfect. > > How about applying the attached small patch for another refactoring?

Re: [HACKERS] Should we cacheline align PGXACT?

On Fri, Mar 10, 2017 at 4:01 PM, Ashutosh Sharma wrote: > > I agree. Probably Simon's patch for reducing pgxact access could negate > > regression in pgxact alignment patch. > > Ashutosh, could please you run read-write and read-only tests when both > > these patches

Re: [HACKERS] Re: proposal - psql: possibility to specify sort for describe commands, when size is printed

2017-03-10 15:10 GMT+01:00 Peter Eisentraut < peter.eisentr...@2ndquadrant.com>: > On 2/24/17 16:32, Pavel Stehule wrote: > > set EXTENDED_DESCRIBE_SORT size_desc > > \dt+ > > \l+ > > \di+ > > > > Possible variants: schema_table, table_schema, size_desc, size_asc > > I can see

Re: [HACKERS] Re: proposal - psql: possibility to specify sort for describe commands, when size is printed

2017-03-10 16:00 GMT+01:00 Alexander Korotkov : > On Fri, Mar 10, 2017 at 5:16 PM, Stephen Frost wrote: > >> * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: >> > On 2/24/17 16:32, Pavel Stehule wrote: >> > > set

Re: [HACKERS] Need a builtin way to run all tests faster manner

Magnus Hagander writes: > AFAIK travis-ci would require us to use github as our hoster for all those > things, and embrace that workflow, they don't support anything else. > > There might be others that do, just not travis. It merely requires the repository to exist on

[HACKERS] scram and \password

Should the \password tool in psql inspect password_encryption and act on it being 'scram'? I didn't see this issue discussed, but the ability to search the archives for backslashes is rather limited. Cheers, Jeff

Re: [HACKERS] SQL/JSON in PostgreSQL

On Thu, Mar 9, 2017 at 1:12 PM, Sven R. Kunze wrote: > On 08.03.2017 20:52, Magnus Hagander wrote: > > On Wed, Mar 8, 2017 at 11:48 AM, Peter van Hardenberg wrote: > >> Small point of order: YAML is not strictly a super-set of JSON. >> >> Editorializing slightly, I

Re: [HACKERS] ANALYZE command progress checker

Hi, On 2017-03-10 02:11:18 -0600, Jim Nasby wrote: > Perhaps instead of adding more clutter to \dvS we could just have a SRF for > now. I don't see that as clutter, it's useful information, and keeping it discoverable is good, not bad. > At over 2800 rows currently, you're not going to notice

Re: [HACKERS] SQL Standard Feature T211

On 3/9/17 18:39, Kevin Grittner wrote: > With the addition of transition tables we have all four, although > I'm not sure whether the CREATE TRIGGER statement conforms closely > enough to claim the feature. The two basic issues I can think of > are: > - we don't allow the OLD and NEW transition

Re: [HACKERS] SQL/JSON in PostgreSQL

On 03/09/2017 10:12 AM, Sven R. Kunze wrote: > On 08.03.2017 20:52, Magnus Hagander wrote: >> On Wed, Mar 8, 2017 at 11:48 AM, Peter van Hardenberg > > wrote: >> >> Small point of order: YAML is not strictly a super-set of JSON. >> >> Editorializing

Re: [HACKERS] Need a builtin way to run all tests faster manner

On Fri, Mar 10, 2017 at 11:29 AM, Dagfinn Ilmari Mannsåker < ilm...@ilmari.org> wrote: > Magnus Hagander writes: > > > AFAIK travis-ci would require us to use github as our hoster for all > those > > things, and embrace that workflow, they don't support anything else. > > >

Re: [HACKERS] logical replication access control patches

On 2/27/17 22:10, Stephen Frost wrote: > Peter, > > * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: >> On 2/18/17 18:06, Stephen Frost wrote: >>> I'm not convinced that it really makes sense to have PUBLICATION of a >>> table be independent from the rights an owner of a table has.

Re: [HACKERS] Need a builtin way to run all tests faster manner

On 3/10/17 03:27, Jim Nasby wrote: > Perhaps https://travis-ci.org/ or something similar could be used for > this. That avoids any issues about random code. That doesn't achieve any platform coverage, which is the main point here. -- Peter Eisentraut http://www.2ndQuadrant.com/

Re: [HACKERS] Adding support for Default partition in partitioning

On 3/2/17 21:40, Robert Haas wrote: > On the point mentioned above, I > don't think adding a partition should move tuples, necessarily; seems > like it would be good enough - maybe better - for it to fail if there > are any that would need to be moved. ISTM that the uses cases of various

Re: [HACKERS] Upgrading postmaster's log messages about bind/listen errors

On 3/9/17 23:43, Tom Lane wrote: > However, if we're measuring this on a scale of usefulness to the average > DBA, I would argue that it's of more interest than any of these messages > that currently appear by default: > > 2017-03-09 23:40:12.334 EST [19335] LOG: MultiXact member wraparound >

Re: [HACKERS] Bizarre choice of case for RELKIND_PARTITIONED_TABLE

I wrote: > Robert Haas writes: >> On Tue, Mar 7, 2017 at 12:55 PM, Tom Lane wrote: >>> Is there a good reason why RELKIND_PARTITIONED_TABLE is 'P' not 'p'? >> I can't muster a lot of outrage about this one way or another. One >> possible advantage of

Re: [HACKERS] Need a builtin way to run all tests faster manner

On 3/10/17 13:02, Magnus Hagander wrote: > for their largest feature development. Could be a good idea to for > example ave an example yml file somewhere on the wiki that people could > put into their branches. https://github.com/petere/postgresql/blob/travis/.travis.yml -- Peter Eisentraut

Re: [HACKERS] WIP: Faster Expression Processing v4

On 2017-03-10 08:51:25 -0500, Peter Eisentraut wrote: > On 3/7/17 19:14, Andres Freund wrote: > >> Why shouldn't the function itself also depend on the components of its > >> return type? > > Because that'd make it impossible to change the return type components - > > if the return type is baked

Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

Robert Haas wrote: > On Wed, Mar 8, 2017 at 2:30 PM, Alvaro Herrera > wrote: > > Not really -- it's a bit slower actually in a synthetic case measuring > > exactly the slowed-down case. See > >

Re: [HACKERS] logical replication access control patches

On 3/3/17 10:07, Stephen Frost wrote: > Will users really understand that the PUBLISH right actually allows > complete access to the entire relation, rather than just the ability for > a user to PUBLISH what they are currently about to SELECT? It certainly > doesn't seem intuitive to me, which is

Re: [HACKERS] [PATCH] Enabling atomics on ARM64

Hi, On 2017-03-08 19:18:04 -0800, Roman Shaposhnik wrote: > I'd like to offer a forward port from a change I'm contributing > the Greenplum code base over here I think the change makes sense. Any chance we could convince you to bring up an arm64 buildfarm animal (our test infrastructure) up, so

Re: [HACKERS] GSOC Introduction / Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions

Hi George, I am Mengxing Liu. Happy to meet someone with the same idea : ) I have been concentrating on it for a long time, reading papers, reading source codes, and discussing details with Mr Grittner. So I really understand your passion on it. But definitely I don't want all these effects

Re: [HACKERS] GSOC Introduction / Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions

Kevin, * Kevin Grittner (kgri...@gmail.com) wrote: > > [two people interested in the same GSoC project] > > It's an interesting problem to have. > > If neither of you chooses to voluntarily back down, the obvious > resolution is for the mentors to vote on the better proposal. If we > do that

Re: [HACKERS] Parallel Append implementation

On Fri, Mar 10, 2017 at 12:17 AM, Amit Khandekar wrote: > I agree that the two-lists approach will consume less memory than > bitmapset. Keeping two lists will effectively have an extra pointer > field which will add up to the AppendPath size, but this size will not > grow

Re: [HACKERS] PATCH: Configurable file mode mask

Greetings, * Tsunakawa, Takayuki (tsunakawa.ta...@jp.fujitsu.com) wrote: > From: pgsql-hackers-ow...@postgresql.org > > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of David Steele > > PostgreSQL currently requires the file mode mask (umask) to be 0077. > > However, this precludes the

Re: [HACKERS] Re: proposal - psql: possibility to specify sort for describe commands, when size is printed

On Fri, Mar 10, 2017 at 5:10 PM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 2/24/17 16:32, Pavel Stehule wrote: > > set EXTENDED_DESCRIBE_SORT size_desc > > \dt+ > > \l+ > > \di+ > > > > Possible variants: schema_table, table_schema, size_desc, size_asc >

Re: [HACKERS] [PATCH] few fts functions for jsonb

> On 28 February 2017 at 19:21, Oleg Bartunov wrote: > 1. add json support I've added json support for all functions. > Its_headline should returns the original json with highlighting Yes, I see now. I don't think it's worth it to add a special option for that purpose,

Re: [HACKERS] Upgrading postmaster's log messages about bind/listen errors

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > database system is ready to accept connections on (1.2.3.4) > > That would be a problem from a couple of directions. First, it wouldn't > be unusual for there to be half a dozen addresses to list, not just

Re: [HACKERS] GSOC Introduction / Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions

Hi all and thank you for your quick replies. > [two people interested in the same GSoC project] Mr. Grittner thank you for sharing this ahead of time. Liu(is this your first name?), > I have been concentrating on it for a long time, reading papers, reading > source codes, and discussing

Re: [HACKERS] GSOC Introduction / Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions

> [two people interested in the same GSoC project] It's an interesting problem to have. If neither of you chooses to voluntarily back down, the obvious resolution is for the mentors to vote on the better proposal. If we do that early enough during the student application period, there might

Re: [HACKERS] SQL/JSON in PostgreSQL

On 10.03.2017 05:07, Petr Jelinek wrote: The original complain was about JSON_VALUE extracting date but I don't understand why there is problem with that, the SQL/JSON defines that behavior. The RETURNING clause there is more or less just shorthand for casting with some advanced options.

Re: [HACKERS] Upgrading postmaster's log messages about bind/listen errors

Stephen Frost writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> ... So I think the logging setup I had in >> my patch is pretty much the only sane way to do it, and we just have >> to decide whether it's worth exposing at default log level or not. > I definitely think we

Re: [HACKERS] Upgrading postmaster's log messages about bind/listen errors

Stephen Frost writes: > * Tels (nospam-pg-ab...@bloodgate.com) wrote: >> I'd argue that from a security standpoint it is important to log at >> startup what addresses the service binds to, just so it is visible, >> explicit and logged. > It's also terribly useful for

Re: [HACKERS] Need a builtin way to run all tests faster manner

On Fri, Mar 10, 2017 at 3:27 AM, Jim Nasby wrote: > On 3/7/17 9:52 PM, Magnus Hagander wrote: > >> There have also on and off been discussions about building arbitrary >> patches as they are sent to the mailinglists. Doing that without any >> committer (or other trusted

Re: [HACKERS] Upgrading postmaster's log messages about bind/listen errors

2017-03-10 1:43 GMT-03:00 Tom Lane : > Yeah, my thought was that if we've gotten along without this for 20 years, > it's probably not of interest to most people most of the time. > > +1 for DEBUG1. > 2017-03-09 23:40:12.334 EST [19335] LOG: MultiXact member wraparound >

Re: [HACKERS] [PATCH] Transaction traceability - txid_status(bigint)

On Fri, Mar 10, 2017 at 2:00 AM, Craig Ringer wrote: > On 10 March 2017 at 02:55, Robert Haas wrote: >> Well, that's why I tried to advocate that their should be two separate >> XID limits in shared memory: leave what's there now the way it is, and

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

Robert Haas wrote: > The smoking gun was in 009_twophase_slave.log: > > TRAP: FailedAssertion("!(nsubxids == MyPgXact->nxids)", File: > "clog.c", Line: 288) > > ...and then the node shuts down, which is why this hangs forever. > (Also... what's up with it hanging forever instead of timing out

Re: [HACKERS] Should we eliminate or reduce HUP from docs?

David G. Johnston wrote: > On Fri, Mar 10, 2017 at 1:02 PM, Alvaro Herrera > wrote: > > There are several ways to cause a config file reload (pg_ctl reload, > > pg_reload_conf, direct SIGHUP). We could have a section in docs listing > > them all, and then all the other

Re: [HACKERS] Should buffer of initialization fork have a BM_PERMANENT flag

On Sat, Mar 11, 2017 at 12:03 AM, Artur Zakirov wrote: > Because BM_PERMANENT is used for init forks of unlogged indexes now. Yes, indeed. -- Michael diff --git a/contrib/bloom/blinsert.c b/contrib/bloom/blinsert.c index 913f1f8a51..3557b106d8 100644 ---

Re: [HACKERS] scram and \password

On Sat, Mar 11, 2017 at 2:53 AM, Jeff Janes wrote: > Should the \password tool in psql inspect password_encryption and act on it > being 'scram'? Not sure if it is wise to change the default fot this release. > I didn't see this issue discussed, but the ability to search

Re: [HACKERS] Should we eliminate or reduce HUP from docs?

On Fri, Mar 10, 2017 at 1:02 PM, Alvaro Herrera wrote: > Joshua D. Drake wrote: > > > I am a bad speaker, I am writing a talk three weeks before the conference > > (as opposed to on the plane). > > Hah. > > > I noticed in the docs we still reference the > > passing of

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

On Fri, Mar 10, 2017 at 3:40 PM, Robert Haas wrote: > Finally, I had an unexplained hang during the TAP tests while testing > out your fix patch. I haven't been able to reproduce that so it > might've just been an artifact of something stupid I did, or of some > unrelated

Re: [HACKERS] Need a builtin way to run all tests faster manner

On 3/10/17 2:18 PM, Magnus Hagander wrote: But if you can put together something that picks up the individual patches out of the mail threads in the CF app and keeps branch-tips in a git repo up-to-date with those, including feeding the results back into the app, then go for it :) Seems like

Re: [HACKERS] Should we eliminate or reduce HUP from docs?

On Fri, Mar 10, 2017 at 3:28 PM, Alvaro Herrera wrote: > David G. Johnston wrote: > > On Fri, Mar 10, 2017 at 1:02 PM, Alvaro Herrera < > alvhe...@2ndquadrant.com> > > wrote: > > > > There are several ways to cause a config file reload (pg_ctl reload, > > >

Re: [HACKERS] Should we eliminate or reduce HUP from docs?

David G. Johnston wrote: > On Fri, Mar 10, 2017 at 3:28 PM, Alvaro Herrera > wrote: > > > I think we could split 19.1.2 in two parts, where the first one is the > > current content minus the paragraph "The configuration file is reread". > > We'd create "19.1.3

Re: [HACKERS] Should we eliminate or reduce HUP from docs?

On Fri, Mar 10, 2017 at 3:51 PM, Alvaro Herrera wrote: > David G. Johnston wrote: > > On Fri, Mar 10, 2017 at 3:28 PM, Alvaro Herrera < > alvhe...@2ndquadrant.com> > > > is incomplete. > > Sure. We can just reword that along the lines of " ... and when a > reload

Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f)

On 2017-03-09 13:34:22 -0500, Robert Haas wrote: > On Mon, Jan 30, 2017 at 6:54 PM, Tom Lane wrote: > > Andres Freund writes: > >> Wonder if we there's an argument to be made for implementing this > >> roughly similarly to split_pathtarget_at_srf - instead

Re: [HACKERS] ANALYZE command progress checker

On 3/10/17 1:06 PM, Andres Freund wrote: Hi, On 2017-03-10 02:11:18 -0600, Jim Nasby wrote: Perhaps instead of adding more clutter to \dvS we could just have a SRF for now. I don't see that as clutter, it's useful information, and keeping it discoverable is good, not bad. If we keep adding

  1   2   >