[HACKERS] Simplifying the interface of UpdateMinRecoveryPoint

2016-07-12 Thread Michael Paquier
Hi all, As of now UpdateMinRecoveryPoint() is using two arguments: - lsn, to check if the minimum recovery point should be updated to that - force, a boolean flag to decide if the update should be enforced or not. However those two arguments are correlated. If lsn is InvalidXlogRecPtr, the

[HACKERS] RecoveryTargetTLI dead variable in XLogCtlData

2016-07-12 Thread Michael Paquier
Hi all, I just bumped into $subject, a variable that is never set and never used: --- a/src/backend/access/transam/xlog.c +++ b/src/backend/access/transam/xlog.c @@ -631,8 +631,6 @@ typedef struct XLogCtlData TimeLineID replayEndTLI; /* timestamp of last COMMIT/ABORT record replayed (or

Re: [HACKERS] [BUG] pg_basebackup from disconnected standby fails

2016-07-12 Thread Michael Paquier
On Tue, Jul 12, 2016 at 12:22 PM, Amit Kapila wrote: > I think updating minRecoveryPoint unconditionally can change it's > purpose in some cases. Refer below comments in code: > > * minRecoveryPoint is updated to the latest replayed LSN whenever we > * flush a data

Re: [HACKERS] pg_basebackup wish list

2016-07-12 Thread Masahiko Sawada
On Wed, Jul 13, 2016 at 1:53 AM, Jeff Janes wrote: > I've been having some adventures with pg_basebackup lately, and had > some suggestions based on those. And what I think is pg_baseback never remove the directory specified by -D option even if execution is failed. initdb

Re: [HACKERS] Showing parallel status in \df+

2016-07-12 Thread Stephen Frost
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 7/12/16 12:17 PM, Tom Lane wrote: > > It's sounding to me like we have consensus on this proposal to further > > change \df+ to replace the "Source code" column with "Internal name", > > which is prosrc for C and internal-language

Re: [HACKERS] Showing parallel status in \df+

2016-07-12 Thread Alvaro Herrera
Peter Eisentraut wrote: > I'm quite fond of having the full source code show in \df+ and I'm > against removing it on short notice past beta2, discussed under a > "false" subject heading. How do you use it? -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development,

Re: [HACKERS] IMPORT FOREIGN SCHEMA can't be run in in pl/pgsql due to INTO

2016-07-12 Thread Tom Lane
Merlin Moncure writes: > On Mon, Jul 11, 2016 at 3:09 PM, Tom Lane wrote: >> While we can certainly hack it by something along the lines of not >> recognizing INTO when the first token was IMPORT, the whole thing >> seems awfully messy and fragile. And it

Re: [COMMITTERS] [HACKERS] Logical decoding

2016-07-12 Thread Fabrízio de Royes Mello
On Mon, Jul 11, 2016 at 2:13 AM, Michael Paquier wrote: > > On Mon, Jul 11, 2016 at 2:03 PM, Craig Ringer wrote: > > On 9 July 2016 at 01:57, Joshua Bay wrote: > >> and where are this code is in the codebase? > > > >

Re: [HACKERS] pgbench - minor fix for meta command only scripts

2016-07-12 Thread Tom Lane
Fabien COELHO writes: > Ok. Here is an updated version, with a better suffix and a simplified > comment. Doesn't this break the handling of latency calculations, or at least make the results completely different for the last metacommand than what they would be for a

Re: [HACKERS] GiST index build versus NaN coordinates

2016-07-12 Thread Tom Lane
I wrote: > Andreas Seltenreich writes: >> The infinite loop from the bug report was triggered. Further, two >> previously unseen errors are logged: >> ERROR: timestamp cannot be NaN >> ERROR: getQuadrant: impossible case >> The first is porbably as boring as it gets, the

Re: [HACKERS] dumping database privileges broken in 9.6

2016-07-12 Thread Stephen Frost
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

[HACKERS] DO with a large amount of statements get stuck with high memory consumption

2016-07-12 Thread Merlin Moncure
I've noticed that pl/pgsql functions/do commands do not behave well when the statement resolves and frees memory. To be clear: FOR i in 1..100 LOOP INSERT INTO foo VALUES (i); END LOOP; ...runs just fine while BEGIN INSERT INTO foo VALUES (1); INSERT INTO foo VALUES (2); ...

Re: [HACKERS] GiST index build versus NaN coordinates

2016-07-12 Thread Tom Lane
I wrote: > I looked into the problem reported in bug #14238, > https://www.postgresql.org/message-id/20160708151747.1426.60...@wrigleys.postgresql.org > I think that probably the most reasonable answer is to replace all the > raw "double" comparisons in this code with float8_cmp_internal() or >

Re: [HACKERS] pg_basebackup wish list

2016-07-12 Thread Kenneth Marshall
On Tue, Jul 12, 2016 at 11:06:39AM -0700, Jeff Janes wrote: > On Tue, Jul 12, 2016 at 10:48 AM, Peter Eisentraut > wrote: > > On 7/12/16 12:53 PM, Jeff Janes wrote: > >> The --help message for pg_basebackup says: > >> > >> -Z, --compress=0-9 compress tar

Re: [HACKERS] pg_basebackup wish list

2016-07-12 Thread Jeff Janes
On Tue, Jul 12, 2016 at 10:48 AM, Peter Eisentraut wrote: > On 7/12/16 12:53 PM, Jeff Janes wrote: >> The --help message for pg_basebackup says: >> >> -Z, --compress=0-9 compress tar output with given compression level >> >> But -Z0 is then rejected as

Re: [HACKERS] pgbench - compute & show latency consistently

2016-07-12 Thread Peter Eisentraut
On 7/9/16 4:42 AM, Fabien COELHO wrote: > number of transactions per client: 1000 > number of transactions actually processed: 1/1 > -latency average = 15.844 ms > -latency stddev = 2.715 ms > +latency average: 15.844 ms > +latency stddev: 2.715 ms > tps = 618.764555 (including

Re: [HACKERS] Fix Error Message for allocate_recordbuf() Failure

2016-07-12 Thread Shoaib Lari
Thank you for the feedback. We had encountered this error message when allocating a record buf of 344 bytes. The message "record length 344 at %X/%X too long" along with the comment /* We treat this as a "bogus data" condition */ masked the OOM condition, implying an error in log record size

Re: [HACKERS] pg_basebackup wish list

2016-07-12 Thread Peter Eisentraut
On 7/12/16 12:53 PM, Jeff Janes wrote: > The --help message for pg_basebackup says: > > -Z, --compress=0-9 compress tar output with given compression level > > But -Z0 is then rejected as 'invalid compression level "0"'. The real > docs do say 1-9, only the --help message has this bug.

Re: [HACKERS] Showing parallel status in \df+

2016-07-12 Thread Peter Eisentraut
On 7/12/16 12:17 PM, Tom Lane wrote: > It's sounding to me like we have consensus on this proposal to further > change \df+ to replace the "Source code" column with "Internal name", > which is prosrc for C and internal-language functions but NULL otherwise. > > If I've not heard objections by

Re: [HACKERS] Showing parallel status in \df+

2016-07-12 Thread Stephen Frost
* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > >> Are we satisfied with telling people to use \sf to see the source code > >> for a PL function? Or should there be another variant of \df that > >> still provides

Re: [HACKERS] Showing parallel status in \df+

2016-07-12 Thread Tom Lane
Stephen Frost writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> Are we satisfied with telling people to use \sf to see the source code >> for a PL function? Or should there be another variant of \df that >> still provides source code? > I don't see the point in having a

[HACKERS] pg_basebackup wish list

2016-07-12 Thread Jeff Janes
I've been having some adventures with pg_basebackup lately, and had some suggestions based on those. The --help message for pg_basebackup says: -Z, --compress=0-9 compress tar output with given compression level But -Z0 is then rejected as 'invalid compression level "0"'. The real docs do

Re: [HACKERS] Showing parallel status in \df+

2016-07-12 Thread Stephen Frost
* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > Agreed. I don't have any issue with "Language", really, but I agree > > that "Source code" makes the output pretty ridiculous. I also liked the > > idea of changing the name to "internal name" or something

Re: [HACKERS] GiST index build versus NaN coordinates

2016-07-12 Thread Tom Lane
Andreas Seltenreich writes: > Tom Lane writes: >> More generally, this example makes me fearful that NaN coordinates in >> geometric values are likely to cause all sorts of issues. It's too late >> to disallow them, probably, but I wonder how can we identify other bugs >> of

Re: [HACKERS] use of SEQ_MINVALUE in btree_gin

2016-07-12 Thread Tom Lane
Peter Eisentraut writes: > btree_gin uses SEQ_MINVALUE as a way to get the smallest int64 value. > This is actually wrong because the smallest int64 value is > SEQ_MINVALUE-1, so this might be slightly broken. > The whole thing was done as a convenience when

Re: [HACKERS] Showing parallel status in \df+

2016-07-12 Thread Tom Lane
Stephen Frost writes: > Agreed. I don't have any issue with "Language", really, but I agree > that "Source code" makes the output pretty ridiculous. I also liked the > idea of changing the name to "internal name" or something along those > lines, rather than having it be

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

2016-07-12 Thread Kevin Grittner
On Fri, Jul 8, 2016 at 1:52 PM, Andres Freund wrote: > I'm a bit confused, why aren't we simply adding LSN interlock > checks for toast? Doesn't look that hard? Seems like a much more > natural course of fixing this issue? I took some time trying to see what you have in

Re: [HACKERS] One process per session lack of sharing

2016-07-12 Thread AMatveev
Hi > amatv...@bitec.ru writes: >> Is there any plan to implement "session per thread" or "shared >> sessions between thread"? > No, not really. The amount of overhead that would add --- eg, the need > for locking on what used to be single-use caches --- makes the benefit > highly

Re: [HACKERS] One process per session lack of sharing

2016-07-12 Thread Tom Lane
amatv...@bitec.ru writes: > Is there any plan to implement "session per thread" or "shared > sessions between thread"? No, not really. The amount of overhead that would add --- eg, the need for locking on what used to be single-use caches --- makes the benefit highly questionable. Also,

[HACKERS] One process per session lack of sharing

2016-07-12 Thread AMatveev
Hi Is there any plan to implement "session per thread" or "shared sessions between thread"? We have analyzed the ability to contribute pgSql to jvm bytecode compiler but with current thread model this idea is far from optimal.(Vm can be different of course. But currently we

Re: [HACKERS] IMPORT FOREIGN SCHEMA can't be run in in pl/pgsql due to INTO

2016-07-12 Thread Merlin Moncure
On Mon, Jul 11, 2016 at 3:09 PM, Tom Lane wrote: > Merlin Moncure writes: >> Currently pl/pgsql interprets the mandatory INTO of IMPORT FOREIGN >> SCHEMA as INTO variable. > > Ugh, that's definitely a bug. > >> I estimate this to be minor oversight in >>

Re: [HACKERS] Showing parallel status in \df+

2016-07-12 Thread Stephen Frost
* Tom Lane (t...@sss.pgh.pa.us) wrote: > Michael Paquier writes: > > On Tue, Jul 12, 2016 at 11:36 AM, Alvaro Herrera > > wrote: > >> So prosrc for internal/C and NULL for others? WFM. > > > And so we'd remove "Language" at the same time?

[HACKERS] Oddity in handling of cached plans for FDW queries

2016-07-12 Thread Etsuro Fujita
Hi, I noticed odd behavior in invalidating a cached plan with a foreign join due to user mapping changes. Consider: postgres=# create extension postgres_fdw; postgres=# create server loopback foreign data wrapper postgres_fdw options (dbname 'postgres'); postgres=# create user mapping

Re: [HACKERS] remove checkpoint_warning

2016-07-12 Thread PostgreSQL - Hans-Jürgen Schönig
On 07/09/2016 11:12 PM, Tom Lane wrote: Alvaro Herrera writes: the checkpoint_warning feature was added by commit 2986aa6a668bce3cfb836 in November 2002 when we didn't have any logging of checkpointing at all. I propose to remove it: surely anyone who cares about

Re: [HACKERS] remove checkpoint_warning

2016-07-12 Thread Magnus Hagander
On Tue, Jul 12, 2016 at 3:32 AM, Craig Ringer wrote: > On 11 July 2016 at 22:25, Stephen Frost wrote: > >> * Tom Lane (t...@sss.pgh.pa.us) wrote: >> > Alvaro Herrera writes: >> > > the checkpoint_warning feature was added by

Re: [HACKERS] GiST index build versus NaN coordinates

2016-07-12 Thread Andreas Seltenreich
Tom Lane writes: > More generally, this example makes me fearful that NaN coordinates in > geometric values are likely to cause all sorts of issues. It's too late > to disallow them, probably, but I wonder how can we identify other bugs > of this ilk. Sounds like some fuzz testing with