Hi,
On Tue, Apr 14, 2009 at 2:41 PM, Fujii Masao wrote:
> I'd like to propose another simple idea; pg_standby deletes the
> trigger file *whenever* the nextWALfile is a timeline history file.
> A timeline history file is restored at the end of recovery, so it's
> guaranteed that the trigger file
Simon Riggs wrote:
On Wed, 2009-04-15 at 11:36 +0300, Heikki Linnakangas wrote:
Extract the source of the offending plpgsql function using e.g
pg_dump, modify it so that it works again, and restore the function.
There's your workaround.
Forcing manual re-editing of an unknown number of lines
On Wed, Apr 15, 2009 at 10:12 AM, Simon Riggs wrote:
>
> How do you know which is the offending function? If we force a full
> application retest we put in place a significant barrier to upgrade.
> That isn't useful for us as developers, nor is it useful for users.
This is a fundamental conflict,
On Wed, 2009-04-15 at 11:36 +0300, Heikki Linnakangas wrote:
> Extract the source of the offending plpgsql function using e.g
> pg_dump, modify it so that it works again, and restore the function.
> There's your workaround.
Forcing manual re-editing of an unknown number of lines of code is not a
On Wed, 2009-04-15 at 10:56 +0100, Greg Stark wrote:
> On Wed, Apr 15, 2009 at 10:12 AM, Simon Riggs wrote:
> >
> > How do you know which is the offending function? If we force a full
> > application retest we put in place a significant barrier to upgrade.
> > That isn't useful for us as develope
Fujii Masao wrote:
> Hi,
>
> On Tue, Apr 14, 2009 at 10:26 PM, Euler Taveira de Oliveira
> wrote:
>> Fujii Masao escreveu:
>>> Is it worth making the patch which creates stats_temp_directory
>>> if not present?
>>>
>> +1.
>
> Here is the patch.
>
> This patch should be added to CommitFest-2009-
On Wed, Apr 15, 2009 at 11:33 AM, Simon Riggs wrote:
>
>> This is a fundamental conflict, not one that has a single simple answer.
>>
>> However this seems like a strange place to pick your battle.
>
> I think you are right that you perceive a fundamental conflict and most
> things I say become ba
On Tue, Apr 14, 2009 at 04:01:48PM +0300, Peter Eisentraut wrote:
> On Saturday 11 April 2009 18:20:47 Sam Mason wrote:
> > I can't see much support in the other database engines; searched for
> > Oracle, MS-SQL, DB2 and Firebird. MySQL has it planned for 7.1, so not
> > for a while.
>
> DB2 supp
Simon Riggs wrote:
How do you know which is the offending function? If we force a full
application retest we put in place a significant barrier to upgrade.
That isn't useful for us as developers, nor is it useful for users.
We support back branches for a long time for a reason. Nobody in
On Wed, Apr 15, 2009 at 5:56 AM, Greg Stark wrote:
> On Wed, Apr 15, 2009 at 10:12 AM, Simon Riggs wrote:
>>
>> How do you know which is the offending function? If we force a full
>> application retest we put in place a significant barrier to upgrade.
>> That isn't useful for us as developers, no
Simon Riggs wrote:
On Tue, 2009-04-14 at 18:29 -0400, Tom Lane wrote:
Simon Riggs writes:
Potentially changing the behaviour of thousands of functions just to fix
a rare bug will not endear us to our users. The bug may be something
that people are relying on in some subtle way, ugly as that so
On Wed, Apr 15, 2009 at 5:56 AM, Greg Stark wrote:
> On Wed, Apr 15, 2009 at 10:12 AM, Simon Riggs wrote:
>>
>> How do you know which is the offending function? If we force a full
>> application retest we put in place a significant barrier to upgrade.
>> That isn't useful for us as developers, no
Xin Wang writes:
> I searched the mailinglist archive and noticed that a patch to improve
> bulk insert performance is committed in Nov 2008. The log message said
> "(the patch) keeps the current target buffer pinned and make it work
> in a small ring of buffers to avoid having bulk inserts trash
Hi.
- Original Message -
From: "Itagaki Takahiro"
Here is a WIP patch to solve server-side encoding issues.
It includes "Solution of the file name problem of copy on windows" patch.
http://archives.postgresql.org/message-id/20090413184335.39be.52131...@oss.ntt.co.jp
It could so
Andrew Dunstan writes:
> We support back branches for a long time for a reason.
I think that's really the bottom line here. If we insist on new major
releases always being bug-compatible with prior releases, our ability to
improve the software will go to zero. The solution we have opted for
ins
On Apr 15, 2009, at 4:45 AM, Sam Mason wrote:
Doh, yes it does doesn't it. Sorry I searched for a bit and failed to
find anything before. Looks as though the signal to noise ratio was
far
too low as I've just searched again and found a (single) reference to
their docs describing the feature
On Wed, 2009-04-15 at 11:45 -0400, Tom Lane wrote:
> Andrew Dunstan writes:
> > We support back branches for a long time for a reason.
>
> I think that's really the bottom line here. If we insist on new major
> releases always being bug-compatible with prior releases, our ability to
> improve th
On Tue, Apr 14, 2009 at 08:10:54AM -0400, Andrew Dunstan wrote:
> Marko Kreen wrote:
> >I still stand on my proposal, how about extending E'' strings with
> >unicode escapes (eg. \u)? The E'' strings are already more
> >clearly defined than '' and they are our "own", we don't need to
> >consid
On Tue, Apr 14, 2009 at 11:32:57AM -0700, David E. Wheeler wrote:
> I've no idea what it would require, but the mapping table must be
> pretty substantial. Still, I'd love to have this functionality in the
> database.
The Unicode tables in ICU outweigh the size of the code by a factor 5
or so.
I wrote:
> =?ISO-8859-1?Q?Christian_Schr=F6der?= writes:
>> This is the query:
>> select isin from ts_frontend.attachment_isins full OUTER JOIN
>> ts_frontend.rec_isins using (attachment,isin) WHERE attachment=2698120
>> GROUP BY isin limit 1000;
> Hmm. It seems 8.3 is failing to push the at
Xin Wang escribió:
> However, I do not know much about the code below the heapam layer. Can that
> patch solve my problem (the version I use is 8.3.5)? Or could you give me
> some suggestion about how to avoid memory exhaustion during bulk insert
> (in the meanwhile it must clean up nicely after a
Hi,
It seems there's a missing gettext() call in new code in hba.c, per the
patch below. I don't actually like this, but it seems the alternative
would be to create a variadic function which I believe to be
overengineering ...
Index: hba.c
"David E. Wheeler" writes:
> Wouldn't we just then say that U&'' strings are always standard-
> conforming?
That's exactly what's causing the problem --- they are, but there
is lots of software that won't know it.
regards, tom lane
--
Sent via pgsql-hackers mailing lis
Alvaro Herrera writes:
> It seems there's a missing gettext() call in new code in hba.c, per the
> patch below. I don't actually like this, but it seems the alternative
> would be to create a variadic function which I believe to be
> overengineering ...
Hmm ... if the second %s here is meant to
On Wed, Apr 15, 2009 at 6:23 PM, Tom Lane wrote:
>> Wouldn't we just then say that U&'' strings are always standard-
>> conforming?
>
> That's exactly what's causing the problem --- they are, but there
> is lots of software that won't know it.
We could say U&'' escapes only work if you have
stan
On Wed, 2009-04-15 at 17:02 +0900, Fujii Masao wrote:
> On Tue, Apr 14, 2009 at 2:41 PM, Fujii Masao wrote:
> > I'd like to propose another simple idea; pg_standby deletes the
> > trigger file *whenever* the nextWALfile is a timeline history file.
> > A timeline history file is restored at the e
On Wed, Apr 15, 2009 at 6:52 PM, Greg Stark wrote:
> On Wed, Apr 15, 2009 at 6:23 PM, Tom Lane wrote:
>>> Wouldn't we just then say that U&'' strings are always standard-
>>> conforming?
>>
>> That's exactly what's causing the problem --- they are, but there
>> is lots of software that won't know
On 4/15/09, Greg Stark wrote:
> On Wed, Apr 15, 2009 at 6:23 PM, Tom Lane wrote:
> >> Wouldn't we just then say that U&'' strings are always standard-
> >> conforming?
> >
> > That's exactly what's causing the problem --- they are, but there
> > is lots of software that won't know it.
>
> We
Marko Kreen writes:
> Whats wrong with requiring U& to conform with stdstr=off quoting rules?
The sole and only excuse for that misbegotten syntax is to be exactly
SQL spec compliant --- otherwise we might as well pick something saner.
So it needs to work like stdstr=on. I thought Peter's propos
Magnush asked me about the beer-ware license on crypt-md5.c file.
I will spare you for the sagas of fun I have had with lawyers because
of the beerware license, you can get them over beer some times.
For the record: You are welcome to slap a 2-clause BSD license on the
file instead of the beerw
On 4/15/09, Tom Lane wrote:
> Marko Kreen writes:
> > Whats wrong with requiring U& to conform with stdstr=off quoting rules?
>
> The sole and only excuse for that misbegotten syntax is to be exactly
> SQL spec compliant --- otherwise we might as well pick something saner.
> So it needs to wor
Martijn van Oosterhout wrote:
On Tue, Apr 14, 2009 at 08:10:54AM -0400, Andrew Dunstan wrote:
Marko Kreen wrote:
I still stand on my proposal, how about extending E'' strings with
unicode escapes (eg. \u)? The E'' strings are already more
clearly defined than '' and they are our
Marko Kreen writes:
> As both this and the doubling-\\ way would mean we should have usable
> alternative in case of stdstr=off also, so in the end we have agreed
> to accept \u also?
Given Martijn's complaint about more-than-16-bit code points, I think
the \u proposal is not mature enough to go
On 4/15/09, Tom Lane wrote:
> Marko Kreen writes:
> > As both this and the doubling-\\ way would mean we should have usable
> > alternative in case of stdstr=off also, so in the end we have agreed
> > to accept \u also?
>
> Given Martijn's complaint about more-than-16-bit code points, I think
>
I wrote:
> On further review, this did work in 8.3 when released. I think it got
> broken here:
> http://archives.postgresql.org/pgsql-committers/2008-06/msg00336.php
> because that change is preventing the "mergedvar = constant" clause from
> being seen as an equivalence, when it should be seen a
On Wed, 2009-04-15 at 12:34 -0400, Tom Lane wrote:
> On further review, this did work in 8.3 when released. I think it got
> broken here:
>
> http://archives.postgresql.org/pgsql-committers/2008-06/msg00336.php
>
> because that change is preventing the "mergedvar = constant" clause from
> bein
Simon Riggs writes:
> I've always been scared to ask this question, in case the answer is No,
> but: Do we have a set of regression tests for the optimizer anywhere?
Nothing beyond what is in the standard tests. While that's okay at
catching wrong answers --- and we have memorialized a number of
On Wed, Apr 15, 2009 at 6:04 PM, Tom Lane wrote:
> Simon Riggs writes:
>> I've always been scared to ask this question, in case the answer is No,
>> but: Do we have a set of regression tests for the optimizer anywhere?
>
> Nothing beyond what is in the standard tests. While that's okay at
> catc
Robert Haas writes:
> We could add some regression tests that create a sample data set,
> ANALYZE it, and then EXPLAIN various things. The results should be
> deterministic,
Sorry, you're wrong.
The output of EXPLAIN is nowhere near stable enough to use within the
current exact-match regression
Zdenek Kotala wrote:
> When postgreSQL is compiled with --thread-safe that libpq should be
> thread safe. But it is not true when somebody call fork(). The problem
> is that fork() forks only active threads and some mutex can stay locked
> by another thread. We use ssl_config mutex which is global.
Where are we on this?
---
Tom Lane wrote:
> Teodor Sigaev writes:
> >> We have an API definition by which extractQuery can distinguish "all
> >> match" from "no match". If we just legislate that "some match" isn't
> >> a v
On Tue, Apr 14, 2009 at 03:18:06PM -0700, David Fetter wrote:
> On Tue, Apr 14, 2009 at 02:52:32PM -0400, Alvaro Herrera wrote:
> > Tom Lane wrote:
> >
> > > I had a second thought about that: presumably we should make the
> > > function type names translatable. If we do that, it might be better
David Fetter wrote:
> > > I think it's good to have them translatable. As for using "aggregate"
> > > instead of "agg" I don't think it's that great an idea. If you need to
> > > notify translators that "agg" stands for "aggregate", add a
> > > /* translator: */ comment.
The "translator: " comm
On Wed, Apr 15, 2009 at 7:39 PM, Tom Lane wrote:
> Robert Haas writes:
>> We could add some regression tests that create a sample data set,
>> ANALYZE it, and then EXPLAIN various things. The results should be
>> deterministic,
>
> Sorry, you're wrong.
>
> The output of EXPLAIN is nowhere near s
On Wed, Apr 15, 2009 at 08:54:10PM -0400, Alvaro Herrera wrote:
> David Fetter wrote:
>
> > > > I think it's good to have them translatable. As for using "aggregate"
> > > > instead of "agg" I don't think it's that great an idea. If you need to
> > > > notify translators that "agg" stands for "a
On Sun, Apr 12, 2009 at 12:00 AM, Robert Haas wrote:
> On Thu, Feb 19, 2009 at 5:53 PM, Tom Lane wrote:
>> Greg Stark writes:
>>> It's tempting to have Hash cheat and just peek at the node beneath it
>>> to see if it's a HashAggregate, in which case it could call a special
>>> method to request
Considered unexpected behavior, or at least in its undocumented form.
If value given to NOTIFY seems schema-qualified, the schema
qualification is eroded by the time it is presented to the listener --
the [ nonexistent ] schema-ish-looking 'foo.' portion of 'foo.bar' is
not presented at all
David Fetter wrote:
> On Wed, Apr 15, 2009 at 08:54:10PM -0400, Alvaro Herrera wrote:
> > The "translator: " comment needs to be in the line just above the
> > string.
>
> Is this any better?
Yeah, this one is good (as far as this very minor detail is concerned anyway)
--
Alvaro Herrera
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> Considered unexpected behavior, or at least in its undocumented form.
> If value given to NOTIFY seems schema-qualified, the schema
> qualification is eroded by the time it is presented to the listener --
See:
http://archives.postgresql.org/
> >>> I still stand on my proposal, how about extending E'' strings with
> >>> unicode escapes (eg. \u)? The E'' strings are already more
> >>> clearly defined than '' and they are our "own", we don't need to
> >>> consider random standards, but can consider our sanity.
> >>>
> >> I sus
> > >>> I still stand on my proposal, how about extending E'' strings with
> > >>> unicode escapes (eg. \u)? The E'' strings are already more
> > >>> clearly defined than '' and they are our "own", we don't need to
> > >>> consider random standards, but can consider our sanity.
> > >>>
On Wed, 2009-04-15 at 20:58 -0400, Robert Haas wrote:
> On Wed, Apr 15, 2009 at 7:39 PM, Tom Lane wrote:
> > The output of EXPLAIN is nowhere near stable enough to use within the
> > current exact-match regression test framework. I'm not sure it would
> > be stable even if we suppressed the row
Hi,
On Wed, Apr 15, 2009 at 5:37 PM, Magnus Hagander wrote:
> This does not take into account the effect of symlinks as mentioned by
> Itakagi Takahiro. I haven't looked at the details, but I don't think it
> would be that much more work to deal with it - and as he mentions, this
> is a very comm
53 matches
Mail list logo
