Re: [HACKERS] New expression evaluator and indirect jumps

Hi Jeff, On 2017-04-01 17:36:42 -0700, Jeff Davis wrote: > Thank you for your great work on the expression evaluator: > https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=b8d7f053c5c2bf2a7e8734fe3327f6a8bc711755 > > I was looking at the dispatch code, and it goes to significant

[HACKERS] New expression evaluator and indirect jumps

Andres, Thank you for your great work on the expression evaluator: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=b8d7f053c5c2bf2a7e8734fe3327f6a8bc711755 I was looking at the dispatch code, and it goes to significant effort (using computed goto) to generate many indirect

Re: [HACKERS] Page Scan Mode in Hash Index

Hi, Thanks for the review. >>> I am suspicious that _hash_kill_items() is going to have problems if >>> the overflow page is freed before it reacquires the lock. >>> _btkillitems() contains safeguards against similar cases. >> >> I have added similar check for hash_kill_items() as well. >> > > I

Re: [HACKERS] GSoC 2017 Proposal for "Explicitly support predicate locks in index access methods besides btree"

On Sat, Apr 1, 2017 at 9:03 AM, anant khandelwal wrote: > From my findings the dependencies which create the anomalies in Snapshot > isolation are: > > wr-dependencies: if T1 writes a version of an object, and T2 > reads that version, then T1 appears to have executed

Re: [HACKERS] [PATCH] few fts functions for jsonb

On 03/31/2017 03:17 PM, Oleg Bartunov wrote: > > > On 30 Mar 2017 23:43, "Dmitry Dolgov" <9erthali...@gmail.com > > wrote: > > On 31 March 2017 at 00:01, Andrew Dunstan > > wrote: >

Re: [HACKERS] [PATCH] Generic type subscripting

2017-03-28 19:31 GMT+03:00 Dmitry Dolgov <9erthali...@gmail.com>: > On 28 March 2017 at 12:08, Dmitry Dolgov <9erthali...@gmail.com> wrote: >> >> Wow, I didn't notice that, sorry - will fix it shortly. > > So, here is the corrected version of the patch. Thank you! The patch looks good to me. But

Re: [HACKERS] BRIN de-summarize ranges

Alvaro Herrera wrote: > > However, I found that when calling brin_desummarize_range > > successively, an assertion is failed. It seems to me that it occurs > > when desummarizing a revmap page that is already desummarized. > > You're right, it's broken for that case. Here's a fixed patch.

Re: [HACKERS] brin autosummarization -- autovacuum "work items"

On Sat, Apr 1, 2017 at 10:09 AM, Alvaro Herrera wrote: > Alvaro Herrera wrote: > > > I also removed the behavior that on index creation the final partial > > block range is always summarized. It's pointless. > > I just pushed this, without this change, because it

Re: [HACKERS] New CORRESPONDING clause design

Pavel Stehule writes: > [ corresponding_clause_v12.patch ] I worked on this for awhile but eventually decided that it's not very close to being committable. The main thing that's scaring me off is a realization that there are a *lot* of places that assume that the

Re: [HACKERS] BRIN de-summarize ranges

Seki, Eiji wrote: > However, I found that when calling brin_desummarize_range > successively, an assertion is failed. It seems to me that it occurs > when desummarizing a revmap page that is already desummarized. You're right, it's broken for that case. Here's a fixed patch. -- Álvaro

[HACKERS] Re: GSoC 2017 Proposal for "Explicitly support predicate locks in index access methods besides btree"

Also can i use the testing tool reside at src/test/isolation. or i should use the testing tool dtester from markus wanner On Sat, Apr 1, 2017 at 7:33 PM, anant khandelwal wrote: > Hi guys, > > My name is Anant Khandelwal currently i am pursuing masters from IIT - > Delhi

Re: [HACKERS] brin autosummarization -- autovacuum "work items"

Alvaro Herrera wrote: > I also removed the behavior that on index creation the final partial > block range is always summarized. It's pointless. I just pushed this, without this change, because it breaks src/test/modules/brin. I still think it's pointless, but it'd require more than one line

Re: [HACKERS] brin autosummarization -- autovacuum "work items"

Robert Haas wrote: > On Tue, Mar 21, 2017 at 4:10 PM, Alvaro Herrera > wrote: > > Well, the number of work items is currently fixed; but if you have many > > BRIN indexes, then you'd overflow (lose requests). By using DSA I am > > making it easy to patch this afterwards

Re: [HACKERS] gitlab post-mortem: pg_basebackup waiting for checkpoint

On Fri, Mar 31, 2017 at 8:59 AM, Magnus Hagander wrote: > > On Wed, Mar 29, 2017 at 1:05 PM, Michael Banck > wrote: > >> Hi, >> >> Am Montag, den 27.02.2017, 16:20 +0100 schrieb Magnus Hagander: >> > On Sun, Feb 26, 2017 at 9:59 PM, Tom Lane

Re: [HACKERS] gitlab post-mortem: pg_basebackup waiting for checkpoint

On Mon, Feb 27, 2017 at 7:46 PM, Jeff Janes wrote: > On Sun, Feb 26, 2017 at 12:32 PM, Magnus Hagander > wrote: > >> >> On Sun, Feb 26, 2017 at 8:27 PM, Michael Banck > > wrote: >> >>> Hi, >>> >>> Am Dienstag, den

Re: [HACKERS] [COMMITTERS] pgsql: Avoid GatherMerge crash when there are no workers.

On Fri, Mar 31, 2017 at 10:26 PM, Andres Freund wrote: > Hi, > > On 2017-04-01 01:22:14 +, Robert Haas wrote: >> Avoid GatherMerge crash when there are no workers. > > I think the gather merge code needs a bit more test coverage (sorry to > make this a larger theme today).

Re: [HACKERS] Multiple false-positive warnings from Valgrind

On Sat, Apr 1, 2017 at 2:51 PM, Noah Misch wrote: > Does this remove the noise under --with-openssl? > > --- a/src/port/pg_strong_random.c > +++ b/src/port/pg_strong_random.c > @@ -104,7 +104,10 @@ pg_strong_random(void *buf, size_t len) > */ > #if

[HACKERS] GSoC 2017 Proposal for "Explicitly support predicate locks in index access methods besides btree"

Hi guys, My name is Anant Khandelwal currently i am pursuing masters from IIT - Delhi and previously i am a software engineer. I am particularly interested in working on the project "Explicitly support predicate locks in index access methods besides b tree".I have gone through

Re: [HACKERS] [sqlsmith] Failed assertion in _hash_kill_items/MarkBufferDirtyHint

On Apr 1, 2017 18:11, "Amit Kapila" wrote: On Sat, Apr 1, 2017 at 6:00 AM, Robert Haas wrote: > On Fri, Mar 31, 2017 at 6:09 PM, Ashutosh Sharma wrote: >> Well, That is another option but the main idea was to be inline with

Re: [HACKERS] [sqlsmith] Failed assertion in _hash_kill_items/MarkBufferDirtyHint

On Sat, Apr 1, 2017 at 6:00 AM, Robert Haas wrote: > On Fri, Mar 31, 2017 at 6:09 PM, Ashutosh Sharma > wrote: >> Well, That is another option but the main idea was to be inline with >> the btree code. > > That's not a bad goal in principal, but

Re: [HACKERS] Partitioning vs ON CONFLICT

On Fri, Mar 31, 2017 at 11:44 PM, Robert Haas wrote: > On Fri, Mar 31, 2017 at 5:33 PM, Peter Geoghegan wrote: >> In my opinion, for the very limited ON CONFLICT DO NOTHING + no >> inference specification case, the implementation should not care about >> the

Re: [HACKERS] Page Scan Mode in Hash Index

On Mon, Mar 27, 2017 at 7:04 PM, Ashutosh Sharma wrote: >> >> I am suspicious that _hash_kill_items() is going to have problems if >> the overflow page is freed before it reacquires the lock. >> _btkillitems() contains safeguards against similar cases. > > I have added

Re: [HACKERS] parallel bitmapscan isn't exercised in regression tests

On Sat, Apr 1, 2017 at 12:16 AM, Andres Freund wrote: > Hi, > > The parallel code-path isn't actually exercised in the tests added in > [1], as evidenced by [2] (they just explain). That imo needs to be > fixed. Thanks for reporting. Attached patch fixes that. -- Regards,

Re: [HACKERS] [sqlsmith] Failed assertion in _hash_kill_items/MarkBufferDirtyHint

Hi Andreas, On Apr 1, 2017 16:15, "Andreas Seltenreich" wrote: Andreas Seltenreich writes: >>> TRAP: FailedAssertion("!(LWLockHeldByMe(((LWLock*) (&(bufHdr)->content_lock", File: "bufmgr.c", Line: 3397) > I got about one TRAP per hour when testing on 20 nodes with one

Re: [HACKERS] [sqlsmith] Failed assertion in _hash_kill_items/MarkBufferDirtyHint

Andreas Seltenreich writes: >>> TRAP: FailedAssertion("!(LWLockHeldByMe(((LWLock*) >>> (&(bufHdr)->content_lock", File: "bufmgr.c", Line: 3397) > I got about one TRAP per hour when testing on 20 nodes with one postgres > and 5 sqlsmithes on each. > Ashutosh Sharma writes: >> [2.

Re: [HACKERS] PATCH: pageinspect / add page_checksum and bt_page_items(bytea)

Hi Tomas, On Fri, Mar 31, 2017 at 11:05 PM, Tomas Vondra wrote: > On 03/31/2017 06:01 PM, Ashutosh Sharma wrote: >> >> >> It seems like the latest patch(v4) shared by Tomas upthread is an >> empty patch. If I am not wrong, please share the correct patch. >> Thanks.

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

On Sat, Apr 1, 2017 at 12:31 PM, Mithun Cy wrote: > Also adding a patch which implements the 2nd way. Sorry, I forgot to add sortbuild_hash patch, which also needs similar changes for the hash_mask. -- Thanks and Regards Mithun C Y EnterpriseDB:

Re: [HACKERS] make check-world output

On Sat, Mar 11, 2017 at 11:14:36AM -0500, Tom Lane wrote: > Alvaro Herrera writes: > > Tom Lane wrote: > >> What about just reverting 2f227656076a? > > > That works for me too, if we think we no longer need that level of > > detail. > > A general issue with this sort

Re: [HACKERS] Page Scan Mode in Hash Index

Hi, > > On 03/29/2017 09:16 PM, Ashutosh Sharma wrote: >>> >>> This patch needs a rebase. >> >> >> Please try applying these patches on top of [1]. I think you should be >> able >> to apply it cleanly. Sorry, I think I forgot to mention this point in my >> earlier mail. >> >> [1] - >> >>

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

On Sat, Apr 1, 2017 at 7:05 AM, Robert Haas wrote: > Hmm, don't the changes to contrib/pageinspect/expected/hash.out > indicate that you've broken something? The hash index has only 4 > buckets, so the new code shouldn't be doing anything differently, but > you've got

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

On Fri, Mar 31, 2017 at 11:54 PM, Pavan Deolasee wrote: > > On Fri, Mar 31, 2017 at 11:16 PM, Robert Haas wrote: >> >> Now, I understand you to be suggesting a flag at >> table-creation time that would, maybe, be immutable after that, but >>