2010/2/21 Andrew Dunstan :
>
>
> Lucas wrote:
>>
>> Tom,
>>
>> I believe that "in core" may be "installed by default" in case of
>> the pgAgent or similar solution...
>>
>> Many big companies does not allow the developers to configure and
>> install components we need to request eve
Robert Haas wrote:
It seems to me that you need to start by thinking about what kinds of
queries could be usefully parallelized. What I think you're proposing
here, modulo large amounts of hand-waving, is that we should basically
find a branch of the query tree, cut it off, and make that branc
On Feb 20, 2010, at 10:56 PM, Tom Lane wrote:
> Robert Haas writes:
>> I think the most likely use of CREATE OR REPLACE [LANGUAGE] is to
>> avoid
>> an error when creating a language that might already exist. But it
>> doesn't seem like the only possible use. Perhaps you've done an
>> in-place
Robert Haas writes:
> I think the most likely use of CREATE OR REPLACE [LANGUAGE] is to avoid
> an error when creating a language that might already exist. But it
> doesn't seem like the only possible use. Perhaps you've done an
> in-place upgrade to version 9.0 and you'd like to add an inline
>
On Sat, Feb 20, 2010 at 6:42 PM, David Christensen wrote:
> In what cases would one be able to meaningfully REPLACE a language, other
> than to not break when encountering an already installed language? i.e., in
> which cases would this not invalidate functions already written if you were
> chang
On Sat, Feb 20, 2010 at 8:31 AM, Dimitri Fontaine
wrote:
>> This is really a topic for another thread, but at 100,000 feet it
>> seems to me that the hardest question is - how will you decide which
>> operations to parallelize in the first place? Actually making it
>> happen is really hard, too,
Ah! wxWidgets... Yes, i knew there was something i didn't like about
pgAgent. So is not as simple as installing it
2010/2/20, Dave Page :
> On Sat, Feb 20, 2010 at 10:03 PM, Dimitri Fontaine
> wrote:
>> Dave Page writes:
>>> Why not just use pgAgent? It's far more flexible than the design
>>> yo
On Feb 20, 2010, at 8:06 PM, "Joshua D. Drake"
wrote:
> There is zero technical reason for this to be in core.
>
> That doesn't mean it isn't a really good idea. It would be nice to
> have
> a comprehensive job scheduling solution that allows me to continue
> abstract away from external solutions
Tom Lane wrote:
> David Christensen writes:
> > On Feb 20, 2010, at 5:16 PM, Bruce Momjian wrote:
> >> If you implement #1, why would you have pg_dump issue CREATE OR
> >> REPLACE LANGUAGE? We don't do the "OR REPLACE" part for any other
> >> object I can think of, so why would pg_dump do it for
On Sat, 2010-02-20 at 18:19 -0500, Tom Lane wrote:
> Dimitri Fontaine writes:
> > Dave Page writes:
> >> Why not just use pgAgent? It's far more flexible than the design
> >> you've suggested, and already exists.
>
> > What would it take to have it included in core,
>
> I don't think this reall
David Christensen writes:
> On Feb 20, 2010, at 5:16 PM, Bruce Momjian wrote:
>> If you implement #1, why would you have pg_dump issue CREATE OR
>> REPLACE LANGUAGE? We don't do the "OR REPLACE" part for any other
>> object I can think of, so why would pg_dump do it for languages by
>> default?
On Sun, Feb 21, 2010 at 12:38 AM, Jaime Casanova
wrote:
> On Sat, Feb 20, 2010 at 7:32 PM, Dave Page wrote:
>> On Sun, Feb 21, 2010 at 12:03 AM, Jaime Casanova
>> wrote:
>>> On Sat, Feb 20, 2010 at 4:37 PM, Dave Page wrote:
On Sat, Feb 20, 2010 at 9:33 PM, Jaime Casanova
wrote:
>
Lucas wrote:
Tom,
I believe that "in core" may be "installed by default" in case of
the pgAgent or similar solution...
Many big companies does not allow the developers to configure and
install components we need to request everthing in 10 copies
of forms...
By mak
On Sat, Feb 20, 2010 at 10:03 PM, Dimitri Fontaine
wrote:
> Dave Page writes:
>> Why not just use pgAgent? It's far more flexible than the design
>> you've suggested, and already exists.
>
> What would it take to have it included in core, so that it's not a
> separate install to do? I'd love to h
On Sat, Feb 20, 2010 at 7:32 PM, Dave Page wrote:
> On Sun, Feb 21, 2010 at 12:03 AM, Jaime Casanova
> wrote:
>> On Sat, Feb 20, 2010 at 4:37 PM, Dave Page wrote:
>>> On Sat, Feb 20, 2010 at 9:33 PM, Jaime Casanova
>>> wrote:
Hi,
I'm trying to figure out how difficult is this
>>>
On Feb 20, 2010, at 3:57 PM, Tom Lane wrote:
>> And if so, would that be a syntax we'd want to accept in general?
>> Could the be a CREATE IF NOT EXISTS TABLE?
>
> *Please* go read some of the linked older discussions before you propose
> that. I don't want to rehash it yet again.
:-) Was jus
On Sat, Feb 20, 2010 at 11:55 PM, Lucas wrote:
> I believe that a database scheduler would allow me to drop 20 thousand lines
> of java code in my server...
How does that work? If you don't have a scheduler in the database, or
pgAgent, why aren't you using cron or Windows task scheduler, neither
On Sun, Feb 21, 2010 at 12:03 AM, Jaime Casanova
wrote:
> On Sat, Feb 20, 2010 at 4:37 PM, Dave Page wrote:
>> On Sat, Feb 20, 2010 at 9:33 PM, Jaime Casanova
>> wrote:
>>> Hi,
>>>
>>> I'm trying to figure out how difficult is this
>>
>> Why not just use pgAgent? It's far more flexible than the
On 2/20/10 3:58 PM, Josh Berkus wrote:
> All,
>
> Problem with the alpha:
>
> initdb --version
> initdb (PostgreSQL) 8.5devel
>
> psql --version
> psql (PostgreSQL) 8.5devel
> contains support for command-line editing
Never mind. My build mistake. Reads 9.0 the way it should.
--Josh
--
Se
On Sat, Feb 20, 2010 at 4:37 PM, Dave Page wrote:
> On Sat, Feb 20, 2010 at 9:33 PM, Jaime Casanova
> wrote:
>> Hi,
>>
>> I'm trying to figure out how difficult is this
>
> Why not just use pgAgent? It's far more flexible than the design
> you've suggested, and already exists.
>
- it's not that
All,
Problem with the alpha:
initdb --version
initdb (PostgreSQL) 8.5devel
psql --version
psql (PostgreSQL) 8.5devel
contains support for command-line editing
Otherwise, builds great on OSX 10.5.
--Josh Berkus
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make ch
"David E. Wheeler" writes:
> Just throwing this out there: would a syntax such as CREATE OF NOT
> EXISTS, a complement to DROP IF EXISTS, avoid the permissions issue?
No, it'd just move it to a different place: now you risk breaking
the restored state rather than pre-existing state.
> And if
Tom,
I believe that "in core" may be "installed by default" in case of the
pgAgent or similar solution...
Many big companies does not allow the developers to configure and install
components we need to request everthing in 10 copies of forms...
By making it "in core" or "installed by default
On Feb 20, 2010, at 15:18, Andrew Dunstan wrote:
I also think we need to state explicitly that module authors can not
expect build files to be version ignorant and always work. Even if
we do something that handles this particular issue, that is likely
to be a happy coincidence rather than
On Feb 20, 2010, at 15:03, Tom Lane wrote:
Well, I'm willing to implement CREATE OR REPLACE LANGUAGE if people
are agreed that that's a reasonable fix. I'm slightly worried about
the restore-could-change-ownership issue, but I think that's much less
likely to cause problems than embedding spec
On Feb 20, 2010, at 5:16 PM, Bruce Momjian wrote:
Robert Haas wrote:
On Sat, Feb 20, 2010 at 5:53 PM, Tom Lane wrote:
Robert Haas writes:
On Sat, Feb 20, 2010 at 2:51 PM, Bruce Momjian
wrote:
Well, I was asking why you labeled it "must fix" rather than
"should
fix". ?I am fine with th
Dimitri Fontaine writes:
> Dave Page writes:
>> Why not just use pgAgent? It's far more flexible than the design
>> you've suggested, and already exists.
> What would it take to have it included in core,
I don't think this really makes sense. There's basically no argument
for having it in core
On Sat, Feb 20, 2010 at 10:03 PM, Dimitri Fontaine
wrote:
> What would it take to have it included in core, so that it's not a
> separate install to do? I'd love to have some support for running my
> maintenance pl functions directly from the database. I mean without
> installing, running and moni
Tom Lane wrote:
> Robert Haas writes:
> > On Sat, Feb 20, 2010 at 5:53 PM, Tom Lane wrote:
> >> I don't think that the way to fix this is to have an ugly kluge in
> >> pg_dump and another ugly kluge in pg_regress (and no doubt ugly kluges
> >> elsewhere by the time all the dust settles).
>
> > I
Robert Haas wrote:
IMO, the non-ugly kludges are (1) implement CREATE OR REPLACE LANGUAGE
and (2) revert the original patch. Do you want to do one of those
(which?) or do you have another idea?
I thought we seemed to be converging on some agreement on CREATE OR
REPLACE LANGUAGE.
If
Robert Haas wrote:
> On Sat, Feb 20, 2010 at 5:53 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> On Sat, Feb 20, 2010 at 2:51 PM, Bruce Momjian wrote:
> >>> Well, I was asking why you labeled it "must fix" rather than "should
> >>> fix". ?I am fine with the pg_regress.c change.
> >
> >> Yeah,
Robert Haas writes:
> On Sat, Feb 20, 2010 at 5:53 PM, Tom Lane wrote:
>> I don't think that the way to fix this is to have an ugly kluge in
>> pg_dump and another ugly kluge in pg_regress (and no doubt ugly kluges
>> elsewhere by the time all the dust settles).
> IMO, the non-ugly kludges are (
On Sat, Feb 20, 2010 at 5:53 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sat, Feb 20, 2010 at 2:51 PM, Bruce Momjian wrote:
>>> Well, I was asking why you labeled it "must fix" rather than "should
>>> fix". I am fine with the pg_regress.c change.
>
>> Yeah, if it makes life easier for other
Robert Haas writes:
> On Sat, Feb 20, 2010 at 2:51 PM, Bruce Momjian wrote:
>> Well, I was asking why you labeled it "must fix" rather than "should
>> fix". I am fine with the pg_regress.c change.
> Yeah, if it makes life easier for other people, I say we go for it.
I don't think that the way
>
> pg_job (
> oid -- use the oid as pk
> jobname
> jobdatoid -- job database oid
> jobowner -- for permission's checking
> jobstarttime -- year to minute
> jobfrequency -- an interval?
> jobnexttime or joblasttime
> jobtype -- if we ar
Dave Page writes:
> Why not just use pgAgent? It's far more flexible than the design
> you've suggested, and already exists.
What would it take to have it included in core, so that it's not a
separate install to do? I'd love to have some support for running my
maintenance pl functions directly fr
On Sat, Feb 20, 2010 at 2:51 PM, Bruce Momjian wrote:
> David E. Wheeler wrote:
>> On Feb 20, 2010, at 11:03 AM, Bruce Momjian wrote:
>>
>> >> There is also the "must fix" issue with pg_regress.
>> >
>> > Why? My pg_regress runs just fine. If you are talking about 3rd party
>> > modules, I sugge
On Sat, Feb 20, 2010 at 4:33 PM, Jaime Casanova
wrote:
> Hi,
>
> I'm trying to figure out how difficult is this
>
> What we need:
> - a shared catalog
> - an API for filling the catalog
> - a scheduler daemon
> - pg_dump support
>
>
> A shared catalog
> -
> Why shared? obvi
On Sat, Feb 20, 2010 at 9:33 PM, Jaime Casanova
wrote:
> Hi,
>
> I'm trying to figure out how difficult is this
Why not just use pgAgent? It's far more flexible than the design
you've suggested, and already exists.
--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
--
Sent via pgsql-ha
Hi,
I'm trying to figure out how difficult is this
What we need:
- a shared catalog
- an API for filling the catalog
- a scheduler daemon
- pg_dump support
A shared catalog
-
Why shared? obviously because we don't want to scan all database's
pg_job every time the daemon
Simon Riggs wrote:
> On Fri, 2009-10-23 at 10:04 -0400, Tom Lane wrote:
> > Simon Riggs writes:
> > > On Fri, 2009-10-23 at 19:38 +0900, KaiGai Kohei wrote:
> > >> Sorry, what is happen if function is marked as "plan security"?
> >
> > > I was suggesting an intelligent default by which we could d
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> I would have said that some time ago, except that I think we have a
> >> "must fix" issue here: isn't pg_upgrade broken for any database
> >> containing plpgsql? A decent solution for that probably will allow
> >> something to fall
Bruce Momjian writes:
> Tom Lane wrote:
>> I would have said that some time ago, except that I think we have a
>> "must fix" issue here: isn't pg_upgrade broken for any database
>> containing plpgsql? A decent solution for that probably will allow
>> something to fall out for the regression test
David E. Wheeler wrote:
> On Feb 20, 2010, at 11:03 AM, Bruce Momjian wrote:
>
> >> There is also the "must fix" issue with pg_regress.
> >
> > Why? My pg_regress runs just fine. If you are talking about 3rd party
> > modules, I suggested conditional Makefile rules.
>
> Because you can either m
On Feb 20, 2010, at 11:03 AM, Bruce Momjian wrote:
>> There is also the "must fix" issue with pg_regress.
>
> Why? My pg_regress runs just fine. If you are talking about 3rd party
> modules, I suggested conditional Makefile rules.
Because you can either make the simple change to pg_regress tha
David E. Wheeler wrote:
> On Feb 20, 2010, at 9:49 AM, Tom Lane wrote:
>
> >> This discussion is sounding very design-ish, which makes me think we
> >> should just leave things unchanged for 9.0 and have external regression
> >> test designers work around this problem in their Makefiles, as Alvaro
On Feb 20, 2010, at 9:49 AM, Tom Lane wrote:
>> This discussion is sounding very design-ish, which makes me think we
>> should just leave things unchanged for 9.0 and have external regression
>> test designers work around this problem in their Makefiles, as Alvaro
>> suggested.
>
> I would have s
Tom Lane wrote:
> Bruce Momjian writes:
> > This discussion is sounding very design-ish, which makes me think we
> > should just leave things unchanged for 9.0 and have external regression
> > test designers work around this problem in their Makefiles, as Alvaro
> > suggested.
>
> I would have sa
Bruce Momjian writes:
> Tom Lane wrote:
>> Chris Campbell writes:
>>> Is there a way to detect when the SSL library has renegotiation disabled?
>>
>> Probably not. The current set of emergency security patches would
>> certainly not have exposed any new API that would help us tell this :-(
>>
Bruce Momjian writes:
> This discussion is sounding very design-ish, which makes me think we
> should just leave things unchanged for 9.0 and have external regression
> test designers work around this problem in their Makefiles, as Alvaro
> suggested.
I would have said that some time ago, except
Tom Lane wrote:
> Chris Campbell writes:
> > Is there a way to detect when the SSL library has renegotiation disabled?
>
> Probably not. The current set of emergency security patches would
> certainly not have exposed any new API that would help us tell this :-(
>
> If said patches were done pr
Dimitri Fontaine wrote:
> Tom Lane writes:
> > Well, that isn't really going to help us in terms of what to do for 9.0.
> > But the possibility that something like this might happen in future is
> > one thing that makes me hesitant about extending CREATE LANGUAGE right
> > now --- the more bells a
On Saturday 20 February 2010 17:34:50 Tom Lane wrote:
> hei...@postgresql.org (Heikki Linnakangas) writes:
> > Forbid setval() during recovery. This prevents the PANIC reported by
> > Erik Rijkers. Patch by Andres Freund.
>
> ISTM this is the wrong fix. The real bug is that setval() doesn't
> ch
Tom Lane writes:
> Indeed, and if I were setting out to parallelize queries in PG (which
> I am not), subplans would be the last thing I would think about. You
> could put an enormous amount of work in there and have nothing much
> to show for it, because the construct doesn't even arise in many
hei...@postgresql.org (Heikki Linnakangas) writes:
> Forbid setval() during recovery. This prevents the PANIC reported by
> Erik Rijkers. Patch by Andres Freund.
ISTM this is the wrong fix. The real bug is that setval() doesn't
check XactReadOnly. Now XactReadOnly is only a "soft" read only
mod
On Fri, Feb 19, 2010 at 10:22 PM, Tom Lane wrote:
> Robert Haas writes:
>> So I guess there are two issues here: (1) somehow I feel like we
>> should be telling the user what expression is being used to initialize
>> $0, $1, etc. when they are PARAM_EXEC parameters;
>
> Maybe, but the only reason
Tom Lane wrote:
Andrew Dunstan writes:
With the following settings
custom_variable_classes = 'auto_explain'
auto_explain.log_min_duration = 0
auto_explain.log_format = 'xml'
auto_explain.log_analyze = on
auto_explain.log_verbose = on
shared_preload_librar
Robert Haas writes:
> On Sat, Feb 20, 2010 at 7:53 AM, Greg Stark wrote:
>> Perhaps it would be clearer to display the "(Subplan 1)" in a function
>> call style format like Subplan1(b.oid)
> I thought about that, too... maybe for 9.1 we should consider it. It
> might be nice to add some sort o
Robert Haas writes:
> On Sat, Feb 20, 2010 at 6:57 AM, Dimitri Fontaine
>> Ok that's a far stretch from the question at hand, but would that be a
>> plausible approach to have parallel queries in PostgreSQL ?
> This is really a topic for another thread, but at 100,000 feet it
> seems to me that t
Robert Haas writes:
> On Sat, Feb 20, 2010 at 6:57 AM, Dimitri Fontaine
> wrote:
>> How much does this stuff is dependent on the current state of the
>> backend?
>
> A whole lot.
Bad news.
>> Ok that's a far stretch from the question at hand, but would that be a
>> plausible approach to have pa
On Sat, Feb 20, 2010 at 7:53 AM, Greg Stark wrote:
> On Sat, Feb 20, 2010 at 4:33 AM, Tom Lane wrote:
>> It's really not much different from a function call with subplans as
>> functions.
>
> Perhaps it would be clearer to display the "(Subplan 1)" in a function
> call style format like Subplan1(
On Sat, Feb 20, 2010 at 6:57 AM, Dimitri Fontaine
wrote:
> Tom Lane writes:
>> It's really not much different from a function call with subplans as
>> functions. The PARAM_EXEC stuff looks just like 1950's era
>> non-reentrant function parameter passing mechanisms, back before anybody
>> had tho
On Fri, Feb 19, 2010 at 11:58 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Feb 19, 2010 at 11:33 PM, Tom Lane wrote:
>>> We can also fetch that tuple's
>>> relfilenode and pass it to the subplan, which we do by setting the $0
>>> Param value before invoking the subplan.
>
>> Are the same
On Sat, Feb 20, 2010 at 4:33 AM, Tom Lane wrote:
> It's really not much different from a function call with subplans as
> functions.
Perhaps it would be clearer to display the "(Subplan 1)" in a function
call style format like Subplan1(b.oid)
--
greg
--
Sent via pgsql-hackers mailing list (pg
Tom Lane writes:
> It's really not much different from a function call with subplans as
> functions. The PARAM_EXEC stuff looks just like 1950's era
> non-reentrant function parameter passing mechanisms, back before anybody
> had thought of recursive functions and they passed a function's
> param
Peter Eisentraut wrote:
Alpha4 has been bundled and is available at
http://developer.postgresql.org/~petere/alpha/
Please check that it is sane.
Since I'll be away for the next few days, someone has to take it from
here: write announcement, move tarballs, send announcement.
I can pass make
66 matches
Mail list logo
