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

On Wed, Mar 22, 2017 at 12:55 AM, Robert Haas wrote: > On Tue, Mar 21, 2017 at 6:36 AM, Dilip Kumar wrote: >> How about taking the decision of execute_once based on >> fcache->returnsSet instead of based on lazyEval? >> >> change >> + ExecutorRun(es->qd, ForwardScanDirection, count, !es->lazyEval

Re: [HACKERS] Create replication slot in pg_basebackup if requested and not yet present

Hello, I favor this feature. At Wed, 22 Mar 2017 00:18:19 -0400, Peter Eisentraut wrote in <1f5daba9-773d-9281-5608-37f049025...@2ndquadrant.com> > On 3/21/17 15:34, Robert Haas wrote: > > So I tend to think that there should always be some explicit user > > action to cause the creation of a sl

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

On 22 March 2017 at 03:35, Craig Ringer wrote: > On 22 March 2017 at 09:49, Craig Ringer wrote: > >>> Overall, though, I think that 0001 looks far better than any previous >>> iteration. It's simple. It looks safe. It seems unlikely to break >>> anything that works now. Woo hoo! >> >> Funny t

[HACKERS] [PATCH] Reduce src/test/recovery verbosity

Hi all Trivial patch to change 'diag' to 'note' in TAP tests in src/test/recovery attached. It'll reduce the test output a little. Those lines are there so you can tell what the test was doing before it does something if it fails at a setup step, or to provide extra diagnostic data, so they're r

Re: [HACKERS] Guidelines for GSoC student proposals / Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions

Hi, Kevin. I've finished a draft proposal for "Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions". You can find it from GSOC website or by the link below. https://docs.google.com/document/d/17TAs3EJIokwPU7UTUmnlVY3ElB-VHViyX1zkQJmrD1A/edit?usp=sharing I was wonde

Re: [HACKERS] Possible regression with gather merge.

Hi, postgres=# explain analyze select * from test order by v1, v2 limit 10; QUERY PLAN Limit (c

Re: [WIP] RE: [HACKERS] DECLARE STATEMENT setting up a connection in ECPG

On Wed, Mar 22, 2017 at 12:51 PM, Haribabu Kommi wrote: > > > On Tue, Mar 7, 2017 at 4:09 PM, Ideriha, Takeshi < > ideriha.take...@jp.fujitsu.com> wrote: > >> >> Attached 004_declareStmt_test_v5.patch is a rebased one. >> The rest of patches are same as older version. >> > > Thanks for the update

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

On Wed, Mar 22, 2017 at 8:43 AM, Pavan Deolasee wrote: > > > BTW may I request another test with the attached patch? In this patch, we > check if the PageIsFull() even before deciding which attributes to check > for modification. If the page is already full, there is hardly any chance > of doing

Re: [HACKERS] identity columns

On 3/21/17, Peter Eisentraut wrote: > On 3/21/17 16:11, Vitaly Burovoy wrote: >> My argument is consistency. >> Since IDENTITY is a property of a column (similar to DEFAULT, NOT >> NULL, attributes, STORAGE, etc.), it follows a different rule: it is >> either set or not set. If it did not set befo

Re: [HACKERS] Bug in get_partition_for_tuple

On 2017/03/13 14:41, Amit Langote wrote: > On 2017/03/13 14:31, Jeevan Ladhe wrote: >> However, In following comment in your test: >> >> -- check routing error through a list partitioned table when they key is >> null >> >> I think you want to say: >> >> -- check routing error through a list partit

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Tue, Mar 21, 2017 at 10:40 PM, Ashutosh Bapat wrote: > Here's the set of patches rebased on latest head, which also has a > commit to eliminate scans on partitioned tables. This change has > caused problems with multi-level partitioned tables, that I have not > fixed in this patch set. Also a c

Re: [HACKERS] BRIN de-summarize ranges

On 2017-02-28 04:56:43 Alvaro Herrera wrote: > Here's a small patch to make a BRIN page range unsummarized. This is > useful if data has been deleted, and the heap pages are now used for > completely different data. Hi, I tried to apply your patch and use it. Applying and "make check" were succ

Re: [HACKERS] Parallel Append implementation

Attached is the updated patch that handles the changes for all the comments except the cost changes part. Details about the specific changes are after the cost-related points discussed below. >> I wanted to take into account per­subpath parallel_workers for total >> cost of Append. Suppose the par

Re: [HACKERS] Logical decoding on standby

On 22 March 2017 at 10:51, Craig Ringer wrote: > Hi all > > Updated timeline following patch attached. > > There's a change in read_local_xlog_page to ensure we maintain > ThisTimeLineID properly, otherwise it's just comment changes. OK, so we're looking OK with the TL following. I'm splitting u

Re: [HACKERS] ANALYZE command progress checker

On 2017/03/21 21:25, Haribabu Kommi wrote: On Tue, Mar 21, 2017 at 3:41 PM, vinayak > wrote: Thank you for testing the patch on Windows platform. Thanks for the updated patch. It works good for a normal relation. But for a relation that contai

Re: [HACKERS] increasing the default WAL segment size

Hello, On Wed, Mar 22, 2017 at 9:19 AM, Robert Haas wrote: > > I'm a little worried that this whole question of changing the file > naming scheme is a diversion which will result in torpedoing any > chance of getting some kind of improvement here for v11. I don't > think the patch is all that

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

>>> > In an attempt to test the geqo side of this patch, I reduced > geqo_threshold to 6 and set enable_partitionwise_join to to true and > tried following query, which crashed, > > explain select * from prt, prt2, prt3, prt32, prt4, prt42 where prt.a > = prt2.b and prt3.a = prt32.b and prt4.a = pr

Re: [HACKERS] segfault in hot standby for hash indexes

Hi, On Wed, Mar 22, 2017 at 8:41 AM, Amit Kapila wrote: > On Tue, Mar 21, 2017 at 11:49 PM, Ashutosh Sharma > wrote: >>> >>> I can confirm that that fixes the seg faults for me. >> >> Thanks for confirmation. >> >>> >>> Did you mean you couldn't reproduce the problem in the first place, or that

[HACKERS] create_unique_path and GEQO

Hi, In create_unique_path() there's comment /* * We must ensure path struct and subsidiary data are allocated in main * planning context; otherwise GEQO memory management causes trouble. */ oldcontext = MemoryContextSwitchTo(root->planner_cxt); pathnode = makeNode(Unique

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

On Wed, Mar 22, 2017 at 3:51 AM, Mithun Cy wrote: > > CREATE INDEX testindx ON testtab (col1, col2, col3, col4, col5, col6, > col7, col8, col9); > Performance measurement tests: Ran12 times to eliminate run to run > latencies. > == > VACUUM FULL; > BEGIN; > UPDATE testtab

Re: [HACKERS] WIP: [[Parallel] Shared] Hash

Hi, Here is a new version addressing feedback from Peter and Andres. Please see below. On Wed, Mar 22, 2017 at 3:18 PM, Peter Geoghegan wrote: > On Tue, Mar 21, 2017 at 5:07 AM, Thomas Munro > wrote: >>> buffile.c should stop pretending to care about anything other than >>> temp files, IMV. 100

Re: [HACKERS] Push down more UPDATEs/DELETEs in postgres_fdw

On 2017/02/22 19:57, Rushabh Lathia wrote: Marked this as Ready for Committer. I noticed that this item in the CF app was incorrectly marked as Committed. This patch isn't committed, so I returned it to the previous status. I also rebased the patch. Attached is a new version of the patch.

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

On Tue, Mar 21, 2017 at 6:47 PM, Pavan Deolasee wrote: > >> > > Please find attached rebased patches. > Few comments on 0005_warm_updates_v18.patch: 1. @@ -806,20 +835,35 @@ hashbucketcleanup(Relation rel, Bucket cur_bucket, Buffer bucket_buf, { .. - if (callback && callback(htup, callback_state

[HACKERS] Re: [COMMITTERS] pgsql: Fix and simplify check for whether we're running as Windows serv

On 03/19/2017 11:40 PM, Tom Lane wrote: Heikki Linnakangas writes: On 03/17/2017 07:57 PM, Tom Lane wrote: This seems to have broken narwhal: It's not very nice to change the requirements in a minor version, but I don't think this would be a real problem for anyone. Not many people build Po

Re: [HACKERS] Measuring replay lag

On 21 March 2017 at 17:32, David Steele wrote: > Hi Thomas, > > On 3/15/17 8:38 PM, Simon Riggs wrote: >> >> On 16 March 2017 at 08:02, Thomas Munro >> wrote: >> >>> I agree that these states exist, but we disagree on what 'lag' really >>> means, or, rather, which of several plausible definitions

Re: [HACKERS] Measuring replay lag

On Wed, Mar 22, 2017 at 11:57 PM, Simon Riggs wrote: >>> I accept your proposal for how we handle these, on condition that you >>> write up some docs that explain the subtle difference between the two, >>> so we can just show people the URL. That needs to explain clearly the >>> difference in an i

Re: [HACKERS] Measuring replay lag

On 22 March 2017 at 11:03, Thomas Munro wrote: > Hah. Apologies for the delay -- I will post a patch with > documentation as requested within 24 hours. Thanks very much. I'll reserve time to commit it tomorrow, all else being good. -- Simon Riggshttp://www.2ndQuadrant.com/ Pos

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

On Wed, Mar 22, 2017 at 3:44 PM, Pavan Deolasee wrote: > > This looks quite weird to me. Obviously these numbers are completely > non-comparable. Even the time for VACUUM FULL goes up with every run. > > May be we can blame it on AWS instance completely, but the pattern in your > tests looks very

Re: [HACKERS] Patch to improve performance of replay of AccessExclusiveLock

On 20 March 2017 at 08:31, David Rowley wrote: > On 18 March 2017 at 21:59, Simon Riggs wrote: >> As Amit says, I don't see the gain from adding that to each xact state. >> >> I'd suggest refactoring my patch so that the existign >> MyXactAccessedTempRel becomes MyXactFlags and we can just set a

Re: [HACKERS] Measuring replay lag

On Wed, Mar 22, 2017 at 6:57 AM, Simon Riggs wrote: > Not sure whether this a 6 day lag, or we should show NULL because we > are up to date. OK, that made me laugh. Thanks for putting in the effort on this patch, BTW. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Post

Re: [HACKERS] Monitoring roles patch

On Fri, Feb 24, 2017 at 5:14 AM, Dave Page wrote: > - Adds a default role called pg_monitor > - Gives members of the pg_monitor role full access to: > pg_ls_logdir() and pg_ls_waldir() > pg_stat_* views and functions > pg_tablespace_size() and pg_database_size() > Contrib modules:

Re: [HACKERS] GUC for cleanup indexes threshold.

On Tue, Mar 21, 2017 at 8:18 PM, Peter Geoghegan wrote: >> Not only might that be unnecessary, but if we don't have a test >> demonstrating the problem, we also don't have a test demonstrating >> that a given approach fixes it. > > Preventing recycling from happening until we feel like it is proba

Re: [HACKERS] Monitoring roles patch

On Wed, Mar 22, 2017 at 11:32 AM, Robert Haas wrote: > On Fri, Feb 24, 2017 at 5:14 AM, Dave Page wrote: >> - Adds a default role called pg_monitor >> - Gives members of the pg_monitor role full access to: >> pg_ls_logdir() and pg_ls_waldir() >> pg_stat_* views and functions >> pg_tab

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

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: tested, passed Documentation:not tested The patch looks good to me. It applies clearly, passes all the te

Re: [HACKERS] scram and \password

On 03/17/2017 05:38 AM, Michael Paquier wrote: Regression tests are proving to be useful here (it would be nice to get those committed first!). I am noticing that this patch breaks connection for users with cleartext or md5-hashed verifier when "password" is used in pg_hba.conf. Are you sure? I

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Wed, Mar 22, 2017 at 3:19 PM, Ashutosh Bapat wrote: >> In an attempt to test the geqo side of this patch, I reduced >> geqo_threshold to 6 and set enable_partitionwise_join to to true and >> tried following query, which crashed, >> >> explain select * from prt, prt2, prt3, prt32, prt4, prt

Re: [HACKERS] logical replication access control patches

On 22/03/17 03:38, Peter Eisentraut wrote: > On 3/20/17 15:10, Petr Jelinek wrote: >> Hmm but REPLICATION role can do basebackup/consume wal, so how does >> giving it limited publication access help? Wouldn't we need some >> SUBSCRIPTION role/grant used instead for logical replication connections >

Re: [HACKERS] [PATCH v1] Add and report the new "in_hot_standby" GUC pseudo-variable.

On Tuesday, March 21, 2017 11:50:38 PM EDT Peter Eisentraut wrote: > On 3/17/17 13:56, Elvis Pranskevichus wrote: > > Currently, clients wishing to know when the server exits hot standby > > have to resort to polling, which is often suboptimal. > > > > This adds the new "in_hot_standby" GUC variab

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

On 21 March 2017 at 20:04, Bruce Momjian wrote: > Yes, but once it is written it will take years before those bits can be > used on most installations. Well the problem isn't most installations. On most installations it should be pretty straightforward to check the oldest database xid and compare

Re: [HACKERS] Logical replication existing data copy

On 3/20/17 16:08, Peter Eisentraut wrote: > The current patch causes a failure in the pg_dump tests, because the > generated CREATE SUBSCRIPTION commands make connection attempts that > don't work. We have the pg_dump option --no-create-subscription-slots > for this, but I suppose we should expand

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Tue, Mar 21, 2017 at 7:37 PM, Peter Geoghegan wrote: >>> Isn't that an essential part of having a refcount, in general? You >>> were the one that suggested refcounting. >> >> No, quite the opposite. My point in suggesting adding a refcount was >> to avoid needing to have a single owner. Inste

Re: [HACKERS] identity columns

On 3/22/17 03:59, Vitaly Burovoy wrote: > Column's IDENTITY behavior is very similar to a DEFAULT one. We write > "SET DEFAULT" and don't care whether it was set before or not, because > we can't have many of them for a single column. Why should we do that > for IDENTITY? One indication is that th

Re: [HACKERS] Logical replication existing data copy

On 22/03/17 13:36, Peter Eisentraut wrote: > On 3/20/17 16:08, Peter Eisentraut wrote: >> The current patch causes a failure in the pg_dump tests, because the >> generated CREATE SUBSCRIPTION commands make connection attempts that >> don't work. We have the pg_dump option --no-create-subscription-

Re: [HACKERS] increasing the default WAL segment size

Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On Tue, Mar 21, 2017 at 8:10 PM, Stephen Frost wrote: > >> We've already > >> created quite a few incompatibilities in this release, and I'm not > >> entirely eager to just keep cranking them out at top speed. > > > > That position would seem

Re: [HACKERS] Monitoring roles patch

On Wed, Mar 22, 2017 at 7:48 AM, Dave Page wrote: >> I'd be inclined to skip the rest of >> this. If an individual user wants to grant that bundle of privileges >> to a role, they can do it with or without pg_monitor. > > GRANT cannot be used in all cases, as some of the functions changed > have

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

> > I tested the applied patch, it is fixing the reported issue. Thanks for the confirmation Rafia. I have included the fix in the latest set of patches. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@

Re: [HACKERS] Monitoring roles patch

On 3/22/17 07:48, Dave Page wrote: > With the patch, complex monitoring systems can easily be setup with > something like: > > CREATE ROLE monitoring_user LOGIN; > GRANT pg_monitor TO monitoring_role; That assumes that we have thought of all the ways in which people might want to monitor things.

Re: [HACKERS] Supporting huge pages on Windows

On Wed, Mar 22, 2017 at 12:07 AM, David Steele wrote: > On 3/8/17 8:36 PM, Tsunakawa, Takayuki wrote: >> >> From: pgsql-hackers-ow...@postgresql.org >>> >>> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Ashutosh Sharma >>> To start with, I ran the regression test-suite and didn't find a

Re: [HACKERS] increasing the default WAL segment size

On 3/22/17 05:44, Beena Emerson wrote: > As stated above, the default 16MB has not changed and so we can take > this separately and not as part of this patch. It's good to have that discussion separately, but if we're planning to do it for PG10 (not saying we should), then we should have that dis

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Wed, Mar 22, 2017 at 8:46 AM, Ashutosh Bapat wrote: > I have also completed reparameterize_path_by_child() for all the > required paths. There's no TODO there now. :) The function has grown > quite long now and might take some time to review. Given the size, I > am wondering whether we should s

Re: [HACKERS] Monitoring roles patch

* Robert Haas (robertmh...@gmail.com) wrote: > On Wed, Mar 22, 2017 at 7:48 AM, Dave Page wrote: > >> I'd be inclined to skip the rest of > >> this. If an individual user wants to grant that bundle of privileges > >> to a role, they can do it with or without pg_monitor. > > > > GRANT cannot be us

Re: [HACKERS] Monitoring roles patch

Peter, * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 3/22/17 07:48, Dave Page wrote: > > With the patch, complex monitoring systems can easily be setup with > > something like: > > > > CREATE ROLE monitoring_user LOGIN; > > GRANT pg_monitor TO monitoring_role; > > That assume

Re: [HACKERS] increasing the default WAL segment size

On Tue, Mar 21, 2017 at 11:49:30PM -0400, Robert Haas wrote: > To be honest, I'd sort of forgotten about the change which is the > nominal subject of this thread - I was more focused on the patch, > which makes it configurable. I was definitely initially in favor of > raising the value, but I got

Re: [HACKERS] Patch to improve performance of replay of AccessExclusiveLock

On 22 March 2017 at 22:27, Simon Riggs wrote: > On 20 March 2017 at 08:31, David Rowley wrote: >> 0003: >> >> Is intended to be patched atop of 0002 (for master only) and revises >> this code further to remove the StandbyReleaseLockTree() function. To >> me it seems better to do this to clear up

Re: [HACKERS] Page Scan Mode in Hash Index

Hi, >> Attached patch modifies hash index scan code for page-at-a-time mode. >> For better readability, I have splitted it into 3 parts, >> > > Due to the commits on master these patches applies with hunks. > > The README should be updated to mention the use of page scan. Done. Please refer to th

Re: [HACKERS] New CORRESPONDING clause design

On Sat, Mar 18, 2017 at 7:50 PM, Tom Lane wrote: > Pavel Stehule writes: > > I have not any objection - I'll mark this patch as ready for commiter > > > I'm a little disturbed by the fact that determineMatchingColumns() > is called twice, and more disturbed by the fact that it looks to be > O(N^

Re: [HACKERS] Possible regression with gather merge.

On Wed, Mar 22, 2017 at 1:09 PM, Rushabh Lathia wrote: > In the code, gather merge consider the limit for the sort into > create_ordered_paths, > which is wrong. Into create_ordered_paths(), GM should not consider the > limit > while doing costing for the sort node. > > Attached patch fix the bug.

Re: [HACKERS] Partitioned tables and relfilenode

Off-list by accident. Re-adding the list. On Tue, Mar 21, 2017 at 10:37 AM, Robert Haas wrote: > On Tue, Mar 21, 2017 at 9:49 AM, Robert Haas wrote: >> On Tue, Mar 21, 2017 at 5:05 AM, Amit Langote >> wrote: >>> Attached updated patches. >> >> Committed 0001 after removing a comma. > > Regardi

[HACKERS] Fix for grammatical error in code-comment

I found a grammatical error in one of the code comments. The comment is made regarding the run-time of the algorithm, and references big-O performance. However the comment text uses "effective", instead of the probably more correct "efficient". The original comment reads as though the code would

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Wed, Mar 22, 2017 at 6:32 PM, Robert Haas wrote: > On Wed, Mar 22, 2017 at 8:46 AM, Ashutosh Bapat > wrote: >> I have also completed reparameterize_path_by_child() for all the >> required paths. There's no TODO there now. :) The function has grown >> quite long now and might take some time to

Re: [HACKERS] Logical decoding on standby

Hi, On 2017-03-21 09:05:26 +0800, Craig Ringer wrote: > > 0002 should be doable as a whole this release, I have severe doubts that > > 0003 as a whole has a chance for 10 - the code is in quite a raw shape, > > there's a significant number of open ends. I'd suggest breaking of bits > > that are i

[HACKERS] Metadata about relation creation & full scans.

Hi, as repeatedly previously discussed, our lack of knowledge in which release a relation has been created / fully scanned prevents us from reclaiming infomask bits (and similar), and makes debugging harder because it's unclear how for one has to go back to look for bugs. I propose that for each

Re: [HACKERS] perlcritic

> On 21 Mar 2017, at 19:20, David Steele wrote: > > On 3/6/17 12:02 PM, Dagfinn Ilmari Mannsåker wrote: >> ilm...@ilmari.org (Dagfinn Ilmari Mannsåker) writes: >> >>> Hi Peter, >>> >>> Peter Eisentraut writes: >>> I posted this about 18 months ago but then ran out of steam. [ ] Here

Re: [HACKERS] Re: [COMMITTERS] pgsql: Fix and simplify check for whether we're running as Windows serv

Heikki Linnakangas wrote: > I did some archeology, and found CheckTokenMembership() in MinGW's w32api > packages version 3.14 > (https://sourceforge.net/projects/mingw/files/MinGW/Base/w32api/w32api-3.14/, > in include/winbase.h). According to the timestamps on that download page, > that was relea

Re: [HACKERS] Metadata about relation creation & full scans.

Andres Freund writes: > I propose that for each pg_class entry we start to keep the following > additional metadata: > - CATALOG_VERSION_NO at relation creation > - PG_VERSION_NUM at relation creation > - CATALOG_VERSION_NO at last full scan by vacuum > - PG_VERSION_NUM at last full scan by vacuum

Re: [HACKERS] [GSoC] Personal presentation and request for clarification

> From: Robert Haas > Sent: 09 March 2017 01:09 > >> The project that most caught my eye was on "Implementing push-based query >> executor". >> Although it completely fits my capabilities and current research, I have >> some concerns on "The ability to understand and modify PostgresSQL executor >>

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

On Wed, Mar 22, 2017 at 8:43 AM, Pavan Deolasee wrote: > Sorry, I did not mean to suggest that you set it up wrongly, I was just > trying to point out that the test case itself may not be very practical. That is cool np!, I was just trying to explain why those tests were made if others wondered ab

Re: [HACKERS] increasing the default WAL segment size

On 3/22/17 08:46, Stephen Frost wrote: > It's not my intent to 'torpedo' this patch but I'm pretty disappointed > that we're introducing yet another initdb-time option with, as far as I > can tell, no option to change it after the cluster has started (without > some serious hackery), and continuing

Re: [HACKERS] Patch to improve performance of replay of AccessExclusiveLock

On 22 March 2017 at 13:19, David Rowley wrote: >> Given that, do you agree to me applying assign_aels_against_subxids.v1.patch >> as well? > > Does applying assign_aels_against_subxids.v1.patch still need to keep > the loop to release the subxacts? Won't this be gone already with the > subxact co

Re: [HACKERS] WIP: Faster Expression Processing v4

I've been busily hacking away on this, trying to make things cleaner and fix a couple of bugs I stumbled across. (Confusion between ExecQual and ExecCheck, for instance - we apparently lack regression tests exercising constraints-returning-null in corner cases such as table rewrite.) It will prob

Re: [HACKERS] increasing the default WAL segment size

Peter, * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 3/22/17 08:46, Stephen Frost wrote: > > It's not my intent to 'torpedo' this patch but I'm pretty disappointed > > that we're introducing yet another initdb-time option with, as far as I > > can tell, no option to change it a

Re: [HACKERS] Metadata about relation creation & full scans.

On 2017-03-22 10:14:14 -0400, Tom Lane wrote: > Andres Freund writes: > > I propose that for each pg_class entry we start to keep the following > > additional metadata: > > - CATALOG_VERSION_NO at relation creation > > - PG_VERSION_NUM at relation creation > > - CATALOG_VERSION_NO at last full sca

Re: [HACKERS] Monitoring roles patch

On Wed, Mar 22, 2017 at 12:55 PM, Peter Eisentraut wrote: > On 3/22/17 07:48, Dave Page wrote: >> With the patch, complex monitoring systems can easily be setup with >> something like: >> >> CREATE ROLE monitoring_user LOGIN; >> GRANT pg_monitor TO monitoring_role; > > That assumes that we have th

Re: [HACKERS] WIP: Faster Expression Processing v4

On 2017-03-22 10:41:06 -0400, Tom Lane wrote: > I've been busily hacking away on this, trying to make things cleaner and > fix a couple of bugs I stumbled across. (Confusion between ExecQual and > ExecCheck, for instance - we apparently lack regression tests exercising > constraints-returning-null

Re: [HACKERS] Metadata about relation creation & full scans.

Andres Freund writes: > On 2017-03-22 10:14:14 -0400, Tom Lane wrote: >> (2) How you gonna update this in vacuum? It cannot do a transactional >> update. > I think we can just do that in a separate transaction, at the tail end > of vacuum_rel() - if we crash just before that, not that much is lo

Re: [HACKERS] Hash support for grouping sets

[snip] This thread seems to have gone quiet - is it time for me to just go ahead and commit the thing anyway? Anyone else want to weigh in? -- Andrew (irc:RhodiumToad) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgr

Re: [HACKERS] Logical decoding on standby

On 22 March 2017 at 13:06, Andres Freund wrote: > But I have to admit, I've *severe* doubts about getting the whole > infrastructure for slot creation on replica into 10. The work is far > from ready, and we're mere days away from freeze. If Craig has to guess what would be acceptable, then its

Re: [HACKERS] WIP: Faster Expression Processing v4

Andres Freund writes: > On 2017-03-22 10:41:06 -0400, Tom Lane wrote: >> * execQual.c doesn't seem to have a unifying reason to exist anymore. >> It certainly has little to do with evaluating typical qual expressions; >> what's left in there seems to be mostly concerned with SRFs. I feel >> like

Re: [HACKERS] Metadata about relation creation & full scans.

On March 22, 2017 3:54:07 PM GMT+01:00, Tom Lane wrote: >Andres Freund writes: >> On 2017-03-22 10:14:14 -0400, Tom Lane wrote: >>> (2) How you gonna update this in vacuum? It cannot do a >transactional >>> update. > >> I think we can just do that in a separate transaction, at the tail >end >>

Re: [HACKERS] logical replication access control patches

On 3/18/17 09:31, Petr Jelinek wrote: >> 0001 Refine rules for altering publication owner >> >> kind of a bug fix > > Agreed, this can be committed as is. > >> >> 0002 Change logical replication pg_hba.conf use >> >> This was touched upon in the discussion at >>

Re: [HACKERS] logical replication access control patches

On 3/22/17 08:12, Petr Jelinek wrote: > On 22/03/17 03:38, Peter Eisentraut wrote: >> On 3/20/17 15:10, Petr Jelinek wrote: >>> Hmm but REPLICATION role can do basebackup/consume wal, so how does >>> giving it limited publication access help? Wouldn't we need some >>> SUBSCRIPTION role/grant used i

Re: [HACKERS] PATCH: Make pg_stop_backup() archive wait optional

David, all, * David Steele (da...@pgmasters.net) wrote: > On 3/21/17 2:34 PM, Fujii Masao wrote: > >The patch basically looks good to me, but one comment is; > >backup.sgml (at least the description for "Making a non-exclusive > >low level backup) seems to need to be updated. > > Agreed. Added i

Re: [HACKERS] [COMMITTERS] pgsql: Sync pg_dump and pg_dumpall output

Andrew, * Andrew Dunstan (and...@dunslane.net) wrote: > Sync pg_dump and pg_dumpall output This probably should have adjusted all callers of pg_dump in the regression tests to use the --no-sync option, otherwise we'll end up spending possibly a good bit of time calling fsync() during the regressi

Re: [HACKERS] Monitoring roles patch

On Wed, Mar 22, 2017 at 1:15 PM, Stephen Frost wrote: > > I did specifically ask for explicit roles to be made to enable such > capability and that the pg_monitor role be GRANT'd those roles instead > of hacking the pg_monitor OID into those checks, but it seems like > that's not been done yet. Y

Re: [HACKERS] PL/Python: Add cursor and execute methods to plan object

On 03/21/2017 06:27 PM, Andrew Dunstan wrote: > On 03/16/2017 05:32 PM, David Steele wrote: >> On 2/25/17 1:27 PM, Peter Eisentraut wrote: >>> Something that has been bothering me in PL/Python for a long time is the >>> non-object-oriented way in which plans are prepared and executed: >>> >>>

Re: [HACKERS] Logical decoding on standby

On 2017-03-22 14:58:29 +, Simon Riggs wrote: > On 22 March 2017 at 13:06, Andres Freund wrote: > > > But I have to admit, I've *severe* doubts about getting the whole > > infrastructure for slot creation on replica into 10. The work is far > > from ready, and we're mere days away from freeze

[HACKERS] bug/oversight in TestLib.pm and PostgresNode.pm

I am trying to re-create pgbench-over-logical-replication as a TAP-test. (the wisdom of that might be doubted, and I appreciate comments on it too, but it's really another subject). While trying to test pgbench's stderr (looking for 'creating tables' in output of the initialisation step) I ra

Re: [HACKERS] Logical decoding on standby

On 22 March 2017 at 13:06, Andres Freund wrote: >> The parts I think are important for Pg10 are: > >> * Ability to create logical slots on replicas > > Doesn't this also imply recovery conflicts on DROP DATABASE? Not needed until the slot is in use, which is a later patch. > Besides, > allowing

Re: [HACKERS] [COMMITTERS] pgsql: Sync pg_dump and pg_dumpall output

On 03/22/2017 11:39 AM, Stephen Frost wrote: > Andrew, > > * Andrew Dunstan (and...@dunslane.net) wrote: >> Sync pg_dump and pg_dumpall output > This probably should have adjusted all callers of pg_dump in the > regression tests to use the --no-sync option, otherwise we'll end up > spending possi

Re: [HACKERS] PATCH: recursive json_populate_record()

On 22.03.2017 00:26, David Steele wrote: On 3/21/17 2:31 PM, Andrew Dunstan wrote: On 03/21/2017 01:37 PM, David Steele wrote: >> This thread has been idle for months since Tom's review. The submission has been marked "Returned with Feedback". Please feel free to resubmit to a future commitf

Re: [HACKERS] [COMMITTERS] pgsql: Sync pg_dump and pg_dumpall output

Andrew, * Andrew Dunstan (andrew.duns...@2ndquadrant.com) wrote: > On 03/22/2017 11:39 AM, Stephen Frost wrote: > > * Andrew Dunstan (and...@dunslane.net) wrote: > >> Sync pg_dump and pg_dumpall output > > This probably should have adjusted all callers of pg_dump in the > > regression tests to use

Re: [HACKERS] increasing the default WAL segment size

On Wed, Mar 22, 2017 at 3:14 PM, Beena Emerson wrote: > PFA an updated patch which fixes a minor bug I found. It only increases the > string size in pretty_wal_size function. > The 01-add-XLogSegmentOffset-macro.patch has also been rebased. Thanks for the updated versions. Here is a partial review

Re: [HACKERS] increasing the default WAL segment size

On Wed, Mar 22, 2017 at 8:46 AM, Stephen Frost wrote: >> I was definitely initially in favor of >> raising the value, but I got cold feet, a bit, when Alvaro pointed out >> that going to 64MB would require a substantial increase in >> min_wal_size. > > The performance concern of having 3 segments

Re: [HACKERS] Logical decoding on standby

On 22 March 2017 at 08:53, Craig Ringer wrote: > I'm splitting up the rest of the decoding on standby patch set with > the goal of getting minimal functionality for creating and managing > slots on standbys in, so we can maintain slots on standbys and use > them when the standby is promoted to ma

Re: [HACKERS] exposing wait events for non-backends (was: Tracking wait event for latches)

On Wed, Mar 22, 2017 at 1:31 AM, Michael Paquier wrote: > Okay, switched as ready for committer. One note for the committer > though: keeping the calls of pgstat_bestart() out of > BackgroundWorkerInitializeConnection() and > BackgroundWorkerInitializeConnectionByOid() keeps users the > possibilit

Re: [HACKERS] [COMMITTERS] pgsql: Sync pg_dump and pg_dumpall output

On 03/22/2017 12:10 PM, Stephen Frost wrote: >> Still I agree that we should have tests for both cases. > Perhaps, though if I recall correctly, we've basically had zero calls > for fsync() until this. If we don't feel like we need to test that in > the backend then it seems a bit silly to feel

Re: [HACKERS] increasing the default WAL segment size

Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On the topic of whether to also change the default, I'm not sure what > is best and will defer to others. On the topic of whether to whack > around the file naming scheme, -1 from me. This patch was posted > three months ago and nobody sugge

Re: [HACKERS] exposing wait events for non-backends (was: Tracking wait event for latches)

On Wed, Mar 22, 2017 at 12:20 PM, Robert Haas wrote: > On Wed, Mar 22, 2017 at 1:31 AM, Michael Paquier > wrote: >> Okay, switched as ready for committer. One note for the committer >> though: keeping the calls of pgstat_bestart() out of >> BackgroundWorkerInitializeConnection() and >> Background

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Wed, Mar 22, 2017 at 5:44 AM, Robert Haas wrote: >> Actually, that's quite possible with the design I came up with. > > I don't think it is. What sequence of calls do the APIs you've > proposed would accomplish that goal? I don't see anything in this > patch set that would permit anything oth

Re: [HACKERS] Logical decoding on standby

On 2017-03-22 15:59:42 +, Simon Riggs wrote: > On 22 March 2017 at 13:06, Andres Freund wrote: > > >> The parts I think are important for Pg10 are: > > > >> * Ability to create logical slots on replicas > > > > Doesn't this also imply recovery conflicts on DROP DATABASE? > > Not needed until

  1   2   >