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
"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
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 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
>> > 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
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
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
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
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
"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
[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
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
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
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
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,
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
"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,
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
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
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
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
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
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 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
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 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
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
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
===
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
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
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
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
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
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;
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
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
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"
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,
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
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
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.
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
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
> 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 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
"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
>>> "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
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
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
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
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
>> 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
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
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
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
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
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
"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.
"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
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
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
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
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
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
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
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
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
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
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_ ?
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
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
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
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
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
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
75 matches
Mail list logo
