Re: [HACKERS] pg_stat_wal_write statistics view

On 2017/03/16 14:46, Haribabu Kommi wrote: On Thu, Mar 16, 2017 at 4:15 PM, vinayak > wrote: On 2017/03/16 10:34, Haribabu Kommi wrote: Updated patch attached. The patch looks good to me. Thanks for

Re: [HACKERS] pg_stat_wal_write statistics view

On Thu, Mar 16, 2017 at 4:15 PM, vinayak wrote: > > On 2017/03/16 10:34, Haribabu Kommi wrote: > > > Updated patch attached. > > The patch looks good to me. > Thanks for the review. How about rename the view as "pg_stat_walwriter"? > With the use of name

Re: [HACKERS] identity columns

On 3/15/17, Peter Eisentraut wrote: > Vitaly, will you be able to review this again? > > -- > Peter Eisentraut http://www.2ndQuadrant.com/ I apologize for a delay. Yes, I'm going to do it by Sunday. -- Best regards, Vitaly Burovoy -- Sent via

Re: [HACKERS] Microvacuum support for Hash Index

On Wed, Mar 15, 2017 at 9:23 PM, Ashutosh Sharma wrote: > >> >> Few other comments: >> 1. >> + if (ndeletable > 0) >> + { >> + /* No ereport(ERROR) until changes are logged */ >> + START_CRIT_SECTION(); >> + >> + PageIndexMultiDelete(page, deletable, ndeletable); >> + >> +

Re: [HACKERS] Transactions involving multiple postgres foreign servers

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: tested, passed Documentation:tested, passed I have tested the latest patch and it looks good to me, so I

Re: [HACKERS] pg_stat_wal_write statistics view

On 2017/03/16 10:34, Haribabu Kommi wrote: Updated patch attached. The patch looks good to me. How about rename the view as "pg_stat_walwriter"? The columns of view : backend_writes -> backend_wal_writes writes-> background_wal_writes write_blocks-> wal_write_blocks

[HACKERS] Split conditions on relations

I've got a customer that is running a pretty expensive function as part of a WHERE clause. With or without the function, the table the function references is the inner-most of a series of nested loops. Without the function things are very fast, but adding the function increases the cost of the

Re: [HACKERS] multivariate statistics (v25)

David Rowley wrote: > + k = -1; > + while ((k = bms_next_member(attnums, k)) >= 0) > + { > + bool attr_found = false; > + for (i = 0; i < info->stakeys->dim1; i++) > + { > + if (info->stakeys->values[i] == k) > + { > + attr_found = true; > + break; > + } > + } > + > + /* found attribute not

Re: [HACKERS] Proposal: GetOldestXminExtend for ignoring arbitrary vacuum flags

On Fri, Feb 24, 2017 at 3:17 PM, Seki, Eiji wrote: > > Thank you for your comments. > > I reflected these comments to the attached patch. And I renamed IGNORE_XXX > flags to PROCARRAY_XXX flags. I checked the latest patch and I have some comments. +static int

Re: [HACKERS] Write Ahead Logging for Hash Indexes

On Wed, Mar 15, 2017 at 7:50 PM, Robert Haas wrote: > On Wed, Mar 15, 2017 at 9:18 AM, Stephen Frost wrote: >>> I think we have sufficient comments in code especially on top of >>> function _hash_alloc_buckets(). >> >> I don't see any comments regarding

Re: [HACKERS] WIP: Faster Expression Processing v4

Hi, I got a test failure with this version of the patch in the postges_fdw. It looks to me like it was caused by a typo in the source code which is fixed in the attached patch. After applying this patch check-world passes. Andreas diff --git a/src/backend/executor/nodeTidscan.c

Re: [HACKERS] logical replication launcher crash on buildfarm

On 2017-03-15 20:28:33 -0700, Andres Freund wrote: > Hi, > > I just unstuck a bunch of my buildfarm animals. That triggered some > spurious failures (on piculet, calliphoridae, mylodon), but also one > that doesn't really look like that: >

[HACKERS] logical replication launcher crash on buildfarm

Hi, I just unstuck a bunch of my buildfarm animals. That triggered some spurious failures (on piculet, calliphoridae, mylodon), but also one that doesn't really look like that: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=culicidae=2017-03-16%2002%3A40%3A03 with the pertinent point

Re: [HACKERS][REVIEW] macaddr 64 bit (EUI-64) datatype support

Andres, * Andres Freund (and...@anarazel.de) wrote: > I see a new warning due to, presumably, this: > /home/andres/src/postgresql/src/backend/utils/adt/mac8.c: In function > ‘hex2_to_uchar’: > /home/andres/src/postgresql/src/backend/utils/adt/mac8.c:71:23: warning: > comparison is always false

Re: [HACKERS] Changing references of password encryption to hashing

On Mon, Mar 13, 2017 at 04:48:21PM +0800, Craig Ringer wrote: > On 12 March 2017 at 06:51, Joe Conway wrote: > > > My opinion is that the user visible aspects of this should be deprecated > > and correct syntax provided. But perhaps that is overkill. > > FWIW, in my

Re: [HACKERS] Microvacuum support for Hash Index

On Mar 16, 2017 7:49 AM, "Robert Haas" wrote: On Wed, Mar 15, 2017 at 4:31 PM, Robert Haas wrote: > On Wed, Mar 15, 2017 at 3:54 PM, Ashutosh Sharma wrote: >> Changed as per suggestions. Attached v9 patch. Thanks. > > Wow,

Re: [HACKERS] \h tab-completion

On 03/01/2017 02:47 PM, Peter Eisentraut wrote: Instead of creating another copy of list_ALTER, let's use the words_after_create list and write a version of create_command_generator/drop_command_generator. Good idea. Here is a patch with that. Andreas commit

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

On Tue, Mar 14, 2017 at 5:50 PM, Vaishnavi Prabakaran < vaishnaviprabaka...@gmail.com> wrote: > > > On Tue, Mar 14, 2017 at 4:19 AM, Daniel Verite > wrote: > >> >> I mean the next iteration of the above while statement. Referring >> to the doc, that would be the "next

Re: [HACKERS] [COMMITTERS] pgsql: Remove objname/objargs split for referring to objects

On Thu, Mar 16, 2017 at 12:18 AM, Alvaro Herrera wrote: > Peter Eisentraut wrote: >> Remove objname/objargs split for referring to objects > > I don't know if this is the guilty commit, but I'm now getting these > compiler warnings: > > >

Re: [HACKERS] Microvacuum support for Hash Index

On 2017-03-15 16:31:11 -0400, Robert Haas wrote: > On Wed, Mar 15, 2017 at 3:54 PM, Ashutosh Sharma > wrote: > > Changed as per suggestions. Attached v9 patch. Thanks. > > Wow, when do you sleep? I think that applies to a bunch of people, including yourself ;) -- Sent

Re: [HACKERS] Microvacuum support for Hash Index

On Wed, Mar 15, 2017 at 4:31 PM, Robert Haas wrote: > On Wed, Mar 15, 2017 at 3:54 PM, Ashutosh Sharma > wrote: >> Changed as per suggestions. Attached v9 patch. Thanks. > > Wow, when do you sleep? Will have a look. Committed with a few

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

On Tue, Mar 14, 2017 at 12:50:09PM -0400, Tom Lane wrote: > I wrote: > >> I think that what would actually be of some use nowadays is a LOG-level > >> message emitted if the wraparound *isn't* activated immediately at start. > >> But otherwise, we should follow the rule that silence is golden. >

Re: [HACKERS] logical replication access control patches

New patch set based on the discussions. I have dropped the PUBLICATION privilege patch. The patches are also reordered a bit in approximate decreasing priority order. 0001 Refine rules for altering publication owner kind of a bug fix 0002 Change logical replication pg_hba.conf use This was

Re: [HACKERS] Backend crash on non-exclusive backup cancel

On Thu, Mar 16, 2017 at 12:46 AM, Andres Freund wrote: > Hi, > > On 2017-03-15 15:28:03 +0900, Michael Paquier wrote: >> diff --git a/src/backend/access/transam/xlog.c >> b/src/backend/access/transam/xlog.c >> index 64335f909e..eaf8e32fe1 100644 >> ---

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

On 16 March 2017 at 13:31, Simon Riggs wrote: > On 8 March 2017 at 10:02, David Rowley > wrote: > > On 8 March 2017 at 01:13, Simon Riggs wrote: > >> Don't understand this. I'm talking about setting a flag on > >>

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

So I am looking at this part of 0008: + /* +* Do not copy parent_rinfo and child_rinfos because 1. they create a +* circular dependency between child and parent RestrictInfo 2. dropping +* those links just means that we loose some memory optimizations. 3. There +

Re: [HACKERS] pg_stat_wal_write statistics view

On Thu, Mar 16, 2017 at 9:55 AM, Julien Rouhaud wrote: > On Wed, Feb 15, 2017 at 02:53:44PM +1100, Haribabu Kommi wrote: > > Here I attached patch that implements the view. > > I will add this patch to next commitfest. > > Hello, > > I just reviewed the patch. >

Re: [HACKERS] Speedup twophase transactions

On Wed, Mar 15, 2017 at 4:48 PM, Nikhil Sontakke wrote: >> boolvalid; /* TRUE if PGPROC entry is in proc array >> */ >> boolondisk; /* TRUE if prepare state file is on disk >> */ >> + boolinredo; /* TRUE if entry

Re: [HACKERS][REVIEW] macaddr 64 bit (EUI-64) datatype support

Andres, * Andres Freund (and...@anarazel.de) wrote: > I see a new warning due to, presumably, this: > /home/andres/src/postgresql/src/backend/utils/adt/mac8.c: In function > ‘hex2_to_uchar’: > /home/andres/src/postgresql/src/backend/utils/adt/mac8.c:71:23: warning: > comparison is always false

Re: [HACKERS][REVIEW] macaddr 64 bit (EUI-64) datatype support

On 2017-03-15 11:20:53 -0400, Stephen Frost wrote: > Greetings Hari Babu, > > * Haribabu Kommi (kommi.harib...@gmail.com) wrote: > > On Mon, Mar 13, 2017 at 6:52 AM, Stephen Frost wrote: > > > And, naturally, re-reading the email as it hit the list made me realize > > > that

Re: [HACKERS][REVIEW] macaddr 64 bit (EUI-64) datatype support

On Thu, Mar 16, 2017 at 2:20 AM, Stephen Frost wrote: > Greetings Hari Babu, > > * Haribabu Kommi (kommi.harib...@gmail.com) wrote: > > On Mon, Mar 13, 2017 at 6:52 AM, Stephen Frost > wrote: > > > And, naturally, re-reading the email as it hit the list

Re: [HACKERS] utility commands benefiting from parallel plan

On Tue, Feb 28, 2017 at 12:48 PM, Haribabu Kommi wrote: > > > On Sat, Feb 25, 2017 at 3:21 AM, Robert Haas > wrote: > >> On Fri, Feb 24, 2017 at 11:43 AM, Haribabu Kommi >> wrote: >> > Here I attached an implementation

Re: [HACKERS] WIP: Faster Expression Processing v4

Hi, On 2017-03-15 20:09:03 -0400, Tom Lane wrote: > Andres Freund writes: > > [ new patches ] > > I've started to look at 0004, and the first conclusion I've come to > is that it's *direly* short of documentation. To the point that I'd > vote against committing it if

Re: [HACKERS] Measuring replay lag

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 would be the > most useful here. > > My proposal is that the *_lag columns should

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

On 8 March 2017 at 10:02, David Rowley wrote: > On 8 March 2017 at 01:13, Simon Riggs wrote: >> Don't understand this. I'm talking about setting a flag on >> commit/abort WAL records, like the attached. > > There's nothing setting a flag in

Re: [HACKERS] WIP: Faster Expression Processing v4

On 2017-03-15 18:48:28 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2017-03-15 18:16:57 -0400, Tom Lane wrote: > >> [ scratches head... ] What deforming logic do you think I'm proposing > >> removing? > > > I thought you were suggesting that we don't do the

Re: [HACKERS] WIP: Faster Expression Processing v4

Andres Freund writes: > [ new patches ] I've started to look at 0004, and the first conclusion I've come to is that it's *direly* short of documentation. To the point that I'd vote against committing it if something isn't done about that. As an example, it's quite unclear

Re: [HACKERS] Measuring replay lag

On Thu, Mar 16, 2017 at 12:07 PM, Simon Riggs wrote: > There are two ways of knowing the lag: 1) by measurement/sampling, > which is the main way this patch approaches this, 2) by direct > observation the LSNs match. Both are equally valid ways of > establishing knowledge.

Re: [HACKERS] Parallel Bitmap scans a bit broken

On Thu, Mar 16, 2017 at 5:02 AM, Dilip Kumar wrote: > After above fix, I am not able to reproduce. Can you give me the > backtrace of the crash location or the dump? > > I am trying on the below commit > > commit c5832346625af4193b1242e57e7d13e66a220b38 > Author: Stephen

Re: [HACKERS] Parallel Bitmap scans a bit broken

On Thu, Mar 16, 2017 at 12:56 AM, Emre Hasegeli wrote: >> Please verify the fix. > > The same test with both of the patches applied still crashes for me. After above fix, I am not able to reproduce. Can you give me the backtrace of the crash location or the dump? I am trying

Re: [HACKERS] Measuring replay lag

On 14 March 2017 at 07:39, Thomas Munro wrote: > Hi, > > Please see separate replies to Simon and Craig below. > > On Sun, Mar 5, 2017 at 8:38 PM, Simon Riggs wrote: >> On 1 March 2017 at 10:47, Thomas Munro

Re: [HACKERS] pg_stat_wal_write statistics view

On Wed, Feb 15, 2017 at 02:53:44PM +1100, Haribabu Kommi wrote: > Here I attached patch that implements the view. > I will add this patch to next commitfest. Hello, I just reviewed the patch. First, there are some whitespace issues that make git-apply complaining (at least lines 218 and 396).

Re: [HACKERS] WIP: Faster Expression Processing v4

Andres Freund writes: > On 2017-03-15 18:16:57 -0400, Tom Lane wrote: >> [ scratches head... ] What deforming logic do you think I'm proposing >> removing? > I thought you were suggesting that we don't do the get_last_attnums (and > inlined version in the isSimpleVar case)

Re: [HACKERS] Measuring replay lag

On 14 March 2017 at 07:39, Thomas Munro wrote: > > On Mon, Mar 6, 2017 at 3:22 AM, Craig Ringer wrote: >> On 5 March 2017 at 15:31, Simon Riggs wrote: >>> What we want from this patch is something that works for both,

Re: [HACKERS] WIP: Faster Expression Processing v4

On 2017-03-15 18:16:57 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2017-03-15 17:33:46 -0400, Tom Lane wrote: > >> We could make the planner mark each table scan node with the highest > >> column number that the plan will access, and use that to drive a > >>

Re: [HACKERS] WIP: Faster Expression Processing v4

Andres Freund writes: > On 2017-03-15 17:33:46 -0400, Tom Lane wrote: >> We could make the planner mark each table scan node with the highest >> column number that the plan will access, and use that to drive a >> slot_getsomeattrs call in advance of any access to tuple

Re: [HACKERS] scram and \password

On Thu, Mar 16, 2017 at 6:46 AM, Joe Conway wrote: > On 03/15/2017 08:48 AM, Michael Paquier wrote: >> I have been hacking my way through this thing, and making >> scram_build_verifier is requiring a bit more refactoring than I >> thought first: >> - stored and server keys are

Re: [HACKERS] WIP: Faster Expression Processing v4

On 2017-03-15 17:33:46 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2017-03-15 16:07:14 -0400, Tom Lane wrote: > >> As for ExecHashGetHashValue, it's most likely going to be working from > >> virtual tuples passed up to the join, which won't benefit from > >>

Re: [HACKERS] scram and \password

On 03/15/2017 08:48 AM, Michael Paquier wrote: > I have been hacking my way through this thing, and making > scram_build_verifier is requiring a bit more refactoring than I > thought first: > - stored and server keys are hex-encoded using a backend-only routine. > I think that those should be

Re: [HACKERS] WIP: Faster Expression Processing v4

Andres Freund writes: > On 2017-03-15 16:07:14 -0400, Tom Lane wrote: >> As for ExecHashGetHashValue, it's most likely going to be working from >> virtual tuples passed up to the join, which won't benefit from >> predetermination of the last column to be accessed. The >>

Re: [HACKERS] parallelize queries containing initplans

On Tue, Mar 14, 2017 at 3:20 PM, Amit Kapila wrote: > Based on that idea, I have modified the patch such that it will > compute the set of initplans Params that are required below gather > node and store them as bitmap of initplan params at gather node. > During

Re: [HACKERS] WIP: Faster Expression Processing v4

On 2017-03-15 16:07:14 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2017-03-15 15:41:22 -0400, Tom Lane wrote: > >> Color me dubious. Which specific other places have you got in mind, and > >> do they have expression trees at hand that would tell them which columns >

Re: [HACKERS] 2017-03 Commitfest Midterm

On 3/15/17 4:38 PM, Alvaro Herrera wrote: > David Steele wrote: >> We are now halfway through the 2017-03 CF. Here's the breakdown: >> >> Needs review: 83 (-45) >> Waiting on Author: 36 (+10) >> Ready for Committer: 19 (-6) >> Total: 208 (+28) >> >> It's interesting that there are 28 more patches

Re: [HACKERS] 2017-03 Commitfest Midterm

David Steele wrote: > We are now halfway through the 2017-03 CF. Here's the breakdown: > > Needs review: 83 (-45) > Waiting on Author: 36 (+10) > Ready for Committer: 19 (-6) > Total: 208 (+28) > > It's interesting that there are 28 more patches than there were on the > 1st. Either I had a

[HACKERS] 2017-03 Commitfest Midterm

We are now halfway through the 2017-03 CF. Here's the breakdown: Needs review: 83 (-45) Waiting on Author: 36 (+10) Ready for Committer: 19 (-6) Total: 208 (+28) It's interesting that there are 28 more patches than there were on the 1st. Either I had a copy-paste-o or the patches are

Re: [HACKERS] Microvacuum support for Hash Index

On Wed, Mar 15, 2017 at 3:54 PM, Ashutosh Sharma wrote: > Changed as per suggestions. Attached v9 patch. Thanks. Wow, when do you sleep? Will have a look. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via

Re: [HACKERS] Odd listen_addresses behavior

On 03/15/2017 12:57 PM, Tom Lane wrote: I'm suspicious that you have an override of listen_addresses somewhere --- for instance, the "-i" postmaster command line switch effectively is --listen-addresses='*'. Yep postgresql.auto.conf. Thanks, sorry for the noise. JD -- Command Prompt,

Re: [HACKERS] WIP: Faster Expression Processing v4

Andres Freund writes: > On 2017-03-15 15:41:22 -0400, Tom Lane wrote: >> Color me dubious. Which specific other places have you got in mind, and >> do they have expression trees at hand that would tell them which columns >> they really need to pull out? > I was thinking of

Re: [HACKERS] WIP: Faster Expression Processing v4

On 2017-03-15 15:41:22 -0400, Tom Lane wrote: > Andres Freund writes: > > On March 15, 2017 12:33:28 PM PDT, Tom Lane wrote: > >> So for my money, you should drop 0002 altogether and just have 0004 > >> remove get_last_attnums() from execUtils.c and stick

Re: [HACKERS] Odd listen_addresses behavior

"Joshua D. Drake" writes: > jd@jd-wks:~/snap/postgresql96/common$ grep listen_addresses > data/postgresql.conf > listen_addresses = '192*' # what IP address(es) to listen on; > -- I wasn't actually expecting the above to work. I was just testing. Fails as

Re: [HACKERS] Microvacuum support for Hash Index

> +action = XLogReadBufferForRedo(record, 0, ); > + > +if (!IsBufferCleanupOK(buffer)) > +elog(PANIC, "hash_xlog_vacuum_one_page: failed to acquire > cleanup lock"); > > That could fail, I think, because of a pin from a Hot Standby backend. > You want to call

[HACKERS] Odd listen_addresses behavior

-hackers, I found this today: jd@jd-wks:~/snap/postgresql96/common/data$ /snap/postgresql96/19/usr/bin/pg_ctl -D data stop pg_ctl: directory "data" does not exist jd@jd-wks:~/snap/postgresql96/common/data$ cd .. jd@jd-wks:~/snap/postgresql96/common$ /snap/postgresql96/19/usr/bin/pg_ctl -D

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

On Tue, Mar 14, 2017 at 7:16 PM, Alvaro Herrera wrote: > Pavan Deolasee wrote: > > On Tue, Mar 14, 2017 at 7:17 AM, Alvaro Herrera < > alvhe...@2ndquadrant.com> > > wrote: > > > > I have already commented about the executor involvement in btrecheck(); > > > that doesn't

Re: [HACKERS] WIP: Faster Expression Processing v4

Andres Freund writes: > On March 15, 2017 12:33:28 PM PDT, Tom Lane wrote: >> So for my money, you should drop 0002 altogether and just have 0004 >> remove get_last_attnums() from execUtils.c and stick it into >> execExpr.c. I suppose you still need the

Re: [HACKERS] WIP: Faster Expression Processing v4

On March 15, 2017 12:33:28 PM PDT, Tom Lane wrote: >Andres Freund writes: >> [ latest patches ] > >I looked through 0002-Make-get_last_attnums-more-generic.patch. >So for my money, you should drop 0002 altogether and just have 0004 >remove

Re: [HACKERS] WIP: Faster Expression Processing v4

Andres Freund writes: > [ latest patches ] I looked through 0002-Make-get_last_attnums-more-generic.patch. Although it seems relatively unobjectionable on its own, I'm not convinced that it's really useful to try to split it out like this. I see that 0004 removes the only

Re: [HACKERS] Parallel Bitmap scans a bit broken

> Please verify the fix. The same test with both of the patches applied still crashes for me. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] pgbench - allow to store select results into variables

Hello Rafia, I was reviewing v7 of this patch, to start with I found following white space errors when applying with git apply, /home/edb/Desktop/patches/others/pgbench-into-7.patch:66: trailing whitespace. Yep. I do not know why "git apply" sometimes complains. All is fine for me both

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

On Wed, Mar 15, 2017 at 8:55 AM, Ashutosh Bapat wrote: > Sorry. That was added by my patch to refactor > set_append_rel_pathlist(). I have added a patch in the series to > remove that line. It's not worth an extra commit just to change what isn't broken. Let's

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

On Wed, Mar 15, 2017 at 8:49 AM, Ashutosh Bapat wrote: >> Of course, that supposes that 0009 can manage to postpone creating >> non-sampled child joinrels until create_partition_join_plan(), which >> it currently doesn't. > > Right. We need the child-join's

Re: [HACKERS] Leftover invalidation handling in RemoveRelations

Hi, On 2017-03-15 14:46:22 -0400, Robert Haas wrote: > On Wed, Mar 15, 2017 at 2:40 PM, Andres Freund wrote: > Yeah, I don't think that would hurt anything. > > (I'm not sure it'll help anything either - the overhead of an extra > AcceptInvalidationMessages() call is quite

Re: [HACKERS] Leftover invalidation handling in RemoveRelations

On Wed, Mar 15, 2017 at 2:40 PM, Andres Freund wrote: > reviewing some citus code copied from postgres I noticed that > RemoveRelations() has the following bit: > > /* > * These next few steps are a great deal like > relation_openrv, but we >

[HACKERS] Leftover invalidation handling in RemoveRelations

Hi, reviewing some citus code copied from postgres I noticed that RemoveRelations() has the following bit: /* * These next few steps are a great deal like relation_openrv, but we * don't bother building a relcache entry since we don't need it.

Re: [HACKERS] Microvacuum support for Hash Index

On Wed, Mar 15, 2017 at 2:10 PM, Ashutosh Sharma wrote: > Okay, I have done the changes as suggested by you. Please refer to the > attached v8 patch. Thanks. Cool, but this doesn't look right: +action = XLogReadBufferForRedo(record, 0, ); + +if

Re: [HACKERS] Microvacuum support for Hash Index

On Wed, Mar 15, 2017 at 9:28 PM, Robert Haas wrote: > On Wed, Mar 15, 2017 at 11:37 AM, Ashutosh Sharma > wrote: >>> +/* Get RelfileNode from relation OID */ >>> +rel = relation_open(htup->t_tableOid, NoLock); >>> +rnode =

Re: [HACKERS] Defaulting psql to ON_ERROR_ROLLBACK=interactive

Just chiming in: I rely heavily on the current default behavior because it prevents large statements pasted into psql that cause errors in transactions from partially running, and if it were changed I would have caused production outages. On Wed, Mar 15, 2017 at 8:42 AM, Pavel Stehule

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

On Wed, Mar 15, 2017 at 11:35 AM, Mengxing Liu wrote: >> On a NUMA machine It is not at all unusual to see bifurcated results >> -- with each run coming in very close to one number or a second >> number, often at about a 50/50 rate, with no numbers falling >>

Re: [HACKERS] [COMMITTERS] pgsql: Improve isolation tests infrastructure.

Hi Peter, All, On 2017-03-14 23:10:19 +, Andres Freund wrote: > Improve isolation tests infrastructure. There's: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=frogmouth=2017-03-15%2012%3A32%3A45

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

Peter Eisentraut writes: > make check-world -O -j6 PROVE_FLAGS=-j6 > 2 min 34 seconds > Nice! One thing I've noticed with parallel check-world is that it's possible for a sub-job to fail and for the resulting complaint from make to scroll offscreen before

Re: [HACKERS] Parallel Bitmap scans a bit broken

On Wed, Mar 15, 2017 at 10:21 PM, Emre Hasegeli wrote: >> hasegeli=# create table r2 as select (random() * 3)::int as i from >> generate_series(1, 100); >> SELECT 100 >> hasegeli=# create index on r2 using brin (i); >> CREATE INDEX >> hasegeli=# analyze r2; >> ANALYZE

Re: [HACKERS] logical replication access control patches

On 3/14/17 14:49, Petr Jelinek wrote: > Not what I mean - owner should be able to publish table. If you are > granted role of the owner you can do what owner can no? I didn't actually know that ownership worked that way. You can grant the role of an owner to someone, and then that someone has

Re: [HACKERS] pg_ls_waldir() & pg_ls_logdir()

On Mon, Feb 20, 2017 at 6:21 AM, Dave Page wrote: > Patch includes the code and doc updates. Review: +strftime(mtime, 25, "%Y-%m-%d %H:%M:%S %Z", localtime(&(attrib.st_ctime))); +const int n = snprintf(NULL, 0, "%lld", attrib.st_size); +char size[n+1];

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

make check-world -O -j6 PROVE_FLAGS=-j6 2 min 34 seconds Nice! -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] logical replication access control patches

On 3/14/17 15:37, Petr Jelinek wrote: > Yeah that's rather hard to say in front. Maybe safest action would be to > give the permission to owners in 10 and revisit special privilege in 11 > based on feedback? I'm fine with that. -- Peter Eisentraut http://www.2ndQuadrant.com/

Re: [HACKERS] logical replication access control patches

On 3/14/17 15:05, Stephen Frost wrote: > Another approach to solving my concern would be to only allow the > publishing of tables by non-owner users who have table-level SELECT > rights An early version of the logical replication patch set did that. But the problem is that this way someone with

Re: [HACKERS] identity columns

Vitaly, will you be able to review this again? On 2/28/17 21:23, Peter Eisentraut wrote: > New patch that fixes everything. ;-) Besides hopefully addressing all > your issues, this version also no longer requires separate privileges on > the internal sequence, which was the last outstanding

Re: [HACKERS] [POC] hash partitioning

On Wed, Mar 15, 2017 at 12:39 PM, David Steele wrote: > Agreed. Perhaps both types of syntax should be supported, one that is > friendly to users and one that is precise for dump tools and those who > care get in the weeds. Eventually, sure. For the first version, I want

Re: [HACKERS] background sessions

On Wed, Mar 15, 2017 at 6:43 AM, Pavel Stehule wrote: > I don't understand - CHECK_FOR_INTERRUPTS called from executor implicitly. True. So there shouldn't be any problem here. I'm confused as can be about what you want changed. Some review of the patch itself: +

Re: [HACKERS] Parallel Bitmap scans a bit broken

> With my test case, I could not crash even with this patch applied. > Can you provide your test case? Yes: > hasegeli=# create table r2 as select (random() * 3)::int as i from > generate_series(1, 100); > SELECT 100 > hasegeli=# create index on r2 using brin (i); > CREATE INDEX >

Re: [HACKERS] [COMMITTERS] pgsql: Use asynchronous connect API in libpqwalreceiver

Andrew Dunstan writes: > On 03/03/2017 11:11 PM, Tom Lane wrote: >> Yeah, I was wondering if this is just exposing a pre-existing bug. >> However, the "normal" path operates by repeatedly invoking PQconnectPoll >> (cf. connectDBComplete) so it's not immediately

Re: [HACKERS] Parallel Bitmap scans a bit broken

On Wed, Mar 15, 2017 at 10:02 PM, Emre Hasegeli wrote: > I was testing with the brin correlation patch [1] applied. I cannot > crash it without the patch either. I am sorry for not testing it > before. The patch make BRIN selectivity estimation function access > more

Re: [HACKERS] [POC] hash partitioning

On 3/15/17 12:25 PM, Robert Haas wrote: > On Tue, Mar 14, 2017 at 10:08 AM, David Steele wrote: >> This patch is marked as POC and after a read-through I agree that's >> exactly what it is. > > Just out of curiosity, were you looking at Nagata-san's patch, or Amul's? Both -

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

> -Original Messages- > From: "Kevin Grittner" > Sent Time: 2017-03-15 23:20:07 (Wednesday) > To: DEV_OPS > Cc: "Mengxing Liu" , > "pgsql-hackers@postgresql.org" > Subject: Re:

Re: [HACKERS] Parallel Bitmap scans a bit broken

> This can crash at line:414, if either tuple is invalid memory(but I > think it's not because we have already accessed this memory in above > if check) or dtup is invalid (this is also not possible because > brin_new_memtuple has already accessed this). I was testing with the brin correlation

Re: [HACKERS] [POC] hash partitioning

On Tue, Mar 14, 2017 at 10:08 AM, David Steele wrote: > This patch is marked as POC and after a read-through I agree that's > exactly what it is. Just out of curiosity, were you looking at Nagata-san's patch, or Amul's? > As such, I'm not sure it belongs in the last >

Re: [HACKERS] Parallel Bitmap scans a bit broken

On Wed, Mar 15, 2017 at 8:11 PM, Emre Hasegeli wrote: >> * thread #1: tid = 0x5045a8f, 0x00010ae44558 >> postgres`brin_deform_tuple(brdesc=0x7fea3c86a3a8, >> tuple=0x7fea3c891040) + 40 at brin_tuple.c:414, queue = >> 'com.apple.main-thread', stop reason = signal

Re: [HACKERS] [PATCH] Suppress Clang 3.9 warnings

Noah Misch writes: > On Wed, Mar 15, 2017 at 10:57:15AM -0400, Tom Lane wrote: >> Seems like the correct solution is to >> absorb that fix, either by updating to a newer autoconf release or by >> carrying our own version of AC_CHECK_DECLS until they come out with one. > As you

[HACKERS] Re: new set of psql patches for loading (saving) data from (to) text, binary files

Pavel, I started looking through this to see if it might be ready to commit and I don't believe it is. Below are my comments about the first patch, I didn't get to the point of looking at the others yet since this one had issues. * Pavel Stehule (pavel.steh...@gmail.com) wrote: > 2017-01-09

Re: [HACKERS] [PATCH] Suppress Clang 3.9 warnings

On Wed, Mar 15, 2017 at 10:57:15AM -0400, Tom Lane wrote: > Noah Misch writes: > > On Mon, Mar 13, 2017 at 06:35:53PM +0300, Aleksander Alekseev wrote: > >> + * Unfortunately in case of strlcat and strlcpy we can't trust tests > >> + * executed by Autotools if Clang > 3.6 is

Re: [HACKERS] Parallel Bitmap scans a bit broken

On Wed, Mar 15, 2017 at 8:51 PM, Dilip Kumar wrote: >> I can try to provide a test case, if that wouldn't be enough to spot >> the problem. > > Thanks for reporting, I am looking into this. Meanwhile, if you can > provide the reproducible test case then locating the issue

  1   2   >