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 prob
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 MyP
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 arch
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 nest
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_ ?
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 rel
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
Magnus Hagander wrote:
> I notice our docs have:
>
> If you are at all concerned about password
> sniffing attacks then md5 is preferred, with
> crypt to be used only if you must support pre-7.2
> clients. Plain password should be avoided especially for
>
>
> At what point do we
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 su
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 tha
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
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
corr
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 t
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 wo
"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
"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.
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 eas
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 th
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=# s
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 f
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
>> 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
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 compatib
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 comman
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 pgsql
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.
>
>> U
>>> "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 t
"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 char
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
> 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 star
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
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
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 thi
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. Pl
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 general
> rule 8g
>
I apologize,
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"
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 t
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 decompressed;
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 somewh
Tom Lane wrote:
A larger objection to Jeff's draft patch is that it doesn't implement
the . 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 be
the death of SQL yet
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 in
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 dur
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 inter
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 revi
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
su
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 maste
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 manageme
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 estimat
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 arr
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 s
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. t
"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,
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 spec
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,
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 developmen
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 Herrerahttp://www.Comm
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 1.9
[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 exa
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 conv
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 atte
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: r
>> > 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 so
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: http://um
"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/re
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
75 matches
Mail list logo
