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

On 12 July 2016 at 21:57, wrote: > Hi > > Is there any plan to implement "session per thread" or "shared > sessions between thread"? > As has been noted by others, there isn't any such plan right now. PostgreSQL isn't threaded. It uses a multi-processing

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

On 14 July 2016 at 03:59, Robert Haas wrote: > I agree that there's not really a plan to implement this, but I don't > agree that connection pooling solves the whole problem. Most people > can't get by with statement pooling, so in practice you are looking at >

[HACKERS] Fix typo in postgres_fdw/deparse.c

Hi all, Attached patch fixes small typo in contrib/postgres_fdw/deparse.c s/whenver/whenever/g Regards, -- Masahiko Sawada fix_small_typo_in_deparse_c.patch Description: binary/octet-stream -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

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

On Jul 13, 2016, at 12:25 PM, Stephen Frost wrote: > I disagree. Adding a column is certainly changing the structure, as is > removing one. This certainly hasn't changed my opinion that it's > worthwhile to consider this change, even at this point in the release > cycle,

Re: [HACKERS] Improving executor performance - tidbitmap

Hi, On 2016-06-24 16:29:53 -0700, Andres Freund wrote: > 4) Various missing micro optimizations have to be performed, for more >architectural issues to become visible. E.g. [2] causes such bad >slowdowns in hash-agg workloads, that other bottlenecks are hidden. One such issue is the

Re: [HACKERS] Improving executor performance

Hi, On 2016-06-24 16:29:53 -0700, Andres Freund wrote: > 2) Baring 1) tuple deforming is the biggest bottleneck in nearly all >queries I looked at. There's various places we trigger deforming, >most ending in either slot_deform_tuple(), heap_getattr(), >heap_deform_tuple(). > >

Re: [HACKERS] bug in citext's upgrade script for parallel aggregates

On 07/09/2016 05:42 AM, David Rowley wrote: On 30 June 2016 at 03:49, Robert Haas wrote: On Sat, Jun 25, 2016 at 3:44 AM, Andreas Karlsson wrote: On 06/24/2016 01:31 PM, David Rowley wrote: Seems there's a small error in the upgrade script for

Re: [HACKERS] unexpected psql "feature"

Alvaro Herrera writes: > Now, I think requesting psql not to split query strings is a good > feature, but having it depend on using \; instead of ; seems way too > obscure. If we want to offer that choice, I propose we do it via some > properly designed mechanism rather

Re: [HACKERS] unexpected psql "feature"

David G. Johnston wrote: > On Wed, Jul 13, 2016 at 5:44 PM, Fabien COELHO wrote: > > > Although "\;" behavior is not documented, I would have expected both > >>> results to be shown one after the other, or having a an error, but not a > >>> quiet discard. > >> > >> See the

[HACKERS] Upcoming PG release schedule

Current plans are to produce a 9.6beta3 release next week (ie, wrap Monday Jul 18 for announcement Thursday Jul 21). Keep in mind also that we expect to make routine back-branch update releases on the previously-announced schedule (wrap Monday Aug 8 for announcement Thursday Aug 11). We'll

Re: [HACKERS] unexpected psql "feature"

On Wed, Jul 13, 2016 at 5:44 PM, Fabien COELHO wrote: > > Hello Tom, > > Although "\;" behavior is not documented, I would have expected both >>> results to be shown one after the other, or having a an error, but not a >>> quiet discard. >>> >> >> See the documentation for

Re: [HACKERS] unexpected psql "feature"

On Wed, Jul 13, 2016 at 5:44 PM, Fabien COELHO wrote: > >> I do not think changing this is appropriate. All you are likely to >> accomplish is breaking code that does what its author wanted. >> > > Hmmm... My 0.02€: Currently this feature is NOT documented, so somehow it >

Re: [HACKERS] unexpected psql "feature"

Hello Tom, Although "\;" behavior is not documented, I would have expected both results to be shown one after the other, or having a an error, but not a quiet discard. See the documentation for PQexec(): all but the last query result is discarded. Sure. That is developer-level answer to

Re: [HACKERS] unexpected psql "feature"

Fabien COELHO writes: > Hello devs, > Although this is probably a "feature", it is a weird one: > $ psql > psql (9.6beta2) > fabien=# SELECT 1 AS one \; > fabien-# SELECT 2 AS two ; >two > - > 2 > (1 row) > Where is my "1"? > Although "\;"

Re: [HACKERS] unexpected psql "feature"

Hello David, At least we aggree that having a documentation would be an improvement:-) On the second point: - all results should be shown, not just the last one disagree # select 1 ; select 2 ; vs # select 1 \; select 2 ; Result in identical behavior seems undesirable. In both

Re: [HACKERS] pgbench - allow to store select results into variables

On Wed, Jul 13, 2016 at 4:02 PM, Tom Lane wrote: > Robert Haas writes: > > On Sat, Jul 9, 2016 at 7:52 AM, Fabien COELHO > wrote: > >> If someone thinks that "gset" is a good idea for pgbench, which I > don't, it > >> could be

Re: [HACKERS] pgbench - allow to store select results into variables

Hello Tom, Sending a batch of requests is a feature of libpq which is accessible through pgbench by using "\;", although the fact is not documented. It makes sense for a client to send independent queries together so as to reduce latency. You're putting an awful lot of weight on an

[HACKERS] Document that vacuum can't truncate if old_snapshot_threshold >= 0

Hi, Currently, if old_snapshot_threshold is enabled, vacuum is prevented from truncating tables: static bool should_attempt_truncation(LVRelStats *vacrelstats) { BlockNumber possibly_freeable; possibly_freeable = vacrelstats->rel_pages - vacrelstats->nonempty_pages; if

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

On 2016-07-13 15:57:02 -0500, Kevin Grittner wrote: > A short answer is that a normal table's heap doesn't go through > systable_getnext_ordered(). That function is used both for cases > where the check should not be made, like toast_delete_datum(), and > cases where it should, like

Re: [HACKERS] rethinking dense_alloc (HashJoin) as a memory context

Andres Freund writes: > On 2016-07-13 16:39:58 -0400, Tom Lane wrote: >> I think there's a lot, but I'm afraid most of them are in contexts >> (pun intended) where aset.c already works pretty well, ie it's a >> short-lived context anyway. > FWIW, hacking up the aset/mcxt.c to

Re: [HACKERS] Simplifying the interface of UpdateMinRecoveryPoint

On Wed, Jul 13, 2016 at 10:31 PM, Simon Riggs wrote: > On 12 July 2016 at 23:49, Michael Paquier wrote: >> Hence why not simplifying its interface and remove the force flag? > > Is this change needed as part of a feature? If not, I see no reason

Re: [HACKERS] Header and comments describing routines in incorrect shape in visibilitymap.c

On Thu, Jul 14, 2016 at 4:29 AM, Robert Haas wrote: > On Fri, Jul 8, 2016 at 7:14 AM, Michael Paquier > wrote: >>> OK, that removes comment duplication. Also, what about replacing >>> "bit(s)" by "one or more bits" in the comment terms where

Re: [HACKERS] unexpected psql "feature"

On Wed, Jul 13, 2016 at 4:47 PM, Fabien COELHO wrote: > > I would suggest that: > - the \; psql feature should be documented somewhere > ​agreed ​ > - all results should be shown, not just the last one > disagree # select 1 ; select 2 ; ?column? -- 1 (1

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

On Wed, Jul 13, 2016 at 12:48 PM, Andres Freund wrote: > On 2016-07-13 10:06:52 -0500, Kevin Grittner wrote: >> On Wed, Jul 13, 2016 at 7:57 AM, Amit Kapila wrote: >>> On Tue, Jul 12, 2016 at 8:34 PM, Kevin Grittner wrote: On

Re: [HACKERS] rethinking dense_alloc (HashJoin) as a memory context

On 2016-07-13 16:39:58 -0400, Tom Lane wrote: > Robert Haas writes: > > On Wed, Jul 13, 2016 at 1:10 PM, Tomas Vondra > > wrote: > > What's not clear to me is to what extent slowing down pfree is an > > acceptable price for improving the

Re: [HACKERS] A Modest Upgrade Proposal

On 13/07/16 21:06, Robert Haas wrote: We have much to discuss in terms of security, the way it should work and what options to support and a sidetrack into syntax isn't warranted at this early stage. Please lets discuss those important things first, then return to whether DDL makes sense or

[HACKERS] unexpected psql "feature"

Hello devs, Although this is probably a "feature", it is a weird one: $ psql psql (9.6beta2) fabien=# SELECT 1 AS one \; fabien-# SELECT 2 AS two ; two - 2 (1 row) Where is my "1"? Although "\;" behavior is not documented, I would have expected both results to be shown one

Re: [HACKERS] A Modest Upgrade Proposal

On 13 July 2016 at 15:06, Robert Haas wrote: > On Thu, Jul 7, 2016 at 9:25 PM, Simon Riggs wrote: > > I note also that replication slots aren't backed up by pg_dump; I see > > analogy here and think that at least some parts of logical replication >

Re: [HACKERS] rethinking dense_alloc (HashJoin) as a memory context

Robert Haas writes: > On Wed, Jul 13, 2016 at 1:10 PM, Tomas Vondra > wrote: > What's not clear to me is to what extent slowing down pfree is an > acceptable price for improving the behavior in other ways. I wonder > how many of the pfree

Re: [HACKERS] sslmode=require fallback

Robert Haas writes: > On Wed, Jul 13, 2016 at 3:16 PM, Tom Lane wrote: >> Robert Haas writes: >>> Suppose we changed the default to "require". How crazy would that be? >> You mean, aside from the fact that it breaks every

Re: [HACKERS] pgbench - allow to store select results into variables

Fabien COELHO writes: > Sending a batch of requests is a feature of libpq which is accessible > through pgbench by using "\;", although the fact is not documented. It > makes sense for a client to send independent queries together so as to > reduce latency. You're putting

Re: [HACKERS] sslmode=require fallback

Robert Haas writes: > On Thu, Jun 16, 2016 at 3:42 AM, Magnus Hagander wrote: >> The default mode of "prefer" is ridiculous in a lot of ways. If you are >> using SSL in any shape or form you should simply not use "prefer". That's >> really the only

Re: [HACKERS] pgbench - allow to store select results into variables

Hello Robert, I agree: I like \into. Great! But: SELECT 1, 2 \; SELECT 3; \into one two three I think that's pretty weird. I agree that it is weird, but I do not think that it is bad. Sending a batch of requests is a feature of libpq which is accessible through pgbench by using

Re: [HACKERS] sslmode=require fallback

On Wed, Jul 13, 2016 at 3:16 PM, Tom Lane wrote: > Robert Haas writes: >> On Thu, Jun 16, 2016 at 3:42 AM, Magnus Hagander wrote: >>> The default mode of "prefer" is ridiculous in a lot of ways. If you are >>> using SSL in any

Re: [HACKERS] rethinking dense_alloc (HashJoin) as a memory context

On Wed, Jul 13, 2016 at 1:10 PM, Tomas Vondra wrote: > I think the MemoryContext API may not be right abstraction for this. +1. The MemoryContext API is little short of an absolute bar to implementing an allocator that works significantly differently than aset.c,

Re: [HACKERS] pgbench - allow to store select results into variables

Robert Haas writes: > On Wed, Jul 13, 2016 at 3:02 PM, Tom Lane wrote: >> I note also that we were talking a couple months ago >> about trying to align psql and pgbench backslash commands more closely. >> This would not be a good step in that direction.

Re: [HACKERS] sslmode=require fallback

On Thu, Jun 16, 2016 at 3:42 AM, Magnus Hagander wrote: > You would think so. > > The default mode of "prefer" is ridiculous in a lot of ways. If you are > using SSL in any shape or form you should simply not use "prefer". That's > really the only answer at this point,

Re: [HACKERS] pgbench - allow to store select results into variables

On Wed, Jul 13, 2016 at 3:02 PM, Tom Lane wrote: > Robert Haas writes: >> On Sat, Jul 9, 2016 at 7:52 AM, Fabien COELHO wrote: >>> If someone thinks that "gset" is a good idea for pgbench, which I don't, it >>> could be

Re: [HACKERS] remove checkpoint_warning

On Tue, Jul 12, 2016 at 3:19 AM, Magnus Hagander wrote: > +1, this is a useful warning. +1. I'd like to see more people turn log_checkpoints=on, and I often ask customers to do that when they're having systemic performance problems. But this warning regularly alerts me to

Re: [HACKERS] pgbench - allow to store select results into variables

Robert Haas writes: > On Sat, Jul 9, 2016 at 7:52 AM, Fabien COELHO wrote: >> If someone thinks that "gset" is a good idea for pgbench, which I don't, it >> could be implemented. I think that an "into" feature, like PL/pgSQL & ECPG, >> makes more sense

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

On Tue, Jul 12, 2016 at 9:18 AM, Tom Lane wrote: > 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

Re: [HACKERS] pgbench - allow to store select results into variables

On Sat, Jul 9, 2016 at 7:52 AM, Fabien COELHO wrote: > If someone thinks that "gset" is a good idea for pgbench, which I don't, it > could be implemented. I think that an "into" feature, like PL/pgSQL & ECPG, > makes more sense for scripting. I agree: I like \into. But: >

Re: [HACKERS] Header and comments describing routines in incorrect shape in visibilitymap.c

On Fri, Jul 8, 2016 at 7:14 AM, Michael Paquier wrote: >> OK, that removes comment duplication. Also, what about replacing >> "bit(s)" by "one or more bits" in the comment terms where adapted? >> That's bikeshedding, but that's what this patch is about. > > Translating

Re: [HACKERS] Bug in batch tuplesort memory CLUSTER case (9.6 only)

On Wed, Jul 13, 2016 at 12:24 PM, Tom Lane wrote: >> I am happy with the adjustment. Please commit the adjusted patch. > > Done with minor adjustments. Thanks. I'm pleased that we found a way forward that addressed every concern. -- Peter Geoghegan -- Sent via

Re: [HACKERS] A Modest Upgrade Proposal

On Fri, Jul 8, 2016 at 5:47 AM, Craig Ringer wrote: >> DDL is our standard way of getting things into the system catalogs. >> We have no system catalog metadata that is intended to be populated by >> any means other than DDL. > > Replication slots? (Arguably not catalogs, I

Re: [HACKERS] Bug in batch tuplesort memory CLUSTER case (9.6 only)

Peter Geoghegan writes: > On Wed, Jul 13, 2016 at 11:44 AM, Tom Lane wrote: >> If you're good with that adjustment, I'm happy to commit this. > I am happy with the adjustment. Please commit the adjusted patch. Done with minor adjustments.

Re: [HACKERS] A Modest Upgrade Proposal

On Thu, Jul 7, 2016 at 9:25 PM, Simon Riggs wrote: > I note also that replication slots aren't backed up by pg_dump; I see > analogy here and think that at least some parts of logical replication will > be similar and not require DDL at all, just as slots do not. I agree

Re: [HACKERS] A Modest Upgrade Proposal

On 07/07/2016 01:01 PM, Robert Haas wrote: There was an unconference session on this topic at PGCon and quite a number of people there stated that they found DDL to be an ease-of-use feature and wanted to have it. Yeah, I haven't meet anyone yet that would like to have: select

Re: [HACKERS] Bug in batch tuplesort memory CLUSTER case (9.6 only)

On Wed, Jul 13, 2016 at 11:44 AM, Tom Lane wrote: > What I don't much like is that it enlarges cluster.out with 200K of > random-looking, hard-to-manually-verify data. May I suggest that > we replace the SELECTs with > > select * from > (select hundred, lag(hundred) over ()

Re: [HACKERS] A Modest Upgrade Proposal

On Thu, Jul 7, 2016 at 8:53 PM, Simon Riggs wrote: >> I thought I sat through, at least, most of it, but you barely gave >> anyone else a chance to talk, which kind of misses the point of an >> unconference. The portion which I attended was not about how to move >> the

Re: [HACKERS] Bug in batch tuplesort memory CLUSTER case (9.6 only)

Peter Geoghegan writes: > Attached patch adds a CLUSTER external sort test case to the > regression tests, as discussed. I took a quick look at this patch. > This makes a hardly noticeable difference on the run time of the > CLUSTER tests, at least for me. Consider the

Re: [HACKERS] rethinking dense_alloc (HashJoin) as a memory context

On 07/13/2016 07:37 PM, Tom Lane wrote: Peter Geoghegan writes: On Wed, Jul 13, 2016 at 7:53 AM, Tomas Vondra wrote: In the thread [1] dealing with hashjoin bug introduced in 9.5, Tom voiced his dislike of dense_alloc. I kinda agree with him

Re: [HACKERS] \timing interval

On Mon, Jul 11, 2016 at 8:35 AM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 7/9/16 4:00 PM, Andrew Gierth wrote: > >> How about >> >> Time: 1234567.666 ms (20m 34.6s) >> > > That's similar to what I had in mind, so I'd be happy with that. > > > -- > Peter Eisentraut

Re: [HACKERS] rethinking dense_alloc (HashJoin) as a memory context

Andres Freund writes: > On 2016-07-13 13:37:55 -0400, Tom Lane wrote: >> We already know that >> that code has performance issues, cf bug #14231, so I suspect there's >> a redesign in its future anyway. > Note that it's not the slab allocators that is having problems, it's >

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

On 2016-07-13 10:06:52 -0500, Kevin Grittner wrote: > On Wed, Jul 13, 2016 at 7:57 AM, Amit Kapila wrote: > > On Tue, Jul 12, 2016 at 8:34 PM, Kevin Grittner wrote: > >> On Fri, Jul 8, 2016 at 1:52 PM, Andres Freund wrote: > >> >

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

On 2016-07-12 10:04:45 -0500, Kevin Grittner wrote: > 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

Re: [HACKERS] rethinking dense_alloc (HashJoin) as a memory context

On 2016-07-13 13:37:55 -0400, Tom Lane wrote: > I wonder though if we don't already have another similar use-case in > the ad-hoc "slab allocators" in reorderbuffer.c. That seems to call more for a general slab allocator design, than for something like here. After all, there's plenty of freeing

Re: [HACKERS] rethinking dense_alloc (HashJoin) as a memory context

Peter Geoghegan writes: > On Wed, Jul 13, 2016 at 7:53 AM, Tomas Vondra > wrote: >> In the thread [1] dealing with hashjoin bug introduced in 9.5, Tom voiced >> his dislike of dense_alloc. I kinda agree with him that introducing "local >>

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

* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 7/12/16 7:11 PM, Stephen Frost wrote: > > I'm curious how it's useful and in what way \sf does not accomplish what > > you use \df+ for. > > One main use is to see multiple related functions next to each other and > compare their

Re: [HACKERS] rethinking dense_alloc (HashJoin) as a memory context

On Wed, Jul 13, 2016 at 7:53 AM, Tomas Vondra wrote: > In the thread [1] dealing with hashjoin bug introduced in 9.5, Tom voiced > his dislike of dense_alloc. I kinda agree with him that introducing "local > allocators" may not be the best idea, and as dense_alloc

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

Peter Eisentraut writes: > On 7/12/16 7:11 PM, Stephen Frost wrote: >> I'm curious how it's useful and in what way \sf does not accomplish what >> you use \df+ for. > One main use is to see multiple related functions next to each other and > compare their source

Re: [HACKERS] UPSERT/RETURNING -> ON CONFLICT SELECT?

Peter Geoghegan writes: > On Wed, Jul 13, 2016 at 2:49 AM, Bjørnar Ness wrote: >> But with upsert/do nothing, this will not work as "needed". >> >> Would it be possible to introduce a "ON CONFLICT SELECT" argument: >> >> with _foo as ( >> insert into

Re: [HACKERS] UPSERT/RETURNING -> ON CONFLICT SELECT?

On Wed, Jul 13, 2016 at 2:49 AM, Bjørnar Ness wrote: > But with upsert/do nothing, this will not work as "needed". > > Would it be possible to introduce a "ON CONFLICT SELECT" argument: > > with _foo as ( > insert into foo(i) values(1) > on conflict select returning id

Re: [HACKERS] application_name in process name?

Mike Blackwell writes: > There are times when it would be useful to have the application_name > connection parameter displayed in the process name - and thus in ps and > pg_top - in addition to the user and database name. > Would there be any downside to this? In a lot

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

On 7/12/16 7:11 PM, Stephen Frost wrote: > I'm curious how it's useful and in what way \sf does not accomplish what > you use \df+ for. One main use is to see multiple related functions next to each other and compare their source code. But also because one is used to \df and wants to see

[HACKERS] application_name in process name?

There are times when it would be useful to have the application_name connection parameter displayed in the process name - and thus in ps and pg_top - in addition to the user and database name. Would there be any downside to this? If it were done, are there any suggestions on how it could be

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

On Wed, Jul 13, 2016 at 7:57 AM, Amit Kapila wrote: > On Tue, Jul 12, 2016 at 8:34 PM, Kevin Grittner wrote: >> On Fri, Jul 8, 2016 at 1:52 PM, Andres Freund wrote: >> >>> I'm a bit confused, why aren't we simply adding LSN

Re: [HACKERS] Documentation fix for CREATE FUNCTION

Albe Laurenz writes: > I just noticed that the documentation for CREATE FUNCTION still mentions > that the temporary namespace is searched for functions even though that > has been removed with commit aa27977. The example you propose to correct was introduced by that

[HACKERS] rethinking dense_alloc (HashJoin) as a memory context

Hi, In the thread [1] dealing with hashjoin bug introduced in 9.5, Tom voiced his dislike of dense_alloc. I kinda agree with him that introducing "local allocators" may not be the best idea, and as dense_alloc was introduced by me I was playing with the idea to wrap this into a regular

Re: [HACKERS] Simplifying the interface of UpdateMinRecoveryPoint

On 12 July 2016 at 23:49, Michael Paquier wrote: > Hence why not simplifying its interface and remove the force flag? Is this change needed as part of a feature? If not, I see no reason for change. If we all work towards meaningful features the code can be cleaned

Re: [HACKERS] Simplifying the interface of UpdateMinRecoveryPoint

On Wed, Jul 13, 2016 at 8:27 PM, Amit Kapila wrote: > On Wed, Jul 13, 2016 at 9:19 AM, Michael Paquier > wrote: >> Hence why not simplifying its interface and remove the force flag? > > One point to note is that the signature and usage of >

Re: [HACKERS] Disable WAL completely - Performance and Persistency research

Your patch is very helpful, I'm still checking it on different file-systems. I really liked the idea of using only the edge checkpoints. Thanks. On Mon, Jul 11, 2016 at 9:26 PM, Jeff Janes wrote: > On Thu, Jul 7, 2016 at 1:01 AM, Netanel Katzburg >

[HACKERS] UPSERT/RETURNING -> ON CONFLICT SELECT?

The new upsert feature is a great addition, but in some cases is not as usable as I and seems lots of others would like it to be, take an example with circular references: create table foo ( id serial references bar(foo_id) on delete cascade, i int ); create table bar ( foo_id integer

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

On Tue, Jul 12, 2016 at 8:34 PM, Kevin Grittner wrote: > 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

Re: [HACKERS] pg_basebackup wish list

On Tue, Jul 12, 2016 at 10:23 PM, Jeff Janes wrote: > 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

Re: [HACKERS] Simplifying the interface of UpdateMinRecoveryPoint

On Wed, Jul 13, 2016 at 9:19 AM, Michael Paquier wrote: > 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

[HACKERS] Constraint merge and not valid status

Hi, Consider a scenario where one adds a *valid* constraint on a inheritance parent which is then merged with a child table's *not valid* constraint during inheritance recursion. If merged, the constraint is not checked for the child data even though it may have some. Is that an oversight?

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

> Seems odd to me. Both relations use the same user mapping as before, so > the join should be pushed down. > > Another thing I noticed is that the code in plancache.c would invalidate a > cached plan with a foreign join due to user mapping changes even in the > case where user mappings are

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

Hello Peter, number of transactions per client: 1000 -latency average = 15.844 ms +latency average: 15.844 ms tps = 618.764555 (including connections establishing) I think what you have here is that colons separate input parameters and equal signs separate result output. So I think it's

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

The attached patch provides a solution which ensures the return in the right condition and after the stat collection. The code structure requires another ugly boolean to proceed so as to preserve doing the reconnection between the decision that the return must be done and the place where it

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

Hello Tom, 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 non-last command? It looks like it

[HACKERS] Documentation fix for CREATE FUNCTION

I just noticed that the documentation for CREATE FUNCTION still mentions that the temporary namespace is searched for functions even though that has been removed with commit aa27977. Attached is a patch to fix that. Yours, Laurenz Albe

Re: [HACKERS] dumping database privileges broken in 9.6

On Wed, Jul 13, 2016 at 5:18 AM, Stephen Frost wrote: > Attached is a patch to address this. > > After much consideration and deliberation, I went with the simpler > solution to simply dump out the database privileges based on what a new > creation of those privileges would