Greg Smith wrote:
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
On Tue, Sep 16, 2008 at 08:59:08PM -0400, Alvaro Herrera wrote:
> 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
>
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, bu
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
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 appl
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
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 RE
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 w
> 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,
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 it
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
ev
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 server
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
> 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 t
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 thi
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
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 t
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 mak
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 pgsql-h
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* da
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, no
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, fp_n
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
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
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 parsetr
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 exp
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 f
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
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?
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 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
> >
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
Hello,
Just curious if this list is being updated ..
http://wiki.postgresql.org/wiki/Todo:WishlistFor84
Steve
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 *) plan)
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 PRO
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 mar
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
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
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 about
Gregory Stark napsal(a):
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
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 a
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 NU
"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
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 utt
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
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
> 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
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
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 poin
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 committ
"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?
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 fo
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
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
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 e
>
>
> > 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
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
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 o
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 WA
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
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 pa
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
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
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 w
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: read, written
Good point. Seems like it should be changed, but I am no
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
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 a
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 <[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 b
68 matches
Mail list logo
