Re: [HACKERS] Tracking wait event for latches

On Sat, Sep 24, 2016 at 1:44 AM, Michael Paquier wrote: > After digesting all the comments given, I have produced the patch > attached that uses the following categories: > +const char *const WaitEventNames[] = { > + /* activity */ > + "ArchiverMain", > +

[HACKERS] "Re: Question about grant create on database and pg_dump/pg_dumpall

On Tue, Jul 5, 2016 at 06:39 AM, Haribabu Kommi kommi(dot)haribabu(at)gmail(dot)com wrote: Still i feel the GRANT statements should be present, as the create database statement is generated only with -C option. So attached patch produces the GRANT statements based on the -x option. The attached

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

On Mon, Sep 26, 2016 at 5:11 PM, Thomas Munro wrote: > It seems that the version of docbook that you get if you follow the > instructions[1] ... > And I mean these instructions: [1] https://www.postgresql.org/docs/devel/static/docguide-toolsets.html -- Thomas

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

On Mon, Sep 26, 2016 at 1:18 PM, Thomas Munro wrote: > On Mon, Sep 19, 2016 at 4:02 PM, David Fetter wrote: > > > > [training_wheels_004.patch] > > openjade:filelist.sgml:144:16:E: character "_" invalid: only parameter > literal, "CDATA",

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

On Mon, Sep 26, 2016 at 5:48 AM, Thomas Munro wrote: > On Mon, Sep 19, 2016 at 4:02 PM, David Fetter wrote: > > > > [training_wheels_004.patch] > > openjade:filelist.sgml:144:16:E: character "_" invalid: only parameter > literal, "CDATA",

Re: [HACKERS] Use of SizeOfIptrData - is that obsolete?

On Fri, Sep 23, 2016 at 12:04 AM, Tom Lane wrote: > > I thought removing the comment altogether was not appropriate, because > it remains true that you want to work really hard to ensure that > sizeof(ItemPointerData) is 6. We're just giving up on pretense of support > for

Re: [HACKERS] Possibly too stringent Assert() in b-tree code

On Mon, Sep 26, 2016 at 8:54 AM, Amit Kapila wrote: > On Sun, Sep 25, 2016 at 9:31 PM, Tom Lane wrote: >> Amit Kapila writes: >>> On Fri, Sep 23, 2016 at 12:21 AM, Tom Lane wrote: This is clearly an

Re: [HACKERS] Possibly too stringent Assert() in b-tree code

On Sun, Sep 25, 2016 at 9:31 PM, Tom Lane wrote: > Amit Kapila writes: >> On Fri, Sep 23, 2016 at 12:21 AM, Tom Lane wrote: >>> This is clearly an oversight in Simon's patch fafa374f2, which introduced >>> this code without any

[HACKERS] Supporting huge pages on Windows

Hello, The attached patch implements huge_pages on Windows. I'll add this to the CommitFest. The performance improvement was about 2% with the following select-only pgbench. The scaling factor is 200, where the database size is roughly 3GB. I ran the benchmark on my Windows 10 PC with 6

Re: [HACKERS] [RFC] Change the default of update_process_title to off

> From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Thomas Munro > Another database vendor recommends granting SeLockMemoryPrivilege so that > it can use large pages on Windows when using several GB of buffer pool. > I wonder if that might help

Re: [HACKERS] Stopping logical replication protocol

On 26 Sep. 2016 02:16, "Vladimir Gordiychuk" wrote: > > >It looks like you didn't import my updated patches, so I've rebased your new patches on top of them. > Yes, i forgot it, sorry. Thanks for you fixes. > > >I did't see you explain why this was removed: > > -/* fast path

Re: [HACKERS] store narrow values in hash indexes?

On Sat, Sep 24, 2016 at 1:03 AM, Amit Kapila wrote: > On Sat, Sep 24, 2016 at 1:02 AM, Robert Haas wrote: >> Currently, hash indexes always store the hash code in the index, but >> not the actual Datum. It's recently been noted that this can make

Re: [HACKERS] VACUUM's ancillary tasks

On Mon, Aug 29, 2016 at 1:26 PM, Vik Fearing wrote: > While doing this, I noticed that ALTER TABLE should also re-analyze the > table for obvious reasons, so I have that one set > "changes_since_analyze" to the number of rows rewritten as well. I noticed that

Re: [HACKERS] Allowing GIN array_ops to work on anyarray

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: not tested Documentation:tested, passed I am resending this due to an earlier error message from the

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

On Mon, Sep 26, 2016 at 1:18 PM, Thomas Munro wrote: > underscore to a minus in various places. That fixes these errors: Correction: s/these errors:/the above errors./ -- Thomas Munro http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list

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

On Mon, Sep 19, 2016 at 4:02 PM, David Fetter wrote: > > [training_wheels_004.patch] openjade:filelist.sgml:144:16:E: character "_" invalid: only parameter literal, "CDATA", "ENDTAG", "MD", "MS", "PI", "PUBLIC", "SDATA", "STARTTAG", "SYSTEM" and parameter separators allowed

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

On Thu, Sep 1, 2016 at 1:41 AM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > [trimmed cc list because of big attachments] > > On 8/16/16 4:22 PM, Jim Nasby wrote: > > Joy, do you have an idea what a *minimally invasive* patch for C++ > > support would look like? That's certainly

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

On 25/09/16 22:17, Tomas Vondra wrote: > On 09/25/2016 08:48 PM, Petr Jelinek wrote: > >> Slab: >> In general it seems understandable, the initial description helps to >> understand what's happening well enough. >> >> One thing I don't understand however is why the freelist is both >> array and

Re: [HACKERS] Optimization for lazy_scan_heap

Hello, Some initial comments on optimize_lazy_scan_heap_v2.patch. >- while (next_unskippable_block < nblocks) >+ while (next_unskippable_block < nblocks && >+ !FORCE_CHECK_PAGE(next_unskippable_block)) Dont we need similar check of

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

On 09/25/2016 08:48 PM, Petr Jelinek wrote: Hi Tomas, On 02/08/16 17:44, Tomas Vondra wrote: This patch actually includes two new memory allocators (not one). Very brief summary (for more detailed explanation of the ideas, see comments at the beginning of slab.c and genslab.c): Slab *

Re: [HACKERS] Better tracking of free space during SP-GiST index build

On 09/25/2016 08:33 PM, Oleg Bartunov wrote: On Sat, Sep 24, 2016 at 11:32 PM, Tomas Vondra wrote: On 09/22/2016 07:37 PM, Tom Lane wrote: Tomas Vondra writes: ... I've tried increasing the cache size to 768 entries, with vast

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

Hi Tomas, On 02/08/16 17:44, Tomas Vondra wrote: > > This patch actually includes two new memory allocators (not one). Very > brief summary (for more detailed explanation of the ideas, see comments > at the beginning of slab.c and genslab.c): > > Slab > > * suitable for fixed-length

Re: [HACKERS] Better tracking of free space during SP-GiST index build

On Sat, Sep 24, 2016 at 11:32 PM, Tomas Vondra wrote: > On 09/22/2016 07:37 PM, Tom Lane wrote: >> >> Tomas Vondra writes: >> >>> ... I've tried increasing the cache size to 768 >>> entries, with vast majority of them (~600) allocated

Re: [HACKERS] Stopping logical replication protocol

>It looks like you didn't import my updated patches, so I've rebased your new patches on top of them. Yes, i forgot it, sorry. Thanks for you fixes. >I did't see you explain why this was removed: -/* fast path */ -/* Try to flush pending output to the client */ -if

Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

On 9/3/16 8:36 AM, Michael Paquier wrote: > > Attached is a new series: * [PATCH 1/8] Refactor SHA functions and move them to src/common/ I'd like to see more code comments in sha.c (though I realize this was copied directly from pgcrypto.) I tested by building with and without --with-openssl

[HACKERS] CommitFest 2016-09 status summary

Hi all, The current status summary is: Needs review: 65 Waiting on author: 34 Ready for Commiter: 9 Commited: 88 Moved to next CF: 1 Rejected: 11 Returned with feedback: 11 TOTAL: 219 The current progress is ~51%. We're in the last week of this CF and we still with about ~30% of patches needing

Re: [HACKERS] Possibly too stringent Assert() in b-tree code

Amit Kapila writes: > On Fri, Sep 23, 2016 at 12:21 AM, Tom Lane wrote: >> This is clearly an oversight in Simon's patch fafa374f2, which introduced >> this code without any consideration for the possibility that the page >> doesn't have a valid

Re: [HACKERS] Development build with uuid-ossp support - macOS

Enrique M writes: > Is there a way to build postgresql and install with uuid-ossp without > having to build the documentation? I don't really need the documentation > for my test. Use "make all contrib" instead of "make world". regards,

Re: [HACKERS] Development build with uuid-ossp support - macOS

I am going to try and switch to macports instead... I see the documentation provides the macports command for installing the toolset... https://www.postgresql.org/docs/9.6/static/docguide-toolsets.html Thank you. On Sat, Sep 24, 2016 at 4:52 PM Enrique M wrote:

Re: [HACKERS] pg_basebackup creates a corrupt file for pg_stat_tmp and pg_replslot on a backup location

Hi Peter, > I just wanted to update you, I have taken this commit fest entry patch > to review because I think it will be addresses as part of "Exclude > additional directories in pg_basebackup", which I'm also reviewing. > Therefore, I'm not actually planning on discussing this patch further. >

Re: [HACKERS] Patch: Implement failover on libpq connect level.

I have some more comments on libpq-failover-8.patch + /* FIXME need to check that port is numeric */ Is this still applicable?. 1) + /* + * if there is more than one host in the connect string and + * target_server_type is not specified explicitely, set + * target_server_type to "master" +

Re: [HACKERS] Write Ahead Logging for Hash Indexes

Hi All, > I forgot to mention that Ashutosh has tested this patch for a day > using Jeff's tool and he didn't found any problem. Also, he has found > a way to easily reproduce the problem. Ashutosh, can you share your > changes to the script using which you have reproduce the problem? I made

Re: [HACKERS] Hash Indexes

On 25/09/16 18:18, Amit Kapila wrote: On Sat, Sep 24, 2016 at 10:49 PM, Greg Stark wrote: On Thu, Sep 22, 2016 at 3:23 AM, Tom Lane wrote: But to kick the hash AM as such to the curb is to say "sorry, there will never be O(1) index lookups in Postgres".