And I wanted to know what type of data structures are created by the parser
/ planner and how are they read by the executor.
I know that it is some sort of tree. But how many child nodes are there in a
node on the tree and what structure is the NODE itself of?
Which files should I look into to
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
On 02.11.2010 00:47, Tom Lane wrote:
Greg Starkgsst...@mit.edu writes:
On Mon, Nov 1, 2010 at 12:37 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
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.
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
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
Fujii Masao masao.fu...@gmail.com 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
Peter Eisentraut pete...@gmx.net 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
Peter Eisentraut pete...@gmx.net 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
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
On 02.11.2010 16:30, Tom Lane wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com 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.
Vaibhav Kaushal vaibhavkaushal...@gmail.com 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
On 02.11.2010 07:15, Fujii Masao wrote:
On Mon, Nov 1, 2010 at 8:32 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
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 of
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
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
Andres Freund and...@anarazel.de 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
On Tue, Nov 2, 2010 at 9:15 AM, Peter Eisentraut pete...@gmx.net 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
On Tue, Nov 2, 2010 at 8:40 AM, Euler Taveira de Oliveira
eu...@timbira.com 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
On Sat, Oct 30, 2010 at 10:01 AM, Tom Lane t...@sss.pgh.pa.us wrote:
marcin mank marcin.m...@gmail.com writes:
On Sat, Oct 30, 2010 at 6:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
3. To hash, apply the element type's hash function to each array
element. Combine these values by rotating the
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
Robert Haas robertmh...@gmail.com writes:
On Sat, Oct 30, 2010 at 10:01 AM, Tom Lane t...@sss.pgh.pa.us wrote:
marcin mank marcin.m...@gmail.com 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
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
On Tue, Nov 2, 2010 at 11:21 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sat, Oct 30, 2010 at 10:01 AM, Tom Lane t...@sss.pgh.pa.us wrote:
marcin mank marcin.m...@gmail.com writes:
This would make the hash the same for arrays with elements 32 apart
Robert Haas robertmh...@gmail.com wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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 ...
On Nov 2, 2010, at 11:17 AM, Peter Eisentraut pete...@gmx.net 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;
On Tue, Nov 2, 2010 at 12:34 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Robert Haas robertmh...@gmail.com wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
The goal is to make those hard to predict, though.
Really? I think I don't understand
Robert Haas robertmh...@gmail.com 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
Robert Haas robertmh...@gmail.com writes:
On Tue, Nov 2, 2010 at 11:21 AM, Tom Lane t...@sss.pgh.pa.us 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
On Tue, Nov 02, 2010 at 04:42:19PM -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Nov 2, 2010 at 11:21 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Really? ?I think I don't understand when this fails isn't obviously
better than being able to predict when it fails ...
On Nov 2, 2010, at 1:42 PM, Tom Lane t...@sss.pgh.pa.us 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
On Tuesday 02 November 2010 18:33:15 Kevin Grittner wrote:
Andres Freund and...@anarazel.de 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
Robert Haas robertmh...@gmail.com writes:
On Nov 2, 2010, at 1:42 PM, Tom Lane t...@sss.pgh.pa.us 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
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 and...@anarazel.de wrote:
* You wont see an error if the next command after the IDLE in
transaction is a COMMIT/ROLLBACK. I don*t see any
Andres Freund and...@anarazel.de 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
On Sat, Oct 30, 2010 at 01:01:44PM -0400, Tom Lane wrote:
marcin mank marcin.m...@gmail.com 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
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 become
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
Alexandre Riveira alexan...@objectdata.com.br 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.
Andres Freund and...@anarazel.de 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
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.
Short
41 matches
Mail list logo
