On Sat, Apr 26, 2014 at 9:16 PM, Tom Lane wrote:
> Peter Geoghegan writes:
>> Backend fsyncs are theoretically still possible after the fsync
>> request queue compaction patch (which was subsequently back-patched to
>> all supported release branches). However, I'm reasonably confident
>> that tha
Peter Geoghegan writes:
> Backend fsyncs are theoretically still possible after the fsync
> request queue compaction patch (which was subsequently back-patched to
> all supported release branches). However, I'm reasonably confident
> that that patch was so effective as to make a backend fsync all
Greg Stark writes:
> On Sat, Apr 26, 2014 at 6:39 PM, Atri Sharma wrote:
>> Without sorting, isnt the scope of a recursive UNION with custom datatypes
>> pretty restrictive?
> All the default data types are hashable. It's not hard to add a hash
> operator class. In a clean slate design it would
Backend fsyncs are theoretically still possible after the fsync
request queue compaction patch (which was subsequently back-patched to
all supported release branches). However, I'm reasonably confident
that that patch was so effective as to make a backend fsync all but
impossible. As such, it seems
On Sat, Apr 26, 2014 at 8:58 PM, Josh Berkus wrote:
> However, there's a fundamental problem with the concept of the dataset
> ID in that there's absolutely no way for PostgreSQL to know when it has
> a unique dataset. Consider a downtime database file cloning for
> example; the two databases wou
Alfred,
* Alfred Perlstein (alf...@freebsd.org) wrote:
> JFYI we have 3 or 4 machines racked for the pgsql project in our DC.
Oh, great!
> Tom informed me he would be lighting them up this week time permitting.
Excellent, many thanks!
Stephen
signature.asc
Description: Digital sig
On Sat, Apr 26, 2014 at 6:39 PM, Atri Sharma wrote:
> Without sorting, isnt the scope of a recursive UNION with custom datatypes
> pretty restrictive?
All the default data types are hashable. It's not hard to add a hash
operator class. In a clean slate design it would probably have been
simpler t
JFYI we have 3 or 4 machines racked for the pgsql project in our DC.
Tom informed me he would be lighting them up this week time permitting.
Sent from my iPhone
> On Apr 26, 2014, at 6:15 PM, Stephen Frost wrote:
>
> Jim,
>
> * Jim Nasby (j...@nasby.net) wrote:
>>> On 4/22/14, 5:01 PM, Alf
Jim,
* Jim Nasby (j...@nasby.net) wrote:
> On 4/22/14, 5:01 PM, Alfred Perlstein wrote:
> >We also have colo space and power, etc. So this would be the whole deal.
> >The cluster would be up for as long as needed.
> >
> >Are the machine specs sufficient? Any other things we should look for?
>
On 4/26/14, 1:27 PM, Andres Freund wrote:
I don't think we need to decide this without benchmarks proving the
benefits. I basically want to know whether somebody has an actual
usecase - even if I really, really, can't think of one - of setting
max_connections even remotely that high. If there's s
On 4/17/14, 6:42 PM, Josh Berkus wrote:
So we have some software we've been procrastinating on OSS'ing, which does:
1) Takes full query CSV logs from a running postgres instance
2) Runs them against a target instance in parallel
3) Records response times for all queries
Is that the stuff you'd
On 4/22/14, 5:01 PM, Alfred Perlstein wrote:
Hey folks, I just spoke with our director of netops Tom Sparks here at Norse
and we have a vested interest in Postgresql. We can throw together a cluster
of 4 machines with specs approximately in the range of dual quad core westmere
with ~64GB of
On 4/25/14, 12:58 PM, Josh Berkus wrote:
Well, I've already had collisions with UUID-OSSP, in production, with
only around 20 billion values. So clearly there aren't 122bits of true
randomness in OSSP. I can't speak for other implementations because I
haven't tried them.
Or perhaps you should
On Sat, Apr 26, 2014 at 1:58 PM, Peter Geoghegan wrote:
> The 2Q paper also suggests a correlated reference period.
I withdraw this. 2Q in fact does not have such a parameter, while
LRU-K does. But the other major system I mentioned very explicitly has
a configurable delay that serves this exact
=?utf-8?B?VmxhZGltaXIgS29rb3ZpxIc=?= writes:
> Thanks Tom, postgresql source now belongs to user 'postgres' and make
> check-world passed.
> But, installcheck-world failed:
installcheck-world is supposed to test against an installed, running
server. So you need to do "make install-world" (not
On Sat, Apr 26, 2014 at 1:30 PM, Noah Misch wrote:
> Sure, let's not actually commit a patch to impose this limit until the first
> change benefiting from doing so is ready to go. There remains an opportunity
> to evaluate whether that beneficiary change is better done a different way.
> By havin
Noah Misch writes:
> On Sat, Apr 26, 2014 at 11:20:56AM -0400, Tom Lane wrote:
>> While I agree with you that it seems somewhat unlikely we'd ever get
>> past 2^16 backends, these arguments are not nearly good enough to
>> justify a hard-wired limitation.
> I'm satisfied with the arguments Andres
Hi,
Thanks Tom, postgresql source now belongs to user 'postgres' and make
check-world passed.
But, installcheck-world failed:
tail /home/src/postgresql-devel/dev-build/make-install-out-dev.log
../../../src/test/regress/pg_regress
--inputdir=/home/src/postgresql-devel/postgresql-git/postgr
Tomas Vondra writes:
> On 25.4.2014 23:26, Tom Lane wrote:
>> The problem is that the CREATE AGGREGATE syntax only specifies the
>> name of the final function, not its argument list, so you have to
>> make an assumption about the argument list in order to look up the
>> final function in the fi
On Sat, Apr 26, 2014 at 11:20:56AM -0400, Tom Lane wrote:
> Andres Freund writes:
> > What I think it's necessary for is at least:
>
> > * Move the buffer content lock inline into to the buffer descriptor,
> > while still fitting into one cacheline.
> > * lockless/atomic Pin/Unpin Buffer.
>
>
On 25.4.2014 23:26, Tom Lane wrote:
> Tomas Vondra writes:
>> On 23.4.2014 16:07, Tom Lane wrote:
>>> To be concrete: let's add a new boolean parameter with the
>>> semantics of "final function takes extra dummy arguments"
>>> (default false). There would need to be one for the separate
>>> mov
On 2014-04-26 13:16:38 -0700, Josh Berkus wrote:
> However, I agree with Tom that Andres should "show his hand" before we
> decrease MAX_BACKENDS by 256X.
I just don't want to invest time in developing and benchmarking
something that's not going to be accepted anyway. Thus my question.
Greetings,
On 04/26/2014 11:06 AM, David Fetter wrote:
> I know we allow for gigantic numbers of backend connections, but I've
> never found a win for >2x the number of cores in the box, which at
> least in my experience so far tops out in the 8-bit (in extreme cases
> unsigned 8-bit) range.
For my part, I'v
On 04/25/2014 11:46 AM, David Fetter wrote:
> On Fri, Apr 25, 2014 at 10:58:29AM -0700, Josh Berkus wrote:
>> You may say "oh, that's not the job of the identifer", but if it's not,
>> WTF is the identifer for, then?
>
> Frequently, it's to provide some kind of opacity in the sense of not
> have a
On 04/26/2014 11:18 AM, Tom Lane wrote:
> It's worth noting in this connection that we've never tried hard to ensure
> that "database identifiers" are actually unique. One potentially serious
> issue is that slave servers will have the same identifier as their master.
Yeah, this is one of those t
Bruce Momjian writes:
> On Mon, Jul 22, 2013 at 07:32:20PM -0400, Tom Lane wrote:
>> We could for instance keep the high half as tv_sec, while making the low
>> half be something like (tv_usec << 12) | (getpid() & 0xfff). This would
>> restore the intended ability to reverse-engineer the exact cr
=?utf-8?B?VmxhZGltaXIgS29rb3ZpxIc=?= writes:
> PostgreSQL build failed with current GIT source.
Works for me ...
> pg_regress: could not open file
> "/home/src/postgresql-devel/postgresql-git/postgresql/src/test/regress/sql/security_label.sql"
>
> for writing: Permission denied
> make[2]: *
On 2014-04-26 11:22:39 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-04-26 05:40:21 -0700, David Fetter wrote:
> >> Out of curiosity, where are you finding that a 32-bit integer is
> >> causing problems that a 16-bit one would solve?
>
> > Save space? For one it allows to shrink some
On 2014-04-26 11:20:56 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-04-26 11:52:44 +0100, Greg Stark wrote:
> >> But I don't think it's beyond the realm of possibility
> >> that we'll reduce the overhead in the future with an eye to being able
> >> to do that. Is it that helpful that
Martijn van Oosterhout writes:
> On Fri, Apr 25, 2014 at 04:18:18PM +0100, Greg Stark wrote:
>> Which isn't to say they're a bad idea but like everything else in
>> engineering there are tradeoffs and no such thing as a free lunch.
>> You can avoid depleting the entropy pool by including data you
On Sat, Apr 26, 2014 at 11:20:56AM -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-04-26 11:52:44 +0100, Greg Stark wrote:
> >> But I don't think it's beyond the realm of possibility
> >> that we'll reduce the overhead in the future with an eye to being able
> >> to do that. Is it that
On Fri, Apr 25, 2014 at 04:18:18PM +0100, Greg Stark wrote:
> Which isn't to say they're a bad idea but like everything else in
> engineering there are tradeoffs and no such thing as a free lunch.
> You can avoid depleting the entropy pool by including data you expect
> to be unique as a kind of fa
Hi,
PostgreSQL build failed with current GIT source.
tail /home/src/postgresql-devel/dev-build/make-out-dev.log
cp ../../../contrib/dummy_seclabel/dummy_seclabel.so dummy_seclabel.so
rm -rf ./testtablespace
mkdir ./testtablespace
../../../src/test/regress/pg_regress
--inputdir=/home/src/postgr
The plain UNION code supports either sorting or hashing, but
> we've not gotten around to supporting a sort-based approach
> to recursive UNION. I'm not convinced that it's worth doing ...
>
> regards, tom lane
>
>
>
Without sorting, isnt the scope of a recursive UNION with
I wrote:
> Christoph Berg writes:
>> $ grep -r include 9.4/server/common/ | grep \"
>> 9.4/server/common/fe_memutils.h:#include "utils/palloc.h"
>> 9.4/server/common/relpath.h:#include "catalog/catversion.h" /* pgrminclude
>> ignore */
>> 9.4/server/common/relpath.h:#include "storage/relfilenode.
Greg Stark writes:
> Not sure what other encodings you mean. Psql uses utf8 for the border and
> the test uses utf8 to test the formatting. I was only anticipating an error
> on platforms where that didn't work.
Well, there are two likely misbehaviors if the regression test is being
run in some o
Not sure what other encodings you mean. Psql uses utf8 for the border and
the test uses utf8 to test the formatting. I was only anticipating an error
on platforms where that didn't work.
I would lean towards having it but I'm fine following your judgement,
especially given the timing.
--
greg
Andres Freund writes:
> On 2014-04-26 05:40:21 -0700, David Fetter wrote:
>> Out of curiosity, where are you finding that a 32-bit integer is
>> causing problems that a 16-bit one would solve?
> Save space? For one it allows to shrink some structs (into one
> cacheline!).
And next week when we n
Andres Freund writes:
> On 2014-04-26 11:52:44 +0100, Greg Stark wrote:
>> But I don't think it's beyond the realm of possibility
>> that we'll reduce the overhead in the future with an eye to being able
>> to do that. Is it that helpful that it's worth baking in more
>> dependencies on that limit
Greg Stark writes:
> I expect this regression test to fail on platforms that don't support
> utf-8 client-side (I'm assuming we such things?). I don't have such a
> platform here and I'm not sure how it would fail so I want to go ahead
> and apply it and grab the output to add the alternate output
Christoph Berg writes:
> internal/postgres_fe.h includes
> common/fe_memutils.h which includes
> utils/palloc.h
Hm. It seems rather fundamentally broken to me that frontend code is
including palloc.h --- that file was never intended to be frontend-safe,
and the #ifdefs that I see in it tod
David Fetter writes:
> On Fri, Apr 25, 2014 at 04:47:49PM -0700, Paul Ramsey wrote:
>> ERROR: could not implement recursive UNION
>> DETAIL: All column datatypes must be hashable.
> This leads to an interesting question, which is why does our
> implementation require this. I'm guessing it's a
On 2014-04-26 05:40:21 -0700, David Fetter wrote:
> On Sat, Apr 26, 2014 at 12:15:40AM +0200, Andres Freund wrote:
> > Hi,
> >
> > Currently the maximum for max_connections (+ bgworkers + autovacuum) is
> > defined by
> > #define MAX_BACKENDS0x7f
> > which unfortunately means that some thi
On 2014-04-26 11:52:44 +0100, Greg Stark wrote:
> On Fri, Apr 25, 2014 at 11:15 PM, Andres Freund
> wrote:
> > Since there's absolutely no sensible scenario for setting
> > max_connections that high, I'd like to change the limit to 2^16, so we
> > can use a uint16 in BufferDesc->refcount.
>
> Cl
On Sat, Apr 26, 2014 at 12:15:40AM +0200, Andres Freund wrote:
> Hi,
>
> Currently the maximum for max_connections (+ bgworkers + autovacuum) is
> defined by
> #define MAX_BACKENDS0x7f
> which unfortunately means that some things like buffer reference counts
> need a full integer to store
Debian is shipping client headers in /usr/include/postgresql in the
libpq-dev package. The server headers go into
/usr/include/postgresql//server in postgresql-server-dev-,
so we can have the headers for several majors installed in parallel.
Historically, a few server headers were also included in
On Fri, Apr 25, 2014 at 04:47:49PM -0700, Paul Ramsey wrote:
> When trying to write a recursive CTE using the PostGIS geometry type,
> I was told this:
>
> ERROR: could not implement recursive UNION
> DETAIL: All column datatypes must be hashable.
This leads to an interesting question, which is
On Fri, Apr 25, 2014 at 11:15 PM, Andres Freund wrote:
> Since there's absolutely no sensible scenario for setting
> max_connections that high, I'd like to change the limit to 2^16, so we
> can use a uint16 in BufferDesc->refcount.
Clearly there's no sensible way to run 64k backends in the curren
48 matches
Mail list logo
