On Mon, Sep 15, 2008 at 06:46:16PM +0900, Tatsuo Ishii wrote:
* Single Evaluation:
with
foo(i) as (select random() as i)
select * from foo union all select * from foo;
i
---
0.233165248762816
0.62126633618027
(2 rows)
Any status updates on the following patches?
1. Fragments in tsearch2 headlines:
http://archives.postgresql.org/pgsql-hackers/2008-08/msg00043.php
2. Bug in hlCover:
http://archives.postgresql.org/pgsql-hackers/2008-08/msg00089.php
-Sushant.
--
Sent via pgsql-hackers mailing list
Tom Lane [EMAIL PROTECTED] writes:
We have recently seen one definite and one probable report of overflow
of the nLocks field of a backend's local lock table:
http://archives.postgresql.org/pgsql-bugs/2008-09/msg00021.php
...
Comments, objections?
In that case the problem could have been
Hi,
Here is my review of the dblink security hole patch written by Marko Kreen:
http://archives.postgresql.org/message-id/[EMAIL PROTECTED]
1 - The patch applies cleanly to the latest GIT repository.
2 - Regression passed before/after the patch.
3 - I have played around with the patch a little
Hi,
Here is my review of the dblink security hole patch written by Marko Kreen:
http://archives.postgresql.org/message-id/[EMAIL PROTECTED]
1 - The patch applies cleanly to the latest GIT repository.
2 - Regression passed before/after the patch.
3 - I have played around with the patch a little
Tom Lane wrote:
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
BTW, we have the word 'Direct' in ShowBufferUsage().
Can I keep it as-is?
ShowBufferUsage()
! Shared blocks: ...
! Local blocks: ...
! Direct blocks: R read, W written
Good point. Seems like it should be changed, but I am
On Mon, 2008-09-15 at 16:00 +0100, Simon Riggs wrote:
On Mon, 2008-09-15 at 10:04 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
The version mismatch idea presumes that a code author would
structure
their code in two pieces: one to generate the WAL and one to read
it.
Andrew Dunstan wrote:
[snip]
Er, who doesn't know what for certain, exactly? pg_restore will
certainly know that it has created the table in another session and
can thus safely truncate the table in the same transaction as the data
load.
cheers
andrew
I'm confused about why table
There is an autovacuum TODO item suggesting pg_autovacuum to be
replaced with pg_class.reloptions. Original discussion at:
http://archives.postgresql.org/pgsql-hackers/2007-02/msg01440.php
A lot of time has passed -- is the proposal still valid or are there
any new thoughts on the matter? Perhaps
On 9/16/08, Ibrar Ahmed [EMAIL PROTECTED] wrote:
Here is my review of the dblink security hole patch written by Marko Kreen:
Thanks for the review.
http://archives.postgresql.org/message-id/[EMAIL PROTECTED]
1 - The patch applies cleanly to the latest GIT repository.
2 - Regression passed
Hello,
== Proposal - GROUPING SETS ==
a grouping set feature allows multiple grouping clauses in one
query. Result of grouping sets is union of results each groupby
clause's result.
create table t(a int, b int);
insert into t values(10,20);
insert into t values(30,40);
select a, b from t group
Russell Smith wrote:
Andrew Dunstan wrote:
[snip]
Er, who doesn't know what for certain, exactly? pg_restore will
certainly know that it has created the table in another session and
can thus safely truncate the table in the same transaction as the data
load.
cheers
andrew
Subtransactions cause a couple of problems for Hot Standby:
* we don't record new subtransactionids in WAL, so we have no direct way
to issue updates to subtrans while in recovery mode as would normally
happen when we assign subtransaction ids (subxids)
* we don't record subtransaction commit in
On 9/12/08, Alvaro Herrera [EMAIL PROTECTED] wrote:
Marko Kreen escribió:
Currently dblink allows regular users to initiate libpq connection
to user-provided connection string. This breaks the default
policy that normal users should not be allowed to freely interact
with outside
Gregory Stark [EMAIL PROTECTED] writes:
Alternatively perhaps we could indicate when taking a lock that we intend to
hold the lock until the end of the transaction. In that case we don't need the
usage counter at all and could just mark it with a special value which we
never increment or
I have attached a patch just for the quick thought. Otherwise there is no
issue with patch.
This is no good - the security_check() needs established connection
to work on.
I know it but after putting the superuser check just above the
security_check function make this function almost
Martijn van Oosterhout wrote:
On Wed, Sep 10, 2008 at 12:51:02PM +0300, Heikki Linnakangas wrote:
Since the set of collations isn't exactly denumerable, we need some way
to allow the user to specify the collation they want. The only
collation PostgreSQL knows about is the C collation. Anything
Hello,
I am returning back to my patch from last previous year
http://archives.postgresql.org/pgsql-patches/2008-04/msg00166.php .
The main objection was about integration encryption method into core.
There was others proposal - using an obfuscate languages. I dislike
it. It lot of duplicate code
Heikki Linnakangas [EMAIL PROTECTED] writes:
Well, I proposed disallowing using a different collation than the source
database, except for using template0 as the source. That's pretty limited, but
is trivial to implement and still let's you have databases with different
collations in the same
Simon Riggs wrote:
Subtransactions cause a couple of problems for Hot Standby:
Do we need to treat subtransactions any differently from normal
transactions? Just treat all subtransactions as top-level transactions
until commit, and mark them all as committed when you see the commit
record
Pavel Stehule [EMAIL PROTECTED] writes:
select a, b from t group by grouping sets(a, b);
is same as:
select a, NULL from t group by a
union all
select NULL, b from t group by b;
Really? That seems utterly bizarre, not to say pointless.
You sure you read the spec correctly?
Heikki Linnakangas wrote:
Simon Riggs wrote:
Subtransactions cause a couple of problems for Hot Standby:
Do we need to treat subtransactions any differently from normal
transactions? Just treat all subtransactions as top-level transactions
until commit, and mark them all as committed
2008/9/16 Tom Lane [EMAIL PROTECTED]:
Pavel Stehule [EMAIL PROTECTED] writes:
select a, b from t group by grouping sets(a, b);
is same as:
select a, NULL from t group by a
union all
select NULL, b from t group by b;
Really? That seems utterly bizarre, not to say pointless.
You sure you
Martin Pihlak escribió:
There is an autovacuum TODO item suggesting pg_autovacuum to be
replaced with pg_class.reloptions. Original discussion at:
http://archives.postgresql.org/pgsql-hackers/2007-02/msg01440.php
A lot of time has passed -- is the proposal still valid or are there
any new
Disabling autovacuum can have catastrophic effects, since it disables
the ANALYZing of tables.
Can we have a mode where we disable autoVACUUM yet enable autoANALYZE?
ANALYZE times are fairly bounded because of the way we do sampling.
VACUUM times are not bounded at all, and typically O(n).
On Tue, 2008-09-16 at 17:01 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
Subtransactions cause a couple of problems for Hot Standby:
Do we need to treat subtransactions any differently from normal
transactions? Just treat all subtransactions as top-level transactions
until
On Tue, 2008-09-16 at 10:11 -0400, Alvaro Herrera wrote:
Heikki Linnakangas wrote:
Simon Riggs wrote:
Subtransactions cause a couple of problems for Hot Standby:
Do we need to treat subtransactions any differently from normal
transactions? Just treat all subtransactions as top-level
On Tue, Sep 16, 2008 at 3:02 PM, Tom Lane [EMAIL PROTECTED] wrote:
Pavel Stehule [EMAIL PROTECTED] writes:
select a, b from t group by grouping sets(a, b);
is same as:
select a, NULL from t group by a
union all
select NULL, b from t group by b;
Really? That seems utterly bizarre, not to
Robert Haas [EMAIL PROTECTED] writes:
This seems like the wrong solution. There is a general problem that
bulk data loads on an empty table tend to result in horrible query
plans,
Please provide some specifics. It's been a very long time since the
planner was completely unaware of the size
2008/9/16 Greg Stark [EMAIL PROTECTED]:
On Tue, Sep 16, 2008 at 3:02 PM, Tom Lane [EMAIL PROTECTED] wrote:
Pavel Stehule [EMAIL PROTECTED] writes:
select a, b from t group by grouping sets(a, b);
is same as:
select a, NULL from t group by a
union all
select NULL, b from t group by b;
Gregory Stark napsal(a):
Heikki Linnakangas [EMAIL PROTECTED] writes:
snip
AFAIK we can't easily connect to the new database and do some fiddling with
it, can we? If we could we could check if there are any non-empty indexes
which depend on the collation and only print the warning if we
Heikki Linnakangas napsal(a):
Martijn van Oosterhout wrote:
On Wed, Sep 10, 2008 at 12:51:02PM +0300, Heikki Linnakangas wrote:
Since the set of collations isn't exactly denumerable, we need some way
to allow the user to specify the collation they want. The only
collation PostgreSQL knows
Simon Riggs wrote:
Perhaps it is sufficient to throw an error if the subxid cache
overflows? But I suspect that may not be acceptable...
Certainly not.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7
Sushant Sinha escribió:
Any status updates on the following patches?
1. Fragments in tsearch2 headlines:
http://archives.postgresql.org/pgsql-hackers/2008-08/msg00043.php
2. Bug in hlCover:
http://archives.postgresql.org/pgsql-hackers/2008-08/msg00089.php
Are these ready for review? If
Zdenek Kotala escribió:
Gregory Stark napsal(a):
AFAIK we can't easily connect to the new database and do some fiddling with
it, can we? If we could we could check if there are any non-empty indexes
which depend on the collation and only print the warning if we find any (and
even mark them
Patch #1. Teodor was fine with the previous version of the patch. After that
I modified it slightly to allow a FragmentDelimiter option and Teodor may
have to look at that.
Patch #2. I think this is a straigt forward bug fix.
-Sushant.
On Tue, Sep 16, 2008 at 11:27 AM, Alvaro Herrera [EMAIL
Hi,
I am implementing a new feature of postgres. The problem is
how to get the attribute of Aggregation. In
/src/backend/commands/explain.c,
I want to add a function after case AGG_HASHED to get the name
of this aggregation attribute in the table. How can I get it.
I tried to see (Agg *)
Hello,
Just curious if this list is being updated ..
http://wiki.postgresql.org/wiki/Todo:WishlistFor84
Steve
Joey K. escribió:
Hello,
Just curious if this list is being updated ..
http://wiki.postgresql.org/wiki/Todo:WishlistFor84
No.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
--
Sent via
On Mon, 2008-09-15 at 22:41 -0700, David Fetter wrote:
On Mon, Sep 15, 2008 at 06:46:16PM +0900, Tatsuo Ishii wrote:
* Single Evaluation:
with
foo(i) as (select random() as i)
select * from foo union all select * from foo;
i
---
On Tue, 2008-09-16 at 10:11 -0400, Alvaro Herrera wrote:
Right now we lock and unlock the clog for each committed subtransaction
at commit time, which is wasteful. A better scheme:
pre-scan the list of xids to derive list of pages
if we have just a single page to update
{
On Tue, 2008-09-16 at 15:38 +0100, Simon Riggs wrote:
On Tue, 2008-09-16 at 17:01 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
Subtransactions cause a couple of problems for Hot Standby:
Do we need to treat subtransactions any differently from normal
transactions? Just treat
On Tue, 2008-09-16 at 11:08 -0400, Alvaro Herrera wrote:
Simon Riggs wrote:
Perhaps it is sufficient to throw an error if the subxid cache
overflows? But I suspect that may not be acceptable...
Certainly not.
Yeh :-) ... it was just a rhetorical question. I'll try to avoid those.
--
Tatsuo Ishii [EMAIL PROTECTED] writes:
Included is the latest patches against CVS HEAD.
I spent some time reading this patch. Here are a few comments in
no particular order:
RangeRecursive node lacks copyfuncs/equalfuncs support.
Query.recursive is missed in equalfuncs.c. But rather than fix
We keep talking about EXEC_BACKEND mode, though until recently I had
misunderstood what that meant. I also realised that I have more than
once neglected to take it into account when writing a patch - one recent
patch failed to do this.
I can't find anything coherent in docs/readme/comments to
Jeff Davis [EMAIL PROTECTED] writes:
I think the right approach is to try to complete it so that everyone is
happy. I will work on this, but unfortunately I don't have a lot of time
right now, so I can't make any promises.
I think there are two significant bits there:
* Fixing the parsetree
Simon Riggs [EMAIL PROTECTED] writes:
We keep talking about EXEC_BACKEND mode, though until recently I had
misunderstood what that meant. I also realised that I have more than
once neglected to take it into account when writing a patch - one recent
patch failed to do this.
I can't find
Tom Lane wrote:
... SQL-spec interval literals. I decided to go look at exactly
how unfinished it was, and it turns out that it's actually pretty close.
Hence the attached proposed patch ;-)
Short summary:
I think this patch fixes a bug with sql-spec negative interval literals.
Longer.
I
Hi Heikki,
I'm still work on performance test, but I have following
comments/questions/suggestion:
1)
#define NodesPerPage (BLCKSZ - SizeOfPageHeaderData - offsetof(FSMPageData,
fp_nodes))
should be
#define NodesPerPage (BLCKSZ - MAXALIGN(SizeOfPageHeaderData) -
offsetof(FSMPageData,
Ron Mayer [EMAIL PROTECTED] writes:
Short summary:
I think this patch fixes a bug with sql-spec negative interval literals.
Hmm. I'm a bit concerned about possible side-effects on other cases:
what had been seen as two separate tokens will now become one token
for *all* datetime types, not
Tom Lane wrote:
Ron Mayer [EMAIL PROTECTED] writes:
Short summary:
I think this patch fixes a bug with sql-spec negative interval literals.
Hmm. I'm a bit concerned about possible side-effects on other cases:
what had been seen as two separate tokens will now become one token
for *all*
I had either on that a while back. I think the existing tuplestore can
be made to work without bad performance penaltiesbin the usual case.
The trick was to do it without making the code unreadable.
I can send the code I had but I doubt you want to use it as-is.
--
greg
--
Sent via
Ron Mayer [EMAIL PROTECTED] writes:
Tom Lane wrote:
Hmm. I'm a bit concerned about possible side-effects on other cases:
what had been seen as two separate tokens will now become one token
for *all* datetime types, not just interval. However, I can't
If it's a concern, I could make
Greg Stark [EMAIL PROTECTED] writes:
I had either on that a while back. I think the existing tuplestore can
be made to work without bad performance penaltiesbin the usual case.
The trick was to do it without making the code unreadable.
I can send the code I had but I doubt you want to use
Tom Lane wrote:
If I read SQL 200N's spec correctly
select interval '-1 1:00:00';
should mean-1 days -1 hours,
yet 8.3 sees it as -1 days +1 hours.
I think we are kind of stuck on this one. If we change it, then how
would one represent -1 days +1 hours? The spec's format is only
KaiGai Kohei wrote:
Could you tell me the current status of reviewing process in the
CommitFest:Sep?
Well ... I have analyzed this patch several times now. The
implementation appears to be pretty straightforward, and when the time
comes, we can discuss some of the low-level details.
At
Please provide some specifics. It's been a very long time since the
planner was completely unaware of the size of such a table. Lack of
stats is certainly a handicap, but I'm not convinced it should result
in horrible plans. Maybe a more appropriate answer to this type of
issue is to tweak
Simon Riggs wrote:
Disabling autovacuum can have catastrophic effects, since it disables
the ANALYZing of tables.
Can we have a mode where we disable autoVACUUM yet enable autoANALYZE?
You mean something like
autovacuum = on / off / analyze ?
We can certainly do that, but is there buy-in?
On Wed, 17 Sep 2008, Peter Eisentraut wrote:
System-wide consistency in access controls could be nice to have in some
cases. But is it really achievable? In the typical three-tier web
application scenario, do you really have system-wide consistency? Can
you configure your application
Andrew Chernow [EMAIL PROTECTED] writes:
Missed that one. Good catch :) Update attached.
Looking at this now. Question: why does PQgetResult invoke the
RESULTCREATE event only for non-error results? This seems a rather
odd asymmetry, particularly in view of the fact that a RESULTDESTROY
Tom Lane wrote:
Andrew Chernow [EMAIL PROTECTED] writes:
Missed that one. Good catch :) Update attached.
Looking at this now. Question: why does PQgetResult invoke the
RESULTCREATE event only for non-error results?
It didn't seem useful to have the eventproc implementation allocate its
Do we really have to make RECURSIVE a fully reserved keyword?
According to the standard, RECURSIVE is a reserved keyword, I believe.
(Actually, the patch makes it worse than reserved, by failing to
add it to the reserved_keywords list.)
Yes, it's a bug. Will fix...
--
Tatsuo Ishii
SRA OSS,
Andrew Chernow [EMAIL PROTECTED] writes:
Tom Lane wrote:
Looking at this now. Question: why does PQgetResult invoke the
RESULTCREATE event only for non-error results?
It didn't seem useful to have the eventproc implementation allocate its
private
storage (or do whatever prep work it
Andrew Chernow [EMAIL PROTECTED] writes:
Yeah. Good point. I fixed it to always fire events.
Applied with editorial revisions --- I don't think I changed any
functionality, but I fixed a number of corner-case bugs and
editorialized on style a bit.
The general question of symmetry between
Tatsuo Ishii [EMAIL PROTECTED] writes:
Do we really have to make RECURSIVE a fully reserved keyword?
According to the standard, RECURSIVE is a reserved keyword, I believe.
Sure, but our general rule is to make keywords no more reserved than
is absolutely necessary to make the bison grammar
Peter, thanks for your comments.
Let's review:
*) System-wide consistency in access controls could be nice to have in
some cases. But is it really achievable? In the typical three-tier web
application scenario, do you really have system-wide consistency? Can
you configure your
Seen on a lamp standard in south Delhi:
http://toroid.org/misc/ne.jpeg
-- ams
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, 17 Sep 2008, Abhijit Menon-Sen wrote:
Seen on a lamp standard in south Delhi:
http://toroid.org/misc/ne.jpeg
I found much better in Russia
http://www.sai.msu.su/~megera/postgres/files/PostgreSQL-Krylov.jpg
This is an illistration to russian fable about mighty elephant and
small,
68 matches
Mail list logo
