Re: [HACKERS] Microvacuum support for Hash Index

On Thu, Mar 16, 2017 at 11:11 AM, Amit Kapila wrote: > 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(); >>> + >>> + PageIndexMultiDe

Re: [HACKERS] WAL Consistency checking for hash indexes

Hi, Attached is the patch that allows WAL consistency tool to mask 'LH_PAGE_HAS_DEAD_TUPLES' flag in hash index. The flag got added as a part of 'Microvacuum support for Hash index' patch . I have already tested it using Kuntal's WAL consistency tool and it works fine. -- With Regards, Ashutosh S

Re: [HACKERS] Partitioned tables and relfilenode

>> >> Will it help to retain the partition hierarchy as inheritance >> hierarchy and then collapse it while creating append paths. That will >> be needed by partition-wise join, will be helpful in partition pruning >> without using constraints and so on. So, may be could use that >> infrastructure

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

On Wed, Mar 15, 2017 at 9:14 PM, Kuntal Ghosh wrote: > I've attached the updated patches. Thanks for the new versions. This begins to look really clear. > In 0001-Infra-to-expose-all-backend-processes-in-pg_stat_get.patch, > I've extended BackendStatusArray to to store auxiliary processes. > Bac

[HACKERS] Re: BUG #13755: pgwin32_is_service not checking if SECURITY_SERVICE_SID is disabled

On 11/08/2016 07:56 AM, Michael Paquier wrote: On Tue, Nov 8, 2016 at 2:25 PM, Tsunakawa, Takayuki wrote: From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier Things are this way since b15f9b08 that introduced pgwin32_is_service(). S

Re: [HACKERS] logical replication launcher crash on buildfarm

On 16/03/17 04:42, Andres Freund wrote: > 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: >> https://bu

Re: [HACKERS] logical replication launcher crash on buildfarm

On 2017-03-16 09:40:48 +0100, Petr Jelinek wrote: > On 16/03/17 04:42, Andres Freund wrote: > > 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

[HACKERS] Quals not pushed down into lateral

Hi, During citus development we noticed that restrictions aren't pushed down into lateral subqueries, even if they semantically could. For example, in this dumbed down example: postgres[31776][1]=# CREATE TABLE t_2(id serial primary key); postgres[31776][1]=# CREATE TABLE t_1(id serial primary k

Re: [HACKERS] logical replication launcher crash on buildfarm

On 16/03/17 09:44, Andres Freund wrote: > On 2017-03-16 09:40:48 +0100, Petr Jelinek wrote: >> On 16/03/17 04:42, Andres Freund wrote: >>> 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 failure

Re: [HACKERS] logical replication launcher crash on buildfarm

On 2017-03-16 09:40:48 +0100, Petr Jelinek wrote: > On 16/03/17 04:42, Andres Freund wrote: > > 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

Re: [HACKERS] logical replication launcher crash on buildfarm

On 16/03/17 09:53, Andres Freund wrote: > On 2017-03-16 09:40:48 +0100, Petr Jelinek wrote: >> On 16/03/17 04:42, Andres Freund wrote: >>> 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 failure

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

Hi On Wed, Mar 15, 2017 at 5:27 PM, Robert Haas wrote: > 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,

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

On Thu, Mar 16, 2017 at 10:40 PM, Dave Page wrote: >> +const int n = snprintf(NULL, 0, "%lld", attrib.st_size); I wonder what the portable printf directive is for off_t. Maybe better to use INT64_FORMAT and cast to int64? -- Thomas Munro http://www.enterprisedb.com -- Sent via pgsql

Re: [HACKERS] Partitioned tables and relfilenode

On 2017/03/15 7:09, Robert Haas wrote: > On Mon, Mar 13, 2017 at 6:24 AM, Amit Langote > wrote: >> The previous proposal was for expand_inherited_rtentry to not create RT >> entries and AppendRelInfo's for the non-leaf tables, but I think that >> doesn't work, as I tried to explain above. We need

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

On Thu, Mar 16, 2017 at 9:54 AM, Thomas Munro wrote: > On Thu, Mar 16, 2017 at 10:40 PM, Dave Page wrote: >>> +const int n = snprintf(NULL, 0, "%lld", attrib.st_size); > > I wonder what the portable printf directive is for off_t. Maybe > better to use INT64_FORMAT and cast to int64? Hmm

Re: [HACKERS] Speedup twophase transactions

> > + * * RecoverPreparedTransactions(), StandbyRecoverPreparedTransact > ions() > + *and PrescanPreparedTransactions() have been modified to go > throug > + *gxact->inredo entries that have not made to disk yet. > > It seems to me that there should be an initial scan of pg_two

Re: [HACKERS] Parallel Bitmap scans a bit broken

> Are you getting the crash with the same test case? Yes. Here is the new backtrace: > * thread #1: tid = 0x51828fd, 0x000100caf314 > postgres`tbm_prepare_shared_iterate [inlined] pg_atomic_write_u32_impl(val=0) > at generic.h:57, queue = 'com.apple.main-thread', stop reason = > EXC_BAD_A

Re: [HACKERS] Parallel Append implementation

On 12 March 2017 at 08:50, Robert Haas wrote: >> However, Ashutosh's response made me think of something: one thing is >> that we probably do want to group all of the non-partial plans at the >> beginning of the Append so that they get workers first, and put the >> partial plans afterward. That's

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

On Thu, Mar 16, 2017 at 12:30 AM, Robert Haas wrote: > 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

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

On Thu, Mar 16, 2017 at 12:35 AM, Robert Haas wrote: > 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 chan

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

On Thu, Mar 16, 2017 at 7:22 AM, David Rowley wrote: > 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 >> >> commit/abort WAL r

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

On Thu, Mar 16, 2017 at 6:01 AM, 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 >>> commit/abort WAL records, like the attached. >> >> There's nothing setting a flag

Re: [HACKERS] Microvacuum support for Hash Index

On Thu, Mar 16, 2017 at 1:02 PM, Ashutosh Sharma wrote: > On Thu, Mar 16, 2017 at 11:11 AM, Amit Kapila wrote: >> On Wed, Mar 15, 2017 at 9:23 PM, Ashutosh Sharma >> wrote: >>> Few other comments: 1. + if (ndeletable > 0) + { + /* No ereport(ERROR) until changes ar

Re: [HACKERS] Defaulting psql to ON_ERROR_ROLLBACK=interactive

On 15.03.2017 16:38, Robert Haas wrote: On Wed, Mar 15, 2017 at 2:29 AM, Peter van Hardenberg wrote: Ads and I were talking over breakfast about usability issues and he mentioned transaction cancellation during interactive sessions as a serious pain point. I suggest we update the default of ON

Re: [HACKERS] logical decoding of two-phase transactions

On 15 March 2017 at 15:42, Petr Jelinek wrote: > Thinking about this some more. Why can't we use the same mechanism > standby uses, ie, use xid to identify the 2PC? It pushes work onto the downstream, which has to keep an mapping in a crash-safe, persistent form. We'll be doing a flush of some

Re: [HACKERS] Parallel Bitmap scans a bit broken

On Thu, Mar 16, 2017 at 3:52 PM, Emre Hasegeli wrote: >> * thread #1: tid = 0x51828fd, 0x000100caf314 >> postgres`tbm_prepare_shared_iterate [inlined] >> pg_atomic_write_u32_impl(val=0) at generic.h:57, queue = >> 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0) >

Re: [HACKERS] logical decoding of two-phase transactions

> On 16 Mar 2017, at 14:44, Craig Ringer wrote: > > I'm going to try to pick this patch up and amend its interface per our > discussion earlier, see if I can get it committable. I’m working right now on issue with building snapshots for decoding prepared tx. I hope I'll send updated patch later

[HACKERS] Error handling in transactions

After the previous thread, Jean-Paul, Ads, Alvarro and I were discussing the use-case described by Joshua and trying to think about mitigating strategies. Before getting into a discussion of a proposed solution, I'll try and expand on the reasoning behind why I think this is a problem worth solving

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

On 15/03/17 17:55, Tom Lane wrote: > 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 immedia

Re: [HACKERS] Speedup twophase transactions

On Thu, Mar 16, 2017 at 7:18 PM, Nikhil Sontakke wrote: >> + * * RecoverPreparedTransactions(), >> StandbyRecoverPreparedTransactions() >> + *and PrescanPreparedTransactions() have been modified to go >> throug >> + *gxact->inredo entries that have not made to disk yet. >> >>

Re: [HACKERS] Parallel Bitmap scans a bit broken

On Thu, Mar 16, 2017 at 5:14 PM, Dilip Kumar wrote: > pg_atomic_write_u32_impl(val=0) at generic.h:57, queue = > 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0) >>> * frame #0: 0x000100caf314 postgres`tbm_prepare_shared_iterate >>> [inlined] pg_atomic_write_u32_

Re: [HACKERS] wait events for disk I/O

Thank you for the updated patch. I have applied and tested it on latest sources and the patch looks good to me. >I am not quite sure about this, as this is for stat statements. Also part from the >place you found there are many other fwrite() call into pg_stat_statements, and >I intentionally hav

Re: [HACKERS] Parallel Append implementation

On Thu, Mar 16, 2017 at 3:57 PM, Amit Khandekar wrote: > On 12 March 2017 at 08:50, Robert Haas wrote: >>> However, Ashutosh's response made me think of something: one thing is >>> that we probably do want to group all of the non-partial plans at the >>> beginning of the Append so that they get w

Re: [HACKERS] multivariate statistics (v25)

On 16 March 2017 at 09:45, Alvaro Herrera wrote: > Here's another version of 0002 after cleaning up almost everything from > David's review. I also added tests for ALTER STATISTICS in > sql/alter_generic.sql which made me realize there were three crasher bug > in here; fixed all those. It also

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

On Wed, Mar 15, 2017 at 3:44 PM, Pavan Deolasee wrote: > I couldn't find a better way without a lot of complex infrastructure. Even > though we now have ability to mark index pointers and we know that a given > pointer either points to the pre-WARM chain or post-WARM chain, this does > not solve t

Re: [HACKERS] Partitioned tables and relfilenode

On Thu, Mar 16, 2017 at 6:03 AM, Amit Langote wrote: > I think we'll need to store *somewhere* the mapping of which inh=false > partitioned table RTE is the child of which inh=true (IOW, parent) > partitioned table RTE. I mean, for the children you're going to scan, that seems to be necessary so

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

On Mon, Mar 13, 2017 at 4:48 AM, Craig Ringer wrote: > So I'm in favour of fixing the docs but I'm not keen on changing the > SQL syntax in a way that just kind of papers over part of the > problems. I agree. I think that trying to design new SQL syntax at this point is unlikely to be a good ide

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

On Thu, Mar 16, 2017 at 12:29 AM, Haribabu Kommi wrote: > 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 hav

Re: [HACKERS] postgres_fdw: support parameterized foreign joins

Hello, 2017-02-27 12:40 GMT+03:00 Etsuro Fujita : > Hi, > > I'd like to propose to support parameterized foreign joins. Attached is a > patch for that, which has been created on top of [1]. > Can you rebase the patch? It is not applied now. -- Arthur Zakirov Postgres Professional: http://www.p

Re: [HACKERS] logical replication launcher crash on buildfarm

On Thu, Mar 16, 2017 at 5:13 AM, Petr Jelinek wrote: > Hmm now that you mention it, I remember discussing something similar > with you last year in Dallas in regards to parallel query. IIRC Windows > should not have this problem but other systems with EXEC_BACKEND do. > Don't remember the details

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

On Fri, Mar 10, 2017 at 11:57:30AM -0800, Joshua Drake wrote: > Hello, > > 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_co

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

Vaishnavi Prabakaran wrote: > So, attached the alternative fix for this issue. > Please share me your thoughts. I assume you prefer the alternative fix because it's simpler. > I would also like to hear Craig's opinion on it before applying this fix > to the original patch, just to make s

Re: [HACKERS] scram and \password

On 03/14/2017 11:14 PM, Tom Lane wrote: In short, I don't think that argument refutes my position that "md5" in pg_hba.conf should be understood as allowing SCRAM passwords too. Yeah, let's do that. Here's a patch. I had some terminology trouble with the docs. What do you call a user that has

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

Noah Misch writes: > On Wed, Mar 15, 2017 at 12:04:11PM +0300, Aleksander Alekseev wrote: >> If it no too much trouble could you please explain what will happen >> on such platforms? > Both port.h and a system header will furnish a strlcpy() declaration. The #if > you modified exists to avoid th

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

On 03/16/2017 06:19 AM, Robert Haas wrote: > On Mon, Mar 13, 2017 at 4:48 AM, Craig Ringer wrote: >> So I'm in favour of fixing the docs but I'm not keen on changing the >> SQL syntax in a way that just kind of papers over part of the >> problems. > > I agree. I think that trying to design new S

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

* Joe Conway (m...@joeconway.com) wrote: > On 03/16/2017 06:19 AM, Robert Haas wrote: > > On Mon, Mar 13, 2017 at 4:48 AM, Craig Ringer wrote: > >> So I'm in favour of fixing the docs but I'm not keen on changing the > >> SQL syntax in a way that just kind of papers over part of the > >> problems.

Re: [HACKERS] wait events for disk I/O

On Thu, Mar 16, 2017 at 8:28 AM, Rahila Syed wrote: > Thank you for the updated patch. > > I have applied and tested it on latest sources and the patch looks good to > me. The documentation puts the new wait events in a pretty random order. I think they should be alphabetized, like we do with the

Re: [HACKERS] scram and \password

On 03/16/2017 06:52 AM, Heikki Linnakangas wrote: > On 03/14/2017 11:14 PM, Tom Lane wrote: >> In short, I don't think that argument refutes my position that "md5" >> in pg_hba.conf should be understood as allowing SCRAM passwords too. > > Yeah, let's do that. Here's a patch. > > I had some termi

Re: [HACKERS] Parallel Bitmap scans a bit broken

> Hopefully, this time I got it correct. Since I am unable to reproduce > the issue so I will again need your help in verifying the fix. It is not crashing with the new patch. Thank you. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription

[HACKERS] Re: [PATCH] guc-ify the formerly hard-coded MAX_SEND_SIZE to max_wal_send

On 1/9/17 11:33 PM, Jon Nelson wrote: > > On Sat, Jan 7, 2017 at 7:48 PM, Jim Nasby > wrote: > > On 1/5/17 12:55 PM, Jonathon Nelson wrote: > > Attached please find a patch for PostgreSQL 9.4 which changes the > maximum amount of data that th

Re: [HACKERS] plpgsql - additional extra checks

On 1/13/17 6:55 AM, Marko Tiikkaja wrote: > On Fri, Jan 13, 2017 at 2:46 AM, Jim Nasby > wrote: > > On 1/11/17 5:54 AM, Pavel Stehule wrote: > > +too_many_rows > + > + > + When result is assigned to a variable

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

On Thu, Mar 16, 2017 at 6:48 AM, Ashutosh Bapat wrote: >> I thought the whole point here was that NOT doing that caused the >> memory usage for partitionwise join to get out of control. Am I >> confused? > > We took a few steps to reduce the memory footprint of partition-wise > join in [1] and [2

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

On Thu, Mar 16, 2017 at 7:19 AM, Ashutosh Bapat wrote: > On Thu, Mar 16, 2017 at 7:10 AM, Robert Haas wrote: >> 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 a

Re: [HACKERS] Crash on promotion when recovery.conf is renamed

On 12/20/16 2:54 AM, Michael Paquier wrote: > On Sat, Dec 17, 2016 at 9:23 PM, Magnus Hagander wrote: >> On Fri, Dec 16, 2016 at 7:08 AM, Michael Paquier >> wrote: >>> Looking at PrescanPreparedTransactions(), I am thinking as well that it >>> would >>> be better to get a hard failure when bumpin

Re: [HACKERS] Parallel Bitmap scans a bit broken

On Thu, Mar 16, 2017 at 10:56 AM, Emre Hasegeli wrote: >> Hopefully, this time I got it correct. Since I am unable to reproduce >> the issue so I will again need your help in verifying the fix. > > It is not crashing with the new patch. Thank you. Thanks for confirming. Some review comments on

Re: [HACKERS] WIP: Faster Expression Processing v4

Andres Freund writes: > On 2017-03-15 20:09:03 -0400, Tom Lane wrote: >> That scares me quite a bit, because it smells exactly like the sort of >> premature optimization that bit us on the rear in CVE-2016-5423 (cf commit >> f0c7b789a). > I don't think there's a danger similar to f0c7b789a here,

Re: [HACKERS] Renaming of pg_xlog and pg_clog

On 1/17/17 2:31 AM, Michael Paquier wrote: > On Tue, Nov 29, 2016 at 1:35 PM, Michael Paquier > wrote: >> On Tue, Nov 22, 2016 at 8:35 PM, Haribabu Kommi >> wrote: >>> Hi Craig, >>> >>> This is a gentle reminder. >>> >>> you assigned as reviewer to the current patch in the 11-2016 commitfest. >>>

Re: [HACKERS] postgres_fdw bug in 9.6

On 1/23/17 4:56 AM, Etsuro Fujita wrote: > On 2017/01/20 14:24, Ashutosh Bapat wrote: >> On Thu, Jan 19, 2017 at 10:38 PM, Robert Haas >> wrote: >>> On Wed, Jan 18, 2017 at 10:26 PM, Ashutosh Bapat >>> wrote: > Yes, I think that's broadly the approach Tom was recommending. > I don't hav

Re: [HACKERS] Push down more full joins in postgres_fdw

On 1/30/17 6:30 AM, Etsuro Fujita wrote: > On 2017/01/27 21:25, Etsuro Fujita wrote: >> On 2017/01/27 20:04, Ashutosh Bapat wrote: >>> I think we should pick up your patch on >>> 27th December, update the comment per your mail on 5th Jan. I will >>> review it once and list down the things left to c

Re: [HACKERS] WIP: Faster Expression Processing v4

I wrote: > Andres Freund writes: >> I don't think there's a danger similar to f0c7b789a here, because the >> "caller" (i.e. the node that needs the expression's result) expects >> resvalue/null to be overwritten. > Yeah, that's what I thought when I wrote the broken code in ExecEvalCase, > too.

Re: [HACKERS] [PATCH] guc-ify the formerly hard-coded MAX_SEND_SIZE to max_wal_send

On Thu, Mar 16, 2017 at 9:59 AM, David Steele wrote: > On 1/9/17 11:33 PM, Jon Nelson wrote: > > > > On Sat, Jan 7, 2017 at 7:48 PM, Jim Nasby > > wrote: > > > > On 1/5/17 12:55 PM, Jonathon Nelson wrote: > > > > Attached please find a patch for Postg

Re: [HACKERS] PATCH: recursive json_populate_record()

On 2/1/17 12:53 AM, Michael Paquier wrote: > On Thu, Jan 26, 2017 at 6:49 AM, Tom Lane wrote: >> Nikita Glukhov writes: >>> On 25.01.2017 23:58, Tom Lane wrote: I think you need to take a second look at the code you're producing and realize that it's not so clean either. This extract f

Re: [HACKERS] [PATCH] guc-ify the formerly hard-coded MAX_SEND_SIZE to max_wal_send

On Mon, Jan 9, 2017 at 4:27 PM, Jonathon Nelson wrote: > [I have not done a rigid analysis, here, but...] > > I *think* libpq is the culprit here. > > walsender says "Hey, libpq - please send (up to) 128KB of data!" and doesn't > "return" until it's "sent". Then it sends more. Regardless of the >

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

Michael Paquier wrote: > What are you using as CFLAGS? As both typenames should be normally > set, what about initializing those fields with NULL and add an > assertion like the attached? Actually, my compiler was right -- this was an ancient bug I introduced in 9.5 (commit a61fd533), and this ne

[HACKERS] Re: [PATCH] guc-ify the formerly hard-coded MAX_SEND_SIZE to max_wal_send

On 3/16/17 11:53 AM, Jon Nelson wrote: > > > On Thu, Mar 16, 2017 at 9:59 AM, David Steele > wrote: > > On 1/9/17 11:33 PM, Jon Nelson wrote: > > > > On Sat, Jan 7, 2017 at 7:48 PM, Jim Nasby > >

Re: [HACKERS] PoC: Make it possible to disallow WHERE-less UPDATE and DELETE

On Thu, Feb 2, 2017 at 12:24 PM, David Fetter wrote: >> Also, somebody who wants a check like that isn't necessarily going >> to want "no WHERE clause" training wheels. So you're going to need >> to think about facilities to enable or disable different checks. > > This is just the discussion I'd

Re: [HACKERS] Microvacuum support for Hash Index

>>> Sure, but we are not clearing in conditionally. I am not sure, how >>> after recovery it will be cleared it gets set during normal operation. >>> Moreover, btree already clears similar flag during replay (refer >>> btree_xlog_delete). >> >> You were right. In case datachecksum is enabled or wa

[HACKERS] Re: Floating point comparison inconsistencies of the geometric types

On 2/1/17 6:36 AM, Emre Hasegeli wrote: >> Got it, but if other people don't agree then this is going nowhere. > > Yes. As I wrote, I don't particularly care about functions like "is > point on line". I can prepare a patch to fix as many problems as > possible around those operators by preservin

Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan

On 2/1/17 3:59 PM, Pavel Stehule wrote: > Hi > > 2017-01-24 21:33 GMT+01:00 Pavel Stehule >: > > Perhaps that's as simple as renaming all the existing _ns_* > functions to _block_ and then adding support for pragmas... > > Sinc

Re: [HACKERS] pgbench more operators & functions

On 2/4/17 4:51 AM, Fabien COELHO wrote: > > Hello, > >> For my 2c, at least, while I'm definitely interested in this, it's not >> nearly high enough on my plate with everything else going on to get any >> attention in the next few weeks, at least. >> >> I do think that, perhaps, this patch may de

Re: [HACKERS] Review: GIN non-intrusive vacuum of posting tree

On 2/5/17 11:04 AM, Andrew Borodin wrote: > Hi, Jeff! > > 2017-02-05 3:45 GMT+05:00 Jeff Davis : >> On Sun, Jan 22, 2017 at 10:32 PM, Jeff Davis wrote: >>> On Sat, Jan 21, 2017 at 4:25 AM, Andrew Borodin >>> wrote: >>> One idea I had that might be simpler is to use a two-stage page >>> delete.

Re: [HACKERS] Time to up bgwriter_lru_maxpages?

On 2/2/17 2:47 PM, Robert Haas wrote: > On Wed, Feb 1, 2017 at 9:47 PM, Jim Nasby wrote: >> Before doing that the first thing to look at would be why the limit is >> currently INT_MAX / 2 instead of INT_MAX. > > Generally the rationale for GUCs with limits of that sort is that > there is or might

Re: [HACKERS] Time to up bgwriter_lru_maxpages?

On 3/16/17 12:41 PM, Robert Haas wrote: > On Thu, Mar 16, 2017 at 12:39 PM, David Steele wrote: >>> Anyway, I committed the patch posted here. Or the important line out >>> of the two, anyway. :-) >> >> It seems that this submission should be marked as "Committed" with >> Robert as the committer

Re: [HACKERS] Time to up bgwriter_lru_maxpages?

On Thu, Mar 16, 2017 at 12:39 PM, David Steele wrote: >> Anyway, I committed the patch posted here. Or the important line out >> of the two, anyway. :-) > > It seems that this submission should be marked as "Committed" with > Robert as the committer. Am I missing something? I think you are rig

Re: [HACKERS] Potential data loss of 2PC files

On 2/13/17 12:10 AM, Michael Paquier wrote: > On Tue, Jan 31, 2017 at 11:07 AM, Michael Paquier > wrote: >> On Mon, Jan 30, 2017 at 10:52 PM, Heikki Linnakangas wrote: >>> If that can happen, don't we have the same problem in many other places? >>> Like, all the SLRUs? They don't fsync the direct

Re: [HACKERS] Push down more full joins in postgres_fdw

On Thu, Mar 16, 2017 at 11:46 AM, David Steele wrote: > $ patch -p1 < ../other/postgres-fdw-subquery-support-v15.patch > patching file contrib/postgres_fdw/deparse.c > Hunk #11 succeeded at 1371 (offset -3 lines). > Hunk #12 succeeded at 1419 (offset -3 lines). > Hunk #13 succeeded at 1486 (offset

[HACKERS] Re: Improve OR conditions on joined columns (common star schema problem)

On 2/14/17 4:03 PM, Tom Lane wrote: > Jim Nasby writes: >> On 2/14/17 1:18 PM, Tom Lane wrote: >>> One point that could use further review is whether the de-duplication >>> algorithm is actually correct. I'm only about 95% convinced by the >>> argument I wrote in planunionor.c's header comment. >

Re: [HACKERS] asynchronous execution

On Mon, Mar 13, 2017 at 9:28 PM, Amit Langote wrote: > On 2017/03/14 10:08, Corey Huinker wrote: > >> I don't think the plan itself will change as a result of applying this > >> patch. You might however be able to observe some performance > improvement. > > > > I could see no performance improvem

Re: [HACKERS] GSOC - TOAST'ing in slices

Hello all, thank you for your replies. I agree with Alexander Korotkov that it is important to have a quality patch at the end of the summer. Stephen, you mentioned PostGIS, but the conversation seems to lean towards JSONB. What are your thoughts? Also, if I am to include some ideas/approac

Re: [HACKERS] [POC] A better way to expand hash indexes.

On 2/21/17 4:58 AM, Mithun Cy wrote: > Thanks, Amit > > On Mon, Feb 20, 2017 at 9:51 PM, Amit Kapila wrote: >> How will high and lowmask calculations work in this new strategy? >> Till now they always work on doubling strategy and I don't see you >> have changed anything related to that code. Ch

Re: [HACKERS] CREATE/ALTER ROLE PASSWORD ('value' USING 'method')

On Thu, Mar 9, 2017 at 4:59 AM, Michael Paquier wrote: > On Thu, Mar 9, 2017 at 1:17 AM, Joe Conway wrote: > > On 03/07/2017 08:29 PM, Tom Lane wrote: > >> Michael Paquier writes: > >>> here is a separate thread dedicated to the following extension for > >>> CREATE/ALTER ROLE: PASSWORD ('value'

Re: [HACKERS] Push down more full joins in postgres_fdw

On Thu, Mar 16, 2017 at 12:48 PM, Robert Haas wrote: > On Thu, Mar 16, 2017 at 11:46 AM, David Steele wrote: >> $ patch -p1 < ../other/postgres-fdw-subquery-support-v15.patch >> patching file contrib/postgres_fdw/deparse.c >> Hunk #11 succeeded at 1371 (offset -3 lines). >> Hunk #12 succeeded at

Re: [HACKERS] LWLock optimization for multicore Power machines

On 2/21/17 9:54 AM, Bernd Helmle wrote: > Am Dienstag, den 14.02.2017, 15:53 +0300 schrieb Alexander Korotkov: >> +1 >> And you could try to use pg_wait_sampling >> to sampling of wait >> events. > > I've tried this with your example from your blog

Re: [HACKERS] PinBuffer() no longer makes use of strategy

On 2/4/17 2:47 PM, Alexander Korotkov wrote: > On Sat, Feb 4, 2017 at 4:33 AM, Andres Freund > wrote: > > On 2017-02-03 19:13:45 -0600, Jim Nasby wrote: > > No, I noticed it while reading code. Removing that does mean that if any > > non-default strategy (in

Re: [HACKERS] Parallel Bitmap scans a bit broken

On Thu, Mar 16, 2017 at 8:42 PM, Robert Haas wrote: > Thanks for confirming. Some review comments on v2: > > +if (istate->pagetable) fixed > > Please compare explicitly to InvalidDsaPointer. > > +if (iterator->ptbase) > +ptbase = iterator->ptbase->ptentry; > +if (iterator->ptp

Re: [HACKERS] Parallel Bitmap scans a bit broken

On Thu, Mar 16, 2017 at 8:26 PM, Emre Hasegeli wrote: >> Hopefully, this time I got it correct. Since I am unable to reproduce >> the issue so I will again need your help in verifying the fix. > > It is not crashing with the new patch. Thank you. Thanks for verifying. -- Regards, Dilip Kumar

Re: [HACKERS] [patch] reorder tablespaces in basebackup tar stream for backup_label

Hi, sorry, it took me a while to get back to this. Am Freitag, den 03.03.2017, 15:44 +0900 schrieb Michael Paquier: > On Wed, Feb 22, 2017 at 9:23 PM, Bernd Helmle wrote: > > The comment in the code says explicitely to add the base directory to > > the end of the list, not sure if that is out of

Re: [HACKERS] Review: GIN non-intrusive vacuum of posting tree

2017-03-16 21:27 GMT+05:00 David Steele : > This patch applies cleanly and compiles at cccbdde. > > Jeff, any thoughts on Andrew's responses? Hi, David! I've got some updates on the matter of this patch, since the understanding of the B-tree bothered me much. Currently, I'm at PgConf.Russia, wher

Re: [HACKERS] logical replication launcher crash on buildfarm

On 2017-03-16 09:27:59 -0400, Robert Haas wrote: > On Thu, Mar 16, 2017 at 5:13 AM, Petr Jelinek > wrote: > > Hmm now that you mention it, I remember discussing something similar > > with you last year in Dallas in regards to parallel query. IIRC Windows > > should not have this problem but other

Re: [HACKERS] Review: GIN non-intrusive vacuum of posting tree

On Thu, Mar 16, 2017 at 11:53 AM, Andrew Borodin wrote: > 2. Thus, L&S fully concurrent vacuum is possible, indeed, and > furthermore Theodor suggested that I should implement not only page > eviction, but also page merge and tree condence algorithm. I think that it's very hard to make merging o

Re: [HACKERS] pgbench more operators & functions

Hello David, This patch applies cleanly and compiles at cccbdde with some whitespace issues. $ patch -p1 < ../other/pgbench-more-ops-funcs-9.patch (Stripping trailing CRs from patch.) My guess is that your mailer changed the eol-style of the file when saving it: sh> sha1sum pg-patches/

Re: [HACKERS] Review: GIN non-intrusive vacuum of posting tree

2017-03-16 23:55 GMT+05:00 Peter Geoghegan : > On Thu, Mar 16, 2017 at 11:53 AM, Andrew Borodin wrote: >> 2. Thus, L&S fully concurrent vacuum is possible, indeed, and >> furthermore Theodor suggested that I should implement not only page >> eviction, but also page merge and tree condence algorit

Re: [HACKERS] Monitoring roles patch

Hi Dave, The patch failed applied... patch -p1 < /home/vagrant/pg_monitor.diff patching file contrib/pg_buffercache/Makefile patching file contrib/pg_buffercache/pg_buffercache--1.2--1.3.sql patching file contrib/pg_buffercache/pg_buffercache.control patching file contrib/pg_freespacemap/Makefile

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

On Thu, Mar 16, 2017 at 6:09 AM, Dave Page wrote: > Hmm, good point. Google seems to be saying there isn't one. Patch > updated as you suggest (and I've added back in a function declaration > that got lost in the rebasing of the last version). OK, I took another look at this: - The documentation

Re: [HACKERS] Parallel Bitmap scans a bit broken

On Thu, Mar 16, 2017 at 1:50 PM, Dilip Kumar wrote: > fixed Committed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.

Re: [HACKERS] logical replication launcher crash on buildfarm

On Thu, Mar 16, 2017 at 2:55 PM, Andres Freund wrote: > I indeed think it's not safe, and it's going to get less and less safe > on windows (or EXEC_BACKEND). I don't think we can afford to disable > ASLR in the long run (I indeed supect that'll just be disallowed at some > point), and that's the

Re: [HACKERS] Parallel Append implementation

On Thu, Mar 16, 2017 at 8:48 AM, Ashutosh Bapat wrote: > Why do we need following code in both ExecAppendInitializeWorker() and > ExecAppendInitializeDSM()? Both of those things happen before starting the > actual execution, so one of those should suffice? > +/* Choose the optimal subplan to b

[HACKERS] temp_buffers vs temp vs local and explain

-hackers, I was reviewing an explain plan today and with some help from Andrew G, I got a lot more information than I deserved. It did however bring up quite a usability issue that I think we should consider. Let's review the following two lines: Sort Method: external merge Disk: 19352kB

Re: [HACKERS] Parallel Append implementation

On Thu, Mar 16, 2017 at 6:27 AM, Amit Khandekar wrote: > Attached is an updated patch v7, which does the above. Some comments: - You've added a GUC (which is good) but not documented it (which is bad) or added it to postgresql.conf.sample (also bad). - You've used a loop inside a spinlock-prote

Re: [HACKERS] asynchronous execution

Corey Huinker writes: > I reworked the test such that all of the foreign tables inherit from the > same parent table, and if you query that you do get async execution. But It > doesn't work when just stringing together those foreign tables with UNION > ALLs. > I don't know how to proceed with thi

  1   2   >