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

extern void assign_max_wal_size(int newval, void *extra); > extern void assign_checkpoint_completion_target(double newval, void *extra); This seems like something easy enough to exercise in a tap test, could we get one? Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-

Re: [HACKERS] WIP: Faster Expression Processing v4

On 2017-03-14 23:10:25 -0400, Peter Eisentraut wrote: > On 3/14/17 19:40, Andres Freund wrote: > > Any idea why we introduce __ stuff? > > Because the symbols start with an underscore: > > /* Define to 1 if your compiler understands _Static_assert. */ > #undef HAVE__ST

Re: [HACKERS] improve comments of snapbuild.c

On 2017-03-14 22:03:21 +0100, Erik Rijkers wrote: > Improvements (grammar/typos) in the comments in snapbuild.c > > To be applied to master. Thanks, pushed. Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] WIP: Faster Expression Processing v4

Hi, On 2017-03-14 19:34:12 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > [ new patch versions ] > > About to leave, but I had time to read 0003: > > It seems bizarre that you chose to spell the new configure symbol as > H

Re: [HACKERS] WIP: Faster Expression Processing v4

On 2017-03-14 14:19:18 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > On 2017-03-14 08:44:24 -0300, Alvaro Herrera wrote: > >> It would be good to have someone at least read it before pushing, but > >> I don't think anyone other than

Re: [HACKERS] WIP: Faster Expression Processing v4

during *initialization* time is that expensive, especially given that previously we allocated a lot of memory separately too. > On Tue, Mar 14, 2017 at 11:51 AM Andres Freund <and...@anarazel.de> wrote: > > > > Hmm. Could we make the instructions variable size? It would allo

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

On 2017-03-13 00:35:06 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > On 2017-03-11 22:14:07 -0500, Tom Lane wrote: > >> This looks generally sane to me, although I'm not very happy about folding > >> the "$(MKDIR_P) output_iso

Re: [HACKERS] [COMMITTERS] pgsql: Add amcheck extension to contrib.

On 2017-03-13 14:09:39 -0700, Andres Freund wrote: > Hi, > > On 2017-03-13 15:45:01 -0400, Tom Lane wrote: > > I could be wrong, but the most obvious explanation for this failure is > > that autovacuum had a lock on the table or index when we looked. > > Even if th

Re: [HACKERS] WIP: Faster Expression Processing v4

Hi, On 2017-03-14 20:28:51 +0200, Heikki Linnakangas wrote: > On 03/14/2017 07:31 PM, Andres Freund wrote: > > On 2017-03-14 16:58:54 +0200, Heikki Linnakangas wrote: > > > * How tight are we on space in the ExprEvalStep union? Currently, the > > > jump-threading prepa

Re: [HACKERS] WIP: Faster Expression Processing v4

On 2017-03-14 08:44:24 -0300, Alvaro Herrera wrote: > Patch 0003 is huge. I suspect you mean 0004? If so - yes :(. I unfortunately don't think there's a useful way to split it in smaller chunks - I originally moved ops over one-by-one, but that required a lot of duplicated structs and such...

Re: [HACKERS] WIP: Faster Expression Processing v4

On 2017-03-14 08:28:02 -0300, Alvaro Herrera wrote: > Andres Freund wrote: > > > EEO_SWITCH(op->opcode) > > { > > EEO_CASE(EEO_DONE): > > goto out; > > Oh my. > > > which is a bit annoying. (the EEO_CASE is either a jump label or

Re: [HACKERS] WIP: Faster Expression Processing v4

Hi, On 2017-03-14 16:58:54 +0200, Heikki Linnakangas wrote: > On 03/14/2017 08:53 AM, Andres Freund wrote: > > Besides that, this version has: > > - pgindented most of the affected pieces (i.e. all significant new code > > has been reindent, not all touched one) > >

Re: [HACKERS] [COMMITTERS] pgsql: Improve postmaster's logging of listen socket creation.

On 2017-03-13 10:12:42 -0400, Robert Haas wrote: > So now on every startup I get this: > > 2017-03-13 10:08:49.399 EDT [90059] LOG: listening on IPv6 address "::1" > 2017-03-13 10:08:49.399 EDT [90059] LOG: listening on IPv4 address > "127.0.0.1" > 2017-03-13 10:08:49.400 EDT [90059] LOG:

Re: [HACKERS] WIP: Faster Expression Processing v4

Hi, On 2017-03-13 01:03:51 -0700, Andres Freund wrote: > What's basically missing here is: > - pgindent run and minimizing resulting damage Running into a bit of an issue here - pgindent mangles something like EEO_SWITCH (op->opcode) { EEO_CASE(EEO_DONE):

Re: [HACKERS] [COMMITTERS] pgsql: Add amcheck extension to contrib.

Hi, On 2017-03-13 15:45:01 -0400, Tom Lane wrote: > I could be wrong, but the most obvious explanation for this failure is > that autovacuum had a lock on the table or index when we looked. > Even if that isn't why axolotl failed in this particular case, I think > it's dead certain that we will

Re: [HACKERS] Relation cache invalidation on replica

On March 12, 2017 11:22:22 PM PDT, Victor Yegorov wrote: >2016-02-28 11:53 GMT+02:00 Simon Riggs : > >> We have various proposals for fixing this, so on consideration here's >what >> I think we should do... >> >> 1. Ignore my first patch to always set

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

0;115;0c On 2017-03-11 22:14:07 -0500, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > On 2017-03-11 11:48:31 -0800, Andres Freund wrote: > >> I think that'd be a good plan. We probably should also keep --outputdir > >> seperate (

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

On 2017-03-11 11:48:31 -0800, Andres Freund wrote: > On 2017-03-11 12:05:23 -0500, Tom Lane wrote: > > I wrote: > > > I believe the core problem is that contrib/test_decoding's regresscheck > > > and isolationcheck targets each want to use ./tmp_check as their >

[HACKERS] src/test/regress's check-prepared-txns target

? I bet these tests are run just about never. I'd suggest removing at least check-prepared-txns and adding the test to the normal check target (which is guaranteed to have prepared xacts enabled). Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org

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

On 2017-03-11 14:17:42 -0800, Andres Freund wrote: > On 2017-03-07 09:36:51 -0300, Alvaro Herrera wrote: > > FWIW, +1 on improving matters here. > > > > Andres Freund wrote: > > > > > The best I can come up so far is a toplevel target that creates the

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

On 2017-03-07 09:36:51 -0300, Alvaro Herrera wrote: > FWIW, +1 on improving matters here. > > Andres Freund wrote: > > > The best I can come up so far is a toplevel target that creates the temp > > install, starts a cluster and then runs the 'installcheck-or-

Re: [HACKERS] How to get the 'ctid' from a record type?

On 2017-03-11 04:31:16 +, Eric Ridge wrote: > Well shoot. That kinda spoils my plans. I think you should elaborate on what you're trying to achieve - otherwise our advice will be affected by the recent, widely reported, crystal ball scarcity. - Andres -- Sent via pgsql-hackers mailing

Re: [HACKERS] INSERT INTO arr2(array[1].d, array[2].d)

On 2017-03-11 14:43:55 -0600, Jim Nasby wrote: > Over in [1], I was very surprised to discover $SUBJECT[2]. I looked in the > docs, and they clearly indicate that INSERT accepts "column names". They also say "The column name can be qualified with a subfield name or array subscript, if needed."

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

On 2017-03-11 12:05:23 -0500, Tom Lane wrote: > I wrote: > > I believe the core problem is that contrib/test_decoding's regresscheck > > and isolationcheck targets each want to use ./tmp_check as their > > --temp-instance. make has no reason to believe it shouldn't run those > > two sub-jobs in

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

On 2017-03-10 18:14:13 -0800, Roman Shaposhnik wrote: > On Fri, Mar 10, 2017 at 11:20 AM, Andres Freund <and...@anarazel.de> wrote: > > 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

Re: [HACKERS] Indirect assignment code for array slices is dead code?

Hi, On 2017-03-10 20:59:48 -0500, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > In the context of my expression evaluation patch, I was trying to > > increase test coverage of execQual.c. I'm a bit confused about > > $subject. ExecEvalArrayRef()

[HACKERS] Indirect assignment code for array slices is dead code?

t; - makes sense), nor can there be an ArrayRef inside a slice ArrayRef for assignemnts, because there are no parens in the LHS, and consecutive []'s are collapsed into a single ArrayRef. Am I standing on my own foot here? Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-

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

Hi, On 2017-03-10 11:57:30 -0800, Joshua D. Drake wrote: > I am a bad speaker, I am writing a talk three weeks before the conference > (as opposed to on the plane). I noticed in the docs we still reference the > passing of SIGHUP for reloading conf file but we now have pg_reload_conf(); > > It

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 <t...@sss.pgh.pa.us> wrote: > > Andres Freund <and...@anarazel.de> writes: > >> Wonder if we there's an argument to be made for implementing this > >> roughly similar

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

Re: [HACKERS] WIP: Faster Expression Processing v4

l|null/domainval|null - I had started down a path of removing the use of those in random parts of the system, but I ended up not going for it. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.post

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

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

up, so we can be sure arm64 stays working? See https://buildfarm.postgresql.org/ Pushed, thanks for your contribution. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref

Re: [HACKERS] ANALYZE command progress checker

ype of thing - not particularly pretty / easy to use. Greetings, Andres Freund -- 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] amcheck (B-Tree integrity checking tool)

Hi, On 2017-03-09 19:04:46 -0800, Peter Geoghegan wrote: > On Thu, Mar 9, 2017 at 4:41 PM, Andres Freund <and...@anarazel.de> wrote: > > I don't really expect buildfarm fallout, but .. > > Unfortunately, there is some on Windows: Thanks for monitoring. > verify_nb

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

On 2017-03-10 10:29:39 +0900, Michael Paquier wrote: > On Fri, Mar 10, 2017 at 3:01 AM, Robert Haas wrote: > > On Wed, Mar 8, 2017 at 10:18 PM, Roman Shaposhnik wrote: > >> I'd like to offer a forward port from a change I'm contributing > >> the Greenplum

Re: [HACKERS] amcheck (B-Tree integrity checking tool)

On 2017-03-09 16:29:24 -0800, Peter Geoghegan wrote: > I am generally in favor of more inclusive Reviewed-By lists. I suggest > that we expand it to: > > "Reviewed-By: Andres Freund, Thomas Vondra, Thomas Munro, Anastasia > Lubennikova, Robert Haas, Amit Langote" And pu

Re: [HACKERS] amcheck (B-Tree integrity checking tool)

On 2017-03-06 20:40:59 -0800, Peter Geoghegan wrote: > On Mon, Mar 6, 2017 at 3:57 PM, Andres Freund <and...@anarazel.de> wrote: > > I'm ok with not immediately doing so, but I think Peter's design isn't > > in line with achieving something like this. > > I would be oka

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

On 2017-03-09 16:37:29 -0500, Tom Lane wrote: > Robert Haas writes: > > On Thu, Mar 9, 2017 at 2:30 PM, Peter Eisentraut > > wrote: > >> In practice, I think it's common to do a quick select * from > >> pg_stat_activity to determine

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

Hi, On 2017-03-09 14:30:21 -0500, Peter Eisentraut wrote: > In practice, I think it's common to do a quick select * from > pg_stat_activity to determine whether a database instance is in use. > (You always see your own session, but that's easy to eyeball.) If we > add all the various background

Re: [HACKERS] Performance issue after upgrading from 9.4 to 9.6

overy_min_apply_delay? Although I'd expect more timestamp calls in that case. Greetings, Andres Freund -- 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] Need a builtin way to run all tests faster manner

On 2017-03-08 16:32:49 -0500, Peter Eisentraut wrote: > On 3/6/17 19:53, Andres Freund wrote: > > I'm just not quite sure what the best way is to make it easier to run > > tests in parallel within the tree. > > make check-world -j2 seems to run fine for me. Hm, I at le

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

On 2017-03-07 20:58:35 +0800, Simon Riggs wrote: > On 7 March 2017 at 20:36, Alvaro Herrera wrote: > > > FWIW, +1 on improving matters here. > > +1 also. > > I don't see what's wrong with relying on buildfarm though; testing is > exactly what its there for. > > If we

Re: [HACKERS] REINDEX CONCURRENTLY 2.0

f ending up with invalid indexes - not that there are none - and it's widespread usage, I'm not too concerned about this. Greetings, Andres Freund -- 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] Skip all-visible pages during second HeapScan of CIC

reduced, because it's held for a shorter amount of time. We need to hold a slightly "more aggressive" snapshot, that's true, but if you have high xid throughput those effects should roughly balance each other. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgs

Re: [HACKERS] Skip all-visible pages during second HeapScan of CIC

On 2017-03-07 21:03:53 -0500, Robert Haas wrote: > On Tue, Mar 7, 2017 at 4:26 PM, Stephen Frost wrote: > > Right, that's what I thought he was getting at and my general thinking > > was that we would need a way to discover if a CIC is ongoing on the > > relation and therefore

Re: [HACKERS] WIP: Faster Expression Processing v4

t'd certainly be annoying if that'd prevent you from dropping columns. > How are argument types handled? We fall through to return expression_tree_walker(node, find_expr_references_walker, (void *) context); which'll ad

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

); +static void *dense_alloc(HashJoinTable hashtable, Size size, +bool respect_work_mem); I still dislike this, but maybe Robert's point of: On 2017-02-16 08:57:21 -0500, Robert Haas wrote: > On Wed, Feb 15, 2017 at 9:36 PM, Andres Fre

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

Hi, On 2017-03-07 02:57:30 +1300, Thomas Munro wrote: > I'm not sure why nodeHashjoin.c is doing raw batchfile read/write > operations anyway; why not use tuplestore.c for that (as > tuplestore.c's comments incorrectly say is the case)? Another reason presumably is that using tuplestores would

Re: [HACKERS] SQL/JSON in PostgreSQL

Hi, On 2017-03-07 12:21:59 +0300, Oleg Bartunov wrote: > On 2017-03-03 15:49:38 -0500, David Steele wrote: > > I propose we move this patch to the 2017-07 CF so further development > > and review can be done without haste and as the standard becomes more > > accessible. +1 > I wanted to have

Re: [HACKERS] Poor memory context performance in large hash joins

On 2017-03-07 13:06:39 -0500, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > >>> On 2017-02-24 18:04:18 -0500, Tom Lane wrote: > >>>> Concretely, something like the attached. This passes regression tests > >>>> but I've not p

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

Hi, On 2017-03-08 00:15:05 +1300, David Rowley wrote: > -static List *RecoveryLockList; > +/* > + * RecoveryLockTable is a poor man's hash table that allows us to partition > + * the stored locks. Which partition a lock is stored in is determined by the > + * xid which the lock belongs to. The

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

On 2017-03-06 19:45:27 -0500, Tom Lane wrote: > Stephen Frost <sfr...@snowman.net> writes: > > * Andres Freund (and...@anarazel.de) wrote: > >> I'm not quite sure what the best way to attack this is, but I think we > >> need to do something. > > > I ten

Re: [HACKERS] Performance degradation in TPC-H Q18

On 2017-03-06 18:59:02 -0500, Robert Haas wrote: > On Mon, Mar 6, 2017 at 5:19 PM, Andres Freund <and...@anarazel.de> wrote: > > The whole performance issue trigger this thread only exists when the > > hashtable sizes are mis-estimated, right? Turns out that after applying &

Re: [HACKERS] amcheck (B-Tree integrity checking tool)

On 2017-02-13 12:05:21 -0500, Robert Haas wrote: > On Fri, Feb 10, 2017 at 8:39 PM, Peter Geoghegan <p...@bowt.ie> wrote: > > On Thu, Feb 9, 2017 at 2:32 PM, Andres Freund <and...@anarazel.de> wrote: > >> Except that the proposed names aren't remotely like that...

Re: [HACKERS] amcheck (B-Tree integrity checking tool)

Hi, On 2017-02-13 11:52:53 -0500, Robert Haas wrote: > On Thu, Feb 9, 2017 at 5:32 PM, Andres Freund <and...@anarazel.de> wrote: > >> > Again, some parts of the code doing something bad isn't a good argument > >> > for doing again. Releasing locks early

Re: [HACKERS] PATCH: two slab-like memory allocators

On 2017-03-02 22:51:09 +0100, Tomas Vondra wrote: > Attaches is the last part of the patch series, rebased to current master and > adopting the new chunk header approach. Something seems to have gone awry while sending that - the attachement is a whopping 0 bytes... -- Sent via pgsql-hackers

Re: [HACKERS] PATCH: two slab-like memory allocators

Hi, On 2017-03-06 23:32:30 +0100, Tomas Vondra wrote: > > > The question however is whether this won't make the optimization > > > pointless. > > > I also, wonder how much we save by this optimization and how widely it's > > > used? Can someone point me to some numbers? > > > > I don't recall

Re: [HACKERS] Performance degradation in TPC-H Q18

On 2017-03-06 16:58:23 -0500, Robert Haas wrote: > On Mon, Mar 6, 2017 at 3:32 PM, Andres Freund <and...@anarazel.de> wrote: > >> I think DEBUG1 is far too high for something that could occur with > >> some frequency on a busy system; I'm fairly strongly of the

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

time. There's also some tests simply taking way too long, e.g. the pg_dump tests just do largely redundant tests for 30s. I'm not quite sure what the best way to attack this is, but I think we need to do something. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hac

Re: [HACKERS] Performance degradation in TPC-H Q18

On 2017-03-04 11:09:40 +0530, Robert Haas wrote: > On Sat, Mar 4, 2017 at 5:56 AM, Andres Freund <and...@anarazel.de> wrote: > > attached is a patch to address this problem, and the one reported by > > Dilip. I ran a lot of TPC-H and other benchmarks, and so far t

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

Hi, This issue has bothered me in non-partitioned use-cases recently, so thanks for taking it up. On 2017-03-06 18:22:17 +0300, Aleksander Alekseev wrote: > diff --git a/src/backend/postmaster/pgstat.c b/src/backend/postmaster/pgstat.c > index 2fb9a8bf58..fa906e7930 100644 > ---

Re: [HACKERS] PATCH: two slab-like memory allocators

Hi, On 2017-03-06 19:49:56 +0100, Tomas Vondra wrote: > On 03/06/2017 07:05 PM, Robert Haas wrote: > > On Mon, Mar 6, 2017 at 12:44 PM, Andres Freund <and...@anarazel.de> wrote: > > > On 2017-03-06 12:40:18 -0500, Robert Haas wrote: > > > > On Wed, M

Re: [HACKERS] PATCH: two slab-like memory allocators

On 2017-03-06 12:40:18 -0500, Robert Haas wrote: > On Wed, Mar 1, 2017 at 5:55 PM, Andres Freund <and...@anarazel.de> wrote: > > The issue was that on 32bit platforms the Datum returned by some > > functions (int2int4_sum in this case) isn't actually a separately > >

Re: [HACKERS] ANALYZE command progress checker

On 2017-03-03 15:33:15 -0500, David Steele wrote: > On 3/1/17 1:25 PM, Andres Freund wrote: > > On 2017-03-01 10:20:41 -0800, David Fetter wrote: > >> On Wed, Mar 01, 2017 at 09:45:40AM -0500, Peter Eisentraut wrote: > >>> On 2/28/17 04:24, vinayak wrote: > >&

Re: [HACKERS] [PATCH] Use $ parameters as replacement characters for pg_stat_statements

Hi, On 2017-03-04 11:02:14 -0500, Tom Lane wrote: > But speaking of ambiguity: isn't it possible for $n symbols to appear in > pg_stat_statements already? Indeed. > I think it is, both from extended-protocol > client queries and from SPI commands, which would mean that the proposal > as it

Re: [HACKERS] REINDEX CONCURRENTLY 2.0

On March 4, 2017 1:16:56 AM PST, Robert Haas wrote: >Maybe. But it looks to me like this patch is going to have >considerably more than its share of user-visible warts, and I'm not >very excited about that. I feel like what we ought to be doing is >keeping the index OID

Re: [HACKERS] PATCH: two slab-like memory allocators

On 2017-03-01 22:19:30 -0800, Andres Freund wrote: > On 2017-03-02 04:36:23 +0100, Tomas Vondra wrote: > > I've noticed two minor typos: > > > > 1) That is solved this by creating ... > >- extra "this" > > > > 2) Given this

Re: [HACKERS] Performance degradation in TPC-H Q18

wrote: > On Fri, Mar 3, 2017 at 8:41 AM, Robert Haas <robertmh...@gmail.com> wrote: > > On Fri, Mar 3, 2017 at 1:22 AM, Andres Freund <and...@anarazel.de> wrote: > >> the resulting hash-values aren't actually meaningfully influenced by the > >> IV. Because w

Re: [HACKERS] Skip all-visible pages during second HeapScan of CIC

On 2017-03-03 15:12:04 -0800, Peter Geoghegan wrote: > On Tue, Feb 28, 2017 at 5:42 AM, Pavan Deolasee > wrote: > > During the second heap scan of CREATE INDEX CONCURRENTLY, we're only > > interested in the tuples which were inserted after the first scan was > > started.

Re: [HACKERS] Skip all-visible pages during second HeapScan of CIC

Hi, On 2017-02-28 19:12:03 +0530, Pavan Deolasee wrote: > Since VM bits are only set during VACUUM which conflicts with CIC on the > relation lock, I don't see any risk of incorrectly skipping pages that the > second scan should have scanned. I think that's true currently, but it'd also prevent

Re: [HACKERS] Statement-level rollback

On 2017-03-03 11:54:06 -0500, David Steele wrote: > Given that this landed on March 28 with no discussion beforehand, I > recommend that we immediately move this patch to the 2017-07 CF. Seconded. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] Performance degradation in TPC-H Q18

On 2017-03-01 11:05:33 +0530, Kuntal Ghosh wrote: > On Wed, Mar 1, 2017 at 10:53 AM, Andres Freund <and...@anarazel.de> wrote: > > On 2017-03-01 10:47:45 +0530, Kuntal Ghosh wrote: > >> if (insertdist > curdist) > >> { > >> swap the entry to be insert

Re: [HACKERS] Performance degradation in TPC-H Q18

Hi, On 2017-03-01 10:39:11 +0530, Kuntal Ghosh wrote: > On Wed, Mar 1, 2017 at 9:33 AM, Kuntal Ghosh <kuntalghosh.2...@gmail.com> > wrote: > > On Wed, Mar 1, 2017 at 9:19 AM, Andres Freund <and...@anarazel.de> wrote: > >> That's without the patch in > >>

Re: [HACKERS] PATCH: two slab-like memory allocators

On 2017-03-02 04:47:13 +0100, Tomas Vondra wrote: > On 03/01/2017 11:55 PM, Andres Freund wrote: > > On 2017-02-28 20:29:36 -0800, Andres Freund wrote: > > > On 2017-02-28 20:18:35 -0800, Andres Freund wrote: > > > > - Andres, hoping the buildfarm turns greener >

Re: [HACKERS] PATCH: two slab-like memory allocators

at relevant; removed and added it, not sure what's better. Greetings, Andres Freund -- 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] REINDEX CONCURRENTLY 2.0

On 2017-03-01 19:25:23 -0600, Jim Nasby wrote: > On 2/28/17 11:21 AM, Andreas Karlsson wrote: > > The only downside I can see to this approach is that we no logner will > > able to reindex catalog tables concurrently, but in return it should be > > easier to confirm that this approach can be made

Re: [HACKERS] PATCH: two slab-like memory allocators

On 2017-02-28 20:29:36 -0800, Andres Freund wrote: > On 2017-02-28 20:18:35 -0800, Andres Freund wrote: > > - Andres, hoping the buildfarm turns greener > > Oh well, that didn't work. Investigating. The fix for that was fairly trivial, and the buildfarm has cooled d

Re: [HACKERS] ANALYZE command progress checker

On March 1, 2017 11:34:48 AM PST, David Fetter wrote: >I notice that that commit has no SGML component. Should it have one? Don't think so. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- Sent via pgsql-hackers mailing list

Re: [HACKERS] ANALYZE command progress checker

On 2017-03-01 10:25:49 -0800, Andres Freund wrote: > We now have a framework for this [1] (currently used by vacuum, but > extensible). The question is about presentation. I'm fairly sure that > we shouldn't just add yet another framework, and I doubt that that's > what's propo

Re: [HACKERS] ANALYZE command progress checker

On 2017-03-01 10:20:41 -0800, David Fetter wrote: > On Wed, Mar 01, 2017 at 09:45:40AM -0500, Peter Eisentraut wrote: > > On 2/28/17 04:24, vinayak wrote: > > > The view provides the information of analyze command progress details as > > > follows > > > postgres=# \d pg_stat_progress_analyze > >

Re: [HACKERS] Possible spelling fixes

On 2017-03-01 14:40:26 -0300, Alvaro Herrera wrote: > Josh Soref wrote: > > > One thing that would be helpful is if someone could comment on: > > https://github.com/jsoref/postgres/commit/9050882d601134ea1ba26f77ce5f1aaed75418de > > -#undef SH_ITERTOR > > +#undef SH_ITERATOR > > > > It's unclear

Re: [HACKERS] Time to drop old-style (V0) functions?

On 2017-03-01 11:18:34 -0500, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > On 2016-12-08 13:34:41 -0800, Andres Freund wrote: > >> Hi, > >> > >> I'm wondering if it's not time for $subject: > >> - V0 causes confusion / weird

Re: [HACKERS] Restricting maximum keep segments by repslots

Hi, On 2017-02-28 12:42:32 +0900, Michael Paquier wrote: > Please no. Replication slots are designed the current way because we > don't want to have to use something like wal_keep_segments as it is a > wart, and this applies as well for replication slots in my opinion. I think a per-slot option

Re: [HACKERS] Time to drop old-style (V0) functions?

On 2017-02-28 23:15:15 -0800, Andres Freund wrote: > On 2016-12-08 13:34:41 -0800, Andres Freund wrote: > > Hi, > > > > I'm wondering if it's not time for $subject: > > - V0 causes confusion / weird crashes when PG_FUNCTION_INFO_V1 was > > forgotten > >

Re: [HACKERS] Time to drop old-style (V0) functions?

On 2016-12-08 13:34:41 -0800, Andres Freund wrote: > Hi, > > I'm wondering if it's not time for $subject: > - V0 causes confusion / weird crashes when PG_FUNCTION_INFO_V1 was > forgotten > - They have us keep weird hacks around just for the sake of testing V0 > - they actu

Re: [HACKERS] [GENERAL] C++ port of Postgres

Hi, On 2017-02-28 23:42:45 -0500, Peter Eisentraut wrote: > On 1/26/17 22:46, Andres Freund wrote: > > On 2016-09-30 15:24:09 -0400, Peter Eisentraut wrote: > >> Yeah, I have committed a few of the patches now and I'll close the CF > >> entry now. Thanks for your

Re: [HACKERS] Performance degradation in TPC-H Q18

On 2017-03-01 10:47:45 +0530, Kuntal Ghosh wrote: > if (insertdist > curdist) > { > swap the entry to be inserted with the current entry. > Try to insert the current entry in the same logic. > } > > So, the second approach will not cause all the followers to be shifted by 1. How not? You'll have

Re: [HACKERS] PATCH: two slab-like memory allocators

On 2017-02-28 20:18:35 -0800, Andres Freund wrote: > - Andres, hoping the buildfarm turns greener Oh well, that didn't work. Investigating. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pg

Re: [HACKERS] PATCH: two slab-like memory allocators

On 2017-02-28 10:41:22 -0800, Andres Freund wrote: > Hi, > > On 2017-02-27 23:44:20 -0800, Andres Freund wrote: > > *preliminary* patch attached. This needs a good bit of polishing > > (primarily comment work, verifying that valgrind works), but I'm too > > tired now.

Re: [HACKERS] Performance degradation in TPC-H Q18

Hi, On 2017-03-01 09:33:07 +0530, Kuntal Ghosh wrote: > On Wed, Mar 1, 2017 at 9:19 AM, Andres Freund <and...@anarazel.de> wrote: > >> So, I was looking for other alternatives and I've found one called > >> RobinHood hashing. > > > > simplehash.h implements

Re: [HACKERS] Performance degradation in TPC-H Q18

On 2017-03-01 09:21:47 +0530, Robert Haas wrote: > On Wed, Mar 1, 2017 at 8:48 AM, Andres Freund <and...@anarazel.de> wrote: > >> BTW, another option to consider is lowering the target fillfactor. > >> IIRC, Kuntal mentioned to me that cranking it down seemed to fix

Re: [HACKERS] Performance degradation in TPC-H Q18

On 2017-03-01 09:13:15 +0530, Kuntal Ghosh wrote: > On Wed, Mar 1, 2017 at 8:48 AM, Andres Freund <and...@anarazel.de> wrote: > >> BTW, another option to consider is lowering the target fillfactor. > >> IIRC, Kuntal mentioned to me that cranking it down seemed to fix

Re: [HACKERS] Performance degradation in TPC-H Q18

On 2017-03-01 08:42:35 +0530, Robert Haas wrote: > On Tue, Feb 28, 2017 at 11:16 PM, Andres Freund <and...@anarazel.de> wrote: > >> To me, it seems like a big problem that we have large, unfixed > >> performance regressions with simplehash four months after it went in.

Re: [HACKERS] Disallowing multiple queries per PQexec()

On 2017-02-28 15:59:08 +0100, Andreas Karlsson wrote: > On 02/28/2017 03:13 PM, Bruce Momjian wrote: > > I might have added that one; the text is: > > > > Consider disallowing multiple queries in PQexec() > > as an additional barrier to SQL injection attacks > > > > and it is a

Re: [HACKERS] PATCH: two slab-like memory allocators

Hi, On 2017-02-27 23:44:20 -0800, Andres Freund wrote: > *preliminary* patch attached. This needs a good bit of polishing > (primarily comment work, verifying that valgrind works), but I'm too > tired now. > > I'm not quite sure how to deal with mmgr/README - it's

Re: [HACKERS] New Committer - Andrew Gierth

Hi, On 2017-02-28 13:22:22 -0500, Stephen Frost wrote: > Greetings! > > The PostgreSQL committers would like to welcome Andrew Gierth as a new > committer for the PostgreSQL project. > > Andrew - welcome! Congratulations Andrew! We now have two Andrews and one Andres amongst the

Re: [HACKERS] Performance degradation in TPC-H Q18

Hi, On 2017-02-26 19:30:32 +0530, Robert Haas wrote: > On Wed, Feb 22, 2017 at 11:23 AM, Kuntal Ghosh > wrote: > > While conducting the experiments for parallelism, Rafia came across a > > hang in Q18 when plan uses partial and finalize hash aggregate. This > > could

Re: [HACKERS] PATCH: two slab-like memory allocators

rently failing. Thanks! - Andres >From a59c3200dd127feb0cb09a055250ff6401aee1aa Mon Sep 17 00:00:00 2001 From: Andres Freund <and...@anarazel.de> Date: Mon, 27 Feb 2017 23:32:22 -0800 Subject: [PATCH] Remove StandardChunkHeader for Slab's benefit. --- src/backend/utils/mmgr/aset.c| 51 +

Re: [HACKERS] PATCH: two slab-like memory allocators

should be doable with something like #if MAXIMUM_ALIGNOF > 4 && SIZEOF_VOID_P == 4 which'd probably be better documentation than a macro that hides this (arguing internally whether SIZEOF_VOID_P or SIZEOF_SIZE_T) is better. Working on a patch now, will post but not push tonight. Greetings,

<    6   7   8   9   10   11   12   13   14   15   >