Recenly, I've been researching and putting together a proposal for window
functions. I have not finished this but when I do, I will post it. A nice
list of examples can be found here[1].
Rather than spend a lot of time talking about the problems window
functions present to the planner and executor
Hello,
This patch fixes a bug of case of extraction of pg_trigger.tgargs.
There was a problem when we used a long argument in defining trigger,
possibly resulting in a server crash.
Example:
We defined a CREATE TRIGGER such as follows and registered trigger.
In this case, the argument
I have a production database that is running on Win32 NTFS with
PostgreSQL 8.2.1. The drive that the data is stored on is dedicated to
PostgreSQL data files (transaction log stored on a separate disk) The
data partition is currently 44% fragmented, which I believe is
resulting in performance degr
Hi!
The attached patch fixes a bug in plpython.
This bug was found while creating sql from trigger functions
written in plpython and later running the generated sql.
The problem was that boolean was was silently converted to
integer, which is ok for python but fails when the created
sql is used.
Hello,
This patch fixes a bug of case of extraction of pg_trigger.tgargs.
There was a problem when we used a long argument in defining trigger,
possibly resulting in a server crash.
Example:
We defined a CREATE TRIGGER such as follows and registered trigger.
In this case, the argument
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Now, if some Windows-enabled person could step forward so that we can
> > suggest some tests to run, that would be great. Perhaps the solution to
> > the problem is to relax the conditions a little, so that two scans are
> > accepted
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Now, if some Windows-enabled person could step forward so that we can
> suggest some tests to run, that would be great. Perhaps the solution to
> the problem is to relax the conditions a little, so that two scans are
> accepted on that table instead of
Alvaro Herrera wrote:
> Stefan Kaltenbrunner wrote:
> > yeah - looks like it's the autovacuum change - snake is now passing the
> > numeric-test but still fails the stats one ...
>
> Interesting -- both yak and snake are failing in a very similar way.
> I'll investigate it tomorrow if no one beat
Ok, understood.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > One of our engineer claimed that double free bug itself is a
> > vulnerability, thus 8.2.1 release should be called as "security
> > release".
>
> [ shrug... ] AFAICS the crashing bugs we fixed in
- Original Message -
From: "Richard Huxton"
To: "Bruce Momjian" <[EMAIL PROTECTED]>
Cc: "Adnan DURSUN" <[EMAIL PROTECTED]>;
Sent: Thursday, January 18, 2007 5:57 PM
Subject: Re: [HACKERS] Temparary disable constraint
Not easily, because the view are bound to the object id of the tabl
Note that a bitmap scan or multi-pass indexscan (OR clause scan) has NIL
pathkeys since we can say nothing about the overall order of its result.
Yeah, but it might come back someday, so I didn't feel a need to change
that sentence...
Hmm. Our OR patch makes the same possibility by using Append
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> But it seems that we need a band-aid for 8.1 and earlier. The simplest
>> fix I can think of is for vacuum not to attempt to advance the
>> datvacuumxid/datfrozenxid fields if it skipped over any temp tables of
>> other backends. Tha
Tom Lane wrote:
> I wrote:
> > ... but I suddenly fear that we've missed a fundamental point about
> > pg_clog truncation. And WAL wraparound for that matter. To wit, a
> > sufficiently long-lived temp table could contain old XIDs, and there's
> > no way for anyone except the owning backend to cl
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> One of our engineer claimed that double free bug itself is a
> vulnerability, thus 8.2.1 release should be called as "security
> release".
[ shrug... ] AFAICS the crashing bugs we fixed in 8.2.1 can't be
exploited for anything beyond crashing the backend
Teodor Sigaev <[EMAIL PROTECTED]> writes:
>> Note that a bitmap scan or multi-pass indexscan (OR clause scan) has NIL
>> pathkeys since we can say nothing about the overall order of its result.
> It's seems to me that multi-pass indexscan was removed after introducing
> bitmapscan.
Yeah, but it
Note that a bitmap scan or multi-pass indexscan (OR clause scan) has NIL
pathkeys since we can say nothing about the overall order of its result.
It's seems to me that multi-pass indexscan was removed after introducing
bitmapscan.
--
Teodor Sigaev E-mail: [EMAI
> P = Parser. The reason for the _P is just to avoid conflicts with
> other definitions of the macro name, either in our own code or various
> platforms' header files. We haven't been totally consistent about it,
> but roughly speaking we've stuck _P on when it was either known or
> seemed likely
Bruce Momjian wrote:
Adnan DURSUN wrote:
Hi, Maybe added more further things to TODO list. Enabled /
disabled other objects like view/funtion. imagine a lot of
views that referances a table and i wanna drop a column on this
table that used by these views. Postgres doesnt allow this.
<[EMAIL PROTECTED]> writes:
> Many of the keywords listed in keywords.c are defined with symbolic
> names that end in '_P' (underscore P).
> What differentiates those keywords from the other keywords? What does
> the 'P' stand for?
P = Parser. The reason for the _P is just to avoid conflicts wit
I can't find an authoritative answer to this question.
Many of the keywords listed in keywords.c are defined with symbolic
names that end in '_P' (underscore P).
What differentiates those keywords from the other keywords? What does
the 'P' stand for?
Are those PostgreSQL-specific keywords (i.e.
Maybe you are right as technically but this behaver causes a lot
of maintance problem on a database that alot of view and functions that
depends on a table or a type. I think objects has a property if that object
is enable or not. We hope this problem can be resolved at 8.4 release.
Takayuki Tsunakawa wrote:
From: "Andrew Dunstan" <[EMAIL PROTECTED]>
Meeting FHS requirements is no bad thing, though. And the ability to
include a common configuration set in multiple instances is surely
useful to a number of people. After all, you aren't forced to use
these
facili
[EMAIL PROTECTED] wrote:
One thing: the patch server will have to run over HTTPS - that way we
can know that it is who it says it is.
Right, I'm not sure if the computer I'm proofing it on is the best
place for it so I didn't bother with the HTTPS, but should be trivial
to have it.
Yes, t
On Thu, 2007-01-18 at 11:53 +1100, Gavin Sherry wrote:
> the major rule in the executor: do what ever the plan tells you to do.
I thought the rule was: do what the plan tells you to do, as efficiently
as possible.
Turning an explicit step into a no-op seems like great execution to me.
In the cas
24 matches
Mail list logo
