On Sun, Oct 26, 2008 at 09:49:49PM -0400, Tom Lane wrote:
So I'm concluding that we can easily afford to switch to tuplestore-always
operation, especially if we are willing to put any effort into tuplestore
optimization. (I note that the current tuplestore code writes 24 bytes
per row for
Jeff Davis wrote:
Currently, we use correlation to estimate the I/O costs of an index
scan. However, this has some problems:
It certainly helps some cases.
Without the patch, the little test script below ends up picking the
third fastest plan (a seq-scan) instead of a faster bitmapscan, or
an
Martin Pihlak [EMAIL PROTECTED] wrote:
ITAGAKI Takahiro wrote:
I'd like to submit pg_stat_statements contrib module
Nice work! There is one feature I'd like to request -- we need to be able
to also track nested statements. This would greatly simplify diagnosing
performance problems in
Here is an updated version of contrib/pg_stat_statements module.
I wrote:
A shutdown hook is probably not needed because I can use proc_exit()
or shmem_exit() for the purpose.
I added shutdown hook eventually because MyProc has been reset already
in on_shmem_exit(). A callback that resets
As Heikki pointed out, the issue is not to decompress the compressed
WAL, but also how we can keep archive log still compressed after it is
handled by pg_standby.
I'm afraid pg_standby cannot handle this solely, may need some support
by the pg core. For example, after closing archive log in
On Mon, 2008-10-27 at 17:00 +0900, ITAGAKI Takahiro wrote:
Martin Pihlak [EMAIL PROTECTED] wrote:
ITAGAKI Takahiro wrote:
I'd like to submit pg_stat_statements contrib module
Nice work! There is one feature I'd like to request -- we need to be able
to also track nested statements.
Hannu Krosing [EMAIL PROTECTED] wrote:
Martin Pihlak [EMAIL PROTECTED] wrote:
we need to be able to also track nested statements.
I tried your request, but found it's hard to determine query text
where the executing plan comes.
Are you sure you need query _text_ ?
Why not just
Hi,
I have encountered a server crash while working with different locale
settings. After searching on the internet I have seen a similar issue
with 8.3.1 release and Tom has fixed that issue. That bug was only in
Windows but I am getting same server crash on Linux, although I am
using a later
Ibrar Ahmed wrote:
I have encountered a server crash while working with different locale
settings. After searching on the internet I have seen a similar issue
with 8.3.1 release and Tom has fixed that issue. That bug was only in
Windows but I am getting same server crash on Linux, although I
Magnus Hagander wrote:
I notice our docs have:
If you are at all concerned about password
quotesniffing/ attacks then literalmd5/ is preferred, with
literalcrypt/ to be used only if you must support pre-7.2
clients. Plain literalpassword/ should be avoided especially for
In a number of places in pg_hba.conf, we don't actually log what goes
wrong - instead we just goto a label that will log invalid token \%s\.
Is there any special reason for this, other than the fact that it was
the easy way out? I think it would be reasonable to for example log
hostssl not
Martijn van Oosterhout [EMAIL PROTECTED] writes:
On Sun, Oct 26, 2008 at 09:49:49PM -0400, Tom Lane wrote:
So I'm concluding that we can easily afford to switch to tuplestore-always
operation, especially if we are willing to put any effort into tuplestore
optimization.
I thought that the bad
Michael Fuhr wrote:
On Sat, Oct 25, 2008 at 12:36:24PM -0400, Tom Lane wrote:
The backend can't take it upon itself to interrupt the send, because
that would result in loss of protocol message sync, and without
knowing how many bytes got sent there's really no way to recover.
The only escape
Ron Mayer [EMAIL PROTECTED] writes:
... I was somewhat surprised that the bitmap cost estimates didn't
also change much. Wouldn't the estimated # of data blocks
read for the bitmap be roughly the same as for the index?
By definition, a bitmap scan's cost isn't affected by index order
Magnus Hagander wrote:
In a number of places in pg_hba.conf, we don't actually log what goes
wrong - instead we just goto a label that will log invalid token \%s\.
Is there any special reason for this, other than the fact that it was
the easy way out? I think it would be reasonable to for
Magnus Hagander [EMAIL PROTECTED] writes:
In a number of places in pg_hba.conf, we don't actually log what goes
wrong - instead we just goto a label that will log invalid token \%s\.
Is there any special reason for this, other than the fact that it was
the easy way out? I think it would be
Stephen R. van den Berg [EMAIL PROTECTED] writes:
What about simply closing the filedescriptor upon discovering a
non-empty sendbuffer upon timeout/querycancel?
So in other words, convert any network glitch, no matter how small,
into an instant fatal error?
regards, tom
Ibrar Ahmed [EMAIL PROTECTED] writes:
I have encountered a server crash while working with different locale
settings.
Are you going to give us a hint what settings those would be?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
In a number of places in pg_hba.conf, we don't actually log what goes
wrong - instead we just goto a label that will log invalid token \%s\.
Is there any special reason for this, other than the fact that it was
the easy way out? I
Alvaro Herrera wrote:
Magnus Hagander wrote:
In a number of places in pg_hba.conf, we don't actually log what goes
wrong - instead we just goto a label that will log invalid token \%s\.
Is there any special reason for this, other than the fact that it was
the easy way out? I think it would
Sure!
CODE
--
/configure --enable-nls --enable-depend --enable-debug
make
make install
SERVER SIDE
-
1 - export LANG=ko_KR.UTF-8
2 - ./initdb -E UTF8 -D ../data
3 - ./postmaster -D ../data
CLIENT SIDE
---
1 - export LANG=ko_KR.UTF-8
2 - psql postgres
postgres=#
Pavel Stehule escribió:
postgres=# create function fx(a int, b int default 30, c int default 40)
postgres-# returns int as $$ select $1 + $2 + $3; $$
postgres-# language sql;
How do you deal with the case where you have
f(a int, b int default 1) and
f(a int, b text default '1') ?
select
Magnus Hagander [EMAIL PROTECTED] writes:
Tom Lane wrote:
It would be seriously messy to try to make the parse-error code know
about things like that. Better would be to keep the GUC variable in
existence always and have an assign hook to throw the error.
Um, no, it wouldn't :-) At least
I thought that the bad case for a tuplestore was if the set returning
function was expensive and the user used it with a LIMIT clause. In the
tuplestore case you evaluate everything then throw it away.
I'm not terribly excited by that example --- but in any case, the real
solution to any
Howdy,
Currently pl/proxy, dblink, DBI-link etc. each have their own remote connection
info management infrastructure (or none at all). It would certainly help if
they could use a common connection database -- with access control, pg_dump
support, etc. There have been hints that a SQL/MED
On Mon, Oct 27, 2008 at 10:06 AM, Martin Pihlak [EMAIL PROTECTED] wrote:
So the proposal is to implement a small subset of SQL/MED to cope with
connection info management -- connection manager. This will only manage the
connection metadata and provide the required system catalogs and commands
On Mon, Oct 27, 2008 at 10:35 AM, Jonah H. Harris
[EMAIL PROTECTED] wrote:
The first wrappers I intend to support are ODBC and
Damn multiple windows :)
The first wrappers I intend to support are ODBC and CSV/fixed-width text.
--
Jonah H. Harris, Senior DBA
myYearbook.com
--
Sent via
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Tom Lane wrote:
It would be seriously messy to try to make the parse-error code know
about things like that. Better would be to keep the GUC variable in
existence always and have an assign hook to throw the error.
Um, no, it
Koichi Suzuki [EMAIL PROTECTED] wrote:
As Heikki pointed out, the issue is not to decompress the compressed
WAL, but also how we can keep archive log still compressed after it
is
handled by pg_standby.
I'm afraid pg_standby cannot handle this solely, may need some
support
by the pg core.
Ibrar Ahmed [EMAIL PROTECTED] writes:
1 - export LANG=ko_KR.UTF-8
Hmph ... I can reproduce that on Fedora 9. It seems the problem is
that that translation is full of characters that don't exist in EUC-JP;
in particular the translations of both ERROR and PANIC contain
untranslatable characters.
On Fri, Oct 24, 2008 at 7:57 PM, Tom Lane [EMAIL PROTECTED] wrote:
Tim Keitt [EMAIL PROTECTED] writes:
The docs for FETCH indicate you can fetch from the current row using
FORWARD 0, but
SPI_scroll_cursor_fetch(someportal, FETCH_FORWARD, 0);
fails for me. Is there a way to emulate FETCH
Per SQL:2008, there are no expected changes to SQL/MED from SQL:2003.
As such, two weeks ago, I completed a full review of SQL/MED and am
planning to fully implement it for 8.5. Currently, I'm working on a
proof of concept and have created a SQL/MED access method (sqlmed) as
well as started
On Monday 20 October 2008 05:25:29 Simon Riggs wrote:
I'm looking to implement the following functions for Hot Standby, to
allow those with administrative tools or management applications to have
more control during recovery. Please let me know if other functions are
required.
What else do
On Sun, Oct 19, 2008 at 11:21:09PM -0400, Tom Lane wrote:
Eric Haszlakiewicz [EMAIL PROTECTED] writes:
On Sun, Oct 19, 2008 at 10:15:22PM -0400, Tom Lane wrote:
What platform is this, anyway?
I'm running on NetBSD 4.
Well, it seems that something doesn't work right with the try the next
Could I request that a link to the developer docs be posted along with
the release docs on
http://www.postgresql.org/docs/manuals/
?
First -- it is interesting. Second, if one is running CVS HEAD for
testing (always a service to the community, if not your data), they
are the appropriate docs.
As I promised, version 7 of the window functions is now released. At
the same time, git repository branch comes back to master.
git: http://git.postgresql.org/?p=~davidfetter/window_functions/.git
patch: http://umitanuki.net/pgsql/window_functions.patch.20081028.gz
It's too huge to send it to
On Mon, 2008-10-27 at 11:42 -0400, Robert Treat wrote:
On Monday 20 October 2008 05:25:29 Simon Riggs wrote:
I'm looking to implement the following functions for Hot Standby, to
allow those with administrative tools or management applications to have
more control during recovery. Please
On Sun, 2008-10-26 at 23:02 -0400, Tom Lane wrote:
Ian Caulfield [EMAIL PROTECTED] writes:
I think array_agg also keeps nulls - although the draft standard I
have seems to contradict itself about this...
The SQL:2008 draft I have says, in 10.9 aggregate function general
rule 8g
I
I wrote:
This is still not very nice because what the user would get is
a complaint about ERRORDATA_STACK_SIZE exceeded with no hint that
he's got an encoding problem. It'd be better if we could get the
disable-gettext-and-FATAL-out behavior to apply to the character
has no equivalent error
Tom Lane escribió:
It might be better to modify elog.c so that errmsg_internal really
doesn't call gettext. This would require kluging up EVALUATE_MESSAGE()
a bit, so I'm not quite sure which is cleaner. Thoughts?
I think we document somewhere that a translator can add errmsg_internal to
Tom Lane wrote:
Stephen R. van den Berg [EMAIL PROTECTED] writes:
What about simply closing the filedescriptor upon discovering a
non-empty sendbuffer upon timeout/querycancel?
So in other words, convert any network glitch, no matter how small,
into an instant fatal error?
The fact that a
Koichi Suzuki wrote:
As Heikki pointed out, the issue is not to decompress the compressed
WAL, but also how we can keep archive log still compressed after it is
handled by pg_standby.
pg_standby makes a *copy* of the segment from the archive, and need only
ensure that the copy is
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane escribió:
It might be better to modify elog.c so that errmsg_internal really
doesn't call gettext. This would require kluging up EVALUATE_MESSAGE()
a bit, so I'm not quite sure which is cleaner. Thoughts?
I think we document somewhere that
Tom Lane wrote:
A larger objection to Jeff's draft patch is that it doesn't implement
the sort specification list. I'm entirely happy about not doing that
--- the current SQL committee's willingness to invent random new syntax
and nonorthogonal behavior for every function they can think of will
2008/10/27 Alvaro Herrera [EMAIL PROTECTED]:
Pavel Stehule escribió:
postgres=# create function fx(a int, b int default 30, c int default 40)
postgres-# returns int as $$ select $1 + $2 + $3; $$
postgres-# language sql;
How do you deal with the case where you have
f(a int, b int default 1)
Simon Riggs wrote:
On Mon, 2008-10-27 at 11:42 -0400, Robert Treat wrote:
On Monday 20 October 2008 05:25:29 Simon Riggs wrote:
I'm looking to implement the following functions for Hot Standby, to
allow those with administrative tools or management applications to have
more control
On Mon, Oct 27, 2008 at 11:31 AM, Martin Pihlak [EMAIL PROTECTED] wrote:
Cool. Have you published some notes on it (wiki etc)?
Not yet. Discussed it a little on irc, but nothing substantial. I'll
look at updating the Wiki hopefully today.
It certainly is an undertaking :) I'm mostly
I wrote:
SQL has the following escape syntax for it:
U'special character: \' [ UESCAPE '\' ]
Here is an in-progress patch for this. It still needs updates in the
psql scanner and possibly other scanners. But the server-side
functionality works.
Index: doc/src/sgml/syntax.sgml
Another small piece of parser acrobatics to become standard conforming.
? src/backend/parser/gram.output
Index: doc/src/sgml/ref/create_table_as.sgml
===
RCS file: /cvsroot/pgsql/doc/src/sgml/ref/create_table_as.sgml,v
retrieving
Peter Eisentraut [EMAIL PROTECTED] writes:
How else will you tell an aggregate function whose result depends on the
input order which order you want?
You feed it from a subquery that has ORDER BY. The only reason the spec
needs this kluge is their insistence that ORDER BY not be used in
On Mon, 2008-10-27 at 13:08 -0400, Robert Treat wrote:
Was thinking that admin tools that show hot standby information might
also want to show the corresponding slave information (from the point
of view of the master).
Well, the standby might be persuaded to know something about the master,
On Monday 27 October 2008 12:12:18 Simon Riggs wrote:
On Mon, 2008-10-27 at 11:42 -0400, Robert Treat wrote:
On Monday 20 October 2008 05:25:29 Simon Riggs wrote:
I'm looking to implement the following functions for Hot Standby, to
allow those with administrative tools or management
Tom Lane wrote:
Ron Mayer [EMAIL PROTECTED] writes:
...bitmap cost estimates didn't also change much
By definition, a bitmap scan's cost isn't affected by index order
correlation.
No? I think I understand that for index scans the correlation
influenced how many data pages are
On Mon, 2008-10-27 at 18:47 +0200, Peter Eisentraut wrote:
How else will you tell an aggregate function whose result depends on the
input order which order you want? The only aggregates defined in the
standard where this matters are array_agg, array_accum, and xmlagg, but
I don't see
http://developer.postgresql.org/pgdocs/postgres/index.html
On Mon, Oct 27, 2008 at 12:11 PM, Webb Sprague [EMAIL PROTECTED] wrote:
Could I request that a link to the developer docs be posted along with
the release docs on
http://www.postgresql.org/docs/manuals/
?
First -- it is
Webb Sprague wrote:
Could I request that a link to the developer docs be posted along with
the release docs on
http://www.postgresql.org/docs/manuals/
they are already referenced in the development section of the website:
http://www.postgresql.org/developer/testing
I'm not sure we actively
Thanks to all for the link.\
they are already referenced in the development section of the website:
They are actually a little difficult to find for those of us that
don't use that section frequently, or at least finding a navigation
page to that section.
I'm not sure we actively should put
Russell Smith wrote:
Alvaro Herrera wrote:
PoolSnoopy wrote:
***PUSH***
this bug is really some annoyance if you use automatic build environments.
I'm using phpunit to run tests and as soon as postgres is involved the php
cli environment segfaults at the end. this can be worked
Stephen R. van den Berg [EMAIL PROTECTED] writes:
Tom Lane wrote:
Stephen R. van den Berg [EMAIL PROTECTED] writes:
What about simply closing the filedescriptor upon discovering a
non-empty sendbuffer upon timeout/querycancel?
So in other words, convert any network glitch, no matter how
Peter Eisentraut [EMAIL PROTECTED] writes:
Another small piece of parser acrobatics to become standard conforming.
I think we deliberately decided that we weren't going to implement this
syntax because it required this sort of pushup to provide a uselessly
redundant behavior. Adding more
Ron Mayer [EMAIL PROTECTED] writes:
Tom Lane wrote:
By definition, a bitmap scan's cost isn't affected by index order
correlation.
No? I think I understand that for index scans the correlation
influenced how many data pages are estimated to get sucked in.
No, it's not about that, it's
am Mon, dem 27.10.2008, um 19:01:14 +0100 mailte Stefan Kaltenbrunner
folgendes:
Webb Sprague wrote:
Could I request that a link to the developer docs be posted along with
the release docs on
http://www.postgresql.org/docs/manuals/
they are already referenced in the development section
A. Kretschmer wrote:
they are already referenced in the development section of the website:
http://www.postgresql.org/developer/testing
I think - no. Mark this as dev-docu, but i think, this is a nice
feature.
+1
--
Alvaro Herrera
With the recent open sourcing of Replicator, the team has been trying
to come up with ways to ensure an open development process. In that
light we have decided to have our first release 1.9 meeting on
Freenode. All people interested in participating in a discussion about
the upcoming Replicator
[EMAIL PROTECTED] (Martin Pihlak) writes:
Tons of details have been omitted, but should be enough to start discussion.
What do you think, does this sound usable? Suggestions, objections?
Slony-I does some vaguely similar stuff in its handling of connection paths;
here's the schema:
create
Robert Haas [EMAIL PROTECTED] writes:
I thought that the bad case for a tuplestore was if the set returning
function was expensive and the user used it with a LIMIT clause. In the
tuplestore case you evaluate everything then throw it away.
I'm not terribly excited by that example --- but in
Heikki Linnakangas [EMAIL PROTECTED] writes:
To modify a page:
If PD_ALL_VISIBLE flag is set, the bit in the visibility map is cleared
first. The heap page is kept pinned, but not locked, while the
visibility map is updated. We want to avoid holding a lock across I/O,
even though the
On Thu, 23 Oct 2008, Kris Jurka wrote:
The problem with trying to deprecate it is that the vast majority of the
backend is still using the old interfaces, so people looking for
inspiration for their external modules will likely end up using the old
interface. Like Alvaro I started this
On Thu, 2008-10-23 at 19:37 +0100, Simon Riggs wrote:
I suggest a third version with these changes:
* Write the SUBCOMMITTED to COMMIT transition as a no-op during redo
rather than as an Assert. This prevents a transition from COMMIT to
SUBCOMMIT to ABORT. By making it a no-op the attempt
I wrote:
I'd like us to be trying to get rid of the special cases in base_yylex
not add more. (It strikes me that now that WITH is fully reserved,
we might not need some of the ones that are there anymore.)
In fact, it looks like what we should do is heed the existing comment
in parser.c:
they are already referenced in the development section of the website:
http://www.postgresql.org/developer/testing
I think - no. Mark this as dev-docu, but i think, this is a nice
feature.
+1
I think what we're talking about is adding a clearly-marked link to
the dev docs somewhere on
Hitoshi Harada Wrote:
As I promised, version 7 of the window functions is now released. At
the same time, git repository branch comes back to master.
git: http://git.postgresql.org/?p=~davidfetter/window_functions/.git
patch: http://umitanuki.net/pgsql/window_functions.patch.20081028.gz
2008/10/28 David Rowley [EMAIL PROTECTED]:
Hitoshi Harada Wrote:
As I promised, version 7 of the window functions is now released. At
the same time, git repository branch comes back to master.
git: http://git.postgresql.org/?p=~davidfetter/window_functions/.git
patch:
Hitoshi Harada [EMAIL PROTECTED] wrote:
As I promised, version 7 of the window functions is now released.
patch: http://umitanuki.net/pgsql/window_functions.patch.20081028.gz
I tested the patch on mingw (Windows) and
got the following warning and error:
A. gram.y: conflicts: 3 shift/reduce
Thanks for your testing all!
2008/10/28 ITAGAKI Takahiro [EMAIL PROTECTED]:
Hitoshi Harada [EMAIL PROTECTED] wrote:
As I promised, version 7 of the window functions is now released.
patch: http://umitanuki.net/pgsql/window_functions.patch.20081028.gz
I tested the patch on mingw (Windows)
75 matches
Mail list logo
