Re: [HACKERS] pgbench vs. wait events

On Fri, Oct 7, 2016 at 11:14 PM, Amit Kapila wrote: > > > Another strategy that may work is actually intentionally > waiting/buffering > > some few ms between flushes/fsync, > > We do that before attempting to write if user has set "commit_delay" > and "commit_siblings" guc parameters. > If you

Re: [HACKERS] pgbench vs. wait events

On Fri, Oct 7, 2016 at 8:51 AM, Jeff Janes wrote: > > I think we need to come up with some benchmarking queries which get more > work done per round-trip to the database. And build them into the binary, > because otherwise people won't use them as much as they should if they h

Re: [HACKERS] Hash Indexes

On Mon, Oct 10, 2016 at 5:55 AM, Amit Kapila wrote: > On Thu, Sep 29, 2016 at 8:27 PM, Amit Kapila > wrote: > > On Thu, Sep 29, 2016 at 6:04 AM, Robert Haas > wrote: > > > >> Another thing I don't quite understand about this algorithm is that in > >> order to conditionally lock the target prima

Re: [HACKERS] Non-empty default log_line_prefix

On Sun, Oct 2, 2016 at 1:20 PM, Christoph Berg wrote: > Re: Tom Lane 2016-09-29 <18642.1475159...@sss.pgh.pa.us> > > > Possibly the longer version could be added as an example in the > > > documentation. > > > > I suspect that simply having a nonempty default in the first place > > is going to do

Re: [HACKERS] Non-empty default log_line_prefix

On Wed, Oct 12, 2016 at 10:11 AM, Tom Lane wrote: > Jeff Janes writes: > > On Sun, Oct 2, 2016 at 1:20 PM, Christoph Berg wrote: > >> Patch attached. (Still using %t, I don't think %m makes sense for the > >> default.) > > > What is the cost of us

Re: [HACKERS] process type escape for log_line_prefix

On Fri, Oct 14, 2016 at 4:11 AM, Christoph Berg wrote: > Re: Michael Paquier 2016-02-10 5y9bpxz+dejbfcctebf06ef2u...@mail.gmail.com> > > On Mon, Feb 8, 2016 at 11:32 PM, Andres Freund > wrote: > > > Frequently when reading postgres logs to do some post mortem analysis > > > I'm left wondering w

Re: [HACKERS] process type escape for log_line_prefix

On Fri, Oct 14, 2016 at 11:51 AM, Andres Freund wrote: > On 2016-10-14 13:11:51 +0200, Christoph Berg wrote: > > Re: Michael Paquier 2016-02-10 5y9bpxz+dejbfcctebf06ef2u...@mail.gmail.com> > > > On Mon, Feb 8, 2016 at 11:32 PM, Andres Freund > wrote: > > > > Frequently when reading postgres log

[HACKERS] postgres_fdw super user checks

postgres_fdw has some checks to enforce that non-superusers must connect to the foreign server with a password-based method. The reason for this is to prevent the authentication to the foreign server from happening on the basis of the OS user who is running the non-foreign server. But I think the

Re: [HACKERS] VACUUM's ancillary tasks

On Fri, Oct 7, 2016 at 6:14 AM, Robert Haas wrote: > On Thu, Oct 6, 2016 at 8:40 PM, Jeff Janes wrote: > > In commit 37484ad2aacef5ec7, you changed the way that frozen tuples were > > represented, so that we could make freezing more aggressive without > losing > > f

[HACKERS] "make check" and pg_hba.conf

Is there a way to get "make check" to install a custom pg_hba.conf for its temporary installation? Something like pre-prending the line: local all password_user md5 To the default pg_hba.conf? Thanks, Jeff

Re: [HACKERS] "make check" and pg_hba.conf

On Tue, Oct 18, 2016 at 2:28 PM, Tom Lane wrote: > Jeff Janes writes: > > Is there a way to get "make check" to install a custom pg_hba.conf for > its > > temporary installation? Something like pre-prending the line: > > local all password_user md5 >

Re: [HACKERS] Remove the comment on the countereffectiveness of large shared_buffers on Windows

On Mon, Nov 7, 2016 at 5:55 AM, Amit Kapila wrote: > On Tue, Sep 20, 2016 at 8:15 AM, Tsunakawa, Takayuki > wrote: > > Hello, > > > >> From: pgsql-hackers-ow...@postgresql.org > >> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Magnus > Hagander > >> On Wed, Aug 24, 2016 at 4:35 AM, Ts

[HACKERS] unchecked chdir warning

When compiling with --enable-profiling using: gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.2) I get the warning: ipc.c: In function 'proc_exit': ipc.c:137:3: warning: ignoring return value of 'chdir', declared with attribute warn_unused_result [-Wunused-result] chdir(gprofDirName)

Re: [HACKERS] Write Ahead Logging for Hash Indexes

On Sat, Sep 24, 2016 at 10:00 PM, Amit Kapila wrote: > On Fri, Sep 23, 2016 at 5:34 PM, Amit Kapila > wrote: > > > > I think here I am slightly wrong. For the full page writes, it do use > > RBM_ZERO_AND_LOCK mode to read the page and for such mode we are not > > doing page verification check a

[HACKERS] checkpoint_flush_after and friends

configuration parameters *_flush_after were added in 9.6. They are not in postgresql.conf.sample, but are also not marked GUC_NOT_IN_SAMPLE. Is this intentional and/or desirable? Cheers, Jeff

Re: [HACKERS] checkpoint_flush_after and friends

On Thu, Nov 10, 2016 at 12:17 PM, Andres Freund wrote: > On 2016-11-10 12:13:05 -0800, Jeff Janes wrote: > > configuration parameters *_flush_after were added in 9.6. They are not > in > > postgresql.conf.sample, but are also not marked GUC_NOT_IN_SAMPLE. Is > this &

Re: [HACKERS] Remove the comment on the countereffectiveness of large shared_buffers on Windows

On Mon, Nov 7, 2016 at 7:03 PM, Amit Kapila wrote: > On Tue, Nov 8, 2016 at 5:12 AM, Jeff Janes wrote: > > On Mon, Nov 7, 2016 at 5:55 AM, Amit Kapila > wrote: > >> > >> > >> Isn't it somewhat strange that writes are showing big win whereas > >

Re: [HACKERS] safer node casting

On Tue, Feb 21, 2017 at 9:00 AM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 1/26/17 16:15, Andres Freund wrote: > > On 2017-01-25 19:21:40 -0500, Tom Lane wrote: > >> Andres Freund writes: > >>> On 2016-12-31 12:08:22 -0500, Peter Eisentraut wrote: > RestrictInfo *rinfo

[HACKERS] Poor memory context performance in large hash joins

When doing a hash join with large work_mem, you can have a large number of chunks. Then if ExecHashIncreaseNumBatches gets called, those chunks are walked through, moving the tuples to new chunks (or to disk, if they no longer match the batch's bitmask), and freeing the old chunks. The number of

Re: [HACKERS] Poor memory context performance in large hash joins

On Thu, Feb 23, 2017 at 2:28 PM, Tom Lane wrote: > Jeff Janes writes: > > The number of new chunks can be almost as as large as the number of old > > chunks, especially if there is a very popular value. The problem is that > > every time an old chunk is freed, the code

Re: [HACKERS] Poor memory context performance in large hash joins

On Thu, Feb 23, 2017 at 10:47 PM, Andres Freund wrote: > On 2017-02-23 17:28:26 -0500, Tom Lane wrote: > > Jeff Janes writes: > > > The number of new chunks can be almost as as large as the number of old > > > chunks, especially if there is a very popular va

Re: [HACKERS] Poor memory context performance in large hash joins

On Fri, Feb 24, 2017 at 10:59 AM, Tom Lane wrote: > Jeff Janes writes: > > On Thu, Feb 23, 2017 at 2:28 PM, Tom Lane wrote: > >> Maybe it's time to convert that to a doubly-linked list. > > > I don't think that would help. You would need some heuristic t

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

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 14.02.2017, 18:18 -0500 schrieb Robert Haas: >> > On Tue, Feb 14, 2017 at 4:06 PM, Alvaro Herrera >> > wrote: >> > > I'd rather have a --quiet mod

Re: [HACKERS] log_autovacuum_min_duration doesn't log VACUUMs

On Wed, Mar 1, 2017 at 6:43 AM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 2/10/17 03:38, Simon Riggs wrote: > > I guess its fairly obvious in the title, but > > log_autovacuum_min_duration doesn't log VACUUMs only autovacuums. > > > > What isn't obvious is why that restructi

Re: [HACKERS] Parallel bitmap heap scan

On Wed, Mar 8, 2017 at 9:08 AM, Robert Haas wrote: > On Wed, Mar 8, 2017 at 11:20 AM, Dilip Kumar > wrote: > > Right, done that way > > This didn't compile because you bobbled some code in > src/backend/nodes, but it was a trivial mistake so I fixed it. > > Committed with that fix and a bunch of

Re: [HACKERS] [PATCH] Teach Catalog.pm how many attributes there should be per DATA() line

On Thu, Mar 9, 2017 at 3:20 PM, Robert Haas wrote: > On Mon, Mar 6, 2017 at 11:37 AM, Dagfinn Ilmari Mannsåker > wrote: > > David Christensen writes: > >>> Hi David, > >>> > >>> Here's a review of your patch. > >> > >> Hi Ilmari, thanks for your time and review. I’m fine with the revised > ver

[HACKERS] scram and \password

Should the \password tool in psql inspect password_encryption and act on it being 'scram'? I didn't see this issue discussed, but the ability to search the archives for backslashes is rather limited. Cheers, Jeff

[HACKERS] make check-world output

There was some recent discussion about making "make check-world" faster. I'm all for that, but how about making it quieter? On both machines I've run it on (CentOS6.8 and Ubuntu 16.04.2), it dumps some gibberish to stderr, example attached. Which first made me wonder whether the test passed or fa

Re: [HACKERS] make check-world output

On Fri, Mar 10, 2017 at 12:24 PM, Alvaro Herrera wrote: > Jeff Janes wrote: > > > Also, it runs in about 8 minutes, not the 20 minutes reported by others. > > My system is virtualized, and not particularly fast. I wonder if it is > > failing early somewhere without ru

Re: [HACKERS] make check-world output

On Fri, Mar 10, 2017 at 4:00 PM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 3/10/17 15:05, Jeff Janes wrote: > > There was some recent discussion about making "make check-world" > > faster. I'm all for that, but how about making it quiete

Re: [HACKERS] scram and \password

On Fri, Mar 10, 2017 at 2:43 PM, Michael Paquier wrote: > On Sat, Mar 11, 2017 at 2:53 AM, Jeff Janes wrote: > > Should the \password tool in psql inspect password_encryption and act on > it > > being 'scram'? > > Not sure if it is wise to change the de

Re: [HACKERS] make check-world output

On Fri, Mar 10, 2017 at 6:19 PM, Tom Lane wrote: > Alvaro Herrera writes: > > Jeff Janes wrote: > >> There was some recent discussion about making "make check-world" faster. > >> I'm all for that, but how about making it quieter? On both machines &

[HACKERS] Silence perl warning in check-world

In some older versions of perl (like v5.10), I get a warning that: Use of implicit split to @_ is deprecated at src/test/recovery/t/ 006_logical_decoding.pl line 26. Splitting into a dummy variable silences that warning, as in the attached. There may be a better way to silence the warning. (Pres

Re: [HACKERS] Authentication tests, and plain 'password' authentication with a SCRAM verifier

On Tue, Mar 14, 2017 at 5:36 AM, Heikki Linnakangas wrote: > Hi, > > I didn't include the authentication TAP tests that Michael wrote in the > main SCRAM commit last week. The main issue was that the new test was > tacked on the src/test/recovery test suite, for lack of a better place. I > propos

Re: [HACKERS] scram and \password

On Tue, Mar 14, 2017 at 3:15 AM, Heikki Linnakangas wrote: > On 03/14/2017 04:47 AM, Tom Lane wrote: > >> Robert Haas writes: >> >>> I'm not talking about changing the default, just having it be possible >>> to use \password with the new system as it was with the old, whatever >>> exactly we thi

Re: [HACKERS] scram and \password

On Tue, Mar 14, 2017 at 8:40 AM, Tom Lane wrote: > Joe Conway writes: > > > I was also thinking about that. Basically a primary method and a > > fallback. If that were the case, a gradual transition could happen, and > > if we want \password to enforce best practice it would be ok. > > Why exact

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 dedicated to the following extension for > >>> CREATE/ALTER ROLE: PASSWORD ('value'

[HACKERS] pageinspect and hash indexes

While trying to figure out some bloating in the newly logged hash indexes, I'm looking into the type of each page in the index. But I get an error: psql -p 9876 -c "select hash_page_type(get_raw_page('foo_index_idx',x)) from generate_series(1650,1650) f(x)" ERROR: page is not a hash page DETAIL

[HACKERS] free space map and visibility map

With some intensive crash-recovery testing, I've run into a situation where I get some bad table bloat. There will be large swaths of the table which are empty (all results from heap_page_items other than lp are either zero or NULL), but have zero available space in the fsm, and are marked as all-

Re: [HACKERS] free space map and visibility map

On Sat, Mar 18, 2017 at 2:09 PM, Masahiko Sawada wrote: > On Fri, Mar 17, 2017 at 9:37 PM, Jeff Janes wrote: > > With some intensive crash-recovery testing, I've run into a situation > where > > I get some bad table bloat. There will be large swaths of the table >

[HACKERS] segfault in hot standby for hash indexes

Against an unmodified HEAD (17fa3e8), I got a segfault in the hot standby. Using the attached files, I start the test case like this: nice sh do_nocrash_sr.sh >& do_nocrash_sr.err & And start the replica like: rm -r /tmp/data2_replica/ ; psql -p 9876 -c "select pg_create_physical_replication_sl

Re: [HACKERS] Re: why postgresql define NTUP_PER_BUCKET as 10, not other numbers smaller

On Tue, Jun 10, 2014 at 5:17 AM, Robert Haas wrote: > The problem case is when you have 1 batch and the increased memory > consumption causes you to switch to 2 batches. That's expensive. It > seems clear based on previous testing that *on the average* > NTUP_PER_BUCKET = 1 will be better, bu

Re: [HACKERS] wrapping in extended mode doesn't work well with default pager

On Wed, Jun 11, 2014 at 12:59 PM, Greg Stark wrote: > I think this whole exercise has mostly just convinced me we should > implement an HTTP interface and reimplement psql as a browser app. I certainly hope not. I've seen lots of browser apps that were nice enough to use for casual use by a cas

Re: [HACKERS] rm_desc signature

On Friday, June 13, 2014, Heikki Linnakangas wrote: > As part of the WAL-format changing patch I've been working on, I changed > the signature of the rm_desc function from: > > void (*rm_desc) (StringInfo buf, uint8 xl_info, char *rec); > void (*rm_desc) (StringInfo buf, XLogRecord *record); > >

[HACKERS] Re: [BUGS] BUG #8673: Could not open file "pg_multixact/members/xxxx" on slave during hot_standby

(Redirected from Bugs to Hackers, as it seems not to be the same bug as the original one.) On Mon, Jun 9, 2014 at 3:50 PM, Alvaro Herrera wrote: > Jeff Janes wrote: > >> This patch seems to solve a problem I've also been having with non-existent >> "pg_multixac

Re: [HACKERS] Is analyze_new_cluster.sh still useful?

On Wed, Jun 18, 2014 at 10:58 AM, Andres Freund wrote: > On 2014-06-18 13:54:16 -0400, Tom Lane wrote: >> I think we're not on the same page. My point is that someone might want >> to automate the whole sequence: stop old postmaster, run pg_upgrade, start >> the updated postmaster normally (henc

Re: [HACKERS] Is analyze_new_cluster.sh still useful?

On Wed, Jun 18, 2014 at 8:41 AM, Christoph Berg wrote: > Hi, > > now that we have vacuumdb --all --analyze-in-stages in 9.4, wouldn't > it make sense to get rid of the analyze_new_cluster.sh file which > pg_upgrade writes? The net content is a single line which could as > well be printed by pg_upg

Re: [HACKERS] TODO : Allow parallel cores to be used by vacuumdb [ WIP ]

On Fri, Mar 21, 2014 at 12:48 AM, Dilip kumar wrote: > On 16 January 2014 19:53, Euler Taveira Wrote, > >> > >> >> For the case where you have tables of varying size this would lead >> to a reduced overall processing time as it prevents large (read: long >> processing time) tables to be processed

Re: [HACKERS] autovacuum scheduling starvation and frenzy

On Thu, May 15, 2014 at 4:06 PM, Jeff Janes wrote: > On Thu, May 15, 2014 at 12:55 PM, Alvaro Herrera > wrote: >> >> Jeff Janes wrote: >> >> > If you have a database with a large table in it that has just passed >> > autovacuum_freeze_max_age, all futur

[HACKERS] Supporting Windows SChannel as OpenSSL replacement

On Wed, Jun 11, 2014 at 7:51 AM, Heikki Linnakangas wrote: > > > I did again the refactoring you did back in 2006, patch attached. One thing > I did differently: I moved the raw, non-encrypted, read/write functions to > separate functions: pqsecure_raw_read and pqsecure_raw_write. Those > function

[HACKERS] tab completion for setting search_path

On Mon, Jun 23, 2014 at 3:53 PM, Andres Freund > wrote: > On 2014-06-23 13:10:34 -0400, Robert Haas wrote: >> On Mon, Jun 23, 2014 at 9:10 AM, Kevin Grittner > wrote: >> > I would be for excluding the pg_toast, pg_toast_temp_n, and >> > pg_temp_n schemas, and including public and pg_catalog. >> >>

Re: [HACKERS] tab completion for setting search_path

On Mon, Jun 23, 2014 at 6:25 PM, Jeff Janes wrote: > On Mon, Jun 23, 2014 at 3:53 PM, Andres Freund > wrote: >> On 2014-06-23 13:10:34 -0400, Robert Haas wrote: >>> On Mon, Jun 23, 2014 at 9:10 AM, Kevin Grittner >>> wrote: >>> > I would be for ex

Re: [HACKERS] TODO : Allow parallel cores to be used by vacuumdb [ WIP ]

On Monday, June 23, 2014, Dilip kumar wrote: > On 24 June 2014 03:31, Jeff Wrote, > > > > Attached the latest updated patch > > > 1. Rebased the patch to current GIT head. > > > 2. Doc is updated. > > > 3. Supported parallel execution for all db option also. > > > > This patch needs to be reb

Re: [HACKERS] TODO : Allow parallel cores to be used by vacuumdb [ WIP ]

On Thu, Jun 26, 2014 at 2:35 AM, Dilip kumar wrote: > > Thank you for giving your time, Please review the updated patch attached in > the mail. > > > > 1. Rebased the patch > > 2. Implemented parallel execution for new option --analyze-in-stages Hi Dilip, Thanks for rebasing. I have

Re: [HACKERS] TODO : Allow parallel cores to be used by vacuumdb [ WIP ]

On Fri, Jun 27, 2014 at 4:10 AM, Dilip kumar wrote: ... > > Updated patch is attached in the mail.. Thanks Dilip. I get a compiler warning when building on Windows. When I started looking into that, I see that two files have too much code duplication between them: src/bin/scripts/vac_parallel.

Re: [HACKERS] TODO : Allow parallel cores to be used by vacuumdb [ WIP ]

On Mon, Jun 30, 2014 at 3:17 PM, Alvaro Herrera wrote: > Jeff Janes wrote: > >> In particular, pgpipe is almost an exact duplicate between them, >> except the copy in vac_parallel.c has fallen behind changes made to >> parallel.c. (Those changes would have fixed t

Re: [HACKERS] Supporting Windows SChannel as OpenSSL replacement

On Thu, Jun 26, 2014 at 4:26 PM, Andreas Karlsson wrote: > On 06/24/2014 03:20 AM, Jeff Janes wrote: > >> I've tried your 0001 patch, reflecting this refactoring, on Linux and it >> caused 'make check' to hang at 'starting postmaster'. >> > &g

Re: [HACKERS] tweaking NTUP_PER_BUCKET

On Tue, Jul 8, 2014 at 6:35 AM, Tomas Vondra wrote: > On 8 Červenec 2014, 14:49, Robert Haas wrote: > > On Wed, Jul 2, 2014 at 8:13 PM, Tomas Vondra wrote: > >> I propose dynamic increase of the nbuckets (up to NTUP_PER_BUCKET=1) > >> once the table is built and there's free space in work_mem. T

Re: [HACKERS] TODO : Allow parallel cores to be used by vacuumdb [ WIP ]

On Fri, Jun 27, 2014 at 4:10 AM, Dilip kumar wrote: > On 27 June 2014 02:57, Jeff Wrote, > >> Based on that, I find most importantly that it doesn't seem to >> correctly vacuum tables which have upper case letters in the name, >> because it does not quote the table names when they need quotes. > >

Re: [HACKERS] Minmax indexes

On Thu, Jul 10, 2014 at 2:30 PM, Jaime Casanova wrote: > On Thu, Jul 10, 2014 at 3:50 PM, Josh Berkus wrote: > > On 07/10/2014 12:20 PM, Alvaro Herrera wrote: > >>> So I guess the only thing left is to issue a NOTICE when said alter > >>> > takes place (I don't see that on the patch, but maybe i

[HACKERS] Getting list of held lwlocks from debugger

Is there an easy way to get a list of held lwlocks out of gdb attached to a core dump (or for that matter attached to a live process)? I can try manually walking the internal data structure, but I am hoping for something analogous to the way you get memory contexts: (gdb) p MemoryContextStats(Top

Re: [HACKERS] TODO : Allow parallel cores to be used by vacuumdb [ WIP ]

On Wed, Jul 16, 2014 at 5:30 AM, Dilip kumar wrote: > On 16 July 2014 12:13 Magnus Hagander Wrote, > > >>Yeah, those are exactly my points. I think it would be significantly > simpler to do it that way, rather than forking and threading. And also > easier to make portable... > > >>(and as a opt

Re: [HACKERS] Fixed redundant i18n strings in json

On Tue, Aug 5, 2014 at 9:35 AM, Robert Haas wrote: > On Sat, Aug 2, 2014 at 9:15 AM, Daniele Varrazzo > wrote: > > I'd definitely replace /arg/argument/. Furthermore I'd avoid the form > > "argument 1: something is wrong": the string is likely to end up in > > sentences with other colons so I'd

Re: [HACKERS] Supporting Windows SChannel as OpenSSL replacement

On Fri, Aug 1, 2014 at 10:58 AM, Heikki Linnakangas wrote: > On 07/08/2014 08:11 PM, Jeff Janes wrote: > >> Is there some recipe for testing the 0002 patch? Can it be tested on an >> MinGW environment, or does it need to use the MicroSoft supplied >> compilers? >>

Re: [HACKERS] Fixed redundant i18n strings in json

On Wed, Aug 6, 2014 at 8:35 AM, Robert Haas wrote: > On Tue, Aug 5, 2014 at 6:05 PM, Jeff Janes wrote: > > I think you missed one of the regression tests, see attached > > Woops. Thanks, committed. > Thanks. It needs to go into 9_4_STABLE as well. Cheers, Jeff

Re: [HACKERS] Removing dependency to wsock32.lib when compiling code on WIndows

On Tue, Jul 15, 2014 at 5:14 AM, Michael Paquier wrote: > On Tue, Jul 15, 2014 at 8:46 PM, Magnus Hagander > wrote: > > On Thu, Jun 19, 2014 at 4:13 PM, MauMau wrote: > >> From: "Michael Paquier" > >> > >>> You are right, I only though about the MS scripts when working on this > >>> patch. Upd

Re: [HACKERS] how to implement selectivity injection in postgresql

On Wed, Aug 13, 2014 at 9:33 AM, Rajmohan C wrote: > SELECT c1, c2, c3, FROM T1, T2, T3 > WHERE T1.x = T2.x AND > T2.y=T3.y AND > T1.x >= ? selectivity 0.1 AND > T2.y > ? selectivity 0.5 AND > T3.z = ? selectivity 0.2 AND > T3.w = ? > > I need

Re: [HACKERS] Supporting Windows SChannel as OpenSSL replacement

On Tue, Aug 12, 2014 at 10:52 AM, Heikki Linnakangas < hlinnakan...@vmware.com> wrote: > On 08/06/2014 08:37 PM, Jeff Janes wrote: > >> But now it looks like 0002 needs a rebase >> > > I've committed the refactoring patch, and here's a rebased and im

Re: [HACKERS] 9.3: more problems with "Could not open file "pg_multixact/members/xxxx"

On Tue, Jul 15, 2014 at 3:58 PM, Jeff Janes wrote: > On Fri, Jun 27, 2014 at 11:51 AM, Alvaro Herrera > wrote: > >> Jeff Janes wrote: >> >> > This problem was initially fairly easy to reproduce, but since I >> > started adding instrumentation

Re: [HACKERS] segfault in hot standby for hash indexes

On Tue, Mar 21, 2017 at 4:00 AM, Ashutosh Sharma wrote: > Hi Jeff, > > On Tue, Mar 21, 2017 at 1:54 PM, Amit Kapila > wrote: > > On Tue, Mar 21, 2017 at 1:28 PM, Jeff Janes > wrote: > >> Against an unmodified HEAD (17fa3e8), I got a segfault in the hot > standb

Re: [HACKERS] ICU integration

On Thu, Mar 23, 2017 at 12:34 PM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 3/23/17 05:34, Andreas Karlsson wrote: > > I am fine with this version of the patch. The issues I have with it, > > which I mentioned earlier in this thread, seem to be issues with ICU > > rather tha

Re: [HACKERS] increasing the default WAL segment size

On Thu, Mar 23, 2017 at 1:45 PM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 3/22/17 17:33, David Steele wrote: > > > and I doubt that most tool writers would be quick to > > add support for a feature that very few people (if any) use. > > I'm not one of those tool writers, al

Re: [HACKERS] free space map and visibility map

On Thu, Mar 23, 2017 at 7:01 PM, Kyotaro HORIGUCHI < horiguchi.kyot...@lab.ntt.co.jp> wrote: > At Wed, 22 Mar 2017 02:15:26 +0900, Masahiko Sawada > wrote in gmail.com> > > On Mon, Mar 20, 2017 at 11:28 PM, Robert Haas > wrote: > > > On Sat, Mar 18, 201

Re: [HACKERS] segfault in hot standby for hash indexes

On Fri, Mar 24, 2017 at 12:49 AM, Amit Kapila wrote: > On Fri, Mar 24, 2017 at 12:25 PM, Ashutosh Sharma > wrote: > >> > >> I think it would have been probably okay to use *int* for ntuples as > >> that matches with what you are actually assigning in the function. > > > > okay, corrected it. Att

Fwd: [HACKERS] free space map and visibility map

I accidentally sent this off-list, sending to the list now: On Sun, Mar 26, 2017 at 10:38 PM, Kyotaro HORIGUCHI < horiguchi.kyot...@lab.ntt.co.jp> wrote: > At Sat, 25 Mar 2017 19:53:47 -0700, Jeff Janes > wrote in gmail.com> > > On Thu, Mar 23, 2017 at 7:01

Re: [HACKERS] postgres_fdw bug in 9.6

On Thu, Mar 23, 2017 at 5:20 AM, Etsuro Fujita wrote: > On 2017/03/21 18:40, Etsuro Fujita wrote: > >> Ok, I'll update the patch. One thing I'd like to revise in addition to >> that is (1) add to JoinPathExtraData a flag member to indicate whether >> to give the FDW a chance to consider a remote

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

On Thu, Mar 30, 2017 at 4:13 AM, Pavan Deolasee wrote: > > > On Thu, Mar 30, 2017 at 3:29 PM, Dilip Kumar > wrote: > >> On Wed, Mar 29, 2017 at 11:51 AM, Pavan Deolasee >> wrote: >> > Thanks. I think your patch of tracking interesting attributes seems ok >> too >> > after the performance issue

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 breaks > src/test/modules/brin.

[HACKERS] Can't compile with profiling after BRIN autosummarization

make maintainer-clean > /dev/null ; ./configure --enable-profiling > /dev/null && make -j8 >/dev/null In file included from ipc.c:29: ../../../../src/include/postmaster/autovacuum.h:73: error: expected declaration specifiers or '...' before 'BlockNumber' make[4]: *** [ipc.o] Error 1 make[3]: ***

Re: [HACKERS] Can't compile with profiling after BRIN autosummarization

On Mon, Apr 3, 2017 at 9:31 AM, Jeff Janes wrote: > make maintainer-clean > /dev/null ; ./configure --enable-profiling > > /dev/null && make -j8 >/dev/null > > In file included from ipc.c:29: > ../../../../src/include/postmaster/autovacuum.h:73: error: expe

Re: [HACKERS] [BUGS] BUG #14600: Passwords in user mappings leaked by psql \deu+ command

On Fri, Mar 31, 2017 at 11:21 AM, Feike Steenbergen < feikesteenber...@gmail.com> wrote: > Forwarding message from pgsql-bugs for review > > > Attached a patch which copies the logic from commit > 93a6be63a55a8cd0d73b3fa81eb6a46013a3a974. > > In the current implementation we only consider privileg

Re: [HACKERS] pg_basebackup: Allow use of arbitrary compression program

On Thu, Apr 6, 2017 at 7:04 PM, Michael Harris wrote: > Hello, > > Back in pg 9.2, we hacked a copy of pg_basebackup to add a command > line option which would allow the user to specify an arbitrary > external program (potentially including arguments) to be used to > compress the tar backup. > >

[HACKERS] pgbench --progress-timestamp no longer works correctly

--progress-timestamp is supposed to make -P report a Unix Epoch time stamp, for easy correlation with the entries in other log files (like the postgres server log file using %n). But that broke in this commit: commit 1d63f7d2d180c8708bc12710254eb7b45823440f Author: Tom Lane Date: Mon Jan 2 13:

[HACKERS] PANIC in pg_commit_ts slru after crashes

In the first statement executed after crash recovery, I sometimes get this error: PANIC: XX000: could not access status of transaction 207580505 DETAIL: Could not read from file "pg_commit_ts/1EF0" at offset 131072: Success. LOCATION: SlruReportIOError, slru.c:918 STATEMENT: create temporary t

Re: [HACKERS] PANIC in pg_commit_ts slru after crashes

On Fri, Apr 14, 2017 at 9:33 PM, Pavan Deolasee wrote: > Since all those offsets fall on a page boundary, my guess is that we're > somehow failing to handle a new page correctly. > > Looking at the patch itself, my feeling is that the following code > in src/backend/access/transam/twophase.c mig

[HACKERS] Failed recovery with new faster 2PC code

After this commit, I get crash recovery failures when using prepared transactions. commit 728bd991c3c4389fb39c45dcb0fe57e4a1dccd71 Author: Simon Riggs Date: Tue Apr 4 15:56:56 2017 -0400 Speedup 2PC recovery by skipping two phase state files in normal path After the induced crash, I get

Re: [HACKERS] PANIC in pg_commit_ts slru after crashes

On Sun, Apr 16, 2017 at 6:59 PM, Michael Paquier wrote: > > > Jeff, does this patch make the situation better? The fix is rather > simple as it just makes sure that the next XID never gets updated if > there are no 2PC files. > Yes, that fixes the reported case when 2PC are not being used. Than

Re: [HACKERS] Failed recovery with new faster 2PC code

On Tue, Apr 18, 2017 at 5:38 AM, Simon Riggs wrote: > On 18 April 2017 at 13:12, Michael Paquier > wrote: > > On Tue, Apr 18, 2017 at 7:54 PM, Simon Riggs > wrote: > >> Yeh, this is better. Pushed. > > > > I have been outraced on this one, the error is obvious once you see it ;) > > Didn't real

Re: [HACKERS] Failed recovery with new faster 2PC code

On Tue, Apr 18, 2017 at 1:17 AM, Nikhil Sontakke wrote: > Hi, > > There was a bug in the redo 2PC remove code path. Because of which, > autovac would think that the 2PC is gone and cause removal of the > corresponding clog entry earlier than needed. > > Please find attached, the bug fix: 2pc_redo

Re: [HACKERS] Highly Variable Planning Times

On Wed, Apr 19, 2017 at 2:39 PM, Michael Malis wrote: > > TBH, I see no convincing explanation in that article of why 1300 partial > > indexes are a good idea. > > I don't like it much either. I've been trying to eliminate most of the > need for the partial indexes, but this is the current state

[HACKERS] AGG_HASHED cost estimate

In cost_size.c, there is this comment block: +* Note: in this cost model, AGG_SORTED and AGG_HASHED have exactly the +* same total CPU cost, but AGG_SORTED has lower startup cost. If the +* input path is already sorted appropriately, AGG_SORTED should be +* preferr

[HACKERS] CREATE SUBSCRIPTION documentation

https://www.postgresql.org/docs/devel/static/sql-createsubscription.html Has the note: See Section 26.2.5.1 for details on how to configure access control between the subscription and the publica

Re: [HACKERS] subscription worker signalling wal writer too much

On Thu, Jun 15, 2017 at 3:06 PM, Jeff Janes wrote: > > This new patch is simpler than the previous one, and more effective at > speeding up replication. I assume it would speed up pgbench with > synchronous_commit turned off (or against unlogged tables) as well, but I > don

[HACKERS] CREATE SUBSCRIPTION log noise

I think this should go away: ereport(NOTICE, (errmsg("created replication slot \"%s\" on publisher", slotname))); It doesn't appear to be contingent on anything other than the content of the command you just gave it. I don't th

Re: [HACKERS] Reducing pg_ctl's reaction time

On Mon, Jun 26, 2017 at 12:15 PM, Tom Lane wrote: > Michael Paquier writes: > > On Mon, Jun 26, 2017 at 7:13 AM, Tom Lane wrote: > >> The attached proposed patch adjusts pg_ctl to check every 100msec, > >> instead of every second, for the postmaster to be done starting or > >> stopping. > > >>

Re: [HACKERS] distinct estimate of a hard-coded VALUES list

On Tue, Aug 23, 2016 at 5:28 AM, Tom Lane wrote: > Tomas Vondra writes: > > On 08/22/2016 07:42 PM, Alvaro Herrera wrote: > >> Also, if we patch it this way and somebody has a slow query because of a > >> lot of duplicate values, it's easy to solve the problem by > >> de-duplicating. But with t

Re: [HACKERS] Reducing pg_ctl's reaction time

On Tue, Jun 27, 2017 at 11:59 AM, Tom Lane wrote: > I wrote: > > Andres Freund writes: > >> On 2017-06-26 17:38:03 -0400, Tom Lane wrote: > >>> Hm. Take that a bit further, and we could drop the connection probes > >>> altogether --- just put the whole responsibility on the postmaster to > >>>

Re: [HACKERS] Reducing pg_ctl's reaction time

On Thu, Jun 29, 2017 at 11:39 AM, Tom Lane wrote: > Jeff Janes writes: > > In the now-committed version of this, the 'pg_ctl start' returns > > successfully as soon as the server reaches a consistent state. Which is > OK, > > except that it does the same

Re: [HACKERS] subscription worker signalling wal writer too much

On Sat, Jun 24, 2017 at 5:09 PM, Andres Freund wrote: > Hi, > > On 2017-06-15 15:06:43 -0700, Jeff Janes wrote: > > > It looks like only limited consolidation was happening, the number of > kills > > invoked was more than half of the number of SetLatch. I think the r

Re: [HACKERS] pgsql 10: hash indexes testing

On Tue, Jul 4, 2017 at 3:57 AM, AP wrote: > > The data being indexed is BYTEA, (quasi)random and 64 bytes in size. > The table has over 2 billion entries. The data is not unique. There's > an average of 10 duplicates for every unique value. > What is the number of duplicates for the most common

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