From: https://www.postgresql.org/docs/9.4/static/sql-createtable.html
"The access method must support amgettuple (see Chapter 55); at
present this means GIN cannot be used. Although it's allowed, there is
little point in using B-tree or hash indexes with an exclusion
constraint, because this does
On Wed, Aug 17, 2016 at 11:51 AM, Amit Langote <
langote_amit...@lab.ntt.co.jp> wrote:
> On 2016/08/17 14:33, Ashutosh Bapat wrote:
> >> +relid_is_partition(Oid relid)
> >> +{
> >> + return SearchSysCacheExists1(PARTRELID,
> ObjectIdGetDatum(relid));
> >> +}
> >>
> >> This is used in a lot o
On 2016/08/17 14:33, Ashutosh Bapat wrote:
>> +relid_is_partition(Oid relid)
>> +{
>> + return SearchSysCacheExists1(PARTRELID, ObjectIdGetDatum(relid));
>> +}
>>
>> This is used in a lot of places, and the overhead of checking it in
>> all of those places is not necessarily nil. Syscache lo
On 17 August 2016 at 05:18, Andres Freund wrote:
> 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
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 resour
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 resour
> +relid_is_partition(Oid relid)
> +{
> + return SearchSysCacheExists1(PARTRELID, ObjectIdGetDatum(relid));
> +}
>
> This is used in a lot of places, and the overhead of checking it in
> all of those places is not necessarily nil. Syscache lookups aren't
> free. What if we didn't create a n
On 17 August 2016 at 08:36, Jim Nasby wrote:
> 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.
Yes, that's right, all WAL-based physical replication replays FPWs.
We could, at the cost of increased WA
On 17 August 2016 at 09:49, Andres Freund wrote:
>
> You need to include the files surrounded by extern "C" { }.
>
I'd really like to adopt the convention used by many libraries etc of doing
this automatically - detecting a c++ compiler in the preprocessor and
wrapping in "extern "C"" .
Having
On Wed, Aug 17, 2016 at 12:06 AM, Stephen Frost wrote:
> 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 sce
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.
BTW, several of the earlier threads complained of needing to make NEXT
a fully-reserved
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():
>> https://www.postgresql.org/message-id/14790.1083955136%40sss.pgh.pa.us
> And also again 10 years
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 Oracle, MS SQL, DB2. Example:
>
> We discussed this b
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 that NEXT VALUE FOR is in fact
*not* a
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 its
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 convinces me we need it, shortly after
>> > devel
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).
You are looking for ap
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 of the data types ass
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 dirty
> > 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
>
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
>> doesn't come at z
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)
To make changes to your subscriptio
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 Eise
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 quantized to hour boundaries
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.
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 t
On 8/16/16 6:56 PM, David G. Johnston wrote:
On Tue, Aug 16, 2016 at 7:47 PM, Jim Nasby mailto:jim.na...@bluetreble.com>>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
> 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)
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 at least compile in both s
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 the
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 attached proposed patch does
>> that
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 cat
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 anyrange?
>>>
>>
>> Because there can be more than one range
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 deduce which one should be
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 Lane wrote:
amul sul writes:
> When I am calling dsm_create on Linux using t
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
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 tuple.
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 think that there exist subtle dif
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.
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 Paquier
> wrote:
>
>> O
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(&barrier, nworkers). Then workers can call
> BarrierWait(&barrier) when they want to block un
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 BarrierAttach() operation; w
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 work_mem before the old hash ta
>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 va
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 y
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
> >> the stack unwind
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
> to use C++ excepti
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 diagno
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 are objections before then
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 general (exceptions are
>
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
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 practices (this is what G
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 bet
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 - that's
> > simply more wor
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 as StringInfo, co
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
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 thr
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 extensions in C++. Alm
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 tak
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 partition using DROP TABLE causes a
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 being
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.
> Um,
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 discipline takes a lot
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 t
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 when I saw the earlier ones
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
+Partitioned table "public.desc
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 seems certain that this indicates a bug introduc
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 (
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 don
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:
>
> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=grouse&dt=2016-08-16%2008%3A39%3A0
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? In other words, m
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 Eisen
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 Deve
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&dt=2016-08-16%2008%3A39%3A03
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=nu
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 entirely, such as Rust, but I do think it would make
> >> sense to write o
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 good idea for
af33039317dd
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 entirely, such as Rust, but I do think it would make
>> sense to write our code so that it can be compiled using either a C
>> compiler
Peter Eisentraut writes:
> A brief look through the code and some reading between the lines of the
> documentation shows that it only cleans up shared memory segments that
> are no longer attached to, but there is no such check for semaphores.
Oh, interesting. It had occurred to me that we might
Andres Freund wrote:
> Phew. Alvaro, are you tackling this?
Sure.
Marko Tiikkaja wrote:
> There's a rolled back subtransaction that also did some magic on the rows
> AFAICT. I can try and spend some time producing a smaller test case over
> the weekend. No hurry since this missed the today's
Robert Haas writes:
> I'm not really interested in supporting PostgreSQL code written in
> other languages entirely, such as Rust, but I do think it would make
> sense to write our code so that it can be compiled using either a C
> compiler or a C++ compiler. Even if we don't ever use any C++ cod
On Mon, Aug 15, 2016 at 5:12 AM, Aleksander Alekseev
wrote:
> Just to keep things sane I would like to remind that in this concrete
> patch there _are_ catalog entries:
>
> ```
> [...]
> This file contents imlementation of special type of temporary tables ---
> fast temporary tables (FTT). From us
On 08/16/2016 09:33 AM, Robert Haas wrote:
On Tue, Aug 16, 2016 at 10:47 AM, Jim Nasby wrote:
On 8/16/16 2:52 AM, Gavin Flower wrote:
I agree with your statement that one of our biggest problems is
getting more developers interested in working on PostgreSQL. Even if
there's only a 10% chanc
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 Lane wrote:
>>> amul sul writes:
When I am calling dsm_create on Linux using the POSIX DSM implementation
can succeed, but result in S
On 8/16/16 11:24 AM, Tom Lane wrote:
> Not sure I believe that --- the cases that have been reported to us
> involved postgres processes that were still alive but had had their
> SysV semaphore sets deleted out from under them. Likely the SysV
> shmem segments too, but that wouldn't cause any obse
On Tue, Aug 16, 2016 at 10:47 AM, Jim Nasby wrote:
> 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++
On 2016-08-11 11:01:18 +0200, Marko Tiikkaja wrote:
> On 11/08/16 8:48 AM, Michael Paquier wrote:
> > On Thu, Aug 11, 2016 at 8:09 AM, Marko Tiikkaja wrote:
> > > On 2016-08-11 12:09 AM, Alvaro Herrera wrote:
> > > >
> > > > BTW this is not a regression, right? It's been broken all along. Or am
Aleksander Alekseev wrote:
You are right, there is none.
First: trees in parser, planer and etc.
Second: normal exception.
Two big projects lately move to C++ from C:
GCC, Mesa
You can read their reasons.
Only C++ we can use without full rewrite currently. (or ObjectC maybe)
If we wish fix C
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
On Tue, Aug 16, 2016 at 5:24 PM, Tom Lane wrote:
> 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 y
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 cr
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 start".
> There are two independent changes
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
algorit
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 the
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 think this is a partially different issue though. They already
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 approach earlier with a different change,
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
gener
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 probably shouldn't be using
> > systemd to start system se
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 account.
I'm not totally sure, but
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 http://www.2ndQuadrant.c
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, 10.1 if we had to
(
1 - 100 of 118 matches
Mail list logo