[HACKERS] Missing PG_INT32_MIN in numutils.c

Hi all, While going through numutils.c I found the following thing: --- a/src/backend/utils/adt/numutils.c +++ b/src/backend/utils/adt/numutils.c @@ -136,7 +136,7 @@ pg_ltoa(int32 value, char *a) * Avoid problems with the most negative integer not being representable * as a positive inte

Re: [HACKERS] [COMMITTERS] pgsql: Add regression tests for multiple synchronous standbys.

On Fri, Apr 8, 2016 at 4:49 PM, Fujii Masao wrote: > Add regression tests for multiple synchronous standbys. > > Authors: Suraj Kharage, Michael Paquier, Masahiko Sawada, refactored by me > Reviewed-By: Kyotaro Horiguchi Well, we are not quite there yet: http://buildfarm.postgresql.org/cgi-bin/sh

[HACKERS] Incomplete startup packet errors

It's fairly common to see a lot of "Incomplete startup packet" in the logfiles caused by monitoring or healthcheck connections. I wonder if it would make sense to only log that error if *at least one byte* has been received and then it becomes empty. Meaning that if the client just connects+discon

Re: [HACKERS] Incomplete startup packet errors

At 2016-04-13 10:02:22 +0200, mag...@hagander.net wrote: > > I wonder if it would make sense to only log that error if *at least > one byte* has been received and then it becomes empty. Yes, it would be very nice to eliminate that logspam, as you say. -- Abhijit -- Sent via pgsql-hackers maili

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

At Wed, 13 Apr 2016 04:43:35 +0900, Fujii Masao wrote in > >>> Thank you for reviewing. > >>> > >>> SyncRepUpdateConfig() seems to be no longer necessary. > >> > >> Really? I was thinking that something like that function needs to > >> be called at the beginning of a backend and walsender in > >

Re: [HACKERS] Incomplete startup packet errors

On Wed, Apr 13, 2016 at 9:02 AM, Magnus Hagander wrote: > It's fairly common to see a lot of "Incomplete startup packet" in the > logfiles caused by monitoring or healthcheck connections. > > I wonder if it would make sense to only log that error if *at least one > byte* has been received and then

Re: [HACKERS] Incomplete startup packet errors

On Wed, Apr 13, 2016 at 1:02 AM, Magnus Hagander wrote: > It's fairly common to see a lot of "Incomplete startup packet" in the > logfiles caused by monitoring or healthcheck connections. I've also seen it caused by port scanning. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (p

Re: [HACKERS] Incomplete startup packet errors

On Wed, Apr 13, 2016 at 10:24 AM, Peter Geoghegan wrote: > On Wed, Apr 13, 2016 at 1:02 AM, Magnus Hagander > wrote: > > It's fairly common to see a lot of "Incomplete startup packet" in the > > logfiles caused by monitoring or healthcheck connections. > > I've also seen it caused by port scanni

Re: [HACKERS] Pglogical questions and problems

On 12 April 2016 at 23:46, Joshua D. Drake wrote: > So what am I missing? > Thanks for the bug report, but unfortunately the CF is now over and pglogical is not in 9.6. So its a little late for reviews and bug reports. I'm not sure of the exact status of pglogical now. It's has a good receptio

[HACKERS] SET ROLE and reserved roles

Hi, I observe this: postgres=# SET ROLE TO NONE; SET postgres=# SET ROLE TO nonexistent; ERROR: role "nonexistent" does not exist postgres=# SET ROLE TO pg_signal_backend; ERROR: invalid value for parameter "role": "pg_signal_backend" Is that behavior deliberate? Might it be better to handle

[HACKERS] [patch] \crosstabview documentation

Re: Alvaro Herrera 2016-04-09 <20160408232553.GA721890@alvherre.pgsql> > It's useful, no doubt. It's cool :) > I pushed it. Here's a small doc patch that removes the bogus space in "colH [:scolH]" (otherwise psql complains that it is ignoring the 4th parameter. It also adds an index entry and a

Re: [HACKERS] [patch] \crosstabview documentation

Re: To PostgreSQL Hackers 2016-04-13 <20160413092312.ga21...@msg.df7cb.de> > Re: Alvaro Herrera 2016-04-09 <20160408232553.GA721890@alvherre.pgsql> > > It's useful, no doubt. > > It's cool :) > > > I pushed it. > > Here's a small doc patch that removes the bogus space in "colH [:scolH]" > (other

[HACKERS] Reserved roles and user mapping

Hi, Currently in CreateUserMapping(): /* Additional check to protect reserved role names */ check_rolespec_name(stmt->user, "Cannot specify reserved role as mapping user."); User mapping terminology is not that clear to me really but how does the following sound a

Re: [HACKERS] Pglogical questions and problems

On 04/13/2016 01:38 AM, Simon Riggs wrote: On 12 April 2016 at 23:46, Joshua D. Drake mailto:j...@commandprompt.com>> wrote: So what am I missing? Thanks for the bug report, but unfortunately the CF is now over and pglogical is not in 9.6. So its a little late for reviews and bug reports.

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

On Tue, Apr 12, 2016 at 2:38 PM, Andres Freund wrote: >> And, on the other hand, if we don't do something like that, it will be >> quite an exceptional case to find anything on the free list. Doing it >> just to speed up developer benchmarking runs seems like the wrong >> idea. > > I don't think

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On Tue, Apr 12, 2016 at 5:12 PM, Amit Kapila wrote: > On Tue, Apr 12, 2016 at 3:48 PM, Alexander Korotkov < > a.korot...@postgrespro.ru> wrote: > >> On Tue, Apr 12, 2016 at 12:40 AM, Andres Freund >> wrote: >> >>> I did get access to the machine (thanks!). My testing shows that >>> performance i

Re: [HACKERS] Missing PG_INT32_MIN in numutils.c

On Wed, Apr 13, 2016 at 3:49 AM, Michael Paquier wrote: > Hi all, > > While going through numutils.c I found the following thing: > --- a/src/backend/utils/adt/numutils.c > +++ b/src/backend/utils/adt/numutils.c > @@ -136,7 +136,7 @@ pg_ltoa(int32 value, char *a) > * Avoid problems with the m

Re: [HACKERS] Missing PG_INT32_MIN in numutils.c

On Wed, Apr 13, 2016 at 8:57 PM, Robert Haas wrote: > On Wed, Apr 13, 2016 at 3:49 AM, Michael Paquier > wrote: >> Hi all, >> >> While going through numutils.c I found the following thing: >> --- a/src/backend/utils/adt/numutils.c >> +++ b/src/backend/utils/adt/numutils.c >> @@ -136,7 +136,7 @@ p

Re: [HACKERS] Why doesn't src/backend/port/win32/socket.c implement bind()?

On Wed, Apr 13, 2016 at 9:06 AM, Tom Lane wrote: > While we wait to see if that actually helps give useful errors, > I had a thought about what may be happening here. PostgresNode.pm > picks a random high port number and tests to see if it's free using > pg_isready, with (unless I'm misreading) a

Re: [HACKERS] pg_upgrade documentation improvement patch

On 03/20/2016 06:40 PM, Yuri Niyazov wrote: > [4:35pm] yuri_niyazov: "Again, use compatible initdb flags that match > the old cluster" - this is when running initdb before running pg_upgrade > [4:36pm] RhodiumToad: same encoding, locale, and checksum settings > [4:36pm] yuri_niyazov: Can I recover

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

On Tue, Apr 12, 2016 at 11:05 PM, Andres Freund wrote: > On 2016-04-12 23:52:14 -0300, Alvaro Herrera wrote: >> Andres Freund wrote: >> > I'm kinda inclined to apply that portion (or just the whole patch with >> > the spurious #ifdef 0 et al fixed) into 9.6; and add the necessary >> > checks in a

Re: [HACKERS] Optimization for updating foreign tables in Postgres FDW

On Tue, Apr 12, 2016 at 10:24 PM, Etsuro Fujita wrote: >> How about we encapsulate the while (PQisBusy(...)) loop into a new >> function pgfdw_get_result(), which can be called after first calling >> PQsendQueryParams()? So then this code will say dmstate->result = >> pgfdw_get_result(dmstate->co

Re: [HACKERS] SET ROLE and reserved roles

On Wed, Apr 13, 2016 at 5:58 PM, Amit Langote wrote: > Is that behavior deliberate? Might it be better to handle the case > specially much as setting to "none" works? Such as: > > ERROR: cannot set to reserved role "pg_signal_backend" > > Sorry if I have missed any discussion where such a choice

Re: [HACKERS] Optimization for updating foreign tables in Postgres FDW

On Wed, Apr 13, 2016 at 9:46 PM, Robert Haas wrote: > On Tue, Apr 12, 2016 at 10:24 PM, Etsuro Fujita > wrote: >>> How about we encapsulate the while (PQisBusy(...)) loop into a new >>> function pgfdw_get_result(), which can be called after first calling >>> PQsendQueryParams()? So then this cod

Re: [HACKERS] Why doesn't src/backend/port/win32/socket.c implement bind()?

Michael Paquier writes: > On Wed, Apr 13, 2016 at 9:06 AM, Tom Lane wrote: >> If there's other stuff using high ports on a particular buildfarm machine, >> you'd expect occasional random test failures due to this. The observed >> fact that some buildfarm critters are much more prone to this type

Re: [HACKERS] Pglogical questions and problems

At 2016-04-13 03:46:21 -0700, j...@commandprompt.com wrote: > > ALTER DATABASE ADD NODE; > ALTER SCHEMA SUBSCRIBE ALL; > CREATE REPLICATION SET; > > But I am unaware if that is possible within the constraints of the > extensions API. It is not possible. -- Abhijit -- Sent via pgsql-hackers ma

Re: [HACKERS] Missing PG_INT32_MIN in numutils.c

Robert Haas writes: > On Wed, Apr 13, 2016 at 3:49 AM, Michael Paquier > wrote: >> While going through numutils.c I found the following thing: >> --- a/src/backend/utils/adt/numutils.c >> +++ b/src/backend/utils/adt/numutils.c >> @@ -136,7 +136,7 @@ pg_ltoa(int32 value, char *a) >> * Avoid proble

Re: [HACKERS] pg_upgrade documentation improvement patch

Peter Eisentraut writes: > Interesting to me would be a way, perhaps with an option in initdb, to > just say, initialize this cluster compatibly with that other cluster, so > you don't have to worry about these details. Good idea, though I'd think of it as a pg_upgrade option more than being init

[HACKERS] Html parsing and inline elements

Hi everyone, I was here wondering whether HTML parsing should separate tokens that are not separated by spaces in the original text, but are separated by an inline element. Let me show you an example: *SELECT to_tsvector('english', 'Helloneighbor, you are nice')* *Results:** "'ce':7 'hello':1 'n'

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

Robert Haas writes: > I have never understood why you didn't include 64-bit atomics in the > original atomics implementation, and I really think we should have > committed a patch to add them long before now. What will you do on 32-bit platforms (or, more generally, anything lacking 64-bit-wide a

Re: [HACKERS] SET ROLE and reserved roles

On Wed, Apr 13, 2016 at 8:49 AM, Michael Paquier wrote: > On Wed, Apr 13, 2016 at 5:58 PM, Amit Langote > wrote: >> Is that behavior deliberate? Might it be better to handle the case >> specially much as setting to "none" works? Such as: >> >> ERROR: cannot set to reserved role "pg_signal_backen

Re: [HACKERS] Missing PG_INT32_MIN in numutils.c

On Wed, Apr 13, 2016 at 9:38 AM, Tom Lane wrote: > Robert Haas writes: >> On Wed, Apr 13, 2016 at 3:49 AM, Michael Paquier >> wrote: >>> While going through numutils.c I found the following thing: >>> --- a/src/backend/utils/adt/numutils.c >>> +++ b/src/backend/utils/adt/numutils.c >>> @@ -136,7

Re: [HACKERS] Incomplete startup packet errors

Magnus Hagander writes: > On Wed, Apr 13, 2016 at 10:24 AM, Peter Geoghegan wrote: >> On Wed, Apr 13, 2016 at 1:02 AM, Magnus Hagander >> wrote: >>> It's fairly common to see a lot of "Incomplete startup packet" in the >>> logfiles caused by monitoring or healthcheck connections. >> I've also s

Re: [HACKERS] SET ROLE and reserved roles

Amit Langote writes: > I observe this: > postgres=# SET ROLE TO NONE; > SET > postgres=# SET ROLE TO nonexistent; > ERROR: role "nonexistent" does not exist > postgres=# SET ROLE TO pg_signal_backend; > ERROR: invalid value for parameter "role": "pg_signal_backend" > Is that behavior deliberat

Re: [HACKERS] Incomplete startup packet errors

On Wed, Apr 13, 2016 at 3:56 PM, Tom Lane wrote: > Magnus Hagander writes: > > On Wed, Apr 13, 2016 at 10:24 AM, Peter Geoghegan wrote: > >> On Wed, Apr 13, 2016 at 1:02 AM, Magnus Hagander > >> wrote: > >>> It's fairly common to see a lot of "Incomplete startup packet" in the > >>> logfiles c

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

Robert Haas wrote: > On Tue, Apr 12, 2016 at 11:05 PM, Andres Freund wrote: > > I didn't plan to do anything without a few +1's. I don't think we can > > release with the state of things as is though. I don't see a less > > intrusive way than to get rid of that spinlock on all platforms capable >

Re: [HACKERS] Html parsing and inline elements

Marcelo Zabani writes: > I was here wondering whether HTML parsing should separate tokens that are > not separated by spaces in the original text, but are separated by an > inline element. Let me show you an example: > *SELECT to_tsvector('english', 'Helloneighbor, you are > nice')* > *Results:**

Re: [HACKERS] Parser extensions (maybe for 10?)

On 04/12/2016 06:45 AM, Craig Ringer wrote: On 12 April 2016 at 12:36, Arcadiy Ivanov > wrote: Is there any interest and/or tips to allow a pluggable parser or at least allow some syntactical pluggability by extensions? I think this may allow some projects

Re: [HACKERS] Missing PG_INT32_MIN in numutils.c

Robert Haas writes: > On Wed, Apr 13, 2016 at 9:38 AM, Tom Lane wrote: >> I am not very convinced that this is an improvement, because you took >> what had been two hard-wired constants and replaced them with a symbol >> and a hard-wired constant.This is more prone to break, not less so. > I thi

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

On Wed, Apr 13, 2016 at 9:52 AM, Tom Lane wrote: > Robert Haas writes: >> I have never understood why you didn't include 64-bit atomics in the >> original atomics implementation, and I really think we should have >> committed a patch to add them long before now. > > What will you do on 32-bit pla

Re: [HACKERS] Missing PG_INT32_MIN in numutils.c

On Wed, Apr 13, 2016 at 10:11 AM, Tom Lane wrote: > Robert Haas writes: >> On Wed, Apr 13, 2016 at 9:38 AM, Tom Lane wrote: >>> I am not very convinced that this is an improvement, because you took >>> what had been two hard-wired constants and replaced them with a symbol >>> and a hard-wired co

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

Robert Haas writes: > On Wed, Apr 13, 2016 at 9:52 AM, Tom Lane wrote: >> Robert Haas writes: >>> I have never understood why you didn't include 64-bit atomics in the >>> original atomics implementation, and I really think we should have >>> committed a patch to add them long before now. >> Wha

Re: [HACKERS] Incomplete startup packet errors

>> I've also seen it caused by port scanning. >> > > Yes, definitely. Question there might be if that's actually a case when we > *want* that logging? Is it possible a user want the log because he/she wants to notice that the system is being attacked? -- Tatsuo Ishii SRA OSS, Inc. Japan English:

Re: [HACKERS] Speedup twophase transactions

> On 13 Apr 2016, at 01:04, Michael Paquier wrote: > > On Wed, Apr 13, 2016 at 1:53 AM, Stas Kelvich > wrote: >>> On 12 Apr 2016, at 15:47, Michael Paquier wrote: >>> >>> It looks to be the case... The PREPARE phase replayed after the >>> standby is restarted in recovery creates a series of e

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

On Wed, Apr 13, 2016 at 10:20 AM, Tom Lane wrote: > Robert Haas writes: >> On Wed, Apr 13, 2016 at 9:52 AM, Tom Lane wrote: >>> Robert Haas writes: I have never understood why you didn't include 64-bit atomics in the original atomics implementation, and I really think we should have >

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

Robert Haas writes: > On Wed, Apr 13, 2016 at 10:20 AM, Tom Lane wrote: >> That's what I thought you were going to say, and it means that any >> "performance improvement" patch that relies on 64-bit atomics in hotspot >> code paths is going to be a complete disaster on anything but modern Intel >

Re: [HACKERS] Parser extensions (maybe for 10?)

On 13 April 2016 at 22:11, José Luis Tallón wrote: > FWIW, I have previously sketched a "syntax rewriter" of sorts: a simple > filter which is applied to input before the lexer even sees it. > Quite some "syntax magic" can be achieved by allowing an extension to > *hook* into this functionality

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

On Wed, Apr 13, 2016 at 10:42 AM, Tom Lane wrote: > Robert Haas writes: >> On Wed, Apr 13, 2016 at 10:20 AM, Tom Lane wrote: >>> That's what I thought you were going to say, and it means that any >>> "performance improvement" patch that relies on 64-bit atomics in hotspot >>> code paths is going

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

On 2016-04-13 08:36:47 -0400, Robert Haas wrote: > I think that a significant performance regression which affects people > not using snapshot_too_old would be a stop-ship issue, but I disagree > that an issue which only affects people using the feature is a > must-fix. It may be desirable to fix

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

On Wed, Apr 13, 2016 at 11:01 AM, Andres Freund wrote: > Well, I'm less likely to write a patch when there's no chance that it's > going to be applied. Which the rest of the thread sounds like... I hope somebody writes it at some point, because we surely want to fix this for 9.7. However, I agre

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

On 2016-04-13 10:42:03 -0400, Tom Lane wrote: > Robert Haas writes: > > On Wed, Apr 13, 2016 at 10:20 AM, Tom Lane wrote: > >> That's what I thought you were going to say, and it means that any > >> "performance improvement" patch that relies on 64-bit atomics in hotspot > >> code paths is going

Re: [HACKERS] Parser extensions (maybe for 10?)

On 04/13/2016 04:43 PM, Craig Ringer wrote: On 13 April 2016 at 22:11, José Luis Tallón mailto:jltal...@adv-solutions.net>> wrote: [snip] I can certainly prepare a small patch for the first commitfest of 9.7 if this sounds viable. I'd be surprised if it was popular. I am familiar wi

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

On 2016-04-13 11:08:21 -0300, Alvaro Herrera wrote: > The patch being proposed for commit is fiddly architecture-specific > stuff which is likely to destabilize the tree for quite some time, and > cause lots of additional work to Andres and anyone else likely to work > on such low-level details, su

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

On Wed, Apr 13, 2016 at 11:18 AM, Andres Freund wrote: > I think generally the only platform of concern wrt is arm (< armv8), > which doesn't have 64bit atomicity and doesn't have > single-copy-atomicity for 8 byte values either (C.f. > https://wiki.postgresql.org/wiki/Atomics). That page is sort

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

On 2016-04-13 06:57:15 -0400, Robert Haas wrote: > You will eventually, because each scan will pick a new ring buffer, > and gradually more and more of the relation will get cached. But it > can take a while. You really don't need much new data to make that an unobtainable goal ... :/ > I'd be

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

Robert Haas writes: > On Wed, Apr 13, 2016 at 10:42 AM, Tom Lane wrote: >> No, you're ignoring my point, which is what happens on single-CPU >> 32-bit machines, and whether we aren't going to destroy performance >> on low-end machines in pursuit of better performance on high-end. > One of us is

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

On Wed, Apr 13, 2016 at 10:01 AM, Andres Freund wrote: > My problem with that is that snapshot-too-old is essentially a > efficiency feature for busy and large databases. Regressing noticeably > when it's enabled in it's natural habitat seems sad. With a real-world application with realistic sim

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

On 2016-04-13 11:27:09 -0400, Robert Haas wrote: > That page is sort of confusing, because it says that platform has > those things but then says ***, which is footnoted to mean "linux > kernel emulation available", but it's not too clear whether that > applies to all atomics or just 8-byte atomics

Re: [HACKERS] [patch] \crosstabview documentation

Christoph Berg writes: >> Here's a small doc patch that removes the bogus space in "colH [:scolH]" >> (otherwise psql complains that it is ignoring the 4th parameter. >> It also adds an index entry and adds a note to the old crosstab >> functions to make people aware of \crosstabview. > I should

Re: [HACKERS] Html parsing and inline elements

Hi, Tom, You're right, I don't think one can argue that the default parser should know HTML. How about your suggestion of there being an HTML parser, is it feasible? I ask this because I think that a lot of people store HTML documents these days, and although there probably aren't lots of HTML wit

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

On 2016-04-13 10:31:19 -0500, Kevin Grittner wrote: > With a real-world application with realistic simulated user load > there was no such regression and a big gain in performance over > time, so we're talking about adjusting how broad a range of > workloads it benefits. I think it depends very he

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

On Wed, Apr 13, 2016 at 10:59 AM, Andres Freund wrote: >> but as an example, if I only see such regression on a Linux kernel >> with version a version < 3.8 I am going to be less concerned about >> getting something into 9.6, since IMO it is completely irresponsible >> to run a NUMA machine with

Re: [HACKERS] Pglogical questions and problems

On Wed, Apr 13, 2016 at 4:38 AM, Simon Riggs wrote: > Anyway, who agrees with the overall design of pglogical and who does not? I haven't spent very much time on it yet. I tend to prefer the idea of integrating it more deeply into core and adding SQL syntax around it, but I'm not going to fight

Re: [HACKERS] Incomplete startup packet errors

On Wed, Apr 13, 2016 at 10:30 AM, Tatsuo Ishii wrote: >>> I've also seen it caused by port scanning. >> >> Yes, definitely. Question there might be if that's actually a case when we >> *want* that logging? > > Is it possible a user want the log because he/she wants to notice that > the system is b

Re: [HACKERS] SET ROLE and reserved roles

Tom, all, On Wednesday, April 13, 2016, Tom Lane wrote: > Amit Langote > writes: > > I observe this: > > > postgres=# SET ROLE TO NONE; > > SET > > postgres=# SET ROLE TO nonexistent; > > ERROR: role "nonexistent" does not exist > > postgres=# SET ROLE TO pg_signal_backend; > > ERROR: invalid

Re: [HACKERS] SET ROLE and reserved roles

On Wed, Apr 13, 2016 at 1:10 PM, Stephen Frost wrote: >> What I'd like to know is why it rejects that at all. What's the point >> of having roles you can't SET to? > > To use them to GRANT access to other roles, which was the goal of the > default roles system to begin with. Well ... yeah. But

Re: [HACKERS] Choosing parallel_degree

On Tue, Apr 12, 2016 at 6:31 PM, Julien Rouhaud wrote: > On 11/04/2016 22:53, Julien Rouhaud wrote: >> On 11/04/2016 17:44, Robert Haas wrote: >>> We should probably add the number of workers actually obtained to the >>> EXPLAIN ANALYZE output. That's been requested before. >> >> If it's not too

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

On 2016-04-12 14:53:57 -0500, Kevin Grittner wrote: > On Tue, Apr 12, 2016 at 2:28 PM, Andres Freund wrote: > > On 2016-04-12 14:17:12 -0500, Kevin Grittner wrote: > >> Well, something is different between your environment and mine, > >> since I saw no difference at scale 100 and 2.2% at scale 200

Re: [HACKERS] SET ROLE and reserved roles

On Wednesday, April 13, 2016, Robert Haas wrote: > On Wed, Apr 13, 2016 at 1:10 PM, Stephen Frost > wrote: > >> What I'd like to know is why it rejects that at all. What's the point > >> of having roles you can't SET to? > > > > To use them to GRANT access to other roles, which was the goal of

Re: [HACKERS] Problems with huge_pages and IBM Power8

> On Apr 12, 2016, at 10:26 PM, Tom Lane wrote: > > Andres Freund writes: >> On 2016-04-12 21:58:14 +0200, reiner peterke wrote: >>> Looking for some insight into this issue. the error from the postgres >>> log on ubuntu is below. It apperas to be related to semephores. > >> I've a bit of a

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

On Wed, Apr 13, 2016 at 1:19 PM, Andres Freund wrote: > On an EC2 m4.10xlarge (dedicated, but still a VM) - sorry I don't have > anything better at hand right now, and it was already running. > > postgres config: > postgres -D /srv/data/dev/ > -c shared_buffers=64GB \ > -c max_wa

Re: [HACKERS] SET ROLE and reserved roles

On Wed, Apr 13, 2016 at 1:24 PM, Stephen Frost wrote: > On Wednesday, April 13, 2016, Robert Haas wrote: >> >> On Wed, Apr 13, 2016 at 1:10 PM, Stephen Frost wrote: >> >> What I'd like to know is why it rejects that at all. What's the point >> >> of having roles you can't SET to? >> > >> > To u

Re: [HACKERS] Parallel Aggregate costs don't consider combine/serial/deserial funcs

On Tue, Apr 12, 2016 at 5:38 PM, David Rowley wrote: >>> One small point which I was a little unsure of in the attached is, >>> should the "if (aggref->aggdirectargs)" part of >>> count_agg_clauses_walker() be within the "if >>> (!context->combineStates)". I simply couldn't decide. We currently >>

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

On 2016-04-13 13:25:14 -0400, Robert Haas wrote: > > With -c old_snapshot_threshold=0: > > > > latency average = 0.218 ms > > latency stddev = 0.154 ms > > tps = 584666.289753 (including connections establishing) > > tps = 584867.785569 (excluding connections establishing) > > > > > > With -c old_s

Re: [HACKERS] Odd system-column handling in postgres_fdw join pushdown patch

On Tue, Apr 5, 2016 at 4:54 AM, Ashutosh Bapat wrote: > With this patch, all instances of tableoid, cmin, cmax etc. will get a > non-NULL value irrespective of whether they appear on nullable side of the > join or not. > > e.g. select t1.c1, t1.tableoid, t2.c1, t2.tableoid from ft4 t1 left join ft

[HACKERS] \crosstabview fixes

I noticed that the \crosstabview documentation asserts that column name arguments are handled per standard SQL semantics. In point of fact, though, the patch expends a couple hundred lines to implement what is NOT standard SQL semantics: matching unquoted names case-insensitively is anything but t

Re: [HACKERS] SET ROLE and reserved roles

Stephen Frost writes: > On Wednesday, April 13, 2016, Robert Haas wrote: >> Well ... yeah. But that doesn't mean it should be impossible to SET >> to that role itself. I'm a little worried that could create strange >> corner cases. > Being able to create objects owned by a default role was one

Re: [HACKERS] SET ROLE and reserved roles

Tom, On Wednesday, April 13, 2016, Tom Lane wrote: > Stephen Frost > writes: > > On Wednesday, April 13, 2016, Robert Haas > wrote: > >> Well ... yeah. But that doesn't mean it should be impossible to SET > >> to that role itself. I'm a little worried that could create strange > >> corner cas

Re: [HACKERS] [COMMITTERS] pgsql: Allow Pin/UnpinBuffer to operate in a lockfree manner.

On 2016-04-12 11:52:01 -0400, Tom Lane wrote: > I wrote: > > It looks like that compiler adheres to the C89 restriction that an > > initializer for an array or struct must contain only link-time-constant > > expressions, even if the target object is of dynamic scope. > > The macro works with a link

Re: [HACKERS] SET ROLE and reserved roles

Stephen Frost writes: > On Wednesday, April 13, 2016, Tom Lane wrote: >> If you want to prevent that, I think it needs to be done somewhere else >> than here. What about "ALTER OWNER TO pg_signal_backend", for instance? > Checks are included in that code path to disallow it. If there are such

Re: [HACKERS] Odd system-column handling in postgres_fdw join pushdown patch

On Wed, Apr 13, 2016 at 1:36 PM, Robert Haas wrote: > I tend to favor zeroes rather than NULLs, because that's what we > typically use to represent an invalid value of those types, and I'm > not aware of any current case where those values are NULL. Actually, come to think of it, what we *really*

Re: [HACKERS] [COMMITTERS] pgsql: Allow Pin/UnpinBuffer to operate in a lockfree manner.

Andres Freund writes: > On 2016-04-12 11:52:01 -0400, Tom Lane wrote: >> It strikes me that that means you could stick with this initialization >> method if you made the macro argument be a literal constant string name, >> like "buffer spinlock", and printed that rather than the address in >> s_lo

Re: [HACKERS] [COMMITTERS] pgsql: Allow Pin/UnpinBuffer to operate in a lockfree manner.

On 2016-04-13 14:16:15 -0400, Tom Lane wrote: > Good point, it would be absolutely duplicative. What I'd suggest, > actually, is that we convert this to the same info as what elog > provides (file+line+function name). Heh, I was wondering the same aftering sending the last email. Will do that th

Re: [HACKERS] Choosing parallel_degree

On 13/04/2016 19:17, Robert Haas wrote: > On Tue, Apr 12, 2016 at 6:31 PM, Julien Rouhaud > wrote: >> On 11/04/2016 22:53, Julien Rouhaud wrote: >>> On 11/04/2016 17:44, Robert Haas wrote: We should probably add the number of workers actually obtained to the EXPLAIN ANALYZE output. That

Re: [HACKERS] Odd system-column handling in postgres_fdw join pushdown patch

On Wed, Apr 13, 2016 at 1:36 PM, Robert Haas wrote: > I tend to favor zeroes rather than NULLs, because that's what we > typically use to represent an invalid value of those types, and I'm > not aware of any current case where those values are NULL. In fact, see heap_attisnull. -- Robert Haas E

Re: [HACKERS] Odd system-column handling in postgres_fdw join pushdown patch

Robert Haas writes: > On Wed, Apr 13, 2016 at 1:36 PM, Robert Haas wrote: >> I tend to favor zeroes rather than NULLs, because that's what we >> typically use to represent an invalid value of those types, and I'm >> not aware of any current case where those values are NULL. > In fact, see heap_a

Re: [HACKERS] Odd system-column handling in postgres_fdw join pushdown patch

On Wed, Apr 13, 2016 at 2:11 PM, Robert Haas wrote: > So, clearly that's not good. It should at least be consistent. But > more than that, the fact that postgres_fdw sets the xmax to 0x > is also pretty wacky. We might use such a value as a sentinel for > some data type, but for transac

[HACKERS] sign function with INTERVAL?

Hi all, Is there a good reason why the SIGN() function does not work with the INTERVAL type? (It is only defined for numeric types.) (http://www.postgresql.org/docs/9.5/static/functions-math.html) select sign(-3); -- okay select sign(interval '4 years'); -- ERROR: function sign(interval) does not

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

On Wed, Apr 13, 2016 at 12:25 PM, Robert Haas wrote: > [test results with old_snapshot_threshold = 0 and 10] >From the docs: | A value of -1 disables this feature, and is the default. > Yuck. Aside from the fact that performance tanks when the feature is > turned on, it seems that there is a

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

On 2016-04-13 13:52:15 -0500, Kevin Grittner wrote: > On Wed, Apr 13, 2016 at 12:25 PM, Robert Haas wrote: > > > [test results with old_snapshot_threshold = 0 and 10] > > From the docs: > > | A value of -1 disables this feature, and is the default. Hm, ok, let me run that as well then. The rea

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

On Wed, Apr 13, 2016 at 1:56 PM, Andres Freund wrote: > I'll run with -1 once the current (longer) run has finished. Just for the record, were any of the other results purporting to be with the feature "off" also actually running with the feature set for its fastest possible timeout? -- Kevin G

Re: [HACKERS] sign function with INTERVAL?

On 4/13/16 1:36 PM, Daniel Lenski wrote: Hi all, Is there a good reason why the SIGN() function does not work with the INTERVAL type? (It is only defined for numeric types.) (http://www.postgresql.org/docs/9.5/static/functions-math.html) The only thing that comes to mind is you can get some str

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

On 4/12/16 12:30 PM, Tom Lane wrote: It'd be good if you document the problems you found somewhere, before you forget them, just in case somebody does want to try to lift the restriction. I agree that scattered code comments wouldn't be the way. Just a quick email to -hackers to get the info int

Re: [HACKERS] [patch] \crosstabview documentation

Re: Tom Lane 2016-04-13 <1854.1460562...@sss.pgh.pa.us> > Hm, we do not have entries attached to any other psql > meta-commands. Maybe they all should have one, or maybe not, but > I'm unconvinced about adding one for just this command. What I did > instead was to make a link target (which there

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

On 2016-04-13 13:52:15 -0500, Kevin Grittner wrote: > On Wed, Apr 13, 2016 at 12:25 PM, Robert Haas wrote: > > > [test results with old_snapshot_threshold = 0 and 10] > > From the docs: > > | A value of -1 disables this feature, and is the default. > > > Yuck. Aside from the fact that performance

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

On Wed, Apr 13, 2016 at 3:08 PM, Kevin Grittner wrote: > On Wed, Apr 13, 2016 at 1:56 PM, Andres Freund wrote: > >> I'll run with -1 once the current (longer) run has finished. > > Just for the record, were any of the other results purporting to be > with the feature "off" also actually running w

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

On 2016-04-13 14:08:49 -0500, Kevin Grittner wrote: > On Wed, Apr 13, 2016 at 1:56 PM, Andres Freund wrote: > > > I'll run with -1 once the current (longer) run has finished. > > Just for the record, were any of the other results purporting to be > with the feature "off" also actually running wi

Re: [HACKERS] SET ROLE and reserved roles

On Wed, Apr 13, 2016 at 2:10 PM, Tom Lane wrote: > Stephen Frost writes: >> On Wednesday, April 13, 2016, Tom Lane wrote: >>> If you want to prevent that, I think it needs to be done somewhere else >>> than here. What about "ALTER OWNER TO pg_signal_backend", for instance? > >> Checks are inclu

Re: [HACKERS] [GENERAL] pg_upgrade error regarding hstore operator

"Feld, Michael (IMS)" writes: > In addition, I noticed the following differences in the pg_depend catalog, > there are 4 entries in 9.1 that are missing in 9.5 which I have separated > with ***: > select classid::regclass, objid, objsubid, refclassid::regclass, refobjid, > refobjsubid, deptype,

Re: [HACKERS] [patch] \crosstabview documentation

Christoph Berg writes: > Another thing about \crosstabview: > # select 1,2 \crosstabview > The query must return at least two columns to be shown in crosstab > s/two/three/, I guess. Yeah, I noticed that. See http://www.postgresql.org/message-id/10276.1460569...@sss.pgh.pa.us

  1   2   >