Re: [HACKERS] Write Ahead Logging for Hash Indexes

On Tue, Sep 20, 2016 at 10:24 PM, Jeff Janes wrote: > On Thu, Sep 15, 2016 at 11:42 PM, Amit Kapila > wrote: >> >> >> Okay, Thanks for pointing out the same. I have fixed it. Apart from >> that, I have changed _hash_alloc_buckets() to initialize

[HACKERS] Re: [HACKERS] Error running custom plugin: “output plugins have to declare the _PG_output_plugin_init symbol”

On Tue, Sep 20, 2016 at 4:32 PM, valeriof wrote: > Hi Ashutosh, > Thank you for your answer. At the end I realized that the PGDLLEXPORT > keyword was missing from the functions definitions. > > As a side question, what are the options to debug the plugin while it's

Re: [HACKERS] Tracking wait event for latches

On Wed, Sep 21, 2016 at 1:03 PM, Thomas Munro wrote: > Yeah but that's at run time. I meant you could help developers > discover ASAP if they add a new item to one place but not the other > with a compile time assertion: > const char * >

Re: [HACKERS] Tracking wait event for latches

On Wed, Sep 21, 2016 at 3:40 PM, Michael Paquier wrote: > On Wed, Sep 21, 2016 at 8:13 AM, Thomas Munro > wrote: >> It looks like this array wants to be in alphabetical order, but it >> isn't quite. Also, perhaps a compile time assertion

Re: [HACKERS] Tracking wait event for latches

On Wed, Sep 21, 2016 at 8:13 AM, Thomas Munro wrote: > + > + EventSet: The server process is waiting on a socket > + or a timer. This wait happens in a latch, an inter-process facility > + using boolean variables letting a process

Re: [HACKERS] Logical Replication WIP

On Tue, 20 Sep 2016, Peter Eisentraut wrote: On 9/18/16 4:17 PM, Steve Singer wrote: I think if we want to prevent the creation of subscriptions that point to self, then we need to create a magic token when the postmaster starts and check for that when we connect. So more of a

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

On Tue, Sep 20, 2016 at 9:15 AM, Dilip Kumar wrote: > +1 > > My test are under run, I will post it soon.. I have some more results now 8 socket machine 10 min run(median of 3 run) synchronous_commit=off scal factor = 300 share buffer= 8GB test1: Simple

Re: [HACKERS] Fix Error Message for allocate_recordbuf() Failure

On Wed, Sep 21, 2016 at 10:25 AM, Michael Paquier wrote: > On Wed, Sep 21, 2016 at 12:32 AM, Robert Haas wrote: >> For what it's worth, I think it's fine. Good error messages are a useful >> thing. >> >> More generally, I think the whole patch

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

On Thu, Sep 15, 2016 at 6:01 AM, Robert Haas wrote: > On Fri, Sep 2, 2016 at 2:33 AM, Haribabu Kommi > wrote: > > On Wed, Aug 31, 2016 at 3:19 AM, Alvaro Herrera < > alvhe...@2ndquadrant.com> > > wrote: > >> Haribabu Kommi wrote: > >> > >>> Apart

Re: [HACKERS] Fix Error Message for allocate_recordbuf() Failure

On Wed, Sep 21, 2016 at 12:32 AM, Robert Haas wrote: > For what it's worth, I think it's fine. Good error messages are a useful > thing. > > More generally, I think the whole patch looks good and should be committed. Hm. I'd think that it is still more portable to just

Re: [HACKERS] [PATCH] get_home_path: use HOME

2016-09-20 18:35 GMT+02:00, Tom Lane : > Rudolf Gavlas writes: >> The usage of HOME environment variable (if set) is IMO the right, >> standard and faster way to get_home_path(). > > Can you provide some evidence for that claim? I can believe "faster"

Re: [HACKERS] [PATCH] get_home_path: use HOME

2016-09-20 18:55 GMT+02:00, Alvaro Herrera : > Rudolf Gavlas wrote: > >> I work in an environment, where servers are administered by people >> with different user names and identical uid (0). > > So everyone is superuser there? That sounds, um, unorthodox. Yes, the

Re: [HACKERS] Exclude schema during pg_restore

On 9/19/16 3:23 PM, Michael Banck wrote: > Version 2 attached. Committed, thanks. I added the new option to the help output in pg_restore. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via

Re: [HACKERS] Hash Indexes

On Mon, Sep 19, 2016 at 03:50:38PM -0400, Robert Haas wrote: > It will probably have some bugs, but they probably won't be worse than > the status quo: > > WARNING: hash indexes are not WAL-logged and their use is discouraged > > Personally, I think it's outright embarrassing that we've had that

Re: [HACKERS] less expensive pg_buffercache on big shmem

On 09/02/2016 11:01 AM, Robert Haas wrote: On Fri, Sep 2, 2016 at 8:49 AM, Andres Freund wrote: On 2016-09-02 08:31:42 +0530, Robert Haas wrote: I wonder whether we ought to just switch from the consistent method to the semiconsistent method and call it good. +1. I

Re: [HACKERS] less expensive pg_buffercache on big shmem

On 09/05/2016 06:19 PM, Ivan Kartyshov wrote: On 09/03/2016 05:04 AM, Tomas Vondra wrote: This patch needs a rebase, as 06d7fd6e bumped the version to 1.2. Thank you for a valuable hint. So, will we get a rebased patch? I see the patch is back in 'needs review' but there's no new version.

Re: [HACKERS] Tracking wait event for latches

+ + EventSet: The server process is waiting on a socket + or a timer. This wait happens in a latch, an inter-process facility + using boolean variables letting a process sleep until it is set. + Latches support several type of operations, like

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

Hi, On 09/19/2016 09:10 PM, Robert Haas wrote: > It's possible that the effect of this patch depends on the number of sockets. EDB test machine cthulhu as 8 sockets, and power2 has 4 sockets. I assume Dilip's tests were run on one of those two, although he doesn't seem to have mentioned which

Re: [HACKERS] gratuitous casting away const

> On Sep 20, 2016, at 1:06 PM, Tom Lane wrote: > > Mark Dilger writes: >> Would patches to not cast away const be considered? > > In general, yes, but I'm not especially in favor of something like this: > >> bool >> PageIndexTupleOverwrite(Page

Re: [HACKERS] needlessly casting away const in localtime.c

Mark Dilger writes: > Friends, per the recent thread "gratuitous casting away const", the > assignment on line 1247 of localtime.c has const lvalue and rvalue, > yet casts through (char *) rather than (const char *). Fix attached. If you want to propose cosmetic

[HACKERS] needlessly casting away const in localtime.c

Friends, per the recent thread "gratuitous casting away const", the assignment on line 1247 of localtime.c has const lvalue and rvalue, yet casts through (char *) rather than (const char *). Fix attached. Mark Dilger localtime.c.patch Description: Binary data -- Sent via pgsql-hackers

Re: [HACKERS] increasing the default WAL segment size

On 2016-09-20 16:32:46 -0400, Robert Haas wrote: > > Requiring a non-default compile time or even just cluster creation time > > option for tuning isn't something worth expanding energy on imo. > > I don't agree. The latency requirements on an archive_command when > you're churning out 16MB

Re: [HACKERS] increasing the default WAL segment size

On Tue, Sep 20, 2016 at 4:25 PM, Andres Freund wrote: >> Even with a 1GB segment size, some of them will fill multiple files >> per minute. At the current limit of 64MB, a few of them would still >> fill more than one file per second. That is not sane. > > I doubt generating

Re: [HACKERS] increasing the default WAL segment size

On 2016-09-20 16:18:02 -0400, Robert Haas wrote: > On Tue, Sep 20, 2016 at 4:09 PM, Andres Freund wrote: > > That sounds way too big to me. WAL file allocation would trigger pretty > > massive IO storms during zeroing, max_wal_size is going to be hard to > > tune, the amounts

Re: [HACKERS] increasing the default WAL segment size

On Tue, Sep 20, 2016 at 4:09 PM, Andres Freund wrote: > On 2016-09-20 16:05:44 -0400, Robert Haas wrote: >> On Tue, Sep 20, 2016 at 2:49 PM, Peter Eisentraut >> wrote: >> > On 8/24/16 9:31 PM, Robert Haas wrote: >> >> I'd like to propose that

Re: [HACKERS] increasing the default WAL segment size

On 2016-09-20 16:05:44 -0400, Robert Haas wrote: > On Tue, Sep 20, 2016 at 2:49 PM, Peter Eisentraut > wrote: > > On 8/24/16 9:31 PM, Robert Haas wrote: > >> I'd like to propose that we increase the default WAL segment size, > >> which is currently 16MB. > > > >

Re: [HACKERS] Rename max_parallel_degree?

On Tue, Sep 20, 2016 at 3:31 PM, Peter Eisentraut wrote: > On 9/20/16 11:47 AM, Robert Haas wrote: >> #define BGWORKER_CLASS_MASK 0x00f0 >> #define BGWORKER_CLASS_PARALLEL 0x0010 >> /* add additional bgworker classes here */ >>> > >>> > Unless

Re: [HACKERS] gratuitous casting away const

Mark Dilger writes: > Would patches to not cast away const be considered? In general, yes, but I'm not especially in favor of something like this: > bool > PageIndexTupleOverwrite(Page page, OffsetNumber offnum, > - Item

Re: [HACKERS] increasing the default WAL segment size

On Tue, Sep 20, 2016 at 2:49 PM, Peter Eisentraut wrote: > On 8/24/16 9:31 PM, Robert Haas wrote: >> I'd like to propose that we increase the default WAL segment size, >> which is currently 16MB. > > While the discussion about the best default value is ongoing,

[HACKERS] gratuitous casting away const

Friends, There are places in the code that cast away const for no apparent reason, fixed like such: diff --git a/src/backend/executor/nodeIndexscan.c b/src/backend/executor/nodeIndexscan.c index 3143bd9..fe2cfc2 100644 --- a/src/backend/executor/nodeIndexscan.c +++

Re: [HACKERS] Rename max_parallel_degree?

On 9/20/16 11:47 AM, Robert Haas wrote: >>> >> #define BGWORKER_CLASS_MASK 0x00f0 >>> >> #define BGWORKER_CLASS_PARALLEL 0x0010 >>> >> /* add additional bgworker classes here */ >> > >> > Unless we have a mechanism that makes use of this somehow, this attempt >> > at categorizing might be

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

On 9/20/16 3:04 PM, David Fetter wrote: > On Fri, Sep 09, 2016 at 09:57:21AM -0400, Peter Eisentraut wrote: >> Review of the patch in the commit fest: >> >> - The documentation is a bit incorrect about the ways to load this >> module. shared_preload_libraries is not necessary. session_ and >>

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

On Fri, Sep 09, 2016 at 09:57:21AM -0400, Peter Eisentraut wrote: > Review of the patch in the commit fest: > > - The documentation is a bit incorrect about the ways to load this > module. shared_preload_libraries is not necessary. session_ and > local_ (with prep) should also work. Would

Re: [HACKERS] [PATCH] get_home_path: use HOME

Rudolf Gavlas wrote: > 2016-09-20 18:55 GMT+02:00, Alvaro Herrera : > > Rudolf Gavlas wrote: > > > >> I work in an environment, where servers are administered by people > >> with different user names and identical uid (0). > > > > So everyone is superuser there? That

Re: [HACKERS] "Some tests to cover hash_index"

Why not use generate_series() queries to insert the appropriate number of tuples, instead of a handful of INSERT lines each time? Since each insert is a separate transaction, that would probably be faster. Why do you have a plpgsql function just to create a cursor? Wouldn't it be simpler to

Re: [HACKERS] increasing the default WAL segment size

On 8/24/16 9:31 PM, Robert Haas wrote: > I'd like to propose that we increase the default WAL segment size, > which is currently 16MB. While the discussion about the best default value is ongoing, maybe we should at least *allow* some larger sizes, for testing out. Currently, configure says

Re: [HACKERS] Tuplesort merge pre-reading

On Fri, Sep 9, 2016 at 9:51 PM, Claudio Freire wrote: > On Fri, Sep 9, 2016 at 8:13 AM, Heikki Linnakangas wrote: >> >> Claudio, if you could also repeat the tests you ran on Peter's patch set on >> the other thread, with these patches, that'd be nice.

Re: [HACKERS] Write Ahead Logging for Hash Indexes

On 09/16/2016 02:42 AM, Amit Kapila wrote: Okay, Thanks for pointing out the same. I have fixed it. Apart from that, I have changed _hash_alloc_buckets() to initialize the page instead of making it completely Zero because of problems discussed in another related thread [1]. I have also

Re: [HACKERS] pageinspect: Hash index support

Hi, On 09/20/2016 01:46 PM, Ashutosh Sharma wrote: I am getting a fatal error along with some warnings when trying to apply the v3 patch using "git apply" command. [ashu@localhost postgresql]$ git apply 0001-pageinspect-Hash-index-support_v3.patch

Re: [HACKERS] pageinspect: Hash index support

On 09/20/2016 12:45 PM, Jeff Janes wrote: Is the 2nd "1" in this call needed? SELECT * FROM hash_page_stats(get_raw_page('mytab_index', 1), 1) As far as I can tell, that argument is only used to stuff into the output field "blkno", it is not used to instruct the interpretation of the raw page

Re: [HACKERS] pageinspect: Hash index support

Hi, I am getting a fatal error along with some warnings when trying to apply the v3 patch using "git apply" command. [ashu@localhost postgresql]$ git apply 0001-pageinspect-Hash-index-support_v3.patch 0001-pageinspect-Hash-index-support_v3.patch:29: trailing whitespace. brinfuncs.o

Re: [HACKERS] Improvements in psql hooks for variables

Ashutosh Bapat wrote: > You may want to add this to the November commitfest > https://commitfest.postgresql.org/11/. Done. It's at https://commitfest.postgresql.org/11/799/ Best regards, -- Daniel Vérité PostgreSQL-powered mailer: http://www.manitou-mail.org Twitter: @DanielVerite --

Re: [HACKERS] Rename max_parallel_degree?

On 20/09/16 17:47, Robert Haas wrote: > On Tue, Sep 20, 2016 at 11:27 AM, Peter Eisentraut > wrote: >> On 9/19/16 2:18 PM, Robert Haas wrote: >>> I suggest that we make it part of bgw_flags, but use a bitmask for it, >>> like this: >>> >>> #define

[HACKERS] Re: [HACKERS] Re: [HACKERS] Re: [HACKERS] Re: [HACKERS] Re: [HACKERS] Windows service is not starting so there’s message in log: FATAL: "could not create shared memory segment “Global/Postgr

On Tue, Sep 20, 2016 at 1:03 PM, Tom Lane wrote: > Robert Haas writes: >> On Thu, May 26, 2016 at 7:44 PM, Michael Paquier >> wrote: >>> Yeah, it is definitely better to register it. And I have switched the >>> patch as ready

[HACKERS] Re: [HACKERS] Re: [HACKERS] Re: [HACKERS] Windows service is not starting so there’s message in log: FATAL: "could not create shared memory segment “Global/PostgreSQL.851401618”: Permission

On Tue, Sep 20, 2016 at 12:53 PM, Tom Lane wrote: > Robert Haas writes: >> Yeah, random() is the wrong thing. It should use PostmasterRandom(). >> Fixed to do that instead. > > I am not very happy about this patch; have you considered the security >

Re: [HACKERS] Re: [HACKERS] Re: [HACKERS] Re: [HACKERS] Re: [HACKERS] Windows service is not starting so there’s message in log: FATAL: "could not create shared memory segment “Global/PostgreSQL.85140

Robert Haas writes: > On Thu, May 26, 2016 at 7:44 PM, Michael Paquier > wrote: >> Yeah, it is definitely better to register it. And I have switched the >> patch as ready for committer just now. > Committed and back-patched to 9.4, where DSM was

Re: [HACKERS] [PATCH] get_home_path: use HOME

Rudolf Gavlas wrote: > I work in an environment, where servers are administered by people > with different user names and identical uid (0). So everyone is superuser there? That sounds, um, unorthodox. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7

Re: [HACKERS] Write Ahead Logging for Hash Indexes

On Thu, Sep 15, 2016 at 11:42 PM, Amit Kapila wrote: > > Okay, Thanks for pointing out the same. I have fixed it. Apart from > that, I have changed _hash_alloc_buckets() to initialize the page > instead of making it completely Zero because of problems discussed in >

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

On Tue, Sep 20, 2016 at 8:34 PM, Tom Lane wrote: > Pavan Deolasee writes: > > I happened to notice this comment in src/include/storage/itemptr.h > > > * Note: because there is an item pointer in each tuple header and index > > * tuple header on

Re: [HACKERS] Re: [HACKERS] Re: [HACKERS] Windows service is not starting so there’s message in log: FATAL: "could not create shared memory segment “Global/PostgreSQL.851401618”: Permission denied”

Robert Haas writes: > Yeah, random() is the wrong thing. It should use PostmasterRandom(). > Fixed to do that instead. I am not very happy about this patch; have you considered the security implications of what you just did? If you haven't, I'll tell you: you just made

Re: [HACKERS] pageinspect: Hash index support

On Tue, Sep 20, 2016 at 5:40 AM, Jesper Pedersen wrote: > On 09/20/2016 03:19 AM, Michael Paquier wrote: > >> You did not get right the comments from Alvaro upthread. The following >> functions are added with this patch: >> function hash_metap(text) >> function

Re: [HACKERS] [PATCH] get_home_path: use HOME

Rudolf Gavlas writes: > The usage of HOME environment variable (if set) is IMO the right, > standard and faster way to get_home_path(). Can you provide some evidence for that claim? I can believe "faster" but the rest sounds like wishful thinking. > I work in an

[HACKERS] Re: [HACKERS] Re: [HACKERS] Windows service is not starting so there’s message in log: FATAL: "could not create shared memory segment “Global/PostgreSQL.851401618”: Permission denied”

On Thu, Oct 15, 2015 at 11:32 PM, Amit Kapila wrote: > On Thu, Oct 15, 2015 at 8:35 PM, Dmitry Vasilyev > wrote: >> >> I think that function dsm_impl_windows() with EACCES error should not >> do ereport() with FATAL level. It works, but it is

[HACKERS] Re: [HACKERS] Re: [HACKERS] Re: [HACKERS] Re: [HACKERS] Windows service is not starting so there’s message in log: FATAL: "could not create shared memory segment “Global/PostgreSQL.851401618

On Thu, May 26, 2016 at 7:44 PM, Michael Paquier wrote: >> Thanks for reviewing the patch. I have added the entry for this patch in >> next CF (https://commitfest.postgresql.org/10/636/), feel free to mark it >> as Ready for committer if you think patch is good. > >

[HACKERS] [PATCH] get_home_path: use HOME

Hi, I work in an environment, where servers are administered by people with different user names and identical uid (0). The attached patch fixes a bug exposed in such environments: where the logic of retrieving a personal configuration file relies solely on get_home_path(), the different users

Re: [HACKERS] Rename max_parallel_degree?

On Tue, Sep 20, 2016 at 11:27 AM, Peter Eisentraut wrote: > On 9/19/16 2:18 PM, Robert Haas wrote: >> I suggest that we make it part of bgw_flags, but use a bitmask for it, >> like this: >> >> #define BGWORKER_CLASS_MASK 0x00f0 >> #define

Re: [HACKERS] Odd system-column handling in postgres_fdw join pushdown patch

On Fri, Jul 1, 2016 at 3:10 AM, Etsuro Fujita wrote: > On 2016/04/14 4:57, Robert Haas wrote: >> >> 1. For a regular FDW scan, zero the xmin, xmax, and cid of the tuple >> before returning it from postgres_fdw, so that we don't expose the >> datum-tuple fields. I

Re: [HACKERS] Fix Error Message for allocate_recordbuf() Failure

On Mon, Jul 11, 2016 at 12:04 AM, Michael Paquier wrote: > On Sat, Jul 9, 2016 at 2:58 AM, Shoaib Lari wrote: >> Besides making the error message more informative, we had to modify >> allocate_recordbuf() to return the actual number of bytes that were

Re: [HACKERS] Logical Replication WIP

On 9/18/16 4:17 PM, Steve Singer wrote: > When I create my subscriber database by doing a physical backup of the > publisher cluster (with cp before I add any data) then I am unable to > connect subscribe. > ie > initdb ../data > cp -r ../data ../data2 > ./postgres -D ../data > ./postgres -D

Re: [HACKERS] Rename max_parallel_degree?

On 9/19/16 2:18 PM, Robert Haas wrote: > I suggest that we make it part of bgw_flags, but use a bitmask for it, > like this: > > #define BGWORKER_CLASS_MASK 0x00f0 > #define BGWORKER_CLASS_PARALLEL 0x0010 > /* add additional bgworker classes here */ Unless we have a mechanism that makes use

Re: [HACKERS] "Some tests to cover hash_index"

On Tue, Sep 20, 2016 at 8:52 AM, Amit Kapila wrote: > I think you have a point, but not sure if it is worth to add a > separate file. It might be tricky to choose which file to add new > tests for hash_indexes. Anybody else have opinion on this point? I think all the

Re: [HACKERS] Hash Indexes

On Thu, Sep 15, 2016 at 11:11:41AM +0530, Amit Kapila wrote: > I think it is possible without breaking pg_upgrade, if we match all > items of a page at once (and save them as local copy), rather than > matching item-by-item as we do now. We are already doing similar for > btree, refer explanation

Re: [HACKERS] more parallel query documentation

On 9/19/16 1:22 PM, Robert Haas wrote: > On Fri, Sep 16, 2016 at 4:28 PM, Alvaro Herrera > wrote: >> I agree it should be added. I suggest that it could even be added to >> the 9.6 docs, if you can make it. > > Here's a patch. I intend to commit this pretty quickly

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

Pavan Deolasee writes: > I happened to notice this comment in src/include/storage/itemptr.h > * Note: because there is an item pointer in each tuple header and index > * tuple header on disk, it's very important not to waste space with > * structure padding bytes.

Re: [HACKERS] Parallel sec scan in plpgsql

On Tue, Sep 20, 2016 at 10:58 AM, Tom Lane wrote: > Maybe it would be better to fix the rule against workers > invoking their own parallel queries. That rule does have the advantage of preventing us from having one user backend launch N^2 workers. I don't think it would be

Re: [HACKERS] Parallel sec scan in plpgsql

On Tue, Sep 20, 2016 at 9:24 AM, Amit Kapila wrote: > I think here point is that for any case where there is count of rows > to be selected, we disable parallelism. There are many genuine cases > like select count(*) into cnt ... which will run to completion, but as >

Re: [HACKERS] [RFC] Should we fix postmaster to avoid slow shutdown?

On Tue, Sep 20, 2016 at 2:20 AM, Tsunakawa, Takayuki wrote: > There's no apparent evidence to indicate the cause, but I could guess a few > reasons. What do you think these are correct and should fix PostgreSQL? (I > think so) I think that we shouldn't start

Re: [HACKERS] Parallel sec scan in plpgsql

Amit Kapila writes: > On Mon, Sep 19, 2016 at 11:39 PM, Robert Haas wrote: >> However, I think the chances of supporting parallel query for queries >> not executed to completion any time in the near future are very poor. > I think here point is

Re: [HACKERS] [PATCH] Transaction traceability - txid_status(bigint)

On Mon, Sep 19, 2016 at 9:54 PM, Craig Ringer wrote: >> You appear to have attached the wrong patch set. > > Whoops, multitasking fail. > > Sorry for the late response, hospitals are "fun". I did some cleanup of 0001 (see attached) and was all set to commit it when I

Re: [HACKERS] Speedup twophase transactions

> > On 20 Sep 2016, at 09:40, Michael Paquier wrote: > Thanks for digging into this. > + StartupCLOG(); > + StartupSUBTRANS(checkPoint.oldestActiveXid); > + RecoverPreparedFromFiles(); > [...] >/* > -* Startup commit log and subtrans

Re: [HACKERS] Declarative partitioning - another take

On Thu, Sep 15, 2016 at 4:53 AM, Amit Langote wrote: > [ new patches ] Re-reviewing 0001. + partexprs + pg_node_tree This documentation doesn't match pg_partition_table.h, which has partexprsrc and partexprbin. I don't understand why it's a good idea

Re: [HACKERS] Parallel sec scan in plpgsql

On Mon, Sep 19, 2016 at 11:39 PM, Robert Haas wrote: > On Sat, Sep 17, 2016 at 11:54 PM, Amit Kapila wrote: >> In general, I think we should support the cases as required (or >> written) by you from plpgsql or sql functions. We need more work to

Re: [HACKERS] "Some tests to cover hash_index"

On Mon, Sep 19, 2016 at 8:44 PM, Mithun Cy wrote: > On Sat, Aug 6, 2016 at 9:41 AM, Amit Kapila wrote: >> I wonder why you have included a new file for these tests, why can't be >> these added to existing hash_index.sql. > tests in

Re: [HACKERS] pageinspect: Hash index support

On 09/20/2016 03:19 AM, Michael Paquier wrote: You did not get right the comments from Alvaro upthread. The following functions are added with this patch: function hash_metap(text) function hash_metap_bytea(bytea) function hash_page_items(text,integer) function hash_page_items_bytea(bytea)

Re: [HACKERS] kqueue

Hi, On 16/09/2016 05:11, Thomas Munro wrote: Still no change measurable on my laptop. Keith, would you be able to test this on your rig and see if it sucks any less than the last one? I've tested kqueue-v6.patch on the Celeron NetBSD machine and numbers were constantly lower by about 5-10%

Re: [HACKERS] Parallel sec scan in plpgsql

On 18.09.2016 06:54, Amit Kapila wrote: On Fri, Sep 16, 2016 at 8:48 PM, Alex Ignatov wrote: On 16.09.2016 16:50, Amit Kapila wrote: Can you try by setting force_parallel_mode = off;? I think it is sending the whole function execution to worker due to

Re: [HACKERS] Error running custom plugin: “output plugins have to declare the _PG_output_plugin_init symbol”

Hi Ashutosh, Thank you for your answer. At the end I realized that the PGDLLEXPORT keyword was missing from the functions definitions. As a side question, what are the options to debug the plugin while it's being executing? I've seen a debug plugin for Postgres but it seems more for SQL

Re: [HACKERS] WIP: Covering + unique indexes.

On Tue, Sep 20, 2016 at 10:51 AM, Amit Kapila wrote: > On Tue, Sep 6, 2016 at 10:18 PM, Anastasia Lubennikova > wrote: >> 28.08.2016 09:13, Amit Kapila: >> >> On Mon, Aug 15, 2016 at 8:15 PM, Anastasia Lubennikova >>

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On 03/17/2016 01:43 AM, Peter Geoghegan wrote: I attach a revision, that makes all the changes that Heikki suggested, except one. As already noted several times, following this suggestion would have added a bug. Alvaro preferred my original approach here in any case. I refer to my original

Re: [HACKERS] IF (NOT) EXISTS in psql-completion

On Mon, Sep 19, 2016 at 6:11 PM, Pavel Stehule wrote: > I am thinking so commit's description should be inside README Horiguchi-san, your patch has some whitespace issues, you may want to get a run with git diff --check. Here are some things I have spotted:

[HACKERS] Use of SizeOfIptrData - is that obsolete?

Hi, I happened to notice this comment in src/include/storage/itemptr.h * Note: because there is an item pointer in each tuple header and index * tuple header on disk, it's very important not to waste space with * structure padding bytes. The struct is designed to be six bytes long * (it

Re: [HACKERS] pageinspect: Hash index support

On Tue, Sep 20, 2016 at 1:11 AM, Jesper Pedersen wrote: > This version adds the overloaded get_raw_page based methods. However, I'm > not verifying the page other than page_id, as hasho_flag can contain > multiple flags in Amit's patches. And, I don't see having

Re: [HACKERS] Speedup twophase transactions

On Sat, Sep 17, 2016 at 2:45 AM, Stas Kelvich wrote: > Looking through old version i’ve noted few things that were bothering me: > > * In case of crash replay PREPARE redo accesses SUBTRANS, but > StartupSUBTRANS() isn’t called yet > in StartupXLOG(). > * Several

[HACKERS] [RFC] Should we fix postmaster to avoid slow shutdown?

Hello, Please let me ask you about possible causes of a certain problem, slow shutdown of postmaster when a backend crashes, and whether to fix PostgreSQL. Our customer is using 64-bit PostgreSQL 9.2.8 on RHEL 6.4. Yes, the PostgreSQL version is rather old but there's no relevant bug fix in

[HACKERS] Calculation of param_source_rels in add_paths_to_joinrel

Hi, There's code in add_paths_to_joinrel() which computes the set of target relations that should overlap parameterization of any proposed join path. 120 /* 121 * Decide whether it's sensible to generate parameterized paths for this 122 * joinrel, and if so, which relations such