[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

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]" >

[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

[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

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

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

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. > >

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.

[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

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:

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

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

[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

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 > 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

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 >>

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) >

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

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 >> +++

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

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

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 =

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

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

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

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] 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

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

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

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] 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

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

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

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

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

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. >

[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

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,

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

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 > 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

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

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

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

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 >

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

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 >

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

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

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

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":

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,

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

On Wed, Apr 13, 2016 at 1:44 PM, Kyotaro HORIGUCHI < horiguchi.kyot...@lab.ntt.co.jp> wrote: > > At Wed, 13 Apr 2016 04:43:35 +0900, Fujii Masao wrote in > > >>> Thank you for reviewing. > > >>> > > >>>

Re: [HACKERS] Performance degradation in commit 6150a1b0

On Tue, Apr 12, 2016 at 11:40:43PM -0400, Robert Haas wrote: > On Tue, Apr 12, 2016 at 10:30 PM, Noah Misch wrote: > > That sounds like this open item is ready for CLOSE_WAIT status; is it? > > I just retested this on power2. > So, yes, I would say this should go to

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

On Wed, Apr 13, 2016 at 11:21 PM, Etsuro Fujita wrote: >>> 2. When a join is pushed down, deparse system columns using something >>> like "CASE WHEN r1.* IS NOT NULL THEN 0 END", except for the table OID >>> column, which gets deparsed with the table OID in place of

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

On Thu, Apr 14, 2016 at 11:45 AM, Amit Kapila wrote: > On Wed, Apr 13, 2016 at 1:44 PM, Kyotaro HORIGUCHI > wrote: >> >> At Wed, 13 Apr 2016 04:43:35 +0900, Fujii Masao >> wrote in >>

Re: [HACKERS] Postgres_fdw join pushdown - INNER - FULL OUTER join combination generating wrong result

On 2016/03/29 23:20, Ashutosh Bapat wrote: I think the reason for that is in foreign_join_ok. This in that function: wrongly pulls up remote_conds from joining relations in the FULL JOIN case. I think we should not pull up such conditions in the FULL JOIN case. Right.

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

On Thu, Apr 14, 2016 at 11:45 AM, Amit Kapila wrote: > Yes, this is what I was trying to explain to Fujii-san upthread and I have > also verified that the same works on Windows. If you could, it would be nice as well to check that nothing breaks with VS when using

Re: [HACKERS] documentation build bleat

On Thu, Apr 14, 2016 at 9:08 AM, Tom Lane wrote: > Some fairly recent commit is causing the HTML docs build to moan about > > collateindex.pl: duplicated index entry found: PG_LOGICAL_EMIT_MESSAGE > 1 entries ignored... This is my fault. Sorry... -

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

On Thu, Apr 14, 2016 at 11:29 AM, Fujii Masao wrote: > On Wed, Apr 13, 2016 at 4:54 PM, Michael Paquier > wrote: >> On Fri, Apr 8, 2016 at 4:49 PM, Fujii Masao wrote: >>> Add regression tests for multiple synchronous

Re: [HACKERS] Performance degradation in commit 6150a1b0

On Wed, Apr 13, 2016 at 9:10 AM, Robert Haas wrote: > > On Tue, Apr 12, 2016 at 10:30 PM, Noah Misch wrote: > > That sounds like this open item is ready for CLOSE_WAIT status; is it? > > I just retested this on power2. Here are the results. I retested

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On 2016-04-14 07:59:07 +0530, Amit Kapila wrote: > What you want to see by prewarming? Prewarming appears to greatly reduce the per-run variance on that machine, making it a lot easier to get meaningful results. Thus it'd make it easier to compare pre/post padding numbers. > Will it have safe

[HACKERS] EXPLAIN VERBOSE with parallel Aggregate

There's 2 problems: 1) I recently noticed that EXPLAIN VERBOSE is a bit bogus when it comes to parallel aggregates with FILTER (WHERE ...) clauses. We get; Output: pg_catalog.sum((sum(num) FILTER (WHERE (num > 0 FILTER (WHERE (num > 0)) Which is simply a lie, we only filter on the partial

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

At Thu, 14 Apr 2016 12:42:06 +0900, Fujii Masao wrote in > > Yes, this is what I was trying to explain to Fujii-san upthread and I have > > also verified that the same works on Windows. > > Oh, okay,

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

On Tue, Apr 12, 2016 at 11:38 AM, 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 >>

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

On Tue, Apr 12, 2016 at 11:38 AM, Andres Freund wrote: > >> The bottom line >> here, IMHO, is not that there's anything wrong with our ring buffer >> implementation, but that if you run PostgreSQL on a system where the >> I/O is hitting a 5.25" floppy (not to say 8") the

Re: [HACKERS] [BUGS] Breakage with VACUUM ANALYSE + partitions

At 2016-04-12 09:00:57 -0400, robertmh...@gmail.com wrote: > > On Mon, Apr 11, 2016 at 1:17 PM, Andres Freund wrote: > > > > 3) Actually handle the case of the last open segment not being > >RELSEG_SIZE properly in _mdfd_getseg() - mdnblocks() does so. > > #3 seems like

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

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

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

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.

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 \

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

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

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

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

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

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

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] 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

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

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

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

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

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

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

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

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

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

[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

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

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:

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: >>> ---

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

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

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

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

[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

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

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

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

  1   2   >