> > This patch passes regression and demonstrates the expected
> speedup on
> > my machine.
> >
>
> Looks good from here:
> - several rounds of regression test
> - psql -f set_time_out.sql
> - pg_ctl signal sending test
> - psql deadlock test
>
> Is there any way to test socket?
On Sun, 2005-10-23 at 03:11 -0400, Gregory Maxwell wrote:
> I don't recall this being mentioned in the prior threads:
> http://www.cs.duke.edu/TPIE/
>
> GPLed, but perhaps it has some good ideas.
Thanks, references are always useful.
Best Regards, Simon Riggs
---(end of
On Sun, 2005-10-23 at 02:04 +0530, Anuj Tripathi wrote:
> Hi
> I am trying to implement Query Progress estimator in postgres for
> queries with long run time.I am looking for info regarding the number of
> tuples already processsed by a running query .
> I would be very thankful if someone can su
Hello people,
I'm thinking to add a stage before the optimizer and after the parser
with a basic rewriter in order to flatten all nested queries using a
pattern and table statistics, here I also can use assetions the
database have. Another and complementary possibility is that I can
make annotatio
On Mon, Oct 24, 2005 at 12:11:55PM +0200, Sebastián Ávila wrote:
> Hello people,
>
> I'm thinking to add a stage before the optimizer and after the parser
> with a basic rewriter in order to flatten all nested queries using a
> pattern and table statistics, here I also can use assetions the
> data
This has been saved for the 8.2 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
> On Sun, Oct 16, 2005 at 04:06:04PM -0400, Andrew Duns
On Mon, Oct 24, 2005 at 08:20:07AM -0400, Bruce Momjian wrote:
>
> This has been saved for the 8.2 release:
>
> http://momjian.postgresql.org/cgi-bin/pgpatches_hold
Is this official "blessing" for the idea that psql should ignore SIGINT
while the pager is running? Or does this mean the ide
Uh, why does Veil have to allocate space from the backend shared memory
pool rather than allocating its own shared memory segment?
---
Marc Munro wrote:
-- Start of PGP signed section.
> Tom,
> My project, Veil, steals some
Martijn van Oosterhout wrote:
On Mon, Oct 24, 2005 at 08:20:07AM -0400, Bruce Momjian wrote:
This has been saved for the 8.2 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
Is this official "blessing" for the idea that psql should ignore SIGINT
while the pager
OK, running the latest patch. Observations:
1. Confirmed that time for count(*) on narrow sets is greatly improved:
A real easy way to show this off is:
select count(*) from generate_series(1,(10^6)::integer);
with about a 60% drop in time on my XP box.
2. Did ISAM style record iteration over r
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Martijn van Oosterhout wrote:
>> On Mon, Oct 24, 2005 at 08:20:07AM -0400, Bruce Momjian wrote:
>>> This has been saved for the 8.2 release:
>> Is this official "blessing" for the idea
> AFAIK it's Bruce's way of not losing track of the patch,
Exactly
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> 3. A pl/pgsql function stuck in a empty loop is unkillable except by
> killing the process on the server, which cycles the entire server. This
> was the behavior before the patch, btw.
Hmm, that suggests we need another CHECK_FOR_INTERRUPTS somewher
Tom wrote:
> "Merlin Moncure" <[EMAIL PROTECTED]> writes:
> > 3. A pl/pgsql function stuck in a empty loop is unkillable except
by
> > killing the process on the server, which cycles the entire server.
This
> > was the behavior before the patch, btw.
>
> Hmm, that suggests we need another CHECK_F
Tom Lane wrote:
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
3. A pl/pgsql function stuck in a empty loop is unkillable except by
killing the process on the server, which cycles the entire server. This
was the behavior before the patch, btw.
Hmm, that suggests we need another CHEC
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> Tom wrote:
>> Hmm, that suggests we need another CHECK_FOR_INTERRUPTS somewhere in
>> plpgsql. Please show the exact test case you were using.
> create function test_func() returns int4 as $$ BEGIN LOOP END LOOP;
> select 0; END; $$ language plpgsql;
This has been saved for the 8.2 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
> On Sun, Oct 16, 2005 at 06:21:37PM -0400, Tom Lane wr
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> We might be able to solve that for plpgsql, but in general we can't,
> ISTM. What if I write a plperl function that loops forever? We have no
> chance there to call CHECK_FOR_INTERRUPTS.
Yeah, I was thinking about that too. Still, we can/should/alrea
In case anyone's wondering why I'm replying to an article that's nearly a
year old, it came up in a search while I was looking for the more recent
LISTEN/NOTIFY thread...
In article <[EMAIL PROTECTED]>,
Tom Lane <[EMAIL PROTECTED]> wrote:
>Sean Chittenden <[EMAIL PROTECTED]> writes:
>> The async
Bruce,
There are two problems, though maybe I came to the wrong solution. I'm
not averse to changing it.
1) Veil starts from a user process and not from the postmaster. This
means that any shared memory segments created can not necessarily be
mapped to the same address space in each process, whi
[EMAIL PROTECTED] (Andreas Pflug) writes:
> Tom Lane wrote:
>> Andreas Pflug <[EMAIL PROTECTED]> writes:
>>
>>> So postmaster doesn't clean up pg_listener,
>> It never has. If you're complaining about this patch
>> http://archives.postgresql.org/pgsql-committers/2005-10/msg00073.php
>> you ought t
Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Certainly there is a lack of ideas as to how to fix it, as you mention
> > in (3). This shows to me that the solution lies in one of two areas: a)
> > the solution has not yet been considered or b) the solution has already
> > been thoug
Is there any TODO here?
---
Tom Lane wrote:
> "Dann Corbit" <[EMAIL PROTECTED]> writes:
> > I guess that additional ambiguity arises if you add additional spaces to
> > the end. Many database systems solve this by trimming
If there are multiple databases, say db1 and db2.
And currently we are in db1, can we create table in db2 (without
switching databases)?
Is there any query to do this?
- Paresh
---(end of broadcast)---
TIP 4: Have you searched our list archives?
Try getting lucky in google with "spinlock contention is greater"
>>> Bruce Momjian >>>
How do other databases deal with this? I can't imagine we are the only
ones. Are we doing something different than them?
---(end of broadcast)---
TIP 1: if
Document the collating sequences used for the character types.
> -Original Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]
> Sent: Monday, October 24, 2005 11:01 AM
> To: Tom Lane
> Cc: Dann Corbit; [EMAIL PROTECTED];
[EMAIL PROTECTED];
> pgsql-hackers@postgresql.org
> Subject: Re
On Mon, 24 Oct 2005, Magnus Hagander wrote:
> > Is there any way to test socket?
>
> Send the backend a signal when it's blocking for socket input (waiting
> for a user command in a psql session for example), and see that it's
> delivered. Hitting hte postmaster will test the select() path, and
>
On Mon, Oct 24, 2005 at 11:32:55PM +0530, Paresh Bafna wrote:
> If there are multiple databases, say db1 and db2.
> And currently we are in db1, can we create table in db2 (without
> switching databases)?
> Is there any query to do this?
This question seems off-topic for pgsql-hackers. The mailin
On Mon, 2005-10-24 at 13:08 -0500, Kevin Grittner wrote:
> Try getting lucky in google with "spinlock contention is greater"
Kevin's reference is actually to a Sybase manual page; very interesting.
This refers to the idea of subdividing the lock into may partitions.
That's already been discussed,
On an powerPC AIX 5.3 box, initdb from 8.1beta4 segfaults at
src/backend/utils/hash/dynahash.c:673. No segfaults occur and all 98
regression tests pass if a test is added to see if keycopy is memcpy and
if it is, go through a loop memcpying one byte at a time instead of
memcpying everything at
On Tue, 2005-10-18 at 18:57 -0400, Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > On Tue, 18 Oct 2005, Tom Lane wrote:
> >> Looking at the code, I notice that the messages are all emitted at level
> >> NOTICE. Perhaps that was not such a good idea --- it'd be pretty much
>
Michael Fuhr wrote:
> I see that new timezone data is available at
>
> ftp://elsie.nci.nih.gov/pub/
>
> It looks like the only changes from PostgreSQL's current data involve
> Kyrgyzstan and Uruguay. What's the policy on keeping the source
> code up to date? Does the data change too often to bo
On Fri, 2005-10-21 at 17:17 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Certainly there is a lack of ideas as to how to fix it, as you mention
> > in (3). This shows to me that the solution lies in one of two areas: a)
> > the solution has not yet been considered or b) the
Bruce Momjian wrote:
Michael Fuhr wrote:
I see that new timezone data is available at
ftp://elsie.nci.nih.gov/pub/
It looks like the only changes from PostgreSQL's current data involve
Kyrgyzstan and Uruguay. What's the policy on keeping the source
code up to date? Does the data change
On Mon, Oct 24, 2005 at 07:02:07PM -0400, Andrew Dunstan wrote:
> There's nothing magical about the files, is there? A user should be able
> to plug in a zic-compiled zone file from just about anywhere if they
> really need it, without having to update postgres, or I have badly
> misunderstood h
Dann Corbit wrote:
> Document the collating sequences used for the character types.
Sorry, I don't understand that. What does it mean?
---
>
> > -Original Message-
> > From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > On Tue, 18 Oct 2005, Tom Lane wrote:
> >> Looking at the code, I notice that the messages are all emitted at level
> >> NOTICE. Perhaps that was not such a good idea --- it'd be pretty much
> >> in-your-face if it were on all t
> -Original Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]
> Sent: Monday, October 24, 2005 5:57 PM
> To: Dann Corbit
> Cc: Tom Lane; [EMAIL PROTECTED]; [EMAIL PROTECTED];
> pgsql-hackers@postgresql.org
> Subject: Re: [GENERAL] [HACKERS] 'a' == 'a '
>
> Dann Corbit wrote:
> > Doc
Michael Fuhr <[EMAIL PROTECTED]> writes:
> * Update timezone data to match latest zic database (see src/timezone/README)
> So in case anybody was going to check on that prior to the upcoming
> 8.1 release candidate, there is new timezone data available (2005n
> vs. the current 2005m) but it appear
Dann Corbit wrote:
> > -Original Message-
> > From: Bruce Momjian [mailto:[EMAIL PROTECTED]
> > Sent: Monday, October 24, 2005 5:57 PM
> > To: Dann Corbit
> > Cc: Tom Lane; [EMAIL PROTECTED]; [EMAIL PROTECTED];
> > pgsql-hackers@postgresql.org
> > Subject: Re: [GENERAL] [HACKERS] 'a' == 'a
"Simon Riggs" <[EMAIL PROTECTED]> wrote
>>
>> How do other databases deal with this? I can't imagine we are the only
>> ones. Are we doing something different than them?
>
> I'm not sure the people qualified to answer that are able to do so. What
> do other OSS projects do about this is more lik
Dann Corbit wrote:
> > But isn't collating sequence related to ordering? How does this
> relate
> > to padding?
>
> Right. Collating sequence is how ordering is defined. But when you
> compare two character types, they are supposed to pad according to the
> collating sequence. So whether you b
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> OK, running the latest patch. Observations:
> ...
> I ran tests for about an hour, randomly killing/canceling backends
> without any problems.
Are we all comfortable that
http://archives.postgresql.org/pgsql-hackers/2005-10/msg01009.php
is OK to ap
Hello.
I've joined this mailing list to report you the success I am having
compiling postgresql-8.1 beta4 on DragonFly BSD, which is not supported.
Because the distribution is not known to postgresql-8.1 beta4, I had to
use ./configure --with-template=freebsd, since DragonFly is (for now)
s
Hi Tomas,
Have you considered joining the PostgreSQL Build Farm?
www.pgbuildfarm.org
Chris
Tomas wrote:
Hello.
I've joined this mailing list to report you the success I am having
compiling postgresql-8.1 beta4 on DragonFly BSD, which is not supported.
Because the distribution is not kno
Bruce Momjian writes:
> OK, I understand now. It is tempting to think that the difference
> between char() and varchar() is that internally they use a different
> collating sequences, but that isn't the case. If it were, space would
> be ignored during comparisons any place in the string, when i
On Mon, Oct 03, 2005 at 23:03:06 +1000,
John Hansen <[EMAIL PROTECTED]> wrote:
> Good people,
>
> Just had a thought!
>
> Might it be worth while protecting the postmaster from an OOM Kill on
> Linux by setting /proc/{pid}/oom_adj to -17 ?
> (Described vaguely in mm/oom_kill.c)
Wouldn't it be
On Mon, 24 Oct 2005, Tom Lane wrote:
>
> Are we all comfortable that
> http://archives.postgresql.org/pgsql-hackers/2005-10/msg01009.php
> is OK to apply?
>
> regards, tom lane
I tried to persuade myself that removing all WaitForSingleObjectEx() is
safe ... the thing is w
Qingqing Zhou <[EMAIL PROTECTED]> writes:
> I tried to persuade myself that removing all WaitForSingleObjectEx() is
> safe ... the thing is we will false alarm EINTR as Magnus said (details to
> repeat it are list below in case).
Just to repeat myself: there were false alarms before. The interlea
Tom Lane wrote:
> Bruce Momjian writes:
> > OK, I understand now. It is tempting to think that the difference
> > between char() and varchar() is that internally they use a different
> > collating sequences, but that isn't the case. If it were, space would
> > be ignored during comparisons any p
Bruce Momjian wrote:
What additional documentation is needed?
Some specific discussion of the relationship to the standard would be
helpful, perhaps.
I guess, but explaining it seems pretty complex in itself, and I am
unsure what value it adds.
It will give us something to
On Mon, 24 Oct 2005, Tom Lane wrote:
> Qingqing Zhou <[EMAIL PROTECTED]> writes:
> > I tried to persuade myself that removing all WaitForSingleObjectEx() is
> > safe ... the thing is we will false alarm EINTR as Magnus said (details to
> > repeat it are list below in case).
>
> Just to repeat my
On Mon, Oct 24, 2005 at 10:20:39PM -0500, Bruno Wolff III wrote:
> On Mon, Oct 03, 2005 at 23:03:06 +1000,
> John Hansen <[EMAIL PROTECTED]> wrote:
> > Good people,
> > Just had a thought!
> > Might it be worth while protecting the postmaster from an OOM Kill on
> > Linux by setting /proc/{pid}/o
On Mon, Oct 24, 2005 at 23:55:07 -0400,
[EMAIL PROTECTED] wrote:
> On Mon, Oct 24, 2005 at 10:20:39PM -0500, Bruno Wolff III wrote:
> > On Mon, Oct 03, 2005 at 23:03:06 +1000,
> > John Hansen <[EMAIL PROTECTED]> wrote:
> > > Good people,
> > > Just had a thought!
> > > Might it be worth while p
On Mon, Oct 24, 2005 at 11:26:52PM -0500, Bruno Wolff III wrote:
> On Mon, Oct 24, 2005 at 23:55:07 -0400,
> [EMAIL PROTECTED] wrote:
> > On Mon, Oct 24, 2005 at 10:20:39PM -0500, Bruno Wolff III wrote:
> > > On Mon, Oct 03, 2005 at 23:03:06 +1000,
> > > John Hansen <[EMAIL PROTECTED]> wrote:
>
daveg wrote:
> When this happens the machine runs out of memory and swap. Without the oom
> killer it simply hangs the machine which is inconvenient as it is at a remote
> location. The oom killer usually lets the machine recover and postgres restart
> without a hard reboot.
>
If vm.overcommit is
55 matches
Mail list logo
