Martin Pihlak <[EMAIL PROTECTED]> writes:
> Yes, creating a new message type was a bit short sighted -- attached is a
> patch
> that uses syscache invalidation messages instead. This also adds additional
> tupleId field to SharedInvalCatcacheMsg. This is used to identify the
> invalidated tuple in
Tom Lane wrote:
> I hadn't read it yet, but that makes it wrong already. There's no need
> for any new inval traffic --- the existing syscache inval messages on
> pg_proc entries should serve fine.
Yes, creating a new message type was a bit short sighted -- attached is a patch
that uses syscache
On Aug 20, 2008, at 9:18 AM, Tom Lane wrote:
However I have no hard evidence to back up drawing the line there
rather
than somewhere else. Anyone have data on what sort of DDL changes are
common in their applications?
I've worked in environments where we used stored functions
extensively
On Wed, Aug 20, 2008 at 05:03:19PM +0300, Asko Oja wrote:
>
> Lets get on with 8.4
Oh, I shoulda mentioned that, too -- I completely support doing this
work for 8.4. (I can think of more than one case where this feature
alone would be worth the upgrade.)
A
--
Andrew Sullivan
[EMAIL PROTECTED]
On Wed, 2008-08-20 at 08:50 -0400, Andrew Dunstan wrote:
>
> Asko Oja wrote:
> > I do get the impression that Tom who would prefer to get all the pl's
> > out of PostgreSQL and live happily ever after with pure SQL standard.
> >
> >
>
> I have not seen the slightest evidence of this, and don't b
David Fetter napsal(a):
On Tue, Aug 19, 2008 at 09:50:53PM -0400, Tom Lane wrote:
David Fetter <[EMAIL PROTECTED]> writes:
On Tue, Aug 19, 2008 at 07:45:16PM -0400, Tom Lane wrote:
FWIW, given that there will probably always be corner cases. I can
see the attraction in Simon's suggestion of pr
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> This is where the interesting questions are:
> http://archives.postgresql.org/message-id/10333.1219179364%40sss.pgh.pa.us
Upthread, someone speculated about solving the problem by forcing plan
cache flush on *any* catalog change. I think that's probabl
Thanks for a nice replay Andrew.
So best solution for 8.3 is update pg_proc set proname = proname; whenever
you need to drop and create functions or some in house patch.
Lets get on with 8.4
Asko
On Wed, Aug 20, 2008 at 4:16 PM, Andrew Sullivan <[EMAIL PROTECTED]>wrote:
> On Wed, Aug 20, 2008
Asko Oja escribió:
> In the first message Martin asked
> "There are probably a lot of details that I have overlooked. I'd be really
> thankful for some constructive comments and criticism. Especially, what
> needs
> to be done to have this in the core. Feedback appreciated."
>
> Can we get back
Asko Oja wrote:
I do get the impression that Tom who would prefer to get all the pl's
out of PostgreSQL and live happily ever after with pure SQL standard.
I have not seen the slightest evidence of this, and don't believe it for
a minute.
I understand some of the frustration you are fee
On Wed, Aug 20, 2008 at 09:16:56AM -0400, Andrew Sullivan wrote:
> On Wed, Aug 20, 2008 at 03:12:43PM +0300, Asko Oja wrote:
>
> > - If there is nothing that can be done in 8.3 at least warning should be
> > added into the documentation. It will be just one more don't in our long
> > list don'ts
On Wed, Aug 20, 2008 at 03:12:43PM +0300, Asko Oja wrote:
> - If there is nothing that can be done in 8.3 at least warning should be
> added into the documentation. It will be just one more don't in our long
> list don'ts for our developers.
I am in favour of that change in the 8.3 branch.
>
>
The lack of plan invalidation is limitation that also has two bugs attached
to it.
I agree that full fledged patch to fix all the isssues should not be done in
8.3.
I can't agree that effort to get the bugs fixed already in 8.3 should not be
made.
I can understand that hackers here have learned to
On Tue, 2008-08-19 at 19:45 -0400, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > If there is plan invalidation then you just change called1() to return
> > one more field and that's it - no juggling with C) and D) and generally
> > less things that can go wrong.
>
> That is a pur
Le mercredi 20 août 2008, Tom Lane a écrit :
> That just begs the question of what's the difference between a "bug" and
> a "limitation". AFAICS, having such a policy/guideline/whatchacallit
> in place wouldn't have done a single thing to stop the current flamewar,
> because the people who want th
Am 19.08.2008 um 20:47 schrieb Tom Lane:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Joshua Drake wrote:
Is our backpatch policy documented? It does not appear to be in
developer FAQ.
Seems we need to add it.
I'm not sure that I *want* a formal written-down backpatch policy.
Whether (and h
On Tue, Aug 19, 2008 at 09:50:53PM -0400, Tom Lane wrote:
> David Fetter <[EMAIL PROTECTED]> writes:
> > On Tue, Aug 19, 2008 at 07:45:16PM -0400, Tom Lane wrote:
> >> FWIW, given that there will probably always be corner cases. I can
> >> see the attraction in Simon's suggestion of providing a way
Every thread we are concerned in turns into something strange thing that is
almost entirely differnet from the original intention. First thread we
started was with the intention to discuss how we should handle the problem.
Instead of discussion it was trolled into oblivion. Then we thought so what
David Fetter <[EMAIL PROTECTED]> writes:
> On Tue, Aug 19, 2008 at 07:45:16PM -0400, Tom Lane wrote:
>> FWIW, given that there will probably always be corner cases. I can
>> see the attraction in Simon's suggestion of providing a way to
>> manually issue a system-wide forced plan flush.
> Would th
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Right. And even if it is a bug the question might be "what sort of bug
> is it?" We might well be prepared to take some risks with code stability
> to plug security or data corruption bugs, a lot more than we would for
> other sorts of bugs.
As indee
On Tue, Aug 19, 2008 at 07:45:16PM -0400, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > If there is plan invalidation then you just change called1() to
> > return one more field and that's it - no juggling with C) and D)
> > and generally less things that can go wrong.
>
> That i
Tom Lane wrote:
Also, there are a whole lot more considerations in a backpatch decision
than just "is it a bug". The (estimated) risk of creating new bugs and
the extent to which the patch will change behavior that apps might be
relying on are two big reasons why we might choose not to back-pa
Hannu Krosing <[EMAIL PROTECTED]> writes:
> If there is plan invalidation then you just change called1() to return
> one more field and that's it - no juggling with C) and D) and generally
> less things that can go wrong.
That is a pure flight of fancy. Adjusting a function's API generally
requir
Joshua Drake <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> wrote:
>> I'm not sure that I *want* a formal written-down backpatch policy.
> Then we write a formal guideline. It really isn't fair to new developers
> to not have any idea how they are going to be able to get a patch
> appl
On Wed, 2008-08-20 at 00:11 +0300, Hannu Krosing wrote:
> On Tue, 2008-08-19 at 16:56 -0400, Tom Lane wrote:
> >
> > More generally, if we are to try to invalidate on the strength of
> > pg_proc changes, what of other DDL changes? Operators, operator
> > classes, maybe? How about renaming a sch
> you have functions
>
> A) caller1() to callerN() which includes call to called1()
>
> B) one of these functions, say callerM() needs one more field returned
> from called1(), so you either write a completely new function
> called1_v2() with one more field and then update callerM() to call
> cal
On Tue, 2008-08-19 at 16:56 -0400, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > The actual criterion is not really "new user-visible feature" versus
> > "bug fix". It's more an attempt at measuring how large a potential
> > impact the change has. The patch I saw was introducin
On Tue, 2008-08-19 at 16:56 -0400, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > The actual criterion is not really "new user-visible feature" versus
> > "bug fix". It's more an attempt at measuring how large a potential
> > impact the change has. The patch I saw was introducin
On Tue, 2008-08-19 at 16:03 -0400, Robert Haas wrote:
> > Another thing I do not understand well is how people are expected to work in
> > 8.3 with a function based API, without hitting Skype problems. I'm having a
>
> All database-driven applications have this problem. Any time you have
> a data
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> The actual criterion is not really "new user-visible feature" versus
> "bug fix". It's more an attempt at measuring how large a potential
> impact the change has. The patch I saw was introducing a whole new
> message type to go through the shared inval
Dimitri Fontaine escribió:
> The problem here (at least for me) was to understand why this (yet to be
> reviewed) patch is about implementing a new feature and not about
> bugfixing an existing one. So we're exactly in the fog around the
> informal backpatch policy, and as long as we're able
On Tue, 19 Aug 2008 16:22:43 -0400
Andrew Sullivan <[EMAIL PROTECTED]> wrote:
> A formal policy that's any more detailed than what's in the FAQ today
> is a solution in search of a problem.
Odd that the problem continues to rear its head though isn't it? This
certainly isn't the first time it has
On Tue, 2008-08-19 at 21:26 +0200, Dimitri Fontaine wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi,
>
> Le 19 août 08 à 19:06, Tom Lane a écrit :
> > Dimitri Fontaine <[EMAIL PROTECTED]> writes:
> >> Another thing I do not understand well is how people are expected
> >> to work
On Tue, Aug 19, 2008 at 12:42:29PM -0700, Joshua Drake wrote:
> Generally speaking we adhere to the following guideline for patches.
>* Security fixes are applied to all applicable branches.
>* Bugfixes are applied to all applicable branches
> * Note: A patch that addresses a known li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Le 19 août 08 à 22:03, Robert Haas a écrit :
All database-driven applications have this problem. Any time you have
a database on the backend and interface code on the front-end, you
need to keep in mind that it won't necessarily be possible to
> Another thing I do not understand well is how people are expected to work in
> 8.3 with a function based API, without hitting Skype problems. I'm having a
All database-driven applications have this problem. Any time you have
a database on the backend and interface code on the front-end, you
nee
On Tue, Aug 19, 2008 at 02:47:13PM -0400, Tom Lane wrote:
> Whether (and how far) to backpatch has always been a best-judgment call
> in the past, and we've gotten along fine with that. I think having a
> formal policy is just likely to lead to even more complaints:
I completely agree with this.
On Tue, 19 Aug 2008 14:47:13 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Joshua Drake wrote:
> >> Is our backpatch policy documented? It does not appear to be in
> >> developer FAQ.
>
> > Seems we need to add it.
>
> I'm not sure that I *want* a form
Le 19 août 08 à 20:47, Tom Lane a écrit :
I'm not sure that I *want* a formal written-down backpatch policy.
Whether (and how far) to backpatch has always been a best-judgment
call
in the past, and we've gotten along fine with that. I think having a
formal policy is just likely to lead to eve
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Le 19 août 08 à 19:06, Tom Lane a écrit :
Dimitri Fontaine <[EMAIL PROTECTED]> writes:
Another thing I do not understand well is how people are expected
to work in
8.3 with a function based API, without hitting Skype problems.
What we've go
Asko Oja escribió:
> > Another thing I do not understand well is how people are expected to work
> in
> > 8.3 with a function based API, without hitting Skype problems.
> People are expected to use same workarounds as Skype is using. For us
> another unneccessary downtime week ago was what set us m
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Joshua Drake wrote:
> >> Is our backpatch policy documented? It does not appear to be in
> >> developer FAQ.
>
> > Seems we need to add it.
>
> I'm not sure that I *want* a formal written-down backpatch policy.
> Whether (and how far
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Joshua Drake wrote:
>> Is our backpatch policy documented? It does not appear to be in
>> developer FAQ.
> Seems we need to add it.
I'm not sure that I *want* a formal written-down backpatch policy.
Whether (and how far) to backpatch has always been a b
>>> Joshua Drake <[EMAIL PROTECTED]> wrote:
> Is our backpatch policy documented? It does not appear to be in
> developer FAQ.
It's mentioned here:
http://www.postgresql.org/support/versioning
"PostgreSQL minor releases fix only frequently-encountered, security,
and data corruption bugs to
Joshua Drake wrote:
> On Tue, 19 Aug 2008 14:29:52 -0400 (EDT)
> Bruce Momjian <[EMAIL PROTECTED]> wrote:
>
>
> > > Do I think it should be pushed back to 8.3.x; no. It is a feature. I
> > > don't consider the existing behavior a bug. I consider it a
> > > limitation and we don't back patch fixes
On Tue, 19 Aug 2008 14:29:52 -0400 (EDT)
Bruce Momjian <[EMAIL PROTECTED]> wrote:
> > Do I think it should be pushed back to 8.3.x; no. It is a feature. I
> > don't consider the existing behavior a bug. I consider it a
> > limitation and we don't back patch fixes for limitations.
>
> The bottom
Joshua Drake wrote:
> On Tue, 19 Aug 2008 12:48:06 +0100
> Gregory Stark <[EMAIL PROTECTED]> wrote:
>
> > "Hannu Krosing" <[EMAIL PROTECTED]> writes:
> >
> > > Maybe there should be something in postgreSQL docs that warns users
> > > against using functions in any non-trivial circumstances, as
>
> Another thing I do not understand well is how people are expected to work
in
> 8.3 with a function based API, without hitting Skype problems.
People are expected to use same workarounds as Skype is using. For us
another unneccessary downtime week ago was what set us moving/thinking :).
When you u
2008/8/19 Dimitri Fontaine <[EMAIL PROTECTED]>:
> Le mardi 19 août 2008, Tom Lane a écrit :
>> [ shrug... ] You have not found a bug in plan invalidation. You have
>> found omitted functionality --- functionality that was *intentionally*
>> omitted from the 8.3 version.
>
> Thanks a lot for this c
Polite answers lead to polite discussions. Caling other people names lead to
flame wars.
It's perfectly ok for Skype to keep our own build of 8.3 with given patch
and make it available for whoever might want it. At least now there is
almost good enough description why the patch was needed althou it
Dimitri Fontaine <[EMAIL PROTECTED]> writes:
> Another thing I do not understand well is how people are expected to work in
> 8.3 with a function based API, without hitting Skype problems.
I could understand this level of complaining if this were a new problem
that'd appeared in 8.3. But *every
Le mardi 19 août 2008, Tom Lane a écrit :
> [ shrug... ] You have not found a bug in plan invalidation. You have
> found omitted functionality --- functionality that was *intentionally*
> omitted from the 8.3 version.
Thanks a lot for this clarification, now I understand you viewpoint.
So, the 8
Dimitri Fontaine <[EMAIL PROTECTED]> writes:
> - now, we have found a bug in plan invalidation
[ shrug... ] You have not found a bug in plan invalidation. You have
found omitted functionality --- functionality that was *intentionally*
omitted from the 8.3 version.
regard
On Tue, 19 Aug 2008 12:48:06 +0100
Gregory Stark <[EMAIL PROTECTED]> wrote:
> "Hannu Krosing" <[EMAIL PROTECTED]> writes:
>
> > Maybe there should be something in postgreSQL docs that warns users
> > against using functions in any non-trivial circumstances, as
> > functions are not expected to be
Le mardi 19 août 2008, Tom Lane a écrit :
> For the same reasons that plan invalidation itself was a new feature
> and not a bug fix;
I'm sorry but that doesn't help me a dime to understand current situation. It
could well be just me, but... here's how I see it:
- plan invalidation is a new fe
Hannu Krosing <[EMAIL PROTECTED]> writes:
> On Mon, 2008-08-18 at 22:41 +0200, Pavel Stehule wrote:
>> I am sorry, but it's really new feature and not bug fix
> Could you please explain why you think so ?
For the same reasons that plan invalidation itself was a new feature
and not a bug fix; nota
"Hannu Krosing" <[EMAIL PROTECTED]> writes:
> Maybe there should be something in postgreSQL docs that warns users against
> using functions in any non-trivial circumstances, as functions are not
> expected to behave like the rest of postgreSQL features and there is
> not plan to fix that ?
Now
On Tue, 2008-08-19 at 12:42 +0200, Pavel Stehule wrote:
> 2008/8/19 Hannu Krosing <[EMAIL PROTECTED]>:
> > On Mon, 2008-08-18 at 22:41 +0200, Pavel Stehule wrote:
> >> 2008/8/18 Hannu Krosing <[EMAIL PROTECTED]>:
> >> > On Mon, 2008-08-18 at 11:05 +0200, Pavel Stehule wrote:
> >> >> 2008/8/18 Dimit
2008/8/19 Hannu Krosing <[EMAIL PROTECTED]>:
> On Mon, 2008-08-18 at 22:41 +0200, Pavel Stehule wrote:
>> 2008/8/18 Hannu Krosing <[EMAIL PROTECTED]>:
>> > On Mon, 2008-08-18 at 11:05 +0200, Pavel Stehule wrote:
>> >> 2008/8/18 Dimitri Fontaine <[EMAIL PROTECTED]>:
>> >> > Hi,
>> >> >
>> >> > Le lu
2008/8/19 Hannu Krosing <[EMAIL PROTECTED]>:
> On Mon, 2008-08-18 at 22:41 +0200, Pavel Stehule wrote:
>> 2008/8/18 Hannu Krosing <[EMAIL PROTECTED]>:
>> > On Mon, 2008-08-18 at 11:05 +0200, Pavel Stehule wrote:
>> >> 2008/8/18 Dimitri Fontaine <[EMAIL PROTECTED]>:
>> >> > Hi,
>> >> >
>> >> > Le lu
On Mon, 2008-08-18 at 20:29 -0400, Tom Lane wrote:
> "Asko Oja" <[EMAIL PROTECTED]> writes:
> > For users of stored procedures it is protection from downtime. For Skype it
> > has been around 20% of databse related downtime this year.
>
> Perhaps Skype needs to rethink how they are modifying funct
On Mon, 2008-08-18 at 22:41 +0200, Pavel Stehule wrote:
> 2008/8/18 Hannu Krosing <[EMAIL PROTECTED]>:
> > On Mon, 2008-08-18 at 11:05 +0200, Pavel Stehule wrote:
> >> 2008/8/18 Dimitri Fontaine <[EMAIL PROTECTED]>:
> >> > Hi,
> >> >
> >> > Le lundi 18 août 2008, Andrew Dunstan a écrit :
> >> >> >
Hi
> The reason that this case wasn't covered in 8.3 is that there didn't
> seem to be a use-case that justified doing the extra work. I still
> haven't seen one.
You just stopped reading the thread where it was discussed after your troll
remark?
> Other than inline-able SQL functions there is n
"Asko Oja" <[EMAIL PROTECTED]> writes:
> For users of stored procedures it is protection from downtime. For Skype it
> has been around 20% of databse related downtime this year.
Perhaps Skype needs to rethink how they are modifying functions.
The reason that this case wasn't covered in 8.3 is tha
> Does it change of result some queries?
Patch in itself is not changing what the queries return. It just gets rid of
error condition from which Postgres itself is not able to recover.
It is protection to server's hang?
For users of stored procedures it is protection from downtime. For Skype it
ha
2008/8/18 Hannu Krosing <[EMAIL PROTECTED]>:
> On Mon, 2008-08-18 at 11:05 +0200, Pavel Stehule wrote:
>> 2008/8/18 Dimitri Fontaine <[EMAIL PROTECTED]>:
>> > Hi,
>> >
>> > Le lundi 18 août 2008, Andrew Dunstan a écrit :
>> >> > On Sat, Aug 16, 2008 at 09:40:19PM -0400, Tom Lane wrote:
>> >> >> Thi
On Mon, 2008-08-18 at 11:05 +0200, Pavel Stehule wrote:
> 2008/8/18 Dimitri Fontaine <[EMAIL PROTECTED]>:
> > Hi,
> >
> > Le lundi 18 août 2008, Andrew Dunstan a écrit :
> >> > On Sat, Aug 16, 2008 at 09:40:19PM -0400, Tom Lane wrote:
> >> >> This is not the kind of patch we put into stable branche
2008/8/18 Dimitri Fontaine <[EMAIL PROTECTED]>:
> Hi,
>
> Le lundi 18 août 2008, Andrew Dunstan a écrit :
>> > On Sat, Aug 16, 2008 at 09:40:19PM -0400, Tom Lane wrote:
>> >> This is not the kind of patch we put into stable branches.
>>
>> So what? That is not the only criterion for backpatching.
>
Hi,
Le lundi 18 août 2008, Andrew Dunstan a écrit :
> > On Sat, Aug 16, 2008 at 09:40:19PM -0400, Tom Lane wrote:
> >> This is not the kind of patch we put into stable branches.
>
> So what? That is not the only criterion for backpatching.
I fail to understand why this problem is not qualified as
David Fetter wrote:
On Sat, Aug 16, 2008 at 09:40:19PM -0400, Tom Lane wrote:
"Asko Oja" <[EMAIL PROTECTED]> writes:
Is it possible to get it into some official 8.3.x release
This is not the kind of patch we put into stable branches.
Does this really count as a user-vis
On Sat, Aug 16, 2008 at 09:40:19PM -0400, Tom Lane wrote:
> "Asko Oja" <[EMAIL PROTECTED]> writes:
> > Is it possible to get it into some official 8.3.x release
>
> This is not the kind of patch we put into stable branches.
Does this really count as a user-visible change, except in the sense
that
"Asko Oja" <[EMAIL PROTECTED]> writes:
> Is it possible to get it into some official 8.3.x release
This is not the kind of patch we put into stable branches.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your s
Hi
We need plan invalidation fix in 8.3 also at least it would make migrating
from 8.2 to 8.3 much more attractive.
Currenlty we are having problems related to plan invalidation couple of
times per week (mainly we have to let developers change their code before we
release it into live databases bu
Tom Lane wrote:
> Martin Pihlak <[EMAIL PROTECTED]> writes:
>> Changing statement result type is also currently prohibited in
>> StorePreparedStatement. There maybe good reasons for this,
>
> How about "the SQL spec says so"?
>
> Admittedly, it's a bit of a jump from views to prepared statements,
> > Changing statement result type is also currently prohibited in
> > StorePreparedStatement. There maybe good reasons for this,
>
> How about "the SQL spec says so"?
Prepare time is often also the time when you bind the result, or more
generally set up the code to handle the result.
Generally
Martin Pihlak <[EMAIL PROTECTED]> writes:
> Changing statement result type is also currently prohibited in
> StorePreparedStatement. There maybe good reasons for this,
How about "the SQL spec says so"?
Admittedly, it's a bit of a jump from views to prepared statements,
but the spec is perfectly c
This is a followup for thread "plan invalidation vs stored procedures".
The background is that it is impossible to change function return type without
dropping and recreating. Unfortunately dropping a function ruins all of the
prepared statements that reference that function (including other funct
77 matches
Mail list logo
