On 8/5/08, Merlin Moncure <[EMAIL PROTECTED]> wrote:
> On Tue, Aug 5, 2008 at 10:12 AM, Martin Pihlak <[EMAIL PROTECTED]> wrote:
> >>> DROP FUNCTION
> >>> create function foo() returns integer as $$ begin return 2; end; $$
> language plpgsql;
> >>> CREATE FUNCTION
> >>> execute c1;
> >>> psql
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Xiao Meng wrote:
> Hi, hackers. Here is some test I run on a bigger set.
>
> The time of the two index is
> btree: 1/0.174700=5.00250125
> hash-patch: 1/0.199900=5.724098
Just to bring it to attention of everybody:
btree: 1/0.174700=5.724098
hash-pat
sorry, I made some mistake here.
The time of the script on two indexes should be
btree: 1/0.174700=5.724098s
hash-patch: 1/0.199900=5.00250125s
On Wed, Aug 6, 2008 at 9:33 AM, Xiao Meng <[EMAIL PROTECTED]> wrote:
> Hi, hackers. Here is some test I run on a bigger set.
>
> Use a word list of 3991
Hi, hackers. Here is some test I run on a bigger set.
Use a word list of 39916800 unique words
The table size is 1529MB.
Index BuildTimeIndexSize
btree 874470.339ms 1027MB
hash-patch 513026.381 ms 1024MB
I use pgbench to test the time of a cust
Hi.
Sorry late reaction..
VC++2008 are official and are not supported. However, it has Build(ed).
Then, I did not reproduce a problem.
http://winpg.jp/~saito/pg_work/pg8.3.3_nmake_VC++2008.txt
It seems that there is some version difference.
Please show "dir Release."
Regards,
Hiroshi Saito
---
korry wrote:
>
> On Aug 5, 2008, at 4:07 PM, Simon Riggs wrote:
>
>>
>> On Sun, 2008-08-03 at 10:36 +0200, Magnus Hagander wrote:
>>> Tom Lane wrote:
Magnus Hagander <[EMAIL PROTECTED]> writes:
>> The good way to solve this would be to have independant command line
>> utilities which
On Aug 5, 2008, at 4:07 PM, Simon Riggs wrote:
On Sun, 2008-08-03 at 10:36 +0200, Magnus Hagander wrote:
Tom Lane wrote:
Magnus Hagander <[EMAIL PROTECTED]> writes:
The good way to solve this would be to have independant command
line
utilities which check pg_hba.conf, pg_ident.conf and
p
On Tue, Aug 5, 2008 at 10:12 AM, Martin Pihlak <[EMAIL PROTECTED]> wrote:
>>> DROP FUNCTION
>>> create function foo() returns integer as $$ begin return 2; end; $$
>>> language plpgsql;
>>> CREATE FUNCTION
>>> execute c1;
>>> psql:test.sql:11: ERROR: cache lookup failed for function 36555
>>
>> T
On Sun, 2008-08-03 at 10:36 +0200, Magnus Hagander wrote:
> Tom Lane wrote:
> > Magnus Hagander <[EMAIL PROTECTED]> writes:
> >>> The good way to solve this would be to have independant command line
> >>> utilities which check pg_hba.conf, pg_ident.conf and postgresql.conf for
> >>> errors. Then
"Russell Smith" <[EMAIL PROTECTED]> writes:
> Gregory Stark wrote:
>> It seems there's something wrong with CheckOtherDBBackends() but I haven't
>> exactly figured out what. There are no other sessions but drop database keeps
>> saying "regression" is being accessed by other users. I do see Autova
Tom Lane napsal(a):
Zdenek Kotala <[EMAIL PROTECTED]> writes:
It seems to me that we should panic that data are overlaped instead of return
zero.
elog(PANIC) is almost never a good idea, and it certainly isn't a good
response here.
Ok PANIC is too strong, but I guess FATAL should be relevant
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> It seems to me that we should panic that data are overlaped instead of return
> zero.
elog(PANIC) is almost never a good idea, and it certainly isn't a good
response here.
regards, tom lane
--
Sent via pgsql-hackers mailing li
Maybe put the whole thing into the ERROR message instead of having a
separate DETAIL line?
ERROR: database "%s" is being accessed by %d session(s)
-or-
ERROR: database "%s'" is being accessed by %d prepared transaction(s)
-or-
ERROR: database "%s'" is being accessed by %d session(s) and %d
prepare
Hello everybody,
I am trying to build libpq.dll from the source on a WIN 2003 system,
the make file is attached. I am using Microsoft Visual Studio 8 and
below is the command and outcome I'm trying to perform:
C:\src\PostgreSQL\postgresql-8.3.0\src\interfaces\libpq>nmake /f
win32.mak /I
The PageGetExactFreeSpace function contains following code:
00486 space = (int) ((PageHeader) page)->pd_upper -
00487 (int) ((PageHeader) page)->pd_lower;
00488
00489 if (space < 0)
00490 return 0;
It seems to me that we should panic that data are overlaped instead of re
Hi,
(sorry... I'm typing too fast and hitting the wrong keys... continuing
the previous mail now...)
Dimitri Fontaine wrote:
Now, this configuration needs to be resistant to network failure of any node,
Yeah, increasing availability is the primary purpose of doing replication.
central one
* Magnus Hagander ([EMAIL PROTECTED]) wrote:
> Tom Lane wrote:
> > It isn't, and I seem to recall we've had that scenario play out a couple
> > times already for postgresql.conf changes. But pg_hba.conf is far more
> > complex than "variable = value" ...
>
> Ok, then I didn't misunderstand that p
>>> On Mon, Aug 4, 2008 at 6:48 PM, in message
<[EMAIL PROTECTED]>,
Tom Lane <[EMAIL PROTECTED]> wrote:
> "Kevin Grittner" <[EMAIL PROTECTED]> writes:
>> I'm adding some NOT EXISTS examples to the thread for completeness
of
>> what someone might want to address while working on it. For two
>> qu
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> There are still two places in the system that hard-wire the use of
>> sorting for duplicate elimination:
>>
>> * Set operations (UNION/INTERSECT/EXCEPT)
> Egads. Are you thinking to reimplement them more in line
Gregory Stark wrote:
> It seems there's something wrong with CheckOtherDBBackends() but I haven't
> exactly figured out what. There are no other sessions but drop database keeps
> saying "regression" is being accessed by other users. I do see Autovacuum
> touching tables in regression but CheckOthe
Hi,
Dimitri Fontaine wrote:
Redirecting writing transactions from slaves to the master node solves
another problem. Being able to 'rescue' such forwarded connections in
case of a failure of the master is just a nice side effect. But it
doesn't solve the problem of connection losses between a cli
Tom Lane napsal(a):
Zdenek Kotala <[EMAIL PROTECTED]> writes:
I'm thinking we should split PageGetTempPage into two versions:
PageGetTempPage: get a temp page the same size as the given page,
but don't initialize its contents at all (so, just a thin wrapper
for palloc). This could be used by
"Tom Lane" <[EMAIL PROTECTED]> writes:
> I've pretty much finished the project I got a bee in my bonnet about
> last week, which is to teach SELECT DISTINCT how to (optionally) use
> hashing for grouping in the same way that GROUP BY has been able to do
> for awhile.
>
> There are still two places
Sounds very much like 80% 20% story. 80% that was easy to do is done and now
20% that is complex and progress is slow is left to be done. Sounds very
familiar from the comment in plan cache invalidation :)
On Tue, Aug 5, 2008 at 5:51 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> I've pretty much fini
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> I attach patch which removes useless page header check when page is zeroed.
> It
> is primary used by hash index.
Looks reasonable; applied.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.o
On 8/5/08, Pavel Stehule <[EMAIL PROTECTED]> wrote:
> >> ERROR: cannot change return type of existing function
> >> HINT: Use DROP FUNCTION first.
>
> you cannot change header of function. It's same as change C header of
> function without complete recompilation.
Thats why plan invalidation fo
I've pretty much finished the project I got a bee in my bonnet about
last week, which is to teach SELECT DISTINCT how to (optionally) use
hashing for grouping in the same way that GROUP BY has been able to do
for awhile.
There are still two places in the system that hard-wire the use of
sorting fo
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> A point that I don't think has been made so far in the thread: the
>>> only place the postmaster could complain in event of problems is the
>>> postmaster log, which we know too well isn't watched by inexperienced
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> A point that I don't think has been made so far in the thread: the
>> only place the postmaster could complain in event of problems is the
>> postmaster log, which we know too well isn't watched by inexperienced
>> DBAs. I guarantee
On Tuesday 05 August 2008 04:36:24 Magnus Hagander wrote:
> Robert Treat wrote:
> > On Monday 04 August 2008 15:38:35 Josh Berkus wrote:
> >> Post-mortem things we've learned about the commitfest are:
> >>
> >> 1) It's hard to get anything done in June-July.
> >
> > True... vacations and conference
Le mardi 05 août 2008, Markus Wanner a écrit :
> Dimitri Fontaine wrote:
> > I'm thinking in term of single master multiple slaves scenario...
> > In single master case, each slave only needs to know who the current
> > master is and if itself can process read-only queries (locally) or not.
>
> I d
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Should I read this as you warming up slightly to the idea of having the
>> postmaster do that? ;-)
>
> No ;-).
Bummer. Worth a shot though :-)
> I still think that a "postgres --check-config" feature would be
> far more complete
[Oops sorry -- I used the wrong links for the previous message. Here are the
correct links]
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> I don't know how that should be resolved, or if it's a genuine ambiguity in
> the
> ANSI and PostgreSQL syntax or something that can be fixed with some
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> I don't know how that should be resolved, or if it's a genuine ambiguity in
> the
> ANSI and PostgreSQL syntax or something that can be fixed with some Bison
> magic.
Fwiw I looked into this once already and noted the same conflict:
http://arti
2008/8/5 Asko Oja <[EMAIL PROTECTED]>:
> postgres=# create or replace function pavel ( i_param text, status OUT int,
> status_text OUT text ) returns record as $$ select 200::int, 'ok'::text; $$
> language sql;
> CREATE FUNCTION
> postgres=# create or replace function pavel ( i_param text, status O
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Should I read this as you warming up slightly to the idea of having the
> postmaster do that? ;-)
No ;-). I still think that a "postgres --check-config" feature would be
far more complete and useful, as well as less likely to cause bugs in
critical co
2008/8/5 Martin Pihlak <[EMAIL PROTECTED]>:
>>> DROP FUNCTION
>>> create function foo() returns integer as $$ begin return 2; end; $$
>>> language plpgsql;
>>> CREATE FUNCTION
>>> execute c1;
>>> psql:test.sql:11: ERROR: cache lookup failed for function 36555
>>
>> This is simply a bad, wrong, st
>> DROP FUNCTION
>> create function foo() returns integer as $$ begin return 2; end; $$ language
>> plpgsql;
>> CREATE FUNCTION
>> execute c1;
>> psql:test.sql:11: ERROR: cache lookup failed for function 36555
>
> This is simply a bad, wrong, stupid way to do it. Why do you not use
> CREATE OR
postgres=# create or replace function pavel ( i_param text, status OUT int,
status_text OUT text ) returns record as $$ select 200::int, 'ok'::text; $$
language sql;
CREATE FUNCTION
postgres=# create or replace function pavel ( i_param text, status OUT int,
status_text OUT text, more_text OUT text
> This is simply a bad, wrong, stupid way to do it. Why do you not use
> CREATE OR REPLACE FUNCTION?
I totally agree we should get this fixed first :)
postgres=# create or replace function pavel ( i_param text, status OUT int,
status_text OUT text ) returns record as $$ select 200::int, 'ok'::tex
Hi,
Dimitri Fontaine wrote:
I'm thinking in term of single master multiple slaves scenario...
In single master case, each slave only needs to know who the current master is
and if itself can process read-only queries (locally) or not.
I don't think that's as trivial as you make it sound. I'd
Martin Pihlak <[EMAIL PROTECTED]> writes:
> create function foo() returns integer as $$ begin return 1; end; $$ language
> plpgsql;
> CREATE FUNCTION
> prepare c1 as select * from foo();
> PREPARE
> execute c1;
> foo
> -
>1
> (1 row)
> drop function foo();
> DROP FUNCTION
> create functi
>>> On Mon, Aug 4, 2008 at 6:48 PM, in message
<[EMAIL PROTECTED]>,
Tom Lane <[EMAIL PROTECTED]> wrote:
> "Kevin Grittner" <[EMAIL PROTECTED]> writes:
>> I'm adding some NOT EXISTS examples to the thread for completeness
of
>> what someone might want to address while working on it. For two
>> qu
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> Seems a lot better to me to just train people to run the check-config
>>> code by hand before pulling the trigger to load the settings for real.
>
>> I think it'd be reasonable to refuse starting if the config is
Hi
Thanks for pointing to another thing to fix :)
postgres=# create type public.ret_status as ( status integer, status_text
text);
CREATE TYPE
postgres=# create or replace function pavel ( i_param text ) returns
public.ret_status as $$ select 200::int, 'ok'::text; $$ language sql;
CREATE FUNCTION
2008/8/5 Martin Pihlak <[EMAIL PROTECTED]>:
> Pavel Stehule wrote:
>> Hello
>>
>> try version 8.3. There lot of dependencies are solved.
>>
>
> Yes, 8.3 was the version I was testing with. Same results on the HEAD:
>
> $ psql -e -f test.sql
> select version();
>
Hi
Sadly PostgreSQL inability to invalidate plan cache when function is dropped
causes us downtime and costs money.
ERROR: cache lookup failed for function 24865)
This time our developers just rewrote function to use OUT parameters instead
of return type.
Currently i had to forbid dropping functi
Pavel Stehule wrote:
> Hello
>
> try version 8.3. There lot of dependencies are solved.
>
Yes, 8.3 was the version I was testing with. Same results on the HEAD:
$ psql -e -f test.sql
select version();
version
Le mardi 05 août 2008, Markus Wanner a écrit :
> I've thought about that as well, but think about it this way: to protect
> against N failing nodes, you need to forward *every* request through N
> living nodes, before actually hitting the node which processes the
> query. To me, that sounds like an
Pavel Stehule wrote:
I trying to implement GROUPING SETS feature. But there is basic
difference between PostgreSQL and ANSI. Pg allows expressions, ANSI
only column reference.
The conflict seems to arise from the parenthesis, between these two rules:
ordinary_grouping_set:
Hello
I trying to implement GROUPING SETS feature. But there is basic
difference between PostgreSQL and ANSI. Pg allows expressions, ANSI
only column reference. I have syntax:
group_clause:
GROUP_P BY grouping_element_list
| /*EMPTY*/
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Attached is a patch that implements this. I went with the option of just
>> storing it in a temporary directory that can be symlinked, and not
>> bothering with a GUC for it. Comments? (documentation updates are also
>> needed, but I'
Hi,
Dimitri Fontaine wrote:
If slave nodes were able to accept connection and redirect them to master, the
client wouldn't need to care about connecting to master or slave, just to
connect to a live node.
I've thought about that as well, but think about it this way: to protect
against N fail
I attach patch which removes useless page header check when page is zeroed. It
is primary used by hash index.
Zdenek
--
Zdenek Kotala Sun Microsystems
Prague, Czech Republic http://sun.com/postgresql
*** pgsql_page_api.7c9eff0cf439/src/backend/storage/buffer/bufmgr.c Ã
Le mardi 05 août 2008, Markus Wanner a écrit :
> > (Think network partition.)
>
> Uh... well, yeah, of course the servers themselves need to exchange
> their state and make sure they only accept clients if they are up and
> running (as seen by the cluster). That's what the 'view' of a GCS is all
>
Hello
try version 8.3. There lot of dependencies are solved.
Regards
Pavel Stehule
2008/8/5 Martin Pihlak <[EMAIL PROTECTED]>:
> Howdy,
>
> What is the status of plan invalidation vs stored procedures? From
> the initial design discussion I understand that function change handling
> was postpone
Hi,
Simon Riggs wrote:
On Tue, 2008-08-05 at 11:50 +0300, Hannu Krosing wrote:
I guess having the title "Automatic Client Failover" suggest to most
readers, that you are trying to solve the client side separately from
server.
Yes, that's right: separately. Why would anybody presume I meant "
Hi,
Greg Stark wrote:
a cwnrallu
What is that?
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hi,
Tom Lane wrote:
Huh? The pgpool is on the server, not on the client side.
Not necessarily. Having pgpool on the client side works just as well.
There is one really bad consequence of the oversimplified failover
design that Simon proposes, which is that clients might try to fail over
for
On Tue, 2008-08-05 at 11:50 +0300, Hannu Krosing wrote:
> On Tue, 2008-08-05 at 07:52 +0100, Simon Riggs wrote:
> > On Mon, 2008-08-04 at 22:56 -0400, Tom Lane wrote:
> > > Josh Berkus <[EMAIL PROTECTED]> writes:
> > > > I think the proposal was for an extremely simple "works 75% of the
> > > > t
Hi,
Josh Berkus wrote:
2) The number of patches is going to keep increasing with each
commitfest. As such, the patch list is going to get harder to deal
with. We now urgently need to start working on CF management software.
Agreed.
3) Round Robin Reviewers didn't really work this time, asi
Hannu Krosing wrote:
On Mon, 2008-08-04 at 13:08 -0400, David Blewett wrote:
Hi All:
This is an off-shoot of the "Do we really want to migrate plproxy and
citext into PG core distribution?" thread.
On the way home from PyOhio, I had a conversation with a few people
that use Zope a lot. I happe
Howdy,
What is the status of plan invalidation vs stored procedures? From
the initial design discussion I understand that function change handling
was postponed to "some time in the future". Is anybody already working
on that or maybe some ideas of how to implement this?
The business case for the
On Tue, 2008-08-05 at 07:52 +0100, Simon Riggs wrote:
> On Mon, 2008-08-04 at 22:56 -0400, Tom Lane wrote:
> > Josh Berkus <[EMAIL PROTECTED]> writes:
> > > I think the proposal was for an extremely simple "works 75% of the time"
> > > failover solution. While I can see the attraction of that, th
Robert Treat wrote:
> On Monday 04 August 2008 15:38:35 Josh Berkus wrote:
>> Post-mortem things we've learned about the commitfest are:
>>
>> 1) It's hard to get anything done in June-July.
>>
>
> True... vacations and conferences abound. September should be better in this
> regard I would think
Le mardi 05 août 2008, Tom Lane a écrit :
> Huh? The problem case is that the primary server goes down, which would
> certainly mean that a pgbouncer instance on the same machine goes with
> it. So it seems to me that integrating pgbouncer is 100% backwards.
With all due respect, it seems to me
Greg
On 5-Aug-08, at 12:15 AM, "Tom Lane" <[EMAIL PROTECTED]> wrote:
There is one really bad consequence of the oversimplified failover
design that Simon proposes, which is that clients might try to fail
over
for reasons other than a primary server failure. (Think network
partition.) You
Nick wrote:
Is the use of CURRVAL in this example reliable in heavy use?
Nick - the hackers list is for people interested in working on the
code-base of PostgreSQL itself. This would have been better on the
general or sql lists.
CREATE RULE add_email AS ON INSERT TO users WHERE (NEW.email
Is the use of CURRVAL in this example reliable in heavy use?
CREATE TABLE users (
id SERIAL NOT NULL,
email VARCHAR(24) DEFAULT NULL,
PRIMARY KEY (id)
);
CREATE TABLE users_with_email (
id INTEGER NOT NULL
);
CREATE RULE add_email AS ON INSERT TO users WHERE (NEW.email IS NULL)
DO INSERT I
69 matches
Mail list logo
