Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()

On 07/30/2016 11:16 AM, Bruce Momjian wrote: On Sat, Jul 30, 2016 at 10:35:58AM -0400, Tom Lane wrote: Greg Stark writes: I agree that a GUC and new functions are overkill --- we should just decide on the format we want to output and what to support for input. As logical as

[HACKERS] Combining hash values

Hi hackers, Andres Freund asked me off list what I thought about this part of execGrouping.c, which builds a hash from the hashes of several datums in a loop: /* rotate hashkey left 1 bit at each step */ hashkey = (hashkey << 1) | ((hashkey & 0x8000) ? 1 : 0); ...

[HACKERS] Hash indexes and effective_cache_size in CREATE INDEX documentation

The CREATE INDEX documentation states: "For hash indexes, the value of effective_cache_size is also relevant to index creation time: PostgreSQL will use one of two different hash index creation methods depending on whether the estimated index size is more or less than effective_cache_size. For

Re: [HACKERS] sslmode=require fallback

On Fri, Jul 29, 2016 at 11:27:06AM -0400, Peter Eisentraut wrote: > On 7/29/16 11:13 AM, Bruce Momjian wrote: > > Yes, I am thinking of a case where Postgres is down but a malevolent > > user starts a Postgres server on 5432 to gather passwords. Verifying > > against an SSL certificate would

Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()

On Sat, Jul 30, 2016 at 10:35:58AM -0400, Tom Lane wrote: > Greg Stark writes: > > I think Bruce's summary is a bit revisionist. > > I would say it's a tempest in a teapot. > > What I think we should do is accept "kb" and the rest case-insensitively, > print them all in

Re: [HACKERS] [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)

On 7/30/16 10:47 AM, Tom Lane wrote: > Pavel Stehule writes: >> But there are some patterns used with work with temp tables,that should not >> working, and we would to decide if we prepare workaround or not. > >> -- problematic pattern (old code) >> IF NOT EXISTS(SELECT

Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()

On Sat, Jul 30, 2016 at 10:35 AM, Tom Lane wrote: > Greg Stark writes: > > I think Bruce's summary is a bit revisionist. > > I would say it's a tempest in a teapot. > > What I think we should do is accept "kb" and the rest case-insensitively, > print them all

Re: [HACKERS] [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)

Pavel Stehule writes: > But there are some patterns used with work with temp tables,that should not > working, and we would to decide if we prepare workaround or not. > -- problematic pattern (old code) > IF NOT EXISTS(SELECT * FROM pg_class WHERE ) THEN > CREATE

Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()

Greg Stark writes: > I think Bruce's summary is a bit revisionist. I would say it's a tempest in a teapot. What I think we should do is accept "kb" and the rest case-insensitively, print them all in all-upper-case always, and tell standards pedants to get lost. The idea of

Re: [HACKERS] [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)

On 07/30/2016 06:49 AM, Pavel Stehule wrote: 1) I wonder whether the FAST makes sense - does this really change the performance significantly? IMHO you only move the catalog rows to memory, so why should the tables be any faster? I also believe this conflicts with SQL standard

Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()

On Sat, Jul 30, 2016 at 2:47 AM, David G. Johnston wrote: > After bouncing on this for a bit I'm inclined to mark the bug itself "won't > fix" but introduce a "to_binary_iso" function (I'm hopeful a better name > will emerge...) that will output a number using ISO

Re: [HACKERS] old_snapshot_threshold allows heap:toast disagreement

On Fri, Jul 29, 2016 at 1:10 AM, Robert Haas wrote: > On Wed, Jul 27, 2016 at 7:26 PM, Andres Freund wrote: > > New version attached. > +static inline void +InitToastSnapshot(Snapshot snapshot, XLogRecPtr lsn) +{ + snapshot->satisfies =

Re: [HACKERS] pg_dumping extensions having sequences with 9.6beta3

On Sat, Jul 30, 2016 at 5:47 AM, Stephen Frost wrote: > What we need to be doing here is combining the set of components that > the sequence has been marked with and the set of components that the > table has been marked with, not trying to figure out if the sequence is > a

Re: [HACKERS] Re: GiST optimizing memmoves in gistplacetopage for fixed-size updates [PoC]

Here is BRIN-compatible version of patch. Now function PageIndexTupleOverwrite consumes tuple size as a parameter, this behavior is coherent with PageAddItem. Also, i had to remove asserstion that item has a storage in the loop that adjusts line pointers. It would be great if someone could check