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. However, I feel that this pr

Re: [HACKERS] Gather Merge

På torsdag 09. mars 2017 kl. 18:09:45, skrev Robert Haas mailto:robertmh...@gmail.com>>: 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 that just working fine. > > Attaching patch, with

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 corresponding two different >>> arrays in AppendState node. Handling

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 basically

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 quest

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 >>> w

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 index OID in the tag. -

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 fo

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 patch. Even I forced the gather merge > > in 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); >>> >>> No

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? > > Is there an implication for SIREAD locks? Predic

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 mailto:andr...@visena.com>> wrote: På torsdag 09. mars 2017 kl. 18:09:45, skrev Robert Haas mailto:robertmh...@gmail.c

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 > scanning the array of plans. But wi

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 kl. 18:09:45, skrev Robert Haas < >> robe

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 mailto:andr...@visena.com>> wrote: [...] The execution-plan seems (unsurprisingly) to depend on data-distribution, so

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 S

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, qu

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 > wrote: > >>> > >>> On 28 February 2017 at 11:34, Ashutosh Sharma > wro

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 execution-plan seems (unsurprisingly) to depend on da

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. An

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) 0001-Rewrite-hash-index-scans-to-work-a-page-at

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 mailto:andr...@visena.com>> wrote: På fredag 10. mars 2017 kl. 10:09:22, skrev Rushabh Lathia mailto:rushabh.lat...@gm

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 successful binding to a port. I'm not sure if

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 there. I'm getting this error on CentOS6.8, pe

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 2017 kl. 10:09:22, skrev Rushabh Lathia > >> : > >> >

Re: [HACKERS] Parallel Append implementation

Moin, On Fri, March 10, 2017 3:24 am, Amit Khandekar wrote: > 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 deriv

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

On Fri, Mar 10, 2017 at 3:58 PM, Jim Nasby wrote: > On 3/6/17 8:34 PM, Masahiko Sawada wrote: >> >> I don't think it can say "1 frozen pages" because the number of >> skipped pages according to visibility map is always more than 32 >> (SKIP_PAGES_THRESHOLD). > > > That's just an artifact of how th

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

On Fri, Mar 10, 2017 at 11:43 AM, Amit Kapila wrote: > On Fri, Mar 10, 2017 at 10:51 AM, Tom Lane wrote: >> >> Also, I see clam reported in green just now, so it's not 100% >> reproducible :-( >> > > Just to let you know that I think I have figured out the reason of > failure. If we run the regr

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

On Fri, Mar 10, 2017 at 11:51 AM, Tom Lane wrote: > Amit Kapila writes: >> Just to let you know that I think I have figured out the reason of >> failure. If we run the regressions with attached patch, it will make >> the regression tests fail consistently in same way. The patch just >> makes al

Re: [HACKERS] New CORRESPONDING clause design

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 a case > of set operation without corresponding clause. The attached patch is > corrected as such .I add t

Re: [HACKERS] Enabling parallelism for queries coming from SQL or other PL functions

On Wed, Mar 8, 2017 at 1:54 AM, Robert Haas wrote: > > Here's a draft patch showing the sort of thing I have in mind. I > think it needs more work, but it gives you the idea, I hope. This is > loosely based on your pl_parallel_exec_support_v1.patch, but what I've > done here is added some flags

Re: [HACKERS] Write Ahead Logging for Hash Indexes

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 dirty), if so >> why? Are you worried about restoration of FPI or something else? > > I haven't thought through all of the possible co

Re: [HACKERS] Declarative partitioning optimization for large amount of partitions

Hi Tels, Thanks a lot for the review! > "corresponding" Fixed. > Also a question: Some one-line comments are > > /* Comment. */ > > while others are > > /* > * Comment. > */ > > Why the difference? I'm trying to follow a code stile used in a code I'm modifying. In this case I got an

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 a case >> of set operation without corresponding

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 dirty), if so >>> why? Are you worried about restoration of FPI or something

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 numbers

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 qu

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 wrote: Do we really need to set LSN on this page (or mark it dirty), if so w

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 s

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 applied? > > I already had t

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 mod

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 co

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: 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 pos

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 function

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 connect

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, I

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 to vote against that, because startup is ge

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, Remot

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 consider differentiating

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 direct

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 u

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] 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 to "expand > "intcol <@ >

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 > buffer safe without setting LSN

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] 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 submit a > proposal to Goog

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

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 variants: schema_tabl

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: schema_table, table_sch

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? This

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 http://www

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 rebased version. Thank y

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 EXTENDED_DESCRIBE_SORT size_desc >> > > \dt+ >> > > \l+ >> >

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 I

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 namin

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 realizing there's an issue.

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 party) as a filter is a co

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, so I've just changed th

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 > protections are now enab

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 one. > Even a default c

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 t

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 GitHub, and postgresql.git

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 stil

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 should include it at th

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 with the number of subpa

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 ea

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. Thanks

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 detai

[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 have not seen much interest in

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. > > > > There might be other

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 > > https://www.postgresql.org/message-id/cad__ougk12zqmwwjzim-yyud1y8jmmy6x9yectnif3rpp6h...@mail.gmail.c

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 'P' is that there are fewer places where 'P'

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. We

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] 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 o

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] 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/ Pos

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 v

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 combinati

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] 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 in

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 > pr

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 slightly, I have not

Re: [HACKERS] Explicit subtransactions for PL/Tcl

On Thu, 9 Mar 2017 12:04:31 +0100 Pavel Stehule wrote: > > Now test demonstrate how errors uncaught on the Tcl level interact > > with postgresql error system. > > > > you can catch the exception outside and write own message OK, here is patch with tests which don't depend on function OIDs Th

Re: [HACKERS] WIP: Faster Expression Processing v4

On 2017-03-10 09:00:14 -0500, Peter Eisentraut wrote: > 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? I'd really like to get it in. The performanc

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

On 2017-03-10 01:59:53 -0500, Peter Eisentraut wrote: > On 3/8/17 16:49, Andres Freund wrote: > >> make check-world -j2 seems to run fine for me. > > > > Hm, I at least used to get a lot of spurious failures with this. I > > e.g. don't think the free port selection is race free. > > I was also no

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 of injecting a > >> ProjectSet node we'd

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

On 3/10/17 1:09 PM, Peter Eisentraut wrote: 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. I don't think platfor

  1   2   >