On Sat, May 14, 2016 at 7:33 PM, Robert Haas wrote:
>
> On Tue, Mar 22, 2016 at 12:56 AM, Amit Kapila
wrote:
> >> >> Yes, same random number generation is not the problem. In windows
apart
> >> >> from EEXIST error, EACCES also needs to be validated and returned
for
> >> >> new random number gene
On Sun, May 15, 2016 at 10:22 AM, Anderson Carniel wrote:
> Thank you very much Joe.
>
> I have followed the crosstab() implementation and understood the idea of per
> query memory context. Now, I am using a unique SPI instance (which I perform
> several sql queries), process the result, transform
Jeff Janes writes:
> There are lots of improvement which get done to in-memory data
> structures that wouldn't require a pg_dump/pg_upgrade, which could in
> principle be ported into prior major versions if we had the resources
> (reviewing, testing, packaging) to do it, with an increase in the
>
On Sat, May 14, 2016 at 7:51 PM, Greg Sabino Mullane wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: RIPEMD160
>
>
>> Wasn't there some controversy about switching to major.minor versioning
>> this in -advocacy?
>>
>> http://www.postgresql.org/message-id/ee13fd2bb44cb086b457be34e81d5...@bigl
"Greg Sabino Mullane" writes:
> I think moving to a two-number format is a mistake: what exactly will
> PQserverVersion() return in that case?
For, say, 10.2 it would be 12, equivalent to 10.0.2 under old style.
We could redefine it as being major plus four-digit minor, really.
Under the cu
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> Wasn't there some controversy about switching to major.minor versioning
> this in -advocacy?
>
> http://www.postgresql.org/message-id/ee13fd2bb44cb086b457be34e81d5...@biglumber.com
I proposed in that thread that we always increment the first
Thank you very much Joe.
I have followed the crosstab() implementation and understood the idea of
per query memory context. Now, I am using a unique SPI instance (which I
perform several sql queries), process the result, transform my result into
a tuplestore, close the SPI and done. It works perfe
On 05/13/2016 07:18 PM, Mark Dilger wrote:
> My main concern is that a commitment to never, ever break backwards
> compatibility is a commitment to obsolescence. It therefore makes sense to
> reserve room in the numbering scheme to be clear and honest about when
> backwards compatibility has been
[ getting back to a complaint I made in December ]
I wrote:
> ... the pg_dump process has crashed with a SIGPIPE without printing
> any message whatsoever, and without coming anywhere near finishing the
> dump.
> A bit of investigation says that this is because somebody had the bright
> idea that
I wrote:
> If it's just a quick kill, then there's a totally separate bug here for
> Windows. What is likely to happen with the current coding is that a
> failing child thread will queue its error message into the communication
> pipe, and then exit(1), thereby killing the whole pg_dump process be
On Fri, May 13, 2016 at 08:55:20PM -0400, David G. Johnston wrote:
> The opinion seems to be that major.0 is some kind of magic incantation in
> the broader world of users...
>From my reading of the thread, while certainly that is the general
definition of a .0, having infrequent .0 releases is no
On Fri, May 13, 2016 at 05:31:00PM -0400, David G. Johnston wrote:
> The underlying premise, for me, of choosing .4 or .5 was that presently we
> discontinue support after 5 years/releases. A new .0 would come out just
> as we discontinue the previous .0
Well maybe the 5 year support cycle would
These raw tps suggest that {backend,bgwriter}_flush_after should better be
zero for this kind of load.Whether it should be the default is unclear yet,
because as Andres pointed out this is one kind of load.
FWIW, I don't think {backend,bgwriter} are the same here. It's primarily
backend that m
+1 for going with 10.0 after 9.6 and 11.0 afterwards, etc.
It will hopefully both end these discussions and remove the confusion
the current versioning scheme has (I too heard way to many times about
people using postgres8 or postgres9).
For those saying this is version inflation. I don't see
El 13/05/16 a las 15:36, Josh berkus escribió:
> On 05/13/2016 11:31 AM, Alvaro Herrera wrote:
>> Josh berkus wrote:
>>
>>> Anyway, can we come up with a consensus of some minimum changes it will
>>> take to make the next version 10.0?
>>
>> I think the next version should be 10.0 no matter what
El 13/05/16 a las 15:31, Alvaro Herrera escribió:
> Josh berkus wrote:
>
>> Anyway, can we come up with a consensus of some minimum changes it will
>> take to make the next version 10.0?
>
> I think the next version should be 10.0 no matter what changes we put
> in.
+1
And another +1 on Tom's
Rather belatedly, I've started to look into a fix for pg_dump's
problem with error reporting in parallel mode:
http://www.postgresql.org/message-id/2458.1450894...@sss.pgh.pa.us
One of the issues here is that pg_dump uses threads not subprocesses
to do parallelism on Windows, which means that tota
On 2016-05-14 18:49:27 +0200, Fabien COELHO wrote:
>
> Hello,
>
> > Please find the results for the following 3 scenarios with unpatched master:
> >
> > 1. Default settings for *_flush_after : TPS = *10677.662356*
> > 2. backend_flush_after=0, rest defaults : TPS = *18452.655936*
> > 3. backend_
Hello,
Please find the results for the following 3 scenarios with unpatched master:
1. Default settings for *_flush_after : TPS = *10677.662356*
2. backend_flush_after=0, rest defaults : TPS = *18452.655936*
3. backend_flush_after=0, bgwriter_flush_after=0,
wal_writer_flush_after=0, checkpoint
On 05/13/2016 09:35 PM, Anderson Carniel wrote:
> I am writing a function that returns a set of tuples by using also the
> PostGIS. Thuis, I am using SRF too. It successfully returns the expected
> result when it has at most 4 tuples. However, this is not the case when
> more than 4 tuples have to
On 05/14/2016 07:08 AM, Robert Haas wrote:
On Fri, May 13, 2016 at 8:00 PM, Tom Lane wrote:
Any project that starts inflating its numbering scheme sends a message to
users of the form, "hey, we've just been taken over by marketing people, and
software quality will go down from now on."
I don'
On Fri, May 13, 2016 at 11:39 AM, Tom Lane wrote:
> Robert Haas writes:
>> There is a long-running thread on pgsql-hackers on whether 9.6 should
>> instead be called 10.0.
>
> First I've seen it mentioned here.
>
> I think you are just about exactly one week too late to bring this up.
> Once we'v
On Fri, May 13, 2016 at 8:00 PM, Tom Lane wrote:
>> Any project that starts inflating its numbering scheme sends a message to
>> users of the form, "hey, we've just been taken over by marketing people, and
>> software quality will go down from now on."
>
> I don't think this is about version numbe
On Mon, May 9, 2016 at 3:17 AM, Michael Paquier
wrote:
> On Tue, Mar 22, 2016 at 1:56 PM, Amit Kapila wrote:
>> So as far as I can see there are two ways to resolve this issue, one is to
>> retry generation of dsm name if CreateFileMapping returns EACCES and second
>> is to append data_dir name t
On Tue, Mar 22, 2016 at 12:56 AM, Amit Kapila wrote:
>> >> Yes, same random number generation is not the problem. In windows apart
>> >> from EEXIST error, EACCES also needs to be validated and returned for
>> >> new random number generation, instead of throwing an error.
>> >
>> > Doing the same
Hi,
Please find the results for the following 3 scenarios with unpatched master:
1. Default settings for *_flush_after : TPS = *10677.662356*
2. backend_flush_after=0, rest defaults : TPS = *18452.655936*
3. backend_flush_after=0, bgwriter_flush_after=0,
wal_writer_flush_after=0, checkpoint_flush
On 05/14/2016 12:10 PM, Andreas Seltenreich wrote:
Konstantin Knizhnik writes:
Latest information from ISP RAS guys: them have made good progress
since February: them have rewritten most of methods of Scan, Aggregate
and Join to LLVM API.
Is their work available somewhere? I'm experimenting i
Re: Álvaro Hernández Tortosa 2016-05-14 <5736f966.3040...@8kdata.com>
> Having said that, I believe having a single major number is a more
> effective marketing. Non major-major versions may make the release look like
> a "probably not worth" upgrade. People may hold their breath until a
> majo
On 14/05/16 02:00, Tom Lane wrote:
[...]
I don't think this is about version number inflation, but actually more
the opposite. What you're calling the major number is really a marketing
number. There is not a technical distinction between major releases where
we choose to bump the first numb
Konstantin Knizhnik writes:
> Latest information from ISP RAS guys: them have made good progress
> since February: them have rewritten most of methods of Scan, Aggregate
> and Join to LLVM API.
Is their work available somewhere? I'm experimenting in that area as
well, although I'm using libFirm
30 matches
Mail list logo
