> 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 s
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 the number of parallel work
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
> >> not very clear what was gained by brea
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 compat
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
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 who uses
>> Windows want to deal with it? Or at
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 regular basis (as best I can
> >> tell, no such changes have been made since
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
> doesn'
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 starts-u
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
think changing GUC def
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 have multiple versions with the sam
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 (pgsql-hackers@postgresql.org)
To
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 to do with
xids so that
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 it to 9.6 would be OK if it gets done RSN. I
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 counting at all.
>
Makes sense. I didn't
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
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,
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 p
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
(
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
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 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
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
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 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
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
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
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
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
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
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
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 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
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 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 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 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 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
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
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
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
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
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 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
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 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
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 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 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-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 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 (
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 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
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
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
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
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,
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 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 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 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
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 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
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-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 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-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
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
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
>
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
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 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 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 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
>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 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
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 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
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
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.
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
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 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 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/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 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/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
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
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
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
> 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 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
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
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.
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
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
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
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
> > 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
>
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
1 - 100 of 118 matches
Mail list logo