On 08/27/2011 06:56 PM, Greg Sabino Mullane wrote:
Once these new flags and the ability to custom format dump pg_dumpall
is done, I'll have very little left to complain about with pg_dump :)
It's off topic. But I think custom format would require a major mangling
to be able to handle a co
On Sat, Aug 27, 2011 at 1:38 AM, Gokulakannan Somasundaram
wrote:
> First i respectfully disagree with you on the point of 80MB. I would say
> that its very rare that a small system( with <1 GB RAM ) might have a long
> running transaction sitting idle, while 10 million transactions are sitting
>
I was able to obtain access to a 32-core HP-UX server. I repeated the
pgbench -S testing that I have previously done on Linux, and found
that the results were not too good. Here are the results at scale
factor 100, on 9.2devel, with various numbers of clients. Five minute
runs, shared_buffers=8G
On Sat, Aug 27, 2011 at 7:43 AM, Dean Rasheed wrote:
> On 27 August 2011 12:29, Dean Rasheed wrote:
>> ... if nothing else it has been a
>> fun exercise figuring out how the datetime string parsing code works.
>
> While looking through the current code, I spotted the following oddity:
>
> select
On Sat, Aug 27, 2011 at 3:30 PM, Tom Lane wrote:
> Daniel Farina writes:
>> On Sat, Aug 27, 2011 at 1:51 PM, Tom Lane wrote:
>>> A more long-range point about it is that the next time we make a
>>> protocol version bump that affects the format of error messages,
>>> the problem comes right back.
Greetings,
On Saturday, August 27, 2011 11:36:13 AM Dean Rasheed wrote:
>
> I'm not sure how best to handle timezones though, since it's
> hard-coded list probably won't match the timezones PostgreSQL knows
> about. Maybe that doesn't matter, I'm not sure.
>
It'll matter when the expression has
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> Well, notwithstanding my well known love of perl, that strikes me as
> spending a pound to save a penny. And custom format dumps rock ;-) Also,
> your recipe above is buggy, BTW. A CREATE INDEX statement might well not
> be the first item i
Daniel Farina writes:
> On Sat, Aug 27, 2011 at 1:51 PM, Tom Lane wrote:
>> A more long-range point about it is that the next time we make a
>> protocol version bump that affects the format of error messages,
>> the problem comes right back. It'd be better if the message somehow
>> indicated tha
On Sat, Aug 27, 2011 at 1:51 PM, Tom Lane wrote:
> A more long-range point about it is that the next time we make a
> protocol version bump that affects the format of error messages,
> the problem comes right back. It'd be better if the message somehow
> indicated that the server hadn't made any
I wrote:
> Magnus Hagander writes:
>> On Sat, Aug 27, 2011 at 01:59, Tom Lane wrote:
>>> Now, seeing as how NEGOTIATE_SSL_CODE has been understood by every build
>>> since PG 7.0, I believe that this is dead code and we could remove it;
>>> it seems exceedingly unlikely that any modern build of l
I wrote:
> Lastly, I noticed that if I tried this repeatedly on a Unix socket,
> I sometimes got
> psql: server closed the connection unexpectedly
> This probably means the server terminated abnormally
> before or while processing the request.
> could not send startup packet: Broke
On mån, 2011-08-22 at 04:09 +, YAMAMOTO Takashi wrote:
> i know that postgresql uses ts=4 for C source code.
> but how about documatation?
I'd say ideally don't use any tabs at all.
> src/backend/access/transam/README seems to have both of
> ts=4 and ts=8 mixed.
It appears to be geared for t
Peter Eisentraut writes:
> EXPLAIN SELECT * FROM test1 WHERE sha1 in (SELECT sha1 FROM test2);
> QUERY PLAN
> --
> Hash Semi Join (cost=30.52..61.27 rows=1000 width=27)
>Hash Cond: (test1.sha1
Magnus Hagander writes:
> On Sat, Aug 27, 2011 at 01:59, Tom Lane wrote:
>> Now, seeing as how NEGOTIATE_SSL_CODE has been understood by every build
>> since PG 7.0, I believe that this is dead code and we could remove it;
>> it seems exceedingly unlikely that any modern build of libpq will ever
Peter Eisentraut writes:
>> Avoid locale dependency in expected output.
>>
>> We'll have to settle for just listing the extensions' data types,
>> since function arguments seem to sort differently in different locales.
>> Per buildfarm results.
> This could probably be worked around by using COL
2011/8/26 Albe Laurenz :
> I wrote:
>> I wrote a FDW for Oracle to a) learn some server coding
>> and b) see how well the FDW API works for me.
>
> I have released the software on PgFoundry:
> http://oracle-fdw.projects.postgresql.org/
>
> Would it make sense to mention that in chapter 5.10
> of th
On 27 August 2011 14:29, Jeff MacDonald wrote:
> Greetings,
>
> On Thursday, August 25, 2011 05:39:09 AM Dean Rasheed wrote:
>> As background, I have an app that accepts user text input and casts it
>> to a timestamp in order to produce reports. I use PostgreSQL's
>> timestamp input conversion for
On 27 August 2011 14:14, Peter Eisentraut wrote:
> On lör, 2011-08-27 at 12:29 +0100, Dean Rasheed wrote:
>> So Robert and Merlin both expressed concerns that the existing
>> datetime string parsing code is so complicated that adding to it would
>> likely just introduce more bugs.
>>
>> My first t
On Sat, Aug 27, 2011 at 01:59, Tom Lane wrote:
> Daniel Farina writes:
>> Some Postgres servers will error out for a while with the following
>> error message:
>> "expected authentication request from server, but received c"
>> [ and this seems to be triggered by fork failures in the server ]
>
>
> Avoid locale dependency in expected output.
>
> We'll have to settle for just listing the extensions' data types,
> since function arguments seem to sort differently in different locales.
> Per buildfarm results.
This could probably be worked around by using COLLATE "C" in psql \df
and \do. Th
On 27 Srpen 2011, 6:01, Noah Misch wrote:
> On Fri, Aug 26, 2011 at 10:46:33AM +0200, Tomas Vondra wrote:
>> 1. collect pg_stat_bgwriter stats
>> 2. run pgbench for 10 minutes
>> 3. collect pg_stat_bgwriter stats (to compute difference with (1))
>> 4. kill the postmaster
>>
>> The problem is that w
Greetings,
On Thursday, August 25, 2011 05:39:09 AM Dean Rasheed wrote:
> As background, I have an app that accepts user text input and casts it
> to a timestamp in order to produce reports. I use PostgreSQL's
> timestamp input conversion for this, since it gives a lot of
> flexibility, and can pa
On lör, 2011-08-27 at 12:29 +0100, Dean Rasheed wrote:
> So Robert and Merlin both expressed concerns that the existing
> datetime string parsing code is so complicated that adding to it would
> likely just introduce more bugs.
>
> My first thought was 'how hard can it be?' - famous last words :-)
On tor, 2011-07-07 at 18:09 -0400, Tom Lane wrote:
> I wrote:
> > Peter Eisentraut writes:
> >> I was adding gcc printf attributes to more functions in obscure places,
> >> and now I'm seeing this in pg_upgrade:
>
> >> relfilenode.c:72:2: warning: zero-length gnu_printf format string
> >> [-Wfor
On 27 August 2011 12:29, Dean Rasheed wrote:
> ... if nothing else it has been a
> fun exercise figuring out how the datetime string parsing code works.
>
While looking through the current code, I spotted the following oddity:
select timestamp 'yesterday 10:30';
timestamp
-
This is an artificial test case shrunk down from a much larger real
query.
CREATE TABLE test1 (
sha1 bytea PRIMARY KEY,
something text
);
CREATE TABLE test2 (
sha1 bytea PRIMARY KEY,
blah text
);
Fill those with 1000 random rows each, e.g.,
for i in $(seq 1 1000); do sha1=$(echo
On 27 August 2011 02:32, Robert Haas wrote:
> Frankly, our current date parsing code is pretty darn strange and
> flaky...
So Robert and Merlin both expressed concerns that the existing
datetime string parsing code is so complicated that adding to it would
likely just introduce more bugs.
My fir
Andrew Dunstan writes:
> For anything more fine-grained, I'm inclined to say that people need to roll
> their own. pg_restore's --list and --use-list give you extremely
> fine-grained control. I have working scripts which use these for example to
> filter out londiste and pgq objects, certain larg
On 2011-08-26 23:02, Tom Lane wrote:
AFAICT this is a red herring: the bug exists all the way back to where
tsvector_concat was added, in 8.3. I think the reason that your test
case happens to not crash before this commit is that it changed the sort
ordering rules for lexemes. As you can see fr
On 08/27/2011 12:01 AM, Noah Misch wrote:
On Fri, Aug 26, 2011 at 10:46:33AM +0200, Tomas Vondra wrote:
1. collect pg_stat_bgwriter stats
2. run pgbench for 10 minutes
3. collect pg_stat_bgwriter stats (to compute difference with (1))
4. kill the postmaster
The problem is that when checkpoi
30 matches
Mail list logo
