Re: [HACKERS] HeapTupleSatisfiesToast() busted? (was atomic pin/unpin causing errors)

On Tue, May 10, 2016 at 4:02 PM, Andres Freund <and...@anarazel.de> wrote: > On 2016-05-10 15:53:38 -0700, Jeff Janes wrote: >> >> But isn't CreateCheckPoint called at the end of the checkpoint, not >> the start of it? > > No, CreateCheckPoint() does it all.

Re: [HACKERS] HeapTupleSatisfiesToast() busted? (was atomic pin/unpin causing errors)

327DC60, desc: NEXTOID 4302693 > > (note that end-of-recovery checkpoints are logged as shutdown > checkpoints, pretty annoying imo) > > So I think the issue is that the 2/12023C38 checkpoint *starts* before > the first NEXTOID, and thus gets an earlier nextoid. But isn't CreateCheckPoint called at the end of the checkpoint, not the start of it? I don't understand how it could be out-of-date at that point. But obviously it is. Cheers, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] HeapTupleSatisfiesToast() busted? (was atomic pin/unpin causing errors)

records you show? My current test harness updates the scalar count field on every iteration, but changes the (probably toasted) text_array field with a probability of only 1% each time. Perhaps making that more likely (by changing line 186 of count.pl) would make it easier to trigger the bug. I'll try

Re: [HACKERS] atomic pin/unpin causing errors

figuration is at which I can reproduce it. Sorry for the confusion. Cheers, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] atomic pin/unpin causing errors

On Thu, May 5, 2016 at 11:52 AM, Andres Freund <and...@anarazel.de> wrote: > Hi Jeff, > > On 2016-04-29 10:38:55 -0700, Jeff Janes wrote: >> I don't see the problem with an cassert-enabled, probably because it >> is just too slow to ever reach the point where the

Re: [HACKERS] Initial release notes created for 9.6

queries" Should be something like Avoid some unnecessary cancellations of hot-standy queries due to AccessExclusiveLocks replay. It was the cancellations, not the waits, which were spurious. Cheers, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make change

Re: [HACKERS] atomic pin/unpin causing errors

On Tue, May 3, 2016 at 4:05 PM, Andres Freund <and...@anarazel.de> wrote: > Hi Jeff, > > On 2016-04-29 10:38:55 -0700, Jeff Janes wrote: >> I've bisected the errors I was seeing, discussed in >> http://www.postgresql.org/message-id/CAMkU=1xqehc0ok4d+tkjfq1nvuho37pyrkhjp6

[HACKERS] atomic pin/unpin causing errors

the bug itself, or is just tripping over corruption left behind by someone else. (This was all run using Teodor's test-enabling patch gin_alone_cleanup-4.patch, so as not to change horses in midstream. Now that a version of that patch has been committed, I will try to repeat this in HEAD) Cheers,

Re: [HACKERS] GIN data corruption bug(s) in 9.6devel

s don't play with toast >> machinery. The single place where this error can occur is a heap_delete() - >> deleting already deleted tuple. > > Like you, I would not expect gin_alone_cleanup-4.patch to cause such an error. > I get the impression Jeff has a test case that he had run in ma

Re: [HACKERS] GIN data corruption bug(s) in 9.6devel

should use that early stopping for vacuum and gin_clean_pending_list, rather than just using it for user backends. While I think correctness allows it to stop early, since these routines are explicitly about cleaning things up it seems like they should volunteer to clean the whole thing.

Re: [HACKERS] GIN data corruption bug(s) in 9.6devel

f the problems are related to crash recovery or are more generic than that. I've never seen these particular problems before, so don't have much insight into what might be going on or how to debug it. Cheers, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make c

[HACKERS] parallel query vs extensions

with a transition file which is nothing but a list of "alter function blah blah blah parallel safe" ? And what of non-contrib extensions? Is there some clever alternative to having a bunch of pseudo versions, like "1.0", "1.0_96", "1.1", "1.1_9.6"

Re: [HACKERS] Detrimental performance impact of ringbuffers on performance

On Tue, Apr 12, 2016 at 11:38 AM, Andres Freund wrote: > >> The bottom line >> here, IMHO, is not that there's anything wrong with our ring buffer >> implementation, but that if you run PostgreSQL on a system where the >> I/O is hitting a 5.25" floppy (not to say 8") the

[HACKERS] tab completion for alter extension

ng a ";" to the list completions to signify you can optionally end the command immediately after UPDATE and have it be a complete command. But I thought perhaps that was too clever, and unprecedented. Will add to commitfest-next Cheers, Jeff diff --git a/src/bin/psql/tab-complete.c b/src/bi

[HACKERS] Sort push down through a nested loop, for 9.7

he opportunity during planning are just not worthwhile, considering how rarely the opportunity arises? Cheers, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Support for N synchronous standby servers - take 2

In function 'SyncRepUpdateConfig': syncrep.c:878:6: warning: variable 'parse_rc' set but not used [-Wunused-but-set-variable] Cheers, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] GIN data corruption bug(s) in 9.6devel

On Thu, Apr 7, 2016 at 4:33 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Jeff Janes <jeff.ja...@gmail.com> writes: >> To summarize the behavior change: > >> In the released code, an inserting backend that violates the pending >> list limit will try to clean t

Re: [HACKERS] GIN data corruption bug(s) in 9.6devel

the cleaner can clean it, leading to unbounded growth in the pending list and could cause a user backend to becoming apparently unresponsive to the user, indefinitely. That is scary to backpatch. Cheers, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] snapshot too old, configured by time

On Mon, Apr 4, 2016 at 8:38 PM, Peter Geoghegan <p...@heroku.com> wrote: > On Sun, Apr 3, 2016 at 2:09 PM, Jeff Janes <jeff.ja...@gmail.com> wrote: >> Also, HOT-cleanup should stop the bloat increase once the snapshot >> crosses the old_snapshot_threshold without

Re: [HACKERS] snapshot too old, configured by time

On Wed, Mar 30, 2016 at 12:34 PM, Kevin Grittner <kgri...@gmail.com> wrote: > On Sat, Mar 19, 2016 at 1:27 AM, Jeff Janes <jeff.ja...@gmail.com> wrote: > >> I'm not sure if this is operating as expected. >> >> I set the value to 1min. >> >> I set up

Re: [HACKERS] Draft release notes for next week's releases

te, but: + + + Correctly handle wraparound cases in the pg_subtrans + startup logic for hot standby (Jeff Janes) + + This applies to all recovery scenarios, whether they are hot standby or just plain-old automatic crash recovery. (However, it does only matter when prepare

[HACKERS] trivial typo in vacuum progress doc

"skipped blocks are included this total" The word "in" is missing Cheers, Jeff diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml new file mode 100644 index cb22afb..105d541 *** a/doc/src/sgml/monitoring.sgml --- b/doc/src/sgml/monitoring.sgml **

Re: [HACKERS] multivariate statistics v14

t=0.43..1569.70 rows=46812 width=8) (actual rows=6 loops=1) Index Cond: ((y >= 478) AND (y <= 480)) Heap Fetches: 0 Planning time: 0.175 ms Execution time: 20.264 ms (I use the "timing off" option, because without it the second plan spends most of

Re: [HACKERS] pgbench stats per script & other stuff

script into the array of scripts at all, rather than adding it in a way where it can never be selected. But then that would complicate the parsing of the per-script stats report, when one of the scripts was no longer reported. I like this way better. Would this be a welcome change? Cheers, Jeff

Re: [HACKERS] pgbench stats per script & other stuff

On Sat, Mar 19, 2016 at 11:34 AM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > Jeff Janes wrote: >> On Sat, Mar 19, 2016 at 8:41 AM, Alvaro Herrera >> <alvhe...@2ndquadrant.com> wrote: >> > I pushed your 25, with some additional minor tweaks. I hope I did

Re: [HACKERS] Weighted Stats

On Fri, Mar 18, 2016 at 11:34 PM, David Fetter <da...@fetter.org> wrote: > On Fri, Mar 18, 2016 at 06:12:12PM -0700, Jeff Janes wrote: >> Also, I think it might not give the correct answer even without >> negative weights: >> >> create table foo as select fl

Re: [HACKERS] logger process infinite loop

On Fri, Mar 18, 2016 at 10:39 PM, Andres Freund <and...@anarazel.de> wrote: > Hi, > > On 2016-03-18 21:59:01 -0700, Jeff Janes wrote: >> While testing some patches on my laptop, I noticed my knee getting >> uncomfortably warm. It turns out I has accumulating deranged lo

Re: [HACKERS] snapshot too old, configured by time

lived snapshot holder receives an error once it tries to access the table again, and then the bloat stops increasing. But shouldn't the bloat have stopped increasing as soon as the snapshot became doomed, which would be after a minute or so? Cheers, Jeff -- Sent via pgsql-hackers mailing list

[HACKERS] logger process infinite loop

0066a878 in PostmasterMain (argc=argc@entry=1, argv=argv@entry=0x26d5a10) at postmaster.c:1208 opt = status = userDoption = listen_addr_saved = i = output_config_variable = __func__ = "PostmasterMain" #5 0x0047cd1e in mai

Re: [HACKERS] Idle In Transaction Session Timeout, revived

On Wed, Mar 16, 2016 at 8:32 AM, Robert Haas wrote: > > Committed with slight changes to the docs, and I added a flag variable > instead of relying on IdleInTransactionSessionTimeout not changing at > an inopportune time. Thanks for committing, this should be a useful

Re: [HACKERS] Fuzzy substring searching with the pg_trgm extension

On Mon, Mar 14, 2016 at 9:27 AM, Artur Zakirov <a.zaki...@postgrespro.ru> wrote: > On 14.03.2016 18:48, David Steele wrote: >> >> Hi Jeff, >> >> On 2/25/16 5:00 PM, Jeff Janes wrote: >> >>> But, It doesn't sound like I am going to win that debate. G

Re: [HACKERS] Weighted Stats

ted_stddev_samp -- 2887.19919651336 The 5th digit seems too early to be seeing round-off error. Cheers, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] memory leak in GIN

extractQuery method. No backpatching, given the lack of complaints from the field. Maybe later, after this has received more field testing. I won't have a chance to do any further analysis for a while. Cheers, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)

Re: [HACKERS] multivariate statistics v14

On Wed, Mar 9, 2016 at 9:21 AM, Tomas Vondra <tomas.von...@2ndquadrant.com> wrote: > Hi, > > On Wed, 2016-03-09 at 08:45 -0800, Jeff Janes wrote: >> On Wed, Mar 9, 2016 at 7:02 AM, Tomas Vondra >> <tomas.von...@2ndquadrant.com> wrote: >> > Hi, >>

Re: [HACKERS] checkpointer continuous flushing - V18

lly correct, > and must not use weasel words. I think it's hard to talk about > performance while maintaining the general tone of the documentation. I > don't know what can be done about that. Would the wiki be a good place for such tips? Not as formal as the documentation, and more centr

Re: [HACKERS] multivariate statistics v14

On Wed, Mar 9, 2016 at 9:21 AM, Tomas Vondra <tomas.von...@2ndquadrant.com> wrote: > Hi, > > On Wed, 2016-03-09 at 08:45 -0800, Jeff Janes wrote: >> On Wed, Mar 9, 2016 at 7:02 AM, Tomas Vondra >> <tomas.von...@2ndquadrant.com> wrote: >> > Hi, >>

Re: [HACKERS] pgcrypto: add s2k-count

On Tue, Mar 8, 2016 at 4:09 PM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > Jeff Janes wrote: >> pgcrypto supports s2k-mode for key-stretching during symmetric >> encryption, and even defaults to s2k-mode=3, which means configurable >> iterations. But i

Re: [HACKERS] multivariate statistics v14

11c0 in PostmasterMain (argc=8, argv=0x23d3f20) at postmaster.c:1298 #25 0x00690026 in main (argc=8, argv=0x23d3f20) at main.c:223 Cheers, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] multivariate statistics v11

ew arguments to function 'clauselist_selectivity' Cheers, Jeff regression.diffs Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Freeze avoidance of very large table.

s. I can't imagine that this code needs to be future-proof. If we change the format again in the future, surely we can't just change this code, we would have to write new code for the new format. Cheers, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] More stable query plans via more predictable column statistics

ow if it is set out somewhere else, but there are many examples in this list of us declining to back-patch performance bug fixes which might negatively impact some users. The only times we have done it that I can think of are when there is almost no conceivable way it could have a meaningful n

[HACKERS] pg_basebackup compression TODO item

Since SSL compression seems to be a busted flush, I would like to see pg_basebackup be able to do compression on the server end, not just the client end, in order to spare network bandwidth. Any comments on how hard this would be, or why we don't want it? Cheers, Jeff -- Sent via pgsql

Re: [HACKERS] Random inconsistencies in GiST support function declarations

ld not execute query: ERROR: function gtsquery_consistent(internal, internal, integer, oid, internal) does not exist Command was: CREATE OPERATOR CLASS "gist_tp_tsquery_ops" FOR TYPE "pg_catalog"."tsquery" USING "gist" AS STORAGE bigint , OPE.

Re: [HACKERS] [NOVICE] WHERE clause not used when index is used

Rastogi Reviewer: Haribabu Kommi Rework of the code and comments by Simon Riggs It is not a part of the code-base I'm familiar with, so it is unlikely I can find the bug. Cheers, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Fuzzy substring searching with the pg_trgm extension

't sound like I am going to win that debate. Given that, I don't think we need a different name for the function. I'm fine with explaining the word-boundary subtlety in the documentation, and keeping the function name itself simple. Cheers, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] GIN data corruption bug(s) in 9.6devel

no throttle. Since the freespace recycling only takes place once the list is completely cleaned, allowing some processes to add to the end while one poor process is trying to clean can lead to less effective recycling. That is my theory, anyway. Cheers, Jeff -- Sent via pgsql-hackers mailing lis

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

n, or could it be added at the same time as the main patch? I think this is something it would be pretty frustrating for the user to be unable to do right from the start. Cheers, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Deferrable check constraints

of? (The mail archive search interface is not so helpful with common words like "check".) Cheers, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Remove or weaken hints about "effective resolution of sleep delays is 10 ms"?

On Tue, Feb 16, 2016 at 12:06 AM, Robert Haas wrote: > On Wed, Feb 10, 2016 at 5:15 PM, Andres Freund wrote: >> Hi, >> >> Several places in our docs have blurbs like >>> Note that on many systems, the effective resolution of sleep delays is >>> 10

Re: [HACKERS] Bug in StartupSUBTRANS

On Tue, Feb 9, 2016 at 10:33 AM, Simon Riggs <si...@2ndquadrant.com> wrote: > On 9 February 2016 at 18:42, Jeff Janes <jeff.ja...@gmail.com> wrote: >> >> While testing the crash resilience of the recent 2-part-commit >> improvements, I've run into a prob

[HACKERS] Seg fault in pgbench

.no-ip.org> Date: Wed Jan 27 02:54:22 2016 +0100 pgbench: improve multi-script support I wasn't able to figure out which email thread corresponds to this commit. Thanks, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription

Re: [HACKERS] Seg fault in pgbench

On Fri, Feb 12, 2016 at 12:22 PM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > Jeff Janes wrote: >> If I give pgbench an empty file, I get a segfault. >> >> $ touch empty.sql >> $ src/bin/pgbench/pgbench -T 60 -f empty.sql >> starting vacuum...end. &g

[HACKERS] pgcrypto: add s2k-count

if people inherently get the feature anyway. Cheers, Jeff diff --git a/contrib/pgcrypto/expected/pgp-encrypt.out b/contrib/pgcrypto/expected/pgp-encrypt.out new file mode 100644 index b35de79..2bf999f *** a/contrib/pgcrypto/expected/pgp-encrypt.out --- b/contrib/pgcrypto/expected/pgp-encrypt.out

Re: [HACKERS] postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs)

couple more small adjustments. I'm getting a compiler warning which I think is coming from this commit. postgres_fdw.c: In function 'fetch_more_data': postgres_fdw.c:2526:17: warning: unused variable 'fsplan' [-Wunused-variable] ForeignScan *fsplan = (ForeignScan *) node->ss.ps.plan; T

Re: [HACKERS] GIN pending list clean up exposure to SQL

This is a corner case that probably does not need to be in the docs, but I wanted to clarify it here in case you disagree: If the index ever had fastupdate turned on, when it is turned off the index will keep whatever pending_list it had until something cleans it up one last time. Thanks for th

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

obar_pkey" does not have default sorting behavior LINE 1: alter table foobar add constraint foobar_pkey primary key us... ^ DETAIL: Cannot create a primary key or unique constraint using such an index. Cheers, Jeff -- Sent via pgsql-hackers mailing list (pgsql-ha

[HACKERS] brin_summarize_new_values error checking

, as they just result in getting less specific error messages that one might hope for, rather than something worse like a panic. But still, we might want to address them. Cheers, Jeff [1] http://www.postgresql.org/message-id/CAHGQGwH=m1baejpqdpjjcneqwg8xa+p8sb+zsvhvwh6gl2j...@mail.gmail.com -- Sent via

Re: [HACKERS] GIN pending list clean up exposure to SQL

On Wed, Jan 20, 2016 at 6:17 AM, Fujii Masao <masao.fu...@gmail.com> wrote: > On Sat, Jan 16, 2016 at 7:42 AM, Julien Rouhaud > <julien.rouh...@dalibo.com> wrote: >> On 15/01/2016 22:59, Jeff Janes wrote: >>> On Sun, Jan 10, 2016 at 4:24 AM, Julien Rouhaud >

Re: [HACKERS] Combining Aggregates

included as dummy > columns in the queries for previous versions. > > The attached fixes the problem. Yep, that fixes it. Thanks, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Combining Aggregates

out=0x1e551e0, agginfo=0x1e65ec0) at pg_dump.c:12670 #1 0x0041df7a in main (argc=, argv=) at pg_dump.c:810 Cheers, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

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

te everything correctly. Unfortunately there are several merge conflicts between your patch and this commit: commit 65c5fcd353a859da9e61bfb2b92a99f12937de3b Author: Tom Lane <t...@sss.pgh.pa.us> Date: Sun Jan 17 19:36:59 2016 -0500 Restructure index access method API to hide most of

Re: [HACKERS] Truncating/vacuuming relations on full tablespaces

vacuum to short-cut out of the pending list cleanup step when it finds someone else already cleaning it. For correctness it has to either clean it itself, or wait until the other process is done (or at least, done up to the point where the tail was at the time the vacuum started). Cheers, Jeff -- Sent v

Re: [HACKERS] Proposal: speeding up GIN build with parallel workers

urrent proposal, and no one has volunteered to do the work on converting it to tuple sort instead. Cheers, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Fuzzy substring searching with the pg_trgm extension

ll them <<-> and <->> , where the first corresponds to <% and the second to %> Cheers, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] GIN pending list clean up exposure to SQL

On Sun, Jan 10, 2016 at 4:24 AM, Julien Rouhaud <julien.rouh...@dalibo.com> wrote: > On 29/12/2015 00:30, Jeff Janes wrote: >> On Wed, Nov 25, 2015 at 9:29 AM, Jeff Janes <jeff.ja...@gmail.com> wrote: >>> >>> I'll prepare a patch for core for the Janu

Re: [HACKERS] Fuzzy substring searching with the pg_trgm extension

On Sat, Dec 26, 2015 at 9:12 PM, Jeff Janes <jeff.ja...@gmail.com> wrote: > On Fri, Dec 18, 2015 at 11:43 AM, Artur Zakirov > <a.zaki...@postgrespro.ru> wrote: >> Hello. >> >> PostgreSQL has a contrib module named pg_trgm. It is used to the fuzzy text &

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

On Tue, Jan 12, 2016 at 8:59 AM, Anastasia Lubennikova <a.lubennik...@postgrespro.ru> wrote: > 08.01.2016 00:12, David Rowley: > > On 7 January 2016 at 06:36, Jeff Janes <jeff.ja...@gmail.com> wrote: >> > But now I see the reason to create non-unique index

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

raining from doing so that a beginner can do them instead. It would need to be separate from a "we can't decide if we want this or can't decide how to do it or don't have the time to do it" list. There is no reason we have to have an issue tracker in order to create that separation, but

Fwd: [HACKERS] Avoid endless futile table locks in vacuuming.

Forgetting to CC the list is starting to become a bad habit, sorry. forwarding to list: -- Forwarded message -- From: Jeff Janes <jeff.ja...@gmail.com> Date: Wed, Dec 30, 2015 at 10:03 AM Subject: Re: [HACKERS] Avoid endless futile table locks in vacuuming. To: Tom L

Re: [HACKERS] Avoid endless futile table locks in vacuuming.

On Mon, Dec 28, 2015 at 2:12 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > I wrote: >> Jeff Janes <jeff.ja...@gmail.com> writes: >>> If a partially-active table develops a slug of stable all-visible, >>> non-empty pages at the end of it, then every autovacuum of

Re: [HACKERS] GIN pending list clean up exposure to SQL

On Wed, Nov 25, 2015 at 9:29 AM, Jeff Janes <jeff.ja...@gmail.com> wrote: > > I'll prepare a patch for core for the January commitfest, and see if > it flies. If not, there is always the extension to fall back to. Here is an updated patch. I've added type and permission checks,

Re: [HACKERS] Check for interrupts in bf and xdes crypt()

rformance hit from this. Looks good to me. Applies, builds, passes make check, does what it says and says what it does. No need for docs, no noticeable performance impact. I've marked it ready for committer. Also recommend for back-patching. Cheers, Jeff -- Sent via pgsql-hackers mailing l

[HACKERS] Avoid endless futile table locks in vacuuming.

to scan the last page only if truncation is eminent. But those seem like needless complications to try to avoid sometimes scanning one block. Cheers, Jeff diff --git a/src/backend/commands/vacuumlazy.c b/src/backend/commands/vacuumlazy.c new file mode 100644 index 2429889..abc2e28 *** a/src

Re: [HACKERS] 9.5rc1 brin_summarize_new_values

On Sat, Dec 26, 2015 at 8:27 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Michael Paquier <michael.paqu...@gmail.com> writes: >> On Sat, Dec 26, 2015 at 7:10 AM, Jeff Janes <jeff.ja...@gmail.com> wrote: >>> brin_summarize_new_values() does not check that it is cal

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

er-statement] SnapshotData SnapshotDirty; ^ And the dblink contrib module fails its make check. I'm trying to find a good test case for it. Unfortunately in most of my natural use cases, the inclusion of the extra column causes the updates to become non-HOT, which causes more problems th

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

On Sat, Dec 26, 2015 at 5:58 PM, Jeff Janes <jeff.ja...@gmail.com> wrote: > > And the dblink contrib module fails its make check. Ignore the dblink complaint. It seems to have been some wonky build issue that is not reproducible. -- Sent via pgsql-hackers mailing list (p

Re: [HACKERS] Fuzzy substring searching with the pg_trgm extension

e the recent changes committed under the thread "Patch: pg_trgm: gin index scan performance for similarity search"? They conflict with your changes. Thanks, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] 9.5rc1 brin_summarize_new_values

brin_summarize_new_values() does not check that it is called on the correct type of index, nor does it check permissions. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Spurious standby query cancellations

On Wed, Dec 23, 2015 at 9:40 PM, Jeff Janes <jeff.ja...@gmail.com> wrote: > On Wed, Sep 23, 2015 at 11:33 PM, Jeff Janes <jeff.ja...@gmail.com> wrote: >> >> On further thought, neither do I. The attached patch inverts >> ResolveRecoveryConflictWithLock to be

Re: [HACKERS] COPY FREEZE and PD_ALL_VISIBLE

patch, I have marked it as "Waiting on Author". > > There has not been an update for this patch in a while, switched to > "returned with feedback" because of lack of author's input. And I've added Simon as an author, as I don't plan on picking it up again myself as long as he is working on his alternative. Thanks, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Using quicksort for every external sort run

cantly ameliorated or even eliminated by applying that patch, > too. After all, Jeff Janes had a much harder time finding a > regression, probably because he benchmarked all patches together. The regression I found when building an index on a column of 400,000,000 md5(random()::text) w

Re: [HACKERS] GIN data corruption bug(s) in 9.6devel

On Mon, Dec 21, 2015 at 11:51 AM, Tomas Vondra <tomas.von...@2ndquadrant.com> wrote: > > > On 12/21/2015 07:41 PM, Jeff Janes wrote: >> >> On Sat, Dec 19, 2015 at 3:19 PM, Tomas Vondra >> <tomas.von...@2ndquadrant.com> wrote: > > > ... > >>

Re: [HACKERS] Spurious standby query cancellations

On Wed, Sep 23, 2015 at 11:33 PM, Jeff Janes <jeff.ja...@gmail.com> wrote: > > On further thought, neither do I. The attached patch inverts > ResolveRecoveryConflictWithLock to be called back from the lmgr code so that > is it like ResolveRecoveryConflictWithBufferPin code

Re: [HACKERS] GIN data corruption bug(s) in 9.6devel

On Sat, Dec 19, 2015 at 3:19 PM, Tomas Vondra <tomas.von...@2ndquadrant.com> wrote: > Hi, > > On 11/06/2015 02:09 AM, Tomas Vondra wrote: >> >> Hi, >> >> On 11/06/2015 01:05 AM, Jeff Janes wrote: >>> >>> On Thu, Nov 5, 2015 at 3:50

Re: [HACKERS] Tab completion for ALTER COLUMN SET STATISTICS

so I've marked this patch as rejected. Thanks, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Cluster "stuck" in "not accepting commands to avoid wraparound data loss"

how template0 and template1 get frozen with xid which were 5 past the xidStopLimit? Is that part of the mystery here, or is that normal? Cheers, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Fwd: [HACKERS] Cluster "stuck" in "not accepting commands to avoid wraparound data loss"

Sorry, accidentally failed to include the list originally, here it is for the list: On Dec 16, 2015 9:52 AM, "Robert Haas" <robertmh...@gmail.com> wrote: > > On Fri, Dec 11, 2015 at 1:08 PM, Jeff Janes <jeff.ja...@gmail.com> wrote: > > Since changes to datfr

Re: [HACKERS] Disabling an index temporarily

scratch is even more horrible. I don't know if suspending maintenance (either globally or just for one session) and then doing a bulk fix-up would be less horrible, but would be willing to give it a test run. Cheers, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Using quicksort for every external sort run

On Sun, Dec 13, 2015 at 3:40 PM, Peter Geoghegan <p...@heroku.com> wrote: > On Sat, Dec 12, 2015 at 4:41 PM, Jeff Janes <jeff.ja...@gmail.com> wrote: > >>>> Also, if I am reading this correctly, when we refill a pool from a >>>> logical tape we sti

Re: [HACKERS] Disabling an index temporarily

k the thread even further in the wrong direction, but I think what Corey really wants here is to stop maintaining the index at retail while preserving the existing definition and existing index data, and then to do a wholesale fix-up, like what is done in the 2nd half of a create index concurrently

Re: [HACKERS] Using quicksort for every external sort run

On Tue, Dec 8, 2015 at 6:39 PM, Greg Stark <st...@mit.edu> wrote: > On Wed, Dec 9, 2015 at 12:02 AM, Jeff Janes <jeff.ja...@gmail.com> wrote: >> >> >> Then in the next (final) merge, it is has to read in this huge >> fragmented tape run emulation

Re: [HACKERS] Should TIDs be typbyval = FLOAT8PASSBYVAL to speed up CREATE INDEX CONCURRENTLY?

he sorting algorithm can do about that. Cheers, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Using quicksort for every external sort run

memory format. This inflates the size quite a bit, at least for single-datum tuples. If we instead just read the disk format directly into the pool, and converted them into the in-memory format when each tuple came due for the merge heap, would that destroy the locality of reference you are se

Re: [HACKERS] Using quicksort for every external sort run

On Sat, Dec 12, 2015 at 2:28 PM, Peter Geoghegan <p...@heroku.com> wrote: > On Sat, Dec 12, 2015 at 12:10 AM, Jeff Janes <jeff.ja...@gmail.com> wrote: >> I have a question about the terminology used in this patch. What is a >> tuple proper? What is it in contradis

Re: [HACKERS] Cluster "stuck" in "not accepting commands to avoid wraparound data loss"

;Nope, not me". Since with default settings each database/table gets frozen 10 times per real wrap-around, this is usually not going to be a problem as having 10 consecutive well timed crashes is very unlikely. But if you increase autovacuum_freeze_max_age a lot, or if the freeze scan t

Re: [HACKERS] Speedup twophase transactions

ta WHERE aid = :to_aid; > PREPARE TRANSACTION ':client_id.:scale'; > COMMIT PREPARED ':client_id.:scale'; > Cheers, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Using quicksort for every external sort run

On Mon, Dec 7, 2015 at 9:01 AM, Jeff Janes <jeff.ja...@gmail.com> wrote: > > The patched one ends with a 2-way, two sequential 233-way merges, and > a final 233-way merge: > > LOG: finished 2-way merge step: CPU 62.08s/435.70u sec elapsed 587.52 sec > LOG: finished 233-wa

Re: [HACKERS] On columnar storage (2)

Could we get this rebased past the merge of the parallel execution commits? Thanks, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Using quicksort for every external sort run

ens to land on a pre-existing infelicity, how big of a deal is that? It wouldn't be creating a regression, just shoving the region that experiences the problem around in such a way that it affects a different group of use cases. And perhaps more importantly, can anyone else reproduce this, or understand i

Re: [HACKERS] Using quicksort for every external sort run

x. In the extrapolated data set, each distinct value shows up a couple hundred times on average. I'm thinking of converting it to a btree_gin index once I've tested them a bit more, as the compression benefits are substantial. Cheers, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

<    1   2   3   4   5   6   7   8   9   10   >