On May 19, 2008, at 6:53 PM, Tom Lane wrote:
Another response I've heard is "but I don't want to make
inside-the-database changes, I want to propagate the state to
someplace
external". Of course that's completely broken too, because there is
*absolutely no way* you will ever make such chang
Tom Lane wrote:
* Trigger on rollback: what's that supposed to do? The current
transaction is already aborted, so the trigger has no hope of making any
database changes that will ever be visible to anyone.
It can however affect state in the backend doing the rollback, which can
be useful.
*
On Fri, 16 May 2008, Josh Berkus wrote:
For a hard-core benchmark, I'd try EAStress (SpecJAppserver Lite)
This reminds me...Jignesh had some interesting EAStress results at the
East conference I was curious to try and replicate more publicly one day.
Now that there are some initial benchmark
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> What I'm inclined to do is move the test for -Wl,--as-needed down till
>> after we've determined the readline dependent-libraries situation, and
>> then enable it only if we can still link readline with it on.
> Works for me. I don't
On May 15, 2008, at 1:40 AM, [EMAIL PROTECTED] wrote:
as I posted already in the general newsgroup our company has decided
that we would like to sponsor the implementation of materialized views
for Postgres.
However at the moment we have no idea about the complexity of the
implementation and ther
Bruce Momjian <[EMAIL PROTECTED]> writes:
>>> trigger on "prepare", "commit", "rollback", "savepoint",
>>
>> This is a sufficiently frequently asked question that I wish someone
>> would add an entry to the FAQ about it, or add it to the TODO list's
>> "Features we don't want" section.
> OK, re
Andrew Dunstan wrote:
>
>
> Fabien COELHO wrote:
> >
> > Dear Tom,
> >
> >>> trigger on "prepare", "commit", "rollback", "savepoint",
> >> Yup, and there won't be.
> >
> > That's a definite answer!
> >
> >> This has been suggested and rejected before. See the archives.
> >
> > I'll check into th
Tom Lane wrote:
I wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
It broke my FC6 box :-(
Yeah, I saw. I'm inclined to wait a day to get a handle on the scope
of the problem before trying to choose an appropriate fix.
So the returns are in, and buildfarm says: t
I wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
>> It broke my FC6 box :-(
> Yeah, I saw. I'm inclined to wait a day to get a handle on the scope
> of the problem before trying to choose an appropriate fix.
So the returns are in, and buildfarm says: this is only broken on
Red Hat-based sys
On Mon, May 19, 2008 at 1:40 PM, cinu <[EMAIL PROTECTED]> wrote:
> Hi All,
>
>
>
> I am trying to install PostgreSQL(postgresql-8.2.4-1PGDG.i686.rpm) on a 64
> bit machine, when I try to install I get the following error message:
>
>
>
> :/home/dump/postgres32bit # rpm -ivh postgresql-server-8.2.4-
Hi All,
I am trying to install PostgreSQL(postgresql-8.2.4-1PGDG.i686.rpm) on a 64 bit machine, when I try to install I get the following error message:
:/home/dump/postgres32bit # rpm -ivh postgresql-server-8.2.4-1PGDG.i686.rpm postgresql-8.2.4-1PGDG.i686.rpm postgresql-libs-8.2.4-1PGDG.i686.
Gregory Stark írta:
"Martijn van Oosterhout" <[EMAIL PROTECTED]> writes:
From an implementation point of view, the only difference between
breadth-first and depth-first is that your tuplestore needs to be LIFO
instead of FIFO.
I think it's not so simple. How do you reconcile that con
Fabien COELHO wrote:
Dear Tom,
trigger on "prepare", "commit", "rollback", "savepoint",
Yup, and there won't be.
That's a definite answer!
This has been suggested and rejected before. See the archives.
I'll check into that.
This is a sufficiently frequently asked question that I
Dear Tom,
trigger on "prepare", "commit", "rollback", "savepoint",
Yup, and there won't be.
That's a definite answer!
This has been suggested and rejected before. See the archives.
I'll check into that.
It seems to me that such triggers would be useful to help implement a
"simple" (hm
Howdy,
I just saw Robert Lor's patch w.r.t. dtrace probes. It looks very
similar in what we've done. We run a nice set of probes in production
here that allow us to track the details of checkpointing and statement
execution. I've given a few presentations around these probes and
have h
"Martijn van Oosterhout" <[EMAIL PROTECTED]> writes:
> From an implementation point of view, the only difference between
> breadth-first and depth-first is that your tuplestore needs to be LIFO
> instead of FIFO.
I think it's not so simple. How do you reconcile that concept with the join
plans l
Fabien COELHO <[EMAIL PROTECTED]> writes:
> I've played with triggers a bit, and I have noticed that there seem to be
> no way to add a trigger on events such as "prepare", "commit", "rollback",
> "savepoint",
Yup, and there won't be. This has been suggested and rejected before.
See the archive
Hannu Krosing <[EMAIL PROTECTED]> writes:
> How will we know then that all listeners have received their events ?
We won't, but we don't know that now. In both the current
implementation and this proposed one, the most you can tell is whether a
backend has absorbed an event notification, not whet
On Sun, 2008-05-18 at 22:17 -0700, David Fetter wrote:
> On Mon, May 19, 2008 at 12:21:20AM -0400, Gregory Stark wrote:
> > "Zoltan Boszormenyi" <[EMAIL PROTECTED]> writes:
> > > Also, it seems there are no infinite recursion detection:
> > >
> > > # with recursive x(level, parent, child) as (
> >
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > Recently while adding $PostgreSQL markers to a bunch of .c and .h files
> > I ran into trouble with the ecpg regression tests and had to revert the
> > change for a handful of files. However, it occurred to me
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Greg Smith <[EMAIL PROTECTED]> writes:
> > When we noticed this recently, my digging suggested you'll be hard pressed
> > to have a RedHat system now without those two installed.
>
> Indeed, I've not heard any squawks from the field yet. It's still
> wrong
Hannu Krosing wrote:
On Sun, 2008-05-18 at 16:00 -0400, Andrew Dunstan wrote:
I am working on moving the notification buffer into shared memory as
previously discussed. Since pg_listener will no longer exist, I think we
need to provide a couple of information functions.
I suggest:
pg_li
On Mon, May 19, 2008 at 05:57:17PM +0900, Yoshiyuki Asaba wrote:
> Hi,
>
> > I think it's the other way around. The server should not emit
> > infinite number of records.
>
> How about adding new GUC parameter "max_recursive_call"?
Couldn't we just have it pay attention to the existing
max_stack
On 18/05 00.59, Tom Lane wrote:
> Greg Smith <[EMAIL PROTECTED]> writes:
> > On Sat, 17 May 2008, Tom Lane wrote:
> >> I was displeased to discover just now that in a standard RPM build of
> >> PG 8.3, psql and the other basic client programs pull in libxml2 and
> >> libxslt; this creates a package
Martijn van Oosterhout írta:
On Mon, May 19, 2008 at 11:56:17AM +0200, Zoltan Boszormenyi wrote:
>From an implementation point of view, the only difference between
breadth-first and depth-first is that your tuplestore needs to be LIFO
instead of FIFO.
Are you sure? I think a LIF
On Mon, May 19, 2008 at 11:56:17AM +0200, Zoltan Boszormenyi wrote:
> >From an implementation point of view, the only difference between
> >breadth-first and depth-first is that your tuplestore needs to be LIFO
> >instead of FIFO.
>
> Are you sure? I think a LIFO tuplestore would simply return rev
Martijn van Oosterhout írta:
On Mon, May 19, 2008 at 08:19:17AM +0200, Zoltan Boszormenyi wrote:
The standard has a clause to specify depth-first order. However doing a
depth-first traversal would necessitate quite a different looking plan and
it's far less obvious (to me anyways) how to do i
Dear pgdev,
I've played with triggers a bit, and I have noticed that there seem to be
no way to add a trigger on events such as "prepare", "commit", "rollback",
"savepoint", if I'm not mistaken. Also, possible interesting events could
be "create", "alter" and so, but it may already be possibl
Martijn van Oosterhout írta:
On Mon, May 19, 2008 at 08:19:17AM +0200, Zoltan Boszormenyi wrote:
The standard has a clause to specify depth-first order. However doing a
depth-first traversal would necessitate quite a different looking plan and
it's far less obvious (to me anyways) how to do i
Yoshiyuki Asaba írta:
Hi,
From: Zoltan Boszormenyi <[EMAIL PROTECTED]>
Subject: Re: [PATCHES] WITH RECURSIVE patch V0.1
Date: Mon, 19 May 2008 08:19:17 +0200
Also, it seems there are no infinite recursion detection:
# with recursive x(level, parent, child) as (
select 1::integer, * from
Hi,
From: Zoltan Boszormenyi <[EMAIL PROTECTED]>
Subject: Re: [PATCHES] WITH RECURSIVE patch V0.1
Date: Mon, 19 May 2008 08:19:17 +0200
> >> Also, it seems there are no infinite recursion detection:
> >>
> >> # with recursive x(level, parent, child) as (
> >>select 1::integer, * from test_con
On Mon, May 19, 2008 at 08:19:17AM +0200, Zoltan Boszormenyi wrote:
> >The standard has a clause to specify depth-first order. However doing a
> >depth-first traversal would necessitate quite a different looking plan and
> >it's far less obvious (to me anyways) how to do it.
>
> That would be even
On Sat, May 17, 2008 at 03:52:07PM -0400, Tom Lane wrote:
> So I coded this up, and fortunately thought to try it with ecpg's tests
> before committing:
> ...
> test preproc/whenever ... FAILED: test process exited with exit code 1
> ...
> Apparently the exit(1) is intentional in that test.
> .
Title: Agro-Annuaire.com
Si vous ne
parvenez pas à visualiser correctement cette newsletter,
cliquez ici
Recom
On Sun, 2008-05-18 at 16:00 -0400, Andrew Dunstan wrote:
> I am working on moving the notification buffer into shared memory as
> previously discussed. Since pg_listener will no longer exist, I think we
> need to provide a couple of information functions.
>
> I suggest:
>
> pg_listened_events(o
Gregory Stark írta:
This is indeed really cool. I'm sorry I haven't gotten to doing what I
promised in this area but I'm glad it's happening anyways.
"Zoltan Boszormenyi" <[EMAIL PROTECTED]> writes:
Can we get the rows in tree order, please?
...
After all, I didn't specify any ORDER BY cl
36 matches
Mail list logo
