Re: [HACKERS] Documentation fixes for pg_visibility

On Tue, Jul 5, 2016 at 8:51 PM, Robert Haas wrote: > > So I'm a bit confused about what you are saying here. If the page is > marked all-frozen but actually isn't all-frozen, then we should clear > the all-frozen bit in the VM. > Agreed. > The easiest way to do that is

Re: [HACKERS] Reviewing freeze map code

On Thu, Jul 7, 2016 at 3:36 AM, Andres Freund wrote: > On 2016-07-05 23:37:59 +0900, Masahiko Sawada wrote: > >> @@ -8694,6 +8761,23 @@ heap_xlog_lock(XLogReaderState *record) >> } >> HeapTupleHeaderSetXmax(htup, xlrec->locking_xid); >>

Re: [HACKERS] Hash Indexes

On Wed, Jun 22, 2016 at 8:44 PM, Robert Haas wrote: > On Wed, Jun 22, 2016 at 5:10 AM, Amit Kapila wrote: >>> > Insertion will happen by scanning the appropriate bucket and needs to >>> > retain pin on primary bucket to ensure that concurrent split

Re: [HACKERS] primary_conninfo missing from pg_stat_wal_receiver

On Thu, Jul 7, 2016 at 4:43 AM, Stephen Frost wrote: > All, > > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: >> Michael Paquier wrote: >> > On Wed, Jul 6, 2016 at 7:34 PM, Fujii Masao wrote: >> > > I have one question; why do we call the column

Re: [HACKERS] [PATCH] Set sgml-basic-offset to 1 in .dir-locals.el

On 7/6/16 4:52 AM, Dagfinn Ilmari Mannsåker wrote: This keeps the indentation consistent when editing the documentation using Emacs. Unfortunately, sgml-basic-offset is not a "safe" variable, so if we put it into .dir-locals.el, then users will always be bothered with a warning about that.

Re: [HACKERS] can we optimize STACK_DEPTH_SLOP

Greg Stark writes: > Ok, I managed to get __atribute__((destructor)) working and capitured > the attached pmap output for all the revisions. You can see the git > revision in the binary name along with a putative date though in the > case of branches the date can be deceptive. It

Re: [HACKERS] dumping database privileges broken in 9.6

All, * Noah Misch (n...@leadboat.com) wrote: > On Wed, Jun 29, 2016 at 11:50:17AM -0400, Stephen Frost wrote: > > * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > > > Do this: > > > > > > CREATE DATABASE test1; > > > REVOKE CONNECT ON DATABASE test1 FROM PUBLIC; > > > > > > Run

Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

* Michael Paquier (michael.paqu...@gmail.com) wrote: > On Tue, Jul 5, 2016 at 5:50 PM, Magnus Hagander wrote: > > On Tue, Jul 5, 2016 at 10:06 AM, Michael Paquier > > wrote: > > However, is there something that's fundamentally better with the

[HACKERS] PARALLEL SAFE/UNSAFE question

Hi all, I was trying writing my own parallel aggregation functions on 9.6beta2. During that, we found a bit confusing behavior with SAFE/UNSAFE options. Once a PARALLEL UNSAFE function f1_unsafe() is wrapped by a PARALLEL SAFE function f1_safe_unsafe(), calling f1_safe_unsafe() produces a

Re: [HACKERS] Reviewing freeze map code

On 2016-07-05 23:37:59 +0900, Masahiko Sawada wrote: > diff --git a/src/backend/access/heap/heapam.c > b/src/backend/access/heap/heapam.c > index 57da57a..fd66527 100644 > --- a/src/backend/access/heap/heapam.c > +++ b/src/backend/access/heap/heapam.c > @@ -3923,6 +3923,17 @@ l2: > > if

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

On 2016-07-02 14:20:13 -0500, Kevin Grittner wrote: > The possible fixes considered were these: > > (1) Always vacuum the heap before its related TOAST table. I think that's clearly not ok from a cost perspective. > (2) Same as (1) but only when old_snapshot_threshold >= 0. > (3) Allow the

Re: [HACKERS] Question about an inconsistency - 1

"pet...@gmail.com" writes: > I have a question regarding the source code in file pg_proc.h > (postgresql-9.4.4). > At line 1224 (copied below) why the 28th identifier is timestamp_eq? > DATA(insert OID = 1152 ( timestamptz_eq PGNSP PGUID 12 1 0 0 0 f f f t t f > i 2 0 16

Re: [HACKERS] primary_conninfo missing from pg_stat_wal_receiver

All, * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > Michael Paquier wrote: > > On Wed, Jul 6, 2016 at 7:34 PM, Fujii Masao wrote: > > > I have one question; why do we call the column "conn_info" instead of > > > "conninfo" which is basically used in other places?

Re: [HACKERS] can we optimize STACK_DEPTH_SLOP

On Wed, Jul 6, 2016 at 2:34 PM, Tom Lane wrote: > > Conclusion: something we did in 8.4 greatly bloated the postmaster's > stack space consumption, to the point that it's significantly more than > anything a normal backend does. That's surprising and scary, because > it means

Re: [HACKERS] primary_conninfo missing from pg_stat_wal_receiver

Michael Paquier wrote: > On Wed, Jul 6, 2016 at 7:34 PM, Fujii Masao wrote: > > I have one question; why do we call the column "conn_info" instead of > > "conninfo" which is basically used in other places? "conninfo" is better to > > me. > > No real reason for one or the

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

Here is a new patch. Updates: 1. Uses MAXALIGN to allocate space on page 2. Uses ItemIdSetNormal in case when ItemId was not normal for some reasons before call 3. Improved comments and var names Best regards, Andrey Borodin, Octonica & Ural Federal University. 2016-07-05 17:54 GMT+05:00 Andrew

[HACKERS] Question about an inconsistency - 1

Hi, I have a question regarding the source code in file pg_proc.h (postgresql-9.4.4). At line 1224 (copied below) why the 28th identifier is timestamp_eq? DATA(insert OID = 1152 ( timestamptz_eq PGNSP PGUID 12 1 0 0 0 f f f t t f i 2 0 16 "1184 1184" _null_ _null_ _null_ _null_

[HACKERS] Re: [BUGS] BUG #14230: Wrong timeline returned by pg_stop_backup on a standby

On 06/07/16 17:41, Marco Nenciarini wrote: > On 06/07/16 17:37, Marco Nenciarini wrote: >> Hi, >> >> On 06/07/16 17:07, francesco.cano...@2ndquadrant.it wrote: >>> The following bug has been logged on the website: >>> >>> Bug reference: 14230 >>> Logged by: Francesco Canovai >>>

[HACKERS] Re: [BUGS] BUG #14230: Wrong timeline returned by pg_stop_backup on a standby

On 06/07/16 17:37, Marco Nenciarini wrote: > Hi, > > On 06/07/16 17:07, francesco.cano...@2ndquadrant.it wrote: >> The following bug has been logged on the website: >> >> Bug reference: 14230 >> Logged by: Francesco Canovai >> Email address: francesco.cano...@2ndquadrant.it >>

[HACKERS] Re: [BUGS] BUG #14230: Wrong timeline returned by pg_stop_backup on a standby

Hi, On 06/07/16 17:07, francesco.cano...@2ndquadrant.it wrote: > The following bug has been logged on the website: > > Bug reference: 14230 > Logged by: Francesco Canovai > Email address: francesco.cano...@2ndquadrant.it > PostgreSQL version: 9.6beta2 > Operating system:

[HACKERS] Don't include MMAP DSM's transient files in basebackup

The files are not useful when restoring a backup and would be automatically deleted on startup anyway. Also deleted an out-of-date comment in dsm.c. / Oskari >From f26f06049b5f89ca3140462d6816259268322d78 Mon Sep 17 00:00:00 2001 From: Oskari Saarenmaa Date: Wed, 6 Jul 2016

Re: [HACKERS] can we optimize STACK_DEPTH_SLOP

Greg Stark writes: > I did a similar(ish) test which is admittedly not as exhaustive as > using pmap. I instrumented check_stack_depth() itself to keep track of > a high water mark (and based on Robert's thought process) to keep > track of the largest increment over the previous

Re: [HACKERS] EXISTS clauses not being optimized in the face of 'one time pass' optimizable expressions

On Fri, Jul 1, 2016 at 11:45 AM, Alvaro Herrera wrote: > Merlin Moncure wrote: > >> It's pretty easy to craft a query where you're on the winning side, >> but what's the worst case of doing two pass...is constant folding a >> non trivial fraction of planning time? > >

Re: [HACKERS] primary_conninfo missing from pg_stat_wal_receiver

On Wed, Jul 6, 2016 at 7:34 PM, Fujii Masao wrote: > I have one question; why do we call the column "conn_info" instead of > "conninfo" which is basically used in other places? "conninfo" is better to > me. No real reason for one or the other to be honest. If you want to

Re: [HACKERS] Forthcoming SQL standards about JSON and Multi-Dimensional Arrays (FYI)

Thomas 2016-07-04 6:44 GMT+02:00 Thomas Munro : > ... But ISO/IEC CD 9075-15 > (Multi-Dimensional Arrays) is in stage 30.92 "CD referred back to > Working Group". Is that how they say "returned with feedback"? > ISO/IEC PDTR 19075-5 (Row Pattern Recognition) has

Re: [HACKERS] primary_conninfo missing from pg_stat_wal_receiver

On Mon, Jul 4, 2016 at 12:40 PM, Michael Paquier wrote: > On Sat, Jul 2, 2016 at 2:56 AM, Alvaro Herrera > wrote: >> Michael Paquier wrote: >>> On Fri, Jul 1, 2016 at 8:50 AM, Michael Paquier >>> wrote: >> >>> >>

Re: [HACKERS] Fix typo in jsonb.c

On Wed, Jul 6, 2016 at 10:27 AM, Masahiko Sawada wrote: > Hi all, > > Attached patch fixes the typo in jsonb.c > Please find it. Pushed. Thanks! Regards, -- Fujii Masao -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

[HACKERS] minor plpgsql doc patch

Hello pgdevs, The very minor patch attached improves the PL/pgSQL documentation about trigger functions. It moves the description common to both data change & database event triggers out of the first section and into a common header. It adds a link at the beginning of the sections to their

[HACKERS] [PATCH] Set sgml-basic-offset to 1 in .dir-locals.el

This keeps the indentation consistent when editing the documentation using Emacs. >From c345671ae4704df500dd17719c5e9973001663c1 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Dagfinn=20Ilmari=20Manns=C3=A5ker?= Date: Sat, 26 Mar 2016 21:58:32 + Subject: [PATCH] Set

Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

On Wed, Jul 6, 2016 at 4:18 PM, Michael Paquier wrote: > OK, after hacking that for a bit I have finished with option 2 and the > set of PG-like set of routines, the use of USE_SSL in the file > containing all the SHA functions of OpenBSD has proved to be really > ugly,

Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

On Tue, Jul 5, 2016 at 5:50 PM, Magnus Hagander wrote: > On Tue, Jul 5, 2016 at 10:06 AM, Michael Paquier > wrote: > However, is there something that's fundamentally better with the OpenSSL > implementation? Or should we just keep *just* the #else