Hi,
Can any one tell me whats the effect of the below Query
SELECT substring(B'0001' from 5 for -2);
SELECT substring(B'0001' from 4 for -3);
its observed that there's an Error "invalid memory alloc request size
4244635647"
What will actually happen to the Postgresql da
Hi, I'm Korean.
CP51949 is EUC-KR correct.
so, that defined code is correct too.
But in Korea, EUC-KR code is not good to use all Korean character.
In recent years, many people in Korea use the CP949 code.
MS Windows codepage also is CP949.
- Original Message -
From: "Takahiro Itagaki"
2010/5/4 Tom Lane :
> Josh Berkus writes:
>>> quietly removing NULL is maybe good for compatibility but is wrong for
>>> functionality.
>
>> I agree. I wasn't aware of this little misfeature.
>
>> Default display for NULL should be a zero-length string.
>
> That's just as broken as Pavel's sugges
On 5/3/2010 10:51 PM, Tom Lane wrote:
Jan Wieck writes:
On 4/30/2010 1:56 AM, Jaime Casanova wrote:
ah! this is because COPY doesn't follow inherited tables... should it?
The TRUNCATE command's behavior was changed in that regard. What
TRUNCATE did in 8.3 is now TRUNCATE ONLY in 8.4. I don'
On 5/2/2010 10:34 AM, Tom Lane wrote:
Simon Riggs writes:
Not commenting further on that patch, but I notice that when we UPDATE
the toasting algorithm takes no account of the available freespace on
the current block. If we are updating and the space available would make
a difference to the row
Tom Lane wrote:
Default display for NULL should be a zero-length string.
That's just as broken as Pavel's suggestion. Unless you have something
that is guaranteed distingishable from the output of any non-null value,
you really can't make a significant improvement here.
Josh Berkus writes:
>> quietly removing NULL is maybe good for compatibility but is wrong for
>> functionality.
> I agree. I wasn't aware of this little misfeature.
> Default display for NULL should be a zero-length string.
That's just as broken as Pavel's suggestion. Unless you have somethi
Jan Wieck writes:
> On 4/30/2010 1:56 AM, Jaime Casanova wrote:
>> ah! this is because COPY doesn't follow inherited tables... should it?
> The TRUNCATE command's behavior was changed in that regard. What
> TRUNCATE did in 8.3 is now TRUNCATE ONLY in 8.4. I don't see a reason
> why COPY should
Simon Riggs wrote:
> On Mon, 2010-05-03 at 13:13 -0400, Stephen Frost wrote:
>
> > Perhaps you could speak to the specific user
> > experience difference that you think there would be from this change?
>
> The difference is really to do with the weight you give to two different
> considerations
>
On 4/30/2010 1:56 AM, Jaime Casanova wrote:
2010/4/30 Jaime Casanova :
Hi,
COPY is not working on latest HEAD?
"""
regression=# select * from a;
aa
32
56
(2 rows)
regression=# COPY a TO '/tmp/copy_test';
COPY 0
"""
ah! this is because COPY doesn't follow inherited tables... should i
> quietly removing NULL is maybe good for compatibility but is wrong for
> functionality.
I agree. I wasn't aware of this little misfeature.
Default display for NULL should be a zero-length string.
--
-- Josh Berkus
Postg
Hello
I understand why we don't support expression 'null'::sometype. But it
does problems with array deserialisation.
postgres=# select array_to_string(ARRAY[10,20,30,NULL,30], '|');
array_to_string
-
10|20|30|30
(1 row)
quietly removing NULL is maybe good for compatibility but
Greg, Robert,
> Certainly that one particular case can be solved by making the
> servers be in time sync a prereq for HS working (in the traditional way).
> And by "prereq" I mean a "user beware" documentation warning.
>
Last I checked, you work with *lots* of web developers and web
companies. I
Greg Smith wrote:
> Bruce Momjian wrote:
> > As a summary, let me list the migrations pg_migrator supports:
> > 8.3 -> 8.4
> > 8.4 -> 9.0
> > 8.3 -> 9.0
> > Surprisingly, it is 8.3 -> 8.4 that has the most restrictions because it
> > doesn't have access to the features we added in Postg
On Mon, 2010-05-03 at 23:28 +0300, Heikki Linnakangas wrote:
> Sorry, I just didn't have the time & energy to figure out what to do
> about that. Feel free to fix as you see fit.
Yeh, I sometimes feel like that towards other hacker's comments as well.
--
Simon Riggs www.2ndQuadrant.c
Robert Haas wrote:
> On Sun, May 2, 2010 at 3:45 PM, Dimitri Fontaine
> wrote:
> > Now you tell me how awful this idea really is :)
>
> I'm not sure I can count that high. :-)
While I can't improve on Robert's reply, I can supply a PDF about how
pg_migrator works:
http://momjian.us/ma
Aidan Van Dyk wrote:
HINT: It's all been done and posted to -hackers before too... Along
with comparisons on on whte "one-time" conversions fare (parsecvs,
cvs2svn/git), etc, as well as long discussion on which keyword you want
expanded, and which you don't, etc. bla bla bla...
And in some
Simon Riggs wrote:
> On Mon, 2010-05-03 at 10:50 +0100, Simon Riggs wrote:
>> On Mon, 2010-05-03 at 12:17 +0300, Heikki Linnakangas wrote:
>>
> * wal_level doesn't describe what the impacts are on a standby if the
> level is changed on the primary, nor is there a caution or a warning of
>>>
On Mon, May 3, 2010 at 11:37 AM, Tom Lane wrote:
> I'm inclined to think that we should throw away all this logic and just
> have the slave cancel competing queries if the replay process waits
> more than max_standby_delay seconds to acquire a lock.
What if we somehow get into a situation where t
Bruce Momjian wrote:
As a summary, let me list the migrations pg_migrator supports:
8.3 -> 8.4
8.4 -> 9.0
8.3 -> 9.0
Surprisingly, it is 8.3 -> 8.4 that has the most restrictions because it
doesn't have access to the features we added in Postgres 9.0.
Tom is right that the
On Mon, 2010-05-03 at 16:12 -0400, Robert Haas wrote:
> On Sun, May 2, 2010 at 3:45 PM, Dimitri Fontaine
> wrote:
> > Now you tell me how awful this idea really is :)
>
> I'm not sure I can count that high. :-)
You don't have to...
NaN
Joshua D. Drake
>
> ...Robert
>
--
PostgreSQL.org
On Sun, May 2, 2010 at 3:45 PM, Dimitri Fontaine wrote:
> Now you tell me how awful this idea really is :)
I'm not sure I can count that high. :-)
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/ma
On Mon, May 3, 2010 at 4:04 PM, Andrew Dunstan wrote:
>
> For those who have been following along, today I reached a bit of a
> milestone. The buildfarm member quoll, which is running a git-ized buildfarm
> client due to be released in a week or so, today successfully built all the
> live branches
On Mon, May 3, 2010 at 3:39 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, May 3, 2010 at 11:37 AM, Tom Lane wrote:
>>> I'm inclined to think that we should throw away all this logic and just
>>> have the slave cancel competing queries if the replay process waits
>>> more than max_standby_
On Mon, 2010-05-03 at 15:39 -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Mon, May 3, 2010 at 11:37 AM, Tom Lane wrote:
> >> I'm inclined to think that we should throw away all this logic and just
> >> have the slave cancel competing queries if the replay process waits
> >> more than max_st
For those who have been following along, today I reached a bit of a
milestone. The buildfarm member quoll, which is running a git-ized
buildfarm client due to be released in a week or so, today successfully
built all the live branches, all the way back to 7.4, from git. Note,
this is running
On Mon, 2010-05-03 at 15:32 -0400, Stephen Frost wrote:
> Simon,
>
> * Simon Riggs (si...@2ndquadrant.com) wrote:
> > Tom's proposed behaviour (has also been proposed before) favours the
> > avoid query cancellation route though could lead to huge amounts of lag.
>
> My impression of Tom's sugges
Alvaro Herrera wrote:
Andrew Dunstan escribió:
I pulled together a quick hack, and here is what I get from my
mirrors. I'm not sure why we get those diffs - it's a bit odd,
although fairly insignificant.
Well, it's a $Log$ CVS keyword -- it's not surprising that it's failing
to prov
Andrew Dunstan writes:
> We need to be thinking more now about such a contingency. Postgres use in
> very large installations is now at such a level that requiring a
> pg_dump/pg_restore is really not an option for many users. If pg_migrator is
> not always going to work then we need to be addre
Simon,
> My initial view was that the High Availability goal/role should be the
> default or most likely mode of operation. I would say that the current
> max_standby_delay favours the HA route since it specifically limits the
> amount by which server can fall behind.
I don't understand how Tom's
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> Based on that, I don't know that there's really much user-seen behaviour
> between the two, except in 'oddball' situations, where there's a time
> skew between the servers, or a large lag, etc, in which case I think
Certainly that one particu
Robert Haas writes:
> On Mon, May 3, 2010 at 11:37 AM, Tom Lane wrote:
>> I'm inclined to think that we should throw away all this logic and just
>> have the slave cancel competing queries if the replay process waits
>> more than max_standby_delay seconds to acquire a lock.
> What if we somehow
> It's really both of those things, so we could call it
> wal_min_keep_segments, but I think an even better name would be
> bikeshed_segments.
Speaking from my UI perspective, I don't think users will care what we
call it.
--
-- Josh Berkus
Simon,
* Simon Riggs (si...@2ndquadrant.com) wrote:
> Tom's proposed behaviour (has also been proposed before) favours the
> avoid query cancellation route though could lead to huge amounts of lag.
My impression of Tom's suggestion was that it would also be a maximum
amount of delay which would b
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, May 3, 2010 at 11:37 AM, Tom Lane wrote:
> > I'm inclined to think that we should throw away all this logic and just
> > have the slave cancel competing queries if the replay process waits
> > more than max_standby_delay seconds to acquire a l
On Mon, 2010-05-03 at 13:13 -0400, Stephen Frost wrote:
> Perhaps you could speak to the specific user
> experience difference that you think there would be from this change?
The difference is really to do with the weight you give to two different
considerations
* avoid query cancellations
* avo
On Mon, May 3, 2010 at 2:54 PM, Kevin Grittner
wrote:
> Simon Riggs wrote:
>> On Fri, 2010-04-30 at 13:41 -0500, Kevin Grittner wrote:
>
>>> Surely it would confuse people to see they have fewer than
>>> min_wal_segments WAL segments.
>>
>> That does sound like a reasonable argument, though it al
Simon Riggs wrote:
> On Fri, 2010-04-30 at 13:41 -0500, Kevin Grittner wrote:
>> Surely it would confuse people to see they have fewer than
>> min_wal_segments WAL segments.
>
> That does sound like a reasonable argument, though it also applies
> to wal_keep_segments, so isn't an argument eithe
On Mon, May 3, 2010 at 2:47 PM, Tom Lane wrote:
> Robert Haas writes:
>> Hmm. When I committed that patch to fix smart shutdown on the
>> standby, we discussed the fact that the startup process can't simply
>> release its locks and die at shutdown time because the locks it holds
>> prevent other
Robert Haas writes:
> Hmm. When I committed that patch to fix smart shutdown on the
> standby, we discussed the fact that the startup process can't simply
> release its locks and die at shutdown time because the locks it holds
> prevent other backends from seeing the database in an inconsistent
>
Robert Haas wrote:
On Mon, May 3, 2010 at 2:22 PM, Stefan Kaltenbrunner
wrote:
Tom Lane wrote:
Stefan Kaltenbrunner writes:
I'm currently testing SR/HS in 9.0beta1 and I noticed that it seems quite
easy to end up in a situation where you have a standby that seems to be
stuck in:
$ psql -p 54
On Mon, May 3, 2010 at 2:22 PM, Stefan Kaltenbrunner
wrote:
> Tom Lane wrote:
>>
>> Stefan Kaltenbrunner writes:
>>>
>>> I'm currently testing SR/HS in 9.0beta1 and I noticed that it seems quite
>>> easy to end up in a situation where you have a standby that seems to be
>>> stuck in:
>>
>>> $ psq
On Mon, 2010-05-03 at 13:21 -0400, Robert Haas wrote:
> On Mon, May 3, 2010 at 11:37 AM, Tom Lane wrote:
> > I'm inclined to think that we should throw away all this logic and just
> > have the slave cancel competing queries if the replay process waits
> > more than max_standby_delay seconds to ac
Robert Haas wrote:
On Mon, May 3, 2010 at 2:04 PM, Stefan Kaltenbrunner
wrote:
I'm currently testing SR/HS in 9.0beta1 and I noticed that it seems quite
easy to end up in a situation where you have a standby that seems to be
stuck in:
$ psql -p 5433
psql: FATAL: the database system is shuttin
Andrew Dunstan escribió:
> I pulled together a quick hack, and here is what I get from my
> mirrors. I'm not sure why we get those diffs - it's a bit odd,
> although fairly insignificant.
Well, it's a $Log$ CVS keyword -- it's not surprising that it's failing
to provide exactly identical output,
On Mon, 2010-05-03 at 13:13 -0400, Stephen Frost wrote:
> * Simon Riggs (si...@2ndquadrant.com) wrote:
> > I guarantee that if that proposal goes in, people will complain about
> > that also. Last minute behaviour changes are bad news. I don't object to
> > adding something, just don't take anythin
Tom Lane wrote:
Stefan Kaltenbrunner writes:
I'm currently testing SR/HS in 9.0beta1 and I noticed that it seems
quite easy to end up in a situation where you have a standby that seems
to be stuck in:
$ psql -p 5433
psql: FATAL: the database system is shutting down
but not not actually s
On Mon, May 3, 2010 at 2:04 PM, Stefan Kaltenbrunner
wrote:
> I'm currently testing SR/HS in 9.0beta1 and I noticed that it seems quite
> easy to end up in a situation where you have a standby that seems to be
> stuck in:
>
> $ psql -p 5433
> psql: FATAL: the database system is shutting down
>
>
Stefan Kaltenbrunner writes:
> I'm currently testing SR/HS in 9.0beta1 and I noticed that it seems
> quite easy to end up in a situation where you have a standby that seems
> to be stuck in:
> $ psql -p 5433
> psql: FATAL: the database system is shutting down
> but not not actually shuting do
I'm currently testing SR/HS in 9.0beta1 and I noticed that it seems
quite easy to end up in a situation where you have a standby that seems
to be stuck in:
$ psql -p 5433
psql: FATAL: the database system is shutting down
but not not actually shuting down ever. I ran into that a few times now
Robert Haas writes:
> On Mon, May 3, 2010 at 1:01 PM, Tom Lane wrote:
>> My own preference for what to do about this is to leave the primary
>> message texts alone and add additional error-message fields for object
>> name and schema. This would address the need without making messages
>> uglier
On Mon, May 3, 2010 at 1:01 PM, Tom Lane wrote:
> My own preference for what to do about this is to leave the primary
> message texts alone and add additional error-message fields for object
> name and schema. This would address the need without making messages
> uglier for the large fraction of
* Simon Riggs (si...@2ndquadrant.com) wrote:
> I guarantee that if that proposal goes in, people will complain about
> that also. Last minute behaviour changes are bad news. I don't object to
> adding something, just don't take anything away. It's not like the code
> for it is pages long or anythin
Aidan Van Dyk wrote:
But your case of trying to "automatically" build/track the branch heads
for the buildfarm w/ git has a lot more strict requirements of the
*incremental* *conversion* *of* *CVS* than any of us had/have...
Actually, the thing that has recently annoyed me most has nothi
On Mon, 2010-05-03 at 10:50 +0100, Simon Riggs wrote:
> On Mon, 2010-05-03 at 12:17 +0300, Heikki Linnakangas wrote:
>
> > >> * wal_level doesn't describe what the impacts are on a standby if the
> > >> level is changed on the primary, nor is there a caution or a warning of
> > >> any kind. For ex
On Mon, 2010-05-03 at 18:54 +0200, Stefan Kaltenbrunner wrote:
> I'm not really sure how much serious testing outside of the small set of
> people mostly interested in one or another specific aspect of HS/SR has
> been actually done with the alphas to be honest.
> I just started testing HS yeste
"Greg Sabino Mullane" writes:
>> We're really not going to address this type of complaint on a
>> one-error-message-at-a-time basis. See prior discussions --- a more
>> realistic (and standards compliant) approach will probably involve
>> adding fields to the verbose form of the error message.
>
Simon Riggs wrote:
On Mon, 2010-05-03 at 11:37 -0400, Tom Lane wrote:
I've finally wrapped my head around exactly what the max_standby_delay
code is doing, and I'm not happy with it.
Yes, I don't think I'd call it perfect yet.
have the slave cancel competing queries if the replay process wa
On Mon, 2010-05-03 at 11:37 -0400, Tom Lane wrote:
> I've finally wrapped my head around exactly what the max_standby_delay
> code is doing, and I'm not happy with it.
Yes, I don't think I'd call it perfect yet.
> have the slave cancel competing queries if the replay process waits
> more than ma
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> ERROR: invalid input syntax for integer: "abc"
> CONTEXT: COPY alpha.foo, line 1, column a: "abc"
> We're really not going to address this type of complaint on a
> one-error-message-at-a-time basis. See prior discussions --- a more
> reali
Magnus Hagander writes:
> On Mon, May 3, 2010 at 17:05, Andrew Dunstan wrote:
>> I pulled together a quick hack, and here is what I get from my mirrors. I'm
>> not sure why we get those diffs - it's a bit odd, although fairly
>> insignificant.
> I don't think we can call anything insignificant -
On Mon, May 3, 2010 at 17:05, Andrew Dunstan wrote:
>
>
> Magnus Hagander wrote:
>>
>> On Mon, May 3, 2010 at 16:03, Aidan Van Dyk wrote:
>>
>>>
>>> * Andrew Dunstan [100503 09:02]:
>>>
I can probably pull together a script that exports from both git and cvs
and compares.
>>>
Tom Lane escribió:
> Andrew Dunstan writes:
> > Robert Haas wrote:
> >> - we need to make sure that all the committers understand how to keep
> >> the history the way we want it - i.e. linear, without merges, and
> >> possibly even implement programmatic safeguards against doing anything
> >> else
On Mon, May 3, 2010 at 17:55, Andrew Dunstan wrote:
>
> Robert Haas wrote:
>> - we need to make sure that all the committers understand how to keep
>> the history the way we want it - i.e. linear, without merges, and
>> possibly even implement programmatic safeguards against doing anything
>> else
Andrew Dunstan writes:
> Robert Haas wrote:
>> - we need to make sure that all the committers understand how to keep
>> the history the way we want it - i.e. linear, without merges, and
>> possibly even implement programmatic safeguards against doing anything
>> else
> That too will be part of my
Robert Haas wrote:
Heikki and I are both BIG git users, and I think Andrew, Simon, and
Alvaro all use it too, though I'm not sure to what extent.
I am using it increasingly. Of course, I need to convert some of my
customers
A couple of random things I'm concerned about:
- the b
I've finally wrapped my head around exactly what the max_standby_delay
code is doing, and I'm not happy with it. The way that code is designed
is that the setting represents a maximum allowed difference between the
standby server's system clock and the commit timestamps it is reading
from the WAL
On Mon, May 3, 2010 at 10:03 AM, Aidan Van Dyk wrote:
> Not to rain on anyone's git-parade, I'm a huge git fan, but until the
> busy committers, like Tom, Bruce, Heikki, Robert, Andrew, Simon, Alvaro,
> (and all the rest I'm missing or don't know how to spell of the top of
> my head) actually *all
* Andrew Dunstan [100503 11:05]:
> If it has been done why isn't it being run?
I suspect (but can only speak for myself) it's simply because to most of
us using git for development, it's irrelevant... We're using it to
track/build/develop, and the "history" and keywords aren't relevant to
us tr
Magnus Hagander wrote:
On Mon, May 3, 2010 at 16:03, Aidan Van Dyk wrote:
* Andrew Dunstan [100503 09:02]:
I can probably pull together a script that exports from both git and cvs
and compares.
HINT: It's all been done and posted to -hackers before too... Along
with compari
Aidan Van Dyk wrote:
* Andrew Dunstan [100503 09:02]:
I can probably pull together a script that exports from both git and cvs
and compares.
HINT: It's all been done and posted to -hackers before too... Along
with comparisons on on whte "one-time" conversions fare (parsecvs,
c
On Mon, May 3, 2010 at 10:25 AM, Tom Lane wrote:
> Magnus Hagander writes:
>> The thing we've always agreed upon is to at least start by migrating
>> something that's as close to our current workflow as possible to git,
>> and *then* consider changing anything in the workflow. We're not going
>>
On Mon, May 3, 2010 at 16:25, Tom Lane wrote:
> Magnus Hagander writes:
>> The thing we've always agreed upon is to at least start by migrating
>> something that's as close to our current workflow as possible to git,
>> and *then* consider changing anything in the workflow. We're not going
>> to
Magnus Hagander writes:
> The thing we've always agreed upon is to at least start by migrating
> something that's as close to our current workflow as possible to git,
> and *then* consider changing anything in the workflow. We're not going
> to change both at once.
Yeah. One of the main constrai
On Mon, May 3, 2010 at 16:13, Tom Lane wrote:
> Aidan Van Dyk writes:
>> If you want, I know a guy in Ottawa that does really fantastic git
>> presentations... He's done them to many of the local *UGs, Is there
>> interest from the core committers in getting one done at PGcon?
>
> I'd be interes
Aidan Van Dyk writes:
> If you want, I know a guy in Ottawa that does really fantastic git
> presentations... He's done them to many of the local *UGs, Is there
> interest from the core committers in getting one done at PGcon?
I'd be interested.
regards, tom lane
--
Se
On Mon, May 3, 2010 at 16:03, Aidan Van Dyk wrote:
> * Andrew Dunstan [100503 09:02]:
>>
>
>> I can probably pull together a script that exports from both git and cvs
>> and compares.
>
> HINT: It's all been done and posted to -hackers before too... Along
> with comparisons on on whte "one-time"
* Andrew Dunstan [100503 09:02]:
>
> I can probably pull together a script that exports from both git and cvs
> and compares.
HINT: It's all been done and posted to -hackers before too... Along
with comparisons on on whte "one-time" conversions fare (parsecvs,
cvs2svn/git), etc, as well as lo
Hello
One Czech pg user reported problems with function xslt_process. This
function is coded with ten parameters limit.
Attached patch add support to unlimited number of parameters.
const char **
parse_params(text *paramstr)
{
char *pos;
char *pstr;
char
Magnus Hagander wrote:
On Fri, Apr 30, 2010 at 19:46, Andrew Dunstan wrote:
Kevin Grittner wrote:
The reported source of the software seems to have gone away. I can
let you have my copy, which reliably reproduces the error, so we
have a good failure test case.
If it's not
Simon Riggs wrote:
> Doesn't this new behaviour prevent startup-from-a-shutdown-checkpoint?
No.
* wal_level doesn't explicitly describe that the levels are in sequence
and that hot_standby is a superset of archive.
>> It does say:
>> "The default value is minimal, which writes only the
On Fri, Apr 30, 2010 at 19:46, Andrew Dunstan wrote:
>
>
> Kevin Grittner wrote:
>>
>>> The reported source of the software seems to have gone away. I can
>>> let you have my copy, which reliably reproduces the error, so we
>>> have a good failure test case.
>>>
>>
>> If it's not as recent as thi
On Mon, 2010-05-03 at 12:17 +0300, Heikki Linnakangas wrote:
> >> * wal_level doesn't describe what the impacts are on a standby if the
> >> level is changed on the primary, nor is there a caution or a warning of
> >> any kind. For example, if a standby is setup with hot_standby = on and
> >> the
Bruce Momjian wrote:
> Simon Riggs wrote:
>> * wal_level = 'hot_standby' doesn't mention that the second parameter
>> also needs to be set, nor is there a xref.
Fixed.
>> * wal_level doesn't describe what the impacts are on a standby if the
>> level is changed on the primary, nor is there a cauti
84 matches
Mail list logo
