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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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.

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

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

[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

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

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

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;

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

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

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

[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

[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

[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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

This mailing list does not welcome top-post replies. On Wed, Mar 15, 2017 at 12:04:11PM +0300, Aleksander Alekseev wrote: > > This is wrong on platforms that do have strlcpy() in libc. > > If it no too much trouble could you please explain what will happen > on such platforms? Both port.h and a

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

Hi 2017-03-15 17:21 GMT+01:00 Stephen Frost : > 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

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 */ >>> +

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

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

[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

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

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

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

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

[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

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

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

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;

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

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

[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

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.

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

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

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

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

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

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

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

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

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

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

[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] 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:

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 >

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

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

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 fully concurrent vacuum is possible, indeed, and >> furthermore Theodor suggested that I should implement not only page >> eviction, but also

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

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

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

Re: [HACKERS] Size vs size_t

On Fri, Mar 17, 2017 at 10:39 AM, Andres Freund wrote: > On 2017-03-16 17:24:17 -0400, Tom Lane wrote: >> Robert Haas writes: >> > On Thu, Mar 16, 2017 at 5:01 PM, Andres Freund wrote: >> >> On 2017-03-16 16:59:29 -0400, Robert Haas

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

From: Heikki Linnakangas So, I think we still need the check for Local System. Thanks, fixed and confirmed that the error message is output in the event log. Regards MauMau win32-security-service-v7.patch Description: Binary data -- Sent via pgsql-hackers mailing list

[HACKERS] [PATCH] Remove defunct and unnecessary link

The HA docs reference a “glossary” link which is no longer accessible, nor is it likely to be useful in general to link off-site IMHO. This simple patch removes this link. Best, David -- David Christensen End Point Corporation da...@endpoint.com 785-727-1171

Re: [HACKERS] \h tab-completion

On 3/15/17 22:46, Andreas Karlsson wrote: > 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

Re: [HACKERS] Making clausesel.c Smarter

David Steele writes: > Anyone familiar with the planner available to review this patch? FWIW, it's on my radar but I don't expect to get to it real soon, as there's other stuff I deem higher priority. In the meantime, I don't want to stand in the way of someone else looking

Re: [HACKERS] Size vs size_t

Andres Freund writes: > On 2017-03-16 17:24:17 -0400, Tom Lane wrote: >> The short answer to that is that "Size" predates the universal acceptance >> of size_t. If we were making these decisions today, or anytime since the >> early 2000s, we'd surely have just gone with

Re: [HACKERS] Size vs size_t

Thomas Munro writes: > Naive replacement in new files (present in master but not in 9.6) with > the attached script, followed by a couple of manual corrections where > Size was really an English word in a comment, gets the attached diff. In the case of mmgr/slab.c,

Re: [HACKERS] Renaming of pg_xlog and pg_clog

On Thu, Mar 16, 2017 at 9:31 PM, Michael Paquier wrote: > On Fri, Mar 17, 2017 at 12:19 AM, David Steele wrote: >> This patch does not apply cleanly at cccbdde: >> >> $ git apply ../other/0001-Rename-pg_clog-to-pg_xact.patch >> error:

Re: [HACKERS] Renaming of pg_xlog and pg_clog

On Fri, Mar 17, 2017 at 11:17 AM, Robert Haas wrote: > I understand that the point of renaming pg_clog to pg_xact is that > pg_clog contains the dreaded letters l-o-g, which we hypothesize > causes DBAs to remove it. (Alternate hypothesis: "So, that's what's > clogging my

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

On Thu, Mar 16, 2017 at 10:17 PM, David Steele wrote: > 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 >>>

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

On 17 March 2017 at 08:10, Stas Kelvich wrote: > While working on this i’ve spotted quite a nasty corner case with aborted > prepared > transaction. I have some not that great ideas how to fix it, but maybe i > blurred my > view and missed something. So want to ask

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

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

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

On 16 March 2017 at 19:52, Stas Kelvich wrote: > > I’m working right now on issue with building snapshots for decoding prepared > tx. > I hope I'll send updated patch later today. Great. What approach are you taking? It looks like the snapshot builder actually does

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

On Mon, Mar 13, 2017 at 5:21 PM, Tom Lane wrote: > "Daniel Verite" writes: > > Tom Lane wrote: > >> when we see \if is that we do nothing but absorb text > >> until we see the matching \endif. At that point we could bitch and > throw > >> everything

  1   2   >