Re: [HACKERS] Set log_line_prefix and application name in test drivers

On 8/16/16 2:23 PM, Peter Eisentraut wrote: > On 8/10/16 9:36 PM, Peter Eisentraut wrote: >> %m vs %t is obviously a minor issue that I will gladly adjust, but >> besides that I prefer to stick with my version. > > Updated patch with %m instead of %t. Will submit to CF. attached -- Peter

Re: [HACKERS] Intermittent "cache lookup failed for type" buildfarm failures

Tom Lane wrote: > Robert Haas writes: > > It would sure be nice if those cache lookup failure messages printed > > the file and line number. I wonder if we could teach psql to always > > treat the VERBOSITY as verbose when the error code is XX000. > > I looked around

Re: [HACKERS] Intermittent "cache lookup failed for type" buildfarm failures

Robert Haas writes: > On Tue, Aug 16, 2016 at 2:21 PM, Tom Lane wrote: >> I grepped through the buildfarm logs and determined that there are exactly >> zero similar failures going back as far as 2016-04-01. Now that we've had >> four in a week, it

Re: [HACKERS] [parallel query] random server crash while running tpc-h query on power2

On Tue, Aug 16, 2016 at 1:05 AM, Rushabh Lathia wrote: > I agree, this make sense. > > Here is the patch to allocate worker instrumentation into same context > as the regular instrumentation which is per-query context. Looks good, committed. I am not sure it was a very

Re: [HACKERS] Set log_line_prefix and application name in test drivers

On 8/10/16 9:36 PM, Peter Eisentraut wrote: > %m vs %t is obviously a minor issue that I will gladly adjust, but > besides that I prefer to stick with my version. Updated patch with %m instead of %t. Will submit to CF. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL

Re: [HACKERS] Intermittent "cache lookup failed for type" buildfarm failures

On Tue, Aug 16, 2016 at 2:21 PM, Tom Lane wrote: > There is something rotten in the state of Denmark. Here are four recent > runs that failed with unexpected "cache lookup failed for type " > errors: > >

Re: [HACKERS] [GENERAL] C++ port of Postgres

2016-08-16 18:52 GMT+03:00 Heikki Linnakangas : > On 08/16/2016 05:47 PM, Jim Nasby wrote: >> >> I realize there's little technical reason why we *need* C++ support. The >> level if discipline applied to our codebase negates some of the benefits >> of C++. But maintaining the

Re: [HACKERS] Slowness of extended protocol

Halfway through this mail I suddenly understood something, please read all the way down before responding... On Tue, Aug 16, 2016 at 2:16 PM, Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > Shay> your analogy breaks down. Of course L2 was invented to improve > performance, > Shay> but

Re: [HACKERS] condition variables

On 2016-08-11 21:27:45 -0400, Robert Haas wrote: > On Thu, Aug 11, 2016 at 6:37 PM, Peter Geoghegan wrote: > > I notice that you acquire a spinlock within the implementation of > > condition variables. Is it worth any effort to consolidate the number > > of spinlock acquisitions?

Re: [HACKERS] [GENERAL] C++ port of Postgres

On Tue, Aug 16, 2016 at 1:13 PM, Robert Haas wrote: > On Tue, Aug 16, 2016 at 12:59 PM, Tom Lane wrote: > > Robert Haas writes: > >> I'm not really interested in supporting PostgreSQL code written in > >> other languages

Re: [HACKERS] parallel.c is not marked as test covered

On 6/20/16 11:16 PM, Tom Lane wrote: >> > I think this test would only fail if it runs out of workers, and that >> > would only happen in an installcheck run against a server configured in >> > a nonstandard way or that is doing something else -- which doesn't >> > happen on the buildfarm. >

[HACKERS] Intermittent "cache lookup failed for type" buildfarm failures

There is something rotten in the state of Denmark. Here are four recent runs that failed with unexpected "cache lookup failed for type " errors: http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=grouse=2016-08-16%2008%3A39%3A03

Re: [HACKERS] Pluggable storage

On 2016-08-15 12:02:18 -0400, Robert Haas wrote: > Thanks for taking a stab at this. I'd like to throw out a few concerns. > > One, I'm worried that adding an additional layer of pointer-jumping is > going to slow things down and make Andres' work to speed up the > executor more difficult. I

Re: [HACKERS] pg_bsd_indent - improvements around offsetof and sizeof

On 2016-08-15 18:09:02 +, Piotr Stefaniak wrote: > There are more fixes I intend to do, of which the most relevant for > Postgres are: > 1) fixing "function pointer typedef formatting" This alone would warrant a bottle of something rather expensive. -- Sent via pgsql-hackers mailing list

Re: [HACKERS] PSA: Systemd will kill PostgreSQL

On 16 August 2016 at 08:33, Tom Lane wrote: > Josh Berkus writes: > > On 08/15/2016 05:18 PM, Tom Lane wrote: > >> Well, yeah, it's easy to fix once you know you need to do so. The > >> complaint is basically that out-of-the-box, it's broken, and it's >

Re: [HACKERS] Bug in to_timestamp().

On 15.08.2016 19:28, Robert Haas wrote: Well, what's the Oracle behavior in any of these cases? I don't think we can decide to change any of this behavior without knowing that. If a proposed behavior change is incompatible with our previous releases, I think it'd better at least be more

Re: [HACKERS] Patch: initdb: "'" for QUOTE_PATH (non-windows)

Ok, I'll do that! Thanks Michael! Ryan On Monday, August 15, 2016, Michael Paquier wrote: > On Mon, Aug 15, 2016 at 12:12 AM, Ryan Murphy > wrote: > > This is to fix an issue that came up for me when running initdb. > > > > At

Re: [HACKERS] Declarative partitioning - another take

> I think it makes sense to keep calling it a table because it has all the > logical properties of a table even though it will differ from a regular > table on the basis of physical implementation details such as that it does > not own physical storage. Am I missing something? > > > > > +

Re: [HACKERS] Let's get rid of the separate minor version numbers for shlibs

> The only place where we'd have a problem is the ecpg preprocessor > itself, which is scheduled to be at version 4.13 this year.  However, > that version number is purely cosmetic since AFAICS the only thing > that gets done with it is to print it in response to -v and suchlike. > I don't really

Re: [HACKERS] System load consideration before spawning parallel workers

On Fri, Aug 5, 2016 at 9:46 AM, Jim Nasby wrote: > On 8/1/16 1:08 AM, Haribabu Kommi wrote: >> >> There are some utilities and functions that are available to calculate the >> current system load, based on the available resources and system load, >> the module can allow

Re: [HACKERS] Index Onlys Scan for expressions

On Tue, Aug 16, 2016 at 1:03 AM, Ildar Musin wrote: > Hi, hackers! > > There is a known issue that index only scan (IOS) can only work with simple > index keys based on single attributes and doesn't work with index > expressions. In this patch I propose a solution that

Re: [HACKERS] Anyone want to update our Windows timezone map?

On Tue, Aug 16, 2016 at 11:15 AM, Michael Paquier wrote: > On Tue, Aug 16, 2016 at 9:14 AM, Michael Paquier > wrote: > > On Tue, Aug 16, 2016 at 4:19 AM, Tom Lane wrote: > >> We have certainly not been doing that on a

[HACKERS] [PATCH] bigint txids vs 'xid' type, new txid_recent(bigint) => xid

Hi all While implementing support for traceable transactions (finding out after the fact whether an xact committed or aborted), I've found that Pg is very inconsistent with what it considers a transaction ID from a user facing point of view, to the point where I think it's hard for users to write

Re: [HACKERS] Anyone want to update our Windows timezone map?

On Tue, Aug 16, 2016 at 9:14 AM, Michael Paquier wrote: > On Tue, Aug 16, 2016 at 4:19 AM, Tom Lane wrote: >> We have certainly not been doing that on a regular basis (as best I can >> tell, no such changes have been made since 2010). Does anybody

Re: [HACKERS] [RFC] Change the default of update_process_title to off

On Fri, Aug 5, 2016 at 12:25 PM, Tsunakawa, Takayuki < tsunakawa.ta...@jp.fujitsu.com> wrote: > > From: Tom Lane [mailto:t...@sss.pgh.pa.us] > > Yeah, I think I agree. It would be bad to disable it by default on Unix, > > because ps(1) is a very standard tool there, but the same argument >

Re: [HACKERS] Declarative partitioning - another take

On Wed, Aug 10, 2016 at 7:09 AM, Amit Langote wrote: > 0002-psql-and-pg_dump-support-for-partitioned-tables.patch +if (pset.sversion >= 90600 && tableinfo.relkind == 'P') Version check is redundant, right? +) PARTITION BY RANGE ((a+b)); +\d describe_range_key

Re: [HACKERS] Declarative partitioning - another take

On Wed, Aug 10, 2016 at 7:09 AM, Amit Langote wrote: > 0003-Catalog-and-DDL-for-partition-bounds.patch > > Partition DDL includes both a way to create new partition and "attach" an > existing table as a partition of parent partitioned table. Attempt to > drop a

Re: [HACKERS] [GENERAL] C++ port of Postgres

I'm sure this wasn't your intent, but the tone of your response is part of why people don't get involved with Postgres development... On 8/16/16 10:39 AM, Aleksander Alekseev wrote: Well, well, well. Another C vs C++ holly war, really? Please note that you're the only person in the entire

Re: [HACKERS] LWLocks in DSM memory

On 2016-08-15 18:15:23 -0400, Robert Haas wrote: > On Thu, Aug 11, 2016 at 2:19 PM, Robert Haas wrote: > > Therefore, I plan to commit this patch, removing the #include > > unless someone convinces me we need it, shortly after > > development for v10 opens, unless there

Re: [HACKERS] Surprising behaviour of \set AUTOCOMMIT ON

>I think I like the option of having psql issue an error. On the >server side, the transaction would still be open, but the user would >receive a psql error message and the autocommit setting would not be >changed. So the user could type COMMIT or ROLLBACK manually and then >retry changing the

Re: [HACKERS] [GENERAL] C++ port of Postgres

On 2016-08-16 13:40:06 -0700, Peter Geoghegan wrote: > On Tue, Aug 16, 2016 at 1:29 PM, Peter Geoghegan wrote: > > IMV, it would be useful to use C++ classes (and even template classes) > > for a small number of data structures, while still largely adhering to > > earlier

Re: [HACKERS] [GENERAL] C++ port of Postgres

Andres Freund writes: > On 2016-08-16 13:40:06 -0700, Peter Geoghegan wrote: >> Actually, come to think of it, I guess this is wrong. The problem with >> what I say here is that longjmp() and setjmp() are incompatible with >> the stack unwinding used by C++ destructors in

Re: [HACKERS] Detecting skipped data from logical slots (data silently skipped)

On 2016-08-08 10:59:20 +0800, Craig Ringer wrote: > Right. Though if we flush lazily I'm surprised the effect is that big, > you're the one who did the work and knows the significance of it. It will be. Either you're increasing bloat (by not increasing the slot's wal position / catalog xmin), or

Re: [HACKERS] [GENERAL] C++ port of Postgres

On 8/16/16 3:29 PM, Andres Freund wrote: Well, having typed pg_list.h style lists, ilist.h linked lists, hash-tables, and proper typechecks for pg_nodes.h instead of the NodeTag stuff, would surely make life easier. I certainly wish parts of the system brought code and "data" together in a

Re: [HACKERS] Wait events monitoring future development

Hi, On 2016-08-07 14:03:17 +0200, Ilya Kosmodemiansky wrote: > Wait event monitoring looks ones again stuck on the way through community > approval in spite of huge progress done last year in that direction. I see little evidence of that. If you consider "please do some reasonable benchmarks" as

Re: [HACKERS] [GENERAL] C++ port of Postgres

On 2016-08-16 16:59:56 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2016-08-16 13:40:06 -0700, Peter Geoghegan wrote: > >> Actually, come to think of it, I guess this is wrong. The problem with > >> what I say here is that longjmp() and setjmp() are incompatible with

Re: [HACKERS] WIP: Barriers

On Mon, Aug 15, 2016 at 6:55 AM, Robert Haas wrote: > A sort of dumb way of handling all this is to assume that once a > worker joins the hash join, it won't go off and do anything else until > the hash join is done. Under that assumption, you just need some sort > of

Re: [HACKERS] [GENERAL] C++ port of Postgres

On 8/16/16 12:53 PM, Joy Arulraj wrote: > The whole thing would make a lot more sense given a credible design > for error handling that keeps both languages happy. Well, getting so that we can at least compile in both systems would certainly increase the chances of somebody

Re: [HACKERS] Slowness of extended protocol

On 2016-07-31 17:57:12 -0400, Tom Lane wrote: > Andres Freund writes: > > FWIW, I've observed the same with (a bit) more complicated queries. A > > part of this is that the extended protocol simply does > > more. PQsendQueryGuts() sends Parse/Bind/Describe/Execute/Sync -

Re: [HACKERS] WIP: Barriers

On Mon, Aug 15, 2016 at 6:55 AM, Robert Haas wrote: > The simple version of this is that when a worker gets done with its > own probe phase for batch X, it can immediately start building the > hash table for phase X+1, stopping if it fills up the unused portion > of

Re: [HACKERS] Let's get rid of the separate minor version numbers for shlibs

Greg Stark writes: > It does rule out the possibility of having a minor bump in the soname > for a point-release, which as you point out wouldn't do much on Linux > but on other operating systems might be a useful thing. I believe we could legally set SO_MINOR_VERSION to, say,

Re: [HACKERS] PSA: Systemd will kill PostgreSQL

On Aug 16, 2016 4:43 PM, "Tom Lane" wrote: > > Peter Eisentraut writes: > > On 8/16/16 8:53 AM, Greg Stark wrote: > >> That's a system level change though. How would a normal user manage this? > > > Arguably, if you are a normal user, you

Re: [HACKERS] Index Onlys Scan for expressions

On Tue, Aug 16, 2016 at 9:09 AM, Oleg Bartunov wrote: > On Tue, Aug 16, 2016 at 1:03 AM, Ildar Musin > wrote: > > Hi, hackers! > > > > There is a known issue that index only scan (IOS) can only work with > simple > > index keys based on single

Re: [HACKERS] PSA: Systemd will kill PostgreSQL

On 8/16/16 8:53 AM, Greg Stark wrote: > That's a system level change though. How would a normal user manage this? Arguably, if you are a normal user, you probably shouldn't be using systemd to start system services under your own account. -- Peter Eisentraut

Re: [HACKERS] PSA: Systemd will kill PostgreSQL

Peter Eisentraut writes: > On 8/16/16 8:53 AM, Greg Stark wrote: >> That's a system level change though. How would a normal user manage this? > Arguably, if you are a normal user, you probably shouldn't be using > systemd to start system services under your own

Re: [HACKERS] [GENERAL] C++ port of Postgres

On 8/16/16 2:52 AM, Gavin Flower wrote: In both cases, part of the motivation to change from C was to appeal to new developers - from what I remember of the discussions. Moving this to -hackers. Original thread at [1]. tl;dr: A C++ port of Postgres has been created, and several folks on

Re: [HACKERS] [GENERAL] C++ port of Postgres

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Peter Geoghegan > I think that the best thing about C++ is the ability to encapsulate and > simplify some aspects of resource management quite well, which necessitates > reimplementing PG_TRY/CATCH.

Re: [HACKERS] anyelement -> anyrange

Jim Nasby writes: > I can't think of any reason you'd want two different range types on a > single element type. We would not have built it that way if there were not clear use-cases. An easy example is you might want both a continuous timestamp range and one that is

[HACKERS] Improve formatting of comments in plpgsql.h

I propose the attached patch to clean up the comment formatting in plpgsql.h. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services >From 1924c0d822b36af32556e49cd0a70da9ab5c87b2 Mon Sep 17 00:00:00 2001 From: Peter

Re: [HACKERS] Slowness of extended protocol

Andres Freund writes: > On 2016-07-31 17:57:12 -0400, Tom Lane wrote: >> Yeah. The extended query protocol was designed to offer a lot of >> functionality that people had asked for, like plan re-use and >> introspection of the data types assigned to query parameters, but that

Re: [HACKERS] [GENERAL] C++ port of Postgres

On 2016-08-16 12:59:24 -0400, Tom Lane wrote: > I'm pretty dubious that it really helps people > to develop extensions in C++. Almost invariably, if you ask *why* they > want to do that, you'll get an answer involving C++ libraries that are > not going to play very nice with our error handling or

Re: [HACKERS] [GENERAL] C++ port of Postgres

On 2016-08-17 10:45:25 +1000, dandl wrote: > From my particular perspective it would be enough if all the internal > headers (that one needs to use in writing server-side extensions) were > completely usable in C++. That should already be the case. There's even a dirty hack^WWscript that checks

Re: [HACKERS] Improve formatting of comments in plpgsql.h

Peter Eisentraut writes: > I propose the attached patch to clean up the comment formatting in > plpgsql.h. Looks reasonable in a quick once-over. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)

Re: [HACKERS] [GENERAL] C++ port of Postgres

On 2016-08-17 11:51:04 +1000, dandl wrote: > > > From my particular perspective it would be enough if all the > > internal > > > headers (that one needs to use in writing server-side extensions) > > were > > > completely usable in C++. > > > > That should already be the case. There's even a

Re: [HACKERS] [GENERAL] C++ port of Postgres

> > From my particular perspective it would be enough if all the > internal > > headers (that one needs to use in writing server-side extensions) > were > > completely usable in C++. > > That should already be the case. There's even a dirty hack^WWscript > that checks that that remains the case

Re: [HACKERS] Slowness of extended protocol

On 2016-08-16 21:40:32 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2016-07-31 17:57:12 -0400, Tom Lane wrote: > >> Yeah. The extended query protocol was designed to offer a lot of > >> functionality that people had asked for, like plan re-use and > >> introspection

Re: [HACKERS] [GENERAL] C++ port of Postgres

On 16 August 2016 at 17:08, Piotr Stefaniak wrote: > On 2016-08-16 18:33, Robert Haas wrote: >> It wouldn't be that much work to maintain, either: we'd >> just set up some buildfarm members that compiled using C++ and when >> they turned red, we'd go fix it. > > I

Re: [HACKERS] anyelement -> anyrange

On Tue, Aug 16, 2016 at 7:47 PM, Jim Nasby wrote: > On 8/15/16 10:12 PM, Tom Lane wrote: > >> Jim Nasby writes: >> >>> Any reason why we can create a function that accepts anyelement and >>> returns anyarray, but can't do the same with

Re: [HACKERS] [GENERAL] C++ port of Postgres

On 2016-08-16 18:52:39 +0300, Heikki Linnakangas wrote: > On 08/16/2016 05:47 PM, Jim Nasby wrote: > > I realize there's little technical reason why we *need* C++ support. The > > level if discipline applied to our codebase negates some of the benefits > > of C++. But maintaining the discipline

Re: [HACKERS] [GENERAL] C++ port of Postgres

On Tue, Aug 16, 2016 at 9:59 AM, Tom Lane wrote: > I think this might have advantages purely from the standpoint of new > compilers possibly offering useful warnings we don't get now. But > if we only go this far, I'm pretty dubious that it really helps people > to develop

Re: [HACKERS] [GENERAL] C++ port of Postgres

On Tue, Aug 16, 2016 at 1:29 PM, Peter Geoghegan wrote: > IMV, it would be useful to use C++ classes (and even template classes) > for a small number of data structures, while still largely adhering to > earlier practices (this is what GCC did). Specifically, a few modules > such

Re: [HACKERS] [GENERAL] C++ port of Postgres

On 2016-08-16 18:33, Robert Haas wrote: > It wouldn't be that much work to maintain, either: we'd > just set up some buildfarm members that compiled using C++ and when > they turned red, we'd go fix it. I think that there exist subtle differences between C and C++ that without compile-time

Re: [HACKERS] [GENERAL] C++ port of Postgres

On Tue, Aug 16, 2016 at 1:59 PM, Tom Lane wrote: >> FWIW, IIRC that's not true for gcc/glibc, because they IIRC use common >> codepaths. But obviously that's not all-encompassing enough to rely on that. > > I wonder whether it'd be possible to implement the PG_TRY/CATCH macros

Re: [HACKERS] WIP: Barriers

On Sat, Aug 13, 2016 at 4:18 PM, Thomas Munro wrote: > First, you initialise a Barrier object somewhere in shared memory, > most likely in the DSM segment used by parallel query, by calling > BarrierInit(, nworkers). Then workers can call > BarrierWait() when they

Re: [HACKERS] psql: tab completion for \l

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: tested, passed Documentation:tested, passed I did some tests and found nothing special. The stated

Re: [HACKERS] Patch: initdb: "'" for QUOTE_PATH (non-windows)

Hi, On 2016-08-14 10:12:45 -0500, Ryan Murphy wrote: > Hello Postgres Team! > but this command did not work for me because my data directory > contained a space. The src/bin/initdb/initdb.c source code > did already have a QUOTE_PATH constant, but it was the empty > string for non-windows cases.

Re: [HACKERS] Server crash due to SIGBUS(Bus Error) when trying to access the memory created using dsm_create().

On Wed, Aug 17, 2016 at 4:50 AM, Robert Haas wrote: > On Fri, Aug 12, 2016 at 9:22 PM, Thomas Munro > wrote: >> On Sat, Aug 13, 2016 at 8:26 AM, Thomas Munro >> wrote: >>> On Sat, Aug 13, 2016 at 2:08 AM, Tom

Re: [HACKERS] anyelement -> anyrange

On 8/15/16 10:12 PM, Tom Lane wrote: Jim Nasby writes: Any reason why we can create a function that accepts anyelement and returns anyarray, but can't do the same with anyrange? Because there can be more than one range type over the same element type, so we couldn't

Re: [HACKERS] Keeping CURRENT_DATE and similar constructs in original format

Peter Eisentraut writes: > On 5/12/16 6:14 PM, Tom Lane wrote: >> So what I've wanted to do for some time is invent a new expression node >> type that represents any one of these functions and can be reverse-listed >> in the same format that the input had. The

Re: [HACKERS] Patch: initdb: "'" for QUOTE_PATH (non-windows)

I've submitted my patch to Commitfest 2016-09. https://commitfest.postgresql.org/10/718/ My username on postgresql.org is murftown On Tue, Aug 16, 2016 at 1:02 AM, Ryan Murphy wrote: > Ok, I'll do that! > Thanks Michael! > Ryan > > > On Monday, August 15, 2016, Michael

Re: [HACKERS] Why we lost Uber as a user

On 8/2/16 10:02 PM, Mark Kirkwood wrote: On 03/08/16 02:27, Robert Haas wrote: Personally, I think that incremental surgery on our current heap format to try to fix this is not going to get very far. If you look at the history of this, 8.3 was a huge release for timely cleanup of dead

Re: [HACKERS] Why we lost Uber as a user

On 8/3/16 3:29 AM, Greg Stark wrote: Honestly the take-away I see in the Uber story is that they apparently had nobody on staff that was on -hackers or apparently even -general and tried to go it alone rather than involve experts from outside their company. As a result they misdiagnosed their

Re: [HACKERS] [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)

On 8/16/16 11:59 AM, Robert Haas wrote: ... That doesn't really solve the problem, because OTHER backends won't be able to see them. So, if I create a fast temporary table in one session that depends on a permanent object, some other session can drop the permanent object. If there were REAL

Re: [HACKERS] Why we lost Uber as a user

Something I didn't see mentioned that I think is a critical point: last I looked, HOT standby (and presumably SR) replays full page writes. That means that *any* kind of corruption on the master is *guaranteed* to replicate to the slave the next time that block is touched. That's completely

Re: [HACKERS] [GENERAL] C++ port of Postgres

On Tue, Aug 16, 2016 at 4:22 PM, Jim Nasby wrote: > On 8/16/16 12:53 PM, Joy Arulraj wrote: > >> > The whole thing would make a lot more sense given a credible design >> > for error handling that keeps both languages happy. >> >> Well, getting so that we can

Re: [HACKERS] [GENERAL] C++ port of Postgres

> Well, getting so that we can at least compile in both systems would > certainly increase the chances of somebody being willing to work on > such a design. >From my particular perspective it would be enough if all the internal headers >(that one needs to use in writing server-side extensions)

Re: [HACKERS] anyelement -> anyrange

On 8/16/16 6:56 PM, David G. Johnston wrote: On Tue, Aug 16, 2016 at 7:47 PM, Jim Nasby >wrote: On 8/15/16 10:12 PM, Tom Lane wrote: Jim Nasby writes: Any reason why we can create a

Re: [HACKERS] Patch: initdb: "'" for QUOTE_PATH (non-windows)

On Wed, Aug 17, 2016 at 8:05 AM, Andres Freund wrote: > ISTM that the correct fix would be to actually introduce something like > quote_path_for_shell() which either adds proper quotes, or fails if > that'd be hard (e.g. if the path contains quotes, and we're on > windows).

[HACKERS] support for NEXT VALUE FOR expression

Here is a patch for implementing the NEXT VALUE FOR expression. This is the SQL-standard conforming version of our nextval() function, and it's also used by Oracle, MS SQL, DB2. Example: SELECT NEXT VALUE FOR foo_seq; The second patch changes the serial column to use this new expression for

Re: [HACKERS] support for NEXT VALUE FOR expression

Peter Eisentraut writes: > Here is a patch for implementing the NEXT VALUE FOR expression. This is > the SQL-standard conforming version of our nextval() function, and it's > also used by Oracle, MS SQL, DB2. Example: We discussed this before and concluded

Re: [HACKERS] support for NEXT VALUE FOR expression

On Wed, Aug 17, 2016 at 3:52 PM, Tom Lane wrote: > Peter Eisentraut writes: >> Here is a patch for implementing the NEXT VALUE FOR expression. This is >> the SQL-standard conforming version of our nextval() function, and it's >> also used by

Re: [HACKERS] support for NEXT VALUE FOR expression

Thomas Munro writes: > On Wed, Aug 17, 2016 at 3:52 PM, Tom Lane wrote: >> We discussed this before and concluded that NEXT VALUE FOR is in fact >> *not* an exact semantic equivalent of nextval(): >>

Re: [HACKERS] LWLocks in DSM memory

On Tue, Aug 16, 2016 at 5:03 PM, Andres Freund wrote: > On 2016-08-15 18:15:23 -0400, Robert Haas wrote: >> On Thu, Aug 11, 2016 at 2:19 PM, Robert Haas wrote: >> > Therefore, I plan to commit this patch, removing the #include >> > unless someone

Re: [HACKERS] [RFC] Change the default of update_process_title to off

Robert Haas writes: > On Tue, Aug 16, 2016 at 5:53 AM, Magnus Hagander wrote: >> What's our take on backpatching such changes? Should this be 9.6 only, or >> back further? > I would have thought this was a master-only change, although > back-patching

Re: [HACKERS] Declarative partitioning - another take

On Tue, Aug 16, 2016 at 2:30 AM, Ashutosh Bapat < ashutosh.ba...@enterprisedb.com> wrote: > > > > >> I think it makes sense to keep calling it a table because it has all the >> logical properties of a table even though it will differ from a regular >> table on the basis of physical implementation

Re: [HACKERS] patch proposal

Greetings, * Venkata B Nagothi (nag1...@gmail.com) wrote: > The above said parameters can be configured to pause, shutdown or prevent > promotion only after reaching the recovery target point. > To clarify, I am referring to a scenario where recovery target point is not > reached at all ( i mean,

Re: [HACKERS] Slowness of extended protocol

Shay> your analogy breaks down. Of course L2 was invented to improve performance, Shay> but that doesn't mean that all caches are the same. More precisely, what I Shay> find objectionable about your approach is not any caching - it's the Shay> implicit or automatic preparation of statements. This

Re: [HACKERS] [PATCH] bigint txids vs 'xid' type, new txid_recent(bigint) => xid

On 16 August 2016 at 20:58, Greg Stark wrote: > On Tue, Aug 16, 2016 at 10:15 AM, Craig Ringer > wrote: > > I'm surprised the 32-bit xid was ever exposed to the user, rather than a > > 64-bit epoch-extended xid. > > Once upon a time we didn't have epoch

Re: [HACKERS] patch proposal

On 8/16/16 1:08 AM, Venkata B Nagothi wrote: > The issue here is, if by any chance, the required WALs are not available > or if there is any WAL missing or corrupted at the restore_command > location, then PostgreSQL recovers until the end of the last available > WAL and

Re: [HACKERS] [RFC] Change the default of update_process_title to off

On Tue, Aug 16, 2016 at 5:53 AM, Magnus Hagander wrote: > What's our take on backpatching such changes? Should this be 9.6 only, or > back further? I would have thought this was a master-only change, although back-patching it to 9.6 would be OK if it gets done RSN. I don't

Re: [HACKERS] Let's get rid of the separate minor version numbers for shlibs

On Mon, Aug 15, 2016 at 11:45 PM, Peter Eisentraut wrote: > If we instead installed > > libpq.so.5 (actual file) > libpq.so -> libpq.so.5 > > nothing would effectively change. It would make it impossible to have multiple versions installed. One doesn't normally

Re: [HACKERS] PSA: Systemd will kill PostgreSQL

On Tue, Aug 16, 2016 at 12:41 AM, Josh Berkus wrote: > Presumably people just need to add the system account tag to the unit > file, no? That's a system level change though. How would a normal user manage this? -- greg -- Sent via pgsql-hackers mailing list

Re: [HACKERS] [PATCH] bigint txids vs 'xid' type, new txid_recent(bigint) => xid

On Tue, Aug 16, 2016 at 10:15 AM, Craig Ringer wrote: > I'm surprised the 32-bit xid was ever exposed to the user, rather than a > 64-bit epoch-extended xid. Once upon a time we didn't have epoch counting at all. I don't think it would be a bad idea to clean up everything

Re: [HACKERS] [GENERAL] C++ port of Postgres

Jim Nasby wrote: My hope is that existing hackers can agree on a reasonable way forward and guide/assist new folks that are interested in walking that path. I tried this path. https://github.com/stalkerg/postgres_cpp And I fully support this desire. But I'm in the minority. I also like

Re: [HACKERS] [GENERAL] C++ port of Postgres

Well, well, well. Another C vs C++ holly war, really? > > In both cases, part of the motivation to change from C was to > > appeal to new developers - from what I remember of the > > discussions. > > Moving this to -hackers. Original thread at [1]. > > tl;dr: A C++ port of Postgres has been

Re: [HACKERS] [GENERAL] C++ port of Postgres

On 08/16/2016 05:47 PM, Jim Nasby wrote: I realize there's little technical reason why we *need* C++ support. The level if discipline applied to our codebase negates some of the benefits of C++. But maintaining the discipline takes a lot of time and effort, and makes it more difficult to attract

Re: [HACKERS] PSA: Systemd will kill PostgreSQL

Magnus Hagander writes: > On Aug 16, 2016 4:43 PM, "Tom Lane" wrote: >> Rather, the problem arises when J. Ordinary User does >> nohup postmaster & >> and then logs out. > I think this is a partially different issue though. They already broke the > nohup

Re: [HACKERS] PSA: Systemd will kill PostgreSQL

On Aug 16, 2016 5:11 PM, "Tom Lane" wrote: > > Magnus Hagander writes: > > On Aug 16, 2016 4:43 PM, "Tom Lane" wrote: > >> Rather, the problem arises when J. Ordinary User does > >> nohup postmaster & > >> and then logs out. > > > I

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

09.08.2016 19:45, Andrew Borodin: Here is new version of the patch, now it includes recommendations from Anastasia Lubennikova. I've investigated anamalous index size decrease. Most probable version appeared to be true. Cube extension, as some others, use Guttman's polynomial time split

Re: [HACKERS] PSA: Systemd will kill PostgreSQL

Magnus Hagander writes: > On Aug 16, 2016 5:11 PM, "Tom Lane" wrote: >> Dunno, it was still working the last time I used Fedora for anything much. >> Admittedly, that was about three years ago. But the issue would still >> arise if you prefer "pg_ctl

  1   2   >