Tom Lane wrote:
> It's possible that the multiply-by-31 method is as good as the
> rotate-and-xor method by that measure, or even better; but it's far from
> obvious that it's better. And I'm not convinced that the multiply
> method has a pedigree that should encourage me to take it on faith.
Sho
Andres Freund writes:
> On Tuesday 02 November 2010 22:59:15 Kevin Grittner wrote:
>>> Does anybody have any idea why COMMIT is allowed there? Seems
>>> pretty strange to me.
>> So that the "failed transaction" state can be cleared. The
>> transaction as a whole has failed, but you don't want th
Alexandre Riveira writes:
> When mentioned in Portuguese case-insensitive in fact we are also talking
> about accent-insensitive
See unaccent dictionary, but don't use only this one in your text search
configuration, IIRC.
http://www.postgresql.org/docs/9/static/unaccent.html
Regards,
--
Dim
Thank you all for your help !
When mentioned in Portuguese case-insensitive in fact we are also
talking about accent-insensitive
A common example is that the name Jose and José also can be written,
citext or ilike only not solve the problem
My progress is ...
Edit file /usr/share/i18n/loca
On Tuesday 02 November 2010 22:59:15 Kevin Grittner wrote:
> > Does anybody have any idea why COMMIT is allowed there? Seems
> > pretty strange to me.
>
>
> So that the "failed transaction" state can be cleared. The
> transaction as a whole has failed, but you don't want the connection
> to bec
On Sat, Oct 30, 2010 at 01:01:44PM -0400, Tom Lane wrote:
> marcin mank writes:
> > This is what boost does:
> > http://www.systomath.com/include/Boost-1_34/doc/html/boost/hash_combine.html
>
> Hmm. I am reminded of Knuth's famous dictum: "never generate random
> numbers with a method chosen at
Andres Freund wrote:
> On Tuesday 02 November 2010 18:33:15 Kevin Grittner wrote:
>> Well, on a ROLLBACK I'm not sure it's a problem. On a COMMIT,
>> couldn't you call a function to check for it in CommitTransaction
>> and PrepareTransaction?
> Sure, throwing an error somewhere wouldnt be that
Excerpts from Andres Freund's message of mar nov 02 18:36:19 -0300 2010:
> On Tuesday 02 November 2010 18:33:15 Kevin Grittner wrote:
> > Andres Freund wrote:
> > > * You wont see an error if the next command after the IDLE in
> > > transaction is a COMMIT/ROLLBACK. I don*t see any sensible way
>
Robert Haas writes:
> On Nov 2, 2010, at 1:42 PM, Tom Lane wrote:
>> However, this is largely beside the point, because that theory, as well
>> as the Java code you're arguing from, has to do with the initial hashing
>> of a raw sequence of input items. Not with combining some existing hash
>> v
On Tuesday 02 November 2010 18:33:15 Kevin Grittner wrote:
> Andres Freund wrote:
> > * You wont see an error if the next command after the IDLE in
> > transaction is a COMMIT/ROLLBACK. I don*t see any sensible way
> > around that.
> Well, on a ROLLBACK I'm not sure it's a problem. On a COMMIT,
>
On Nov 2, 2010, at 1:42 PM, Tom Lane wrote:
> However, this is largely beside the point, because that theory, as well
> as the Java code you're arguing from, has to do with the initial hashing
> of a raw sequence of input items. Not with combining some existing hash
> values. The rotate-and-xor
On Tue, Nov 02, 2010 at 04:42:19PM -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Tue, Nov 2, 2010 at 11:21 AM, Tom Lane wrote:
> >> Really? ?I think "I don't understand when this fails" isn't obviously
> >> better than being able to predict when it fails ...
>
> > Isn't that the whole poin
Robert Haas writes:
> On Tue, Nov 2, 2010 at 11:21 AM, Tom Lane wrote:
>> Really? I think "I don't understand when this fails" isn't obviously
>> better than being able to predict when it fails ...
> Isn't that the whole point of hash functions? Collisions are
> inevitable, but you want them t
Robert Haas wrote:
>> There's no reason that the hash value of an integer of the same
>> size as the hash shouldn't be the integer itself, for example.
>> It's hard to get more predictable than that, yet it works well
>> for hash lookups.
>
> Well, no, not really. For example, it may be that
On Tue, Nov 2, 2010 at 12:34 PM, Kevin Grittner
wrote:
> Robert Haas wrote:
>> Tom Lane wrote:
>>> Robert Haas writes:
>
The goal is to make those hard to predict, though.
>>>
>>> Really? I think "I don't understand when this fails" isn't
>>> obviously better than being able to predict wh
On Nov 2, 2010, at 11:17 AM, Peter Eisentraut wrote:
> On tis, 2010-11-02 at 10:54 -0700, Robert Haas wrote:
>> What do you plan to do about this case?
>>
>> CREATE TYPE test_type AS (a int, b text);
>> CREATE TABLE test_tbl (x test_type);
>> ALTER TYPE test_type ADD ATTRIBUTE c text;
>
> This i
Robert Haas wrote:
> Tom Lane wrote:
>> Robert Haas writes:
>>> The goal is to make those hard to predict, though.
>>
>> Really? I think "I don't understand when this fails" isn't
>> obviously better than being able to predict when it fails ...
>
> Isn't that the whole point of hash function
On Tue, Nov 2, 2010 at 11:21 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Sat, Oct 30, 2010 at 10:01 AM, Tom Lane wrote:
>>> marcin mank writes:
This would make the hash the same for arrays with elements 32 apart
swapped.
>>>
>>> Well, there are *always* going to be cases where yo
Excerpts from Tom Lane's message of mar nov 02 15:21:31 -0300 2010:
> What concerns me about that is that it tends to push the bits to the
> left --- I think the effects of the earlier inputs are going to overflow
> out as you incorporate a lot of newer inputs. What you want is a scheme
> where e
Robert Haas writes:
> On Sat, Oct 30, 2010 at 10:01 AM, Tom Lane wrote:
>> marcin mank writes:
>>> This would make the hash the same for arrays with elements 32 apart swapped.
>>
>> Well, there are *always* going to be cases where you get the same hash
>> value for two different inputs; it's un
On tis, 2010-11-02 at 10:54 -0700, Robert Haas wrote:
> What do you plan to do about this case?
>
> CREATE TYPE test_type AS (a int, b text);
> CREATE TABLE test_tbl (x test_type);
> ALTER TYPE test_type ADD ATTRIBUTE c text;
This is currently prohibited, and I'm not planning to do anything about
On Sat, Oct 30, 2010 at 10:01 AM, Tom Lane wrote:
> marcin mank writes:
>> On Sat, Oct 30, 2010 at 6:21 PM, Tom Lane wrote:
>>> 3. To hash, apply the element type's hash function to each array
>>> element. Combine these values by rotating the accumulator left
>>> one bit at each step and xor'in
On Tue, Nov 2, 2010 at 8:40 AM, Euler Taveira de Oliveira
wrote:
> Alexandre Riveira escreveu:
>> I've achieved some success in changing collate operating system (linux)
>> to generate sort of way of Brazil Portuguese hopes by adding the
>> following code in LC_COLLATE
>>
> This was already discus
On Tue, Nov 2, 2010 at 9:15 AM, Peter Eisentraut wrote:
> I'm working on propagating ALTER TYPE commands to typed tables. This is
> currently prohibited. For example, take these regression test cases:
>
> CREATE TYPE test_type2 AS (a int, b text);
> CREATE TABLE test_tbl2 OF test_type2;
> ALTER
Andres Freund wrote:
> * You wont see an error if the next command after the IDLE in
> transaction is a COMMIT/ROLLBACK. I don*t see any sensible way
> around that.
Well, on a ROLLBACK I'm not sure it's a problem. On a COMMIT,
couldn't you call a function to check for it in CommitTransaction
On Mon, Nov 01, 2010 at 12:17:02PM +0900, Itagaki Takahiro wrote:
> There are some "== true" in the codes, but they might not be safe
> because all non-zero values are true in C. Is it worth cleaning up them?
> ...
> src/interfaces/ecpg/ecpglib/connect.c(168): if (con->autocommit ==
> true && str
I'm working on propagating ALTER TYPE commands to typed tables. This is
currently prohibited. For example, take these regression test cases:
CREATE TYPE test_type2 AS (a int, b text);
CREATE TABLE test_tbl2 OF test_type2;
ALTER TYPE test_type2 ADD ATTRIBUTE c text; -- fails
ALTER TYPE test_type2
Alexandre Riveira escreveu:
> I've achieved some success in changing collate operating system (linux)
> to generate sort of way of Brazil Portuguese hopes by adding the
> following code in LC_COLLATE
>
This was already discussed; search the archives [1] [2].
> So far, I understood the mechanism o
On 02.11.2010 07:15, Fujii Masao wrote:
On Mon, Nov 1, 2010 at 8:32 PM, Heikki Linnakangas
wrote:
Yeah, that's one approach. Another is to validate the TLI in the xlog page
header, it should always match the current timeline we're on. That would
feel more robust to me.
Yeah, that seems bette
Vaibhav Kaushal wrote:
> What version should I start from? I guess postgresql 9.1 alpha
> would be good.
The HEAD of the master branch of the git repository is where
development normally takes place. You should start by developer
section of the main PostgreSQL web site and the pages to which
On 02.11.2010 16:30, Tom Lane wrote:
Heikki Linnakangas writes:
I think we can fix this by requiring that any multi-WAL-record actions
that are in-progress when a checkpoint starts (at the REDO-pointer) must
finish before the checkpoint record is written.
What happens if someone wants to star
Heikki Linnakangas writes:
> I think we can fix this by requiring that any multi-WAL-record actions
> that are in-progress when a checkpoint starts (at the REDO-pointer) must
> finish before the checkpoint record is written.
What happens if someone wants to start a new split while the checkpoin
Peter Eisentraut writes:
> This patch requires GNU make 3.80, because of the above "|" feature and
> the $(eval) function. Version 3.80 is dated October 2002, so it should
> be no problem, but I do occasionally read of make 3.79 around here;
> maybe it's time to get rid of that. I did put in a c
Peter Eisentraut writes:
> On sön, 2010-10-31 at 22:41 +0100, Andres Freund wrote:
>> * I renamed pg_[il]toa to pg_s(16|32|64)toa - I found the names
>> confusing. Not sure if its worth it.
> Given that there are widely established functions atoi() and atol(),
> naming the reverse itoa() and lto
Fujii Masao writes:
> After 9.0 release, I've often heard that some people want to know
> how far transactions have been replayed in the standby in timestamp
> rather than LSN. So I'm thinking to include the function which returns
> the timestamp of the last applied transaction (i.e., commit/abort
Hi,
After 9.0 release, I've often heard that some people want to know
how far transactions have been replayed in the standby in timestamp
rather than LSN. So I'm thinking to include the function which returns
the timestamp of the last applied transaction (i.e., commit/abort WAL
record) in the core
Hello All,
I am Vijay Ghatpande from Pune, India. I am in IT field for last 30 years and
mainly in ERP design, development and implementation. I have worked on JD
Edwards, Oracle Apps and SAP. I was involved in design and development of ERP
package called ISP – Integrated Software for Productio
We have the rm_safe_restartpoint mechanism to ensure that we don't use a
checkpoint that splits a multi-level B-tree insertion as a restart
point. But to my surprise, we don't have anything to protect against the
analogous case during normal operation. This is possible:
1. Split child page. Wr
On 02.11.2010 00:47, Tom Lane wrote:
Greg Stark writes:
On Mon, Nov 1, 2010 at 12:37 AM, Heikki Linnakangas
wrote:
Yes, indeed there is a corner-case bug when you try to stream the very first
WAL segment, with log==seg==0.
This smells very much like
http://article.gmane.org/gmane.comp.db.
On sön, 2010-10-31 at 22:41 +0100, Andres Freund wrote:
> * I renamed pg_[il]toa to pg_s(16|32|64)toa - I found the names
> confusing. Not sure if its worth it.
Given that there are widely established functions atoi() and atol(),
naming the reverse itoa() and ltoa() makes a lot of sense. The chan
40 matches
Mail list logo
