On Mon, Aug 04, 2008 at 10:31:10AM -0700, David Wheeler wrote:
On Jul 31, 2008, at 00:07, Abhijit Menon-Sen wrote:
I have attached two patches:
- funcdef.diff implements pg_get_functiondef()
- edit.diff implements \ef function in psql based on (1).
Comments appreciated.
+1
I like! The
Here is a patch to user NDirectFileRead/Write counters to get I/O counts
in BufFile module. We can see the counters when log_statement_stats is on.
The information is different from trace_sort; trace_sort shows used blocks
in external sort, and log_statement_stats shows how many I/Os are
Simon Riggs wrote:
On Sun, 2008-08-03 at 22:09 +0200, Hans-Jürgen Schönig wrote:
Another alternative would be to have a plugin that can examine the
plan
immediately after planner executes, so you can implement this
yourself,
plus some other possibilities.
this would be really fancy.
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, the
consequences of having failover *not* work are pretty severe.
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
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
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
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
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, the
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
time
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 postponed to
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
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
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
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,
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,
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
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.
Um.
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
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
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
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'll wait
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*/
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:
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:
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
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
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
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
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 *known
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
queries which can
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 function foo()
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
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,
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
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 REPLACE
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, stupid way to do it. Why
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 code
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 OUT
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:
[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 Bison
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 and useful,
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 don't
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 conferences abound.
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 you that
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
DBAs. I
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
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 for
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.org)
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
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 in the
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
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
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
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 with the way
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
queries which can
* 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 part at
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
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
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\libpqnmake /f
win32.mak /I
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
prepared
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 list
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
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 Autovacuum
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 DBAs could run a
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
This is simply a bad,
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
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 check pg_hba.conf,
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
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
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 39916800
-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-patch:
72 matches
Mail list logo
