okay, I got it. The main reason behind it - is that I do drop table
in transaction. Every 10 minutes. So during that period, when
'replication' is running - the thing becomes unstable, and this error
can appear.
--
Grzegorz Jaskiewicz
C/C++ freelance for hire
On Mar 22, 2007, at 7:25 AM, Pavan Deolasee wrote:
Grzegorz, if you can try HOT as well, that will be great.
I tried, and it worked very well with 4.2 v of patch, as I remember.
My point was, since 'the day' comes closer, and you guys work on
close areas inside pg - I would like to be
Ühel kenal päeval, K, 2007-03-21 kell 17:25, kirjutas Bruce Momjian:
Added to TODO:
o During index creation, pre-sort the tuples to improve build speed
http://archives.postgresql.org/pgsql-hackers/2007-03/msg01199.php
Maybe the TODO text should mention, that it is about
On 3/21/07, Tom Lane [EMAIL PROTECTED] wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I guess this matches this TODO item:
o Allow selection of individual object(s) of all types, not just
tables
(...)
Code-wise, the patch seems a bit of a mess too --- it will certainly not
speaking with pavan off list he seems to think that only 'create
index' is outside transaction, not the other ddl flavors of it because
they are generally acquiring a excl lock. so, in that sense it is
possibly acceptable to me although still a pretty tough pill to
swallow (thinking, guc
On 3/22/07, Csaba Nagy [EMAIL PROTECTED] wrote:
speaking with pavan off list he seems to think that only 'create
index' is outside transaction, not the other ddl flavors of it because
they are generally acquiring a excl lock. so, in that sense it is
possibly acceptable to me although still
Hi,
I'm looking for a way to regenerate the plpgsql function cache, without
CREATE OR REPLACE function or restarting database...
Sometimes, tables could be dropped and recreated, and then all our
function working on these tables failed...
In fact we've more than 100 functions in our intranet
Pavan Deolasee wrote:
What I am hearing from many users is that its probably not such
a nice thing to put such restriction. Thats fair. It really helps to think
about a solution once you know what is acceptable and what is not.
That's likely to be the reaction for almost any restriction you
Hello,
There are many users (especially novice) asking about better and
easier configuration of tsearch2, which is quite complicated
currently. Even new FTS features in 8.3 (e.g. much clearer
configuration with SQL commands) won't help much for users that want
simple several clicks setup of a
On 3/21/2007 10:24 PM, Bruce Momjian wrote:
Ah, so you wait for me to go on vacation to apply it! Well, I am back
now, buddy. ;-)
Got to use my chances, don't I? :-p
One thing that bothers me about the patch is that it seems you are
adding functionality that allows you to enable/disable
On 3/22/07, Pavan Deolasee [EMAIL PROTECTED] wrote:
On 3/22/07, Csaba Nagy [EMAIL PROTECTED] wrote:
speaking with pavan off list he seems to think that only 'create
index' is outside transaction, not the other ddl flavors of it because
they are generally acquiring a excl lock. so, in that
Another change that could be done to Dllist is removing the Dllist
pointer from the Dlelem struct:
Index: src/include/lib/dllist.h
===
RCS file: /home/alvherre/Code/cvs/pgsql/src/include/lib/dllist.h,v
retrieving revision 1.27
diff
On 3/22/07, Hubert FONGARNAND [EMAIL PROTECTED] wrote:
Hi,
I'm looking for a way to regenerate the plpgsql function cache, without CREATE
OR REPLACE function or restarting database...
Sometimes, tables could be dropped and recreated, and then all our function
working on these tables
Hannu Krosing wrote:
?hel kenal p?eval, K, 2007-03-21 kell 17:25, kirjutas Bruce Momjian:
Added to TODO:
o During index creation, pre-sort the tuples to improve build speed
http://archives.postgresql.org/pgsql-hackers/2007-03/msg01199.php
Maybe the TODO text should
Hannu Krosing [EMAIL PROTECTED] writes:
Ãhel kenal päeval, K, 2007-03-21 kell 17:25, kirjutas Bruce Momjian:
Added to TODO:
o During index creation, pre-sort the tuples to improve build speed
Maybe the TODO text should mention, that it is about HASH indexes ?
It's under the hash-index
Alvaro Herrera [EMAIL PROTECTED] writes:
Another change that could be done to Dllist is removing the Dllist
pointer from the Dlelem struct:
I think this is a bad idea. The patch you propose makes
CatCacheRemoveCTup significantly more expensive (extra hash
calculation). Moreover, the savings
Hubert FONGARNAND [EMAIL PROTECTED] writes:
I'm looking for a way to regenerate the plpgsql function cache, without
CREATE OR REPLACE function or restarting database...
You don't have to restart the whole database, just start fresh connections.
regards, tom lane
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
I found LIKE operators are slower on multi-byte encoding databases
than single-byte encoding ones. It comes from difference between
MatchText() and MBMatchText().
We've had an optimization for single-byte encodings using
I advocate the following:
- Enable specification of TOAST policy on a per column basis
As a first step, then:
- Enable vertical partitioning of tables using per-column specification of
storage policy.
- Luke
On 3/21/07 1:12 PM, Bruce Momjian [EMAIL PROTECTED] wrote:
Is this a TODO?
Hi,
I want to contribute with new features in Data mining. In the University of
Nariño (Colombia) works in new operators and primitives in Knowledge
Discovery in Databases and We had integrated several operators in a own
version named PostgresKDD, We like integrate this features in the official
Please read the developer's FAQ on the web site first. That should have
all the information you need.
---
andress calderon wrote:
Hi,
I want to contribute with new features in Data mining. In the University of
Nari?o
Bruce Momjian wrote:
Please read the developer's FAQ on the web site first. That should have
all the information you need.
Andress,
First let me say welcome! We are always glad to have more contributors.
As Bruce said, the first step would be reading the developers FAQ. You
can find it here:
Hi,
I'm seeing the following regression failure in PL/Tcl. It seems to be
just an ordering issue, and the order in which a trigger is fired.
This is a pristine, freshly updated copy of CVS head as of right now.
I'm not sure why the buildfarm is not having this problem.
alvherre=# select
Alvaro Herrera wrote:
Hi,
I'm seeing the following regression failure in PL/Tcl. It seems to be
just an ordering issue, and the order in which a trigger is fired.
This is a pristine, freshly updated copy of CVS head as of right now.
I removed the derived files (moral equivalent of make
On 3/21/07, Bruce Momjian [EMAIL PROTECTED] wrote:
A different idea is to flag the _index_ as using HOT for the table or
not, using a boolean in pg_index. The idea is that when a new index is
created, it has its HOT boolean set to false and indexes all tuples and
ignores HOT chains. Then
Luke Lonergan wrote:
I advocate the following:
- Enable specification of TOAST policy on a per column basis
As a first step, then:
- Enable vertical partitioning of tables using per-column specification of
storage policy.
Wouldn't it be enough to enable having the toast table on a
Alvaro Herrera [EMAIL PROTECTED] writes:
I'm seeing the following regression failure in PL/Tcl. It seems to be
just an ordering issue, and the order in which a trigger is fired.
Works on my x86_64 box. Are you running the test in C locale (because
it looks a bit like a sort-ordering issue)?
Alvaro Herrera wrote:
Hi,
I'm seeing the following regression failure in PL/Tcl. It seems to be
just an ordering issue, and the order in which a trigger is fired.
This is a pristine, freshly updated copy of CVS head as of right now.
I'm not sure why the buildfarm is not having this problem.
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
I'm seeing the following regression failure in PL/Tcl. It seems to be
just an ordering issue, and the order in which a trigger is fired.
Works on my x86_64 box. Are you running the test in C locale (because
it looks a bit like a
Andreas,
On 3/22/07 9:40 AM, Andreas Pflug [EMAIL PROTECTED] wrote:
Wouldn't it be enough to enable having the toast table on a different
table space?
Yes, but the ultimate goal would allow the allocation of a storage mechanism
that is unique to each column. The most frequently used
Pavan Deolasee [EMAIL PROTECTED] writes:
When CREATE INDEX starts, it acquires ShareLock on the table.
At this point we may have one or more HOT-update chains in the
table. Tuples in this chain may be visible to one or more running
transactions. The fact that we have ShareLock on the table
William Garrison [EMAIL PROTECTED] writes:
Tom Lane wrote:
What do you mean by one batch exactly? Both CREATE and DROP TABLESPACE
refuse to run in a transaction block, so I'm confused about this.
Not a transaction block. A batch of commands submitted to the server in
a single call. In
On 3/22/07, Tom Lane [EMAIL PROTECTED] wrote:
Pavan Deolasee [EMAIL PROTECTED] writes:
When CREATE INDEX starts, it acquires ShareLock on the table.
At this point we may have one or more HOT-update chains in the
table. Tuples in this chain may be visible to one or more running
transactions.
TANIDA Yutaka [EMAIL PROTECTED] writes:
My customer found a problem about PL/pgsql functions and TRUNCATE command.
If you execute PL/pgsql function includeing TRUNCATE command concurrently,
causes relation ... does not exist. or relation with OID X does not
exist against
exists table.
On Mon, Mar 19, 2007 at 12:05:19PM +, Simon Riggs wrote:
I was unwilling to compromise to have HOT if only one index existed, but
IMHO allowing HOT with = 3 indexes is an acceptable compromise for this
release. (We can always use vertical partitioning techniques to allow
additional access
Pavan Deolasee wrote:
My argument is that its enough to index only the LIVE tuple which
is at the end of the chain if we don't use the new index for queries
in transactions which were started before CREATE INDEX. I am
proposing to do that by storing an xid in the pg_index row. A
special case
On Thu, 2007-03-22 at 22:11 +0530, Pavan Deolasee wrote:
With this background, I propose to index ONLY the head of the
HOT-chain. The TID of the root tuple is used instead of the actual
TID of the tuple being indexed. This index will not be available to
the transactions which are started
[EMAIL PROTECTED] (Luke Lonergan) writes:
Andreas,
On 3/22/07 9:40 AM, Andreas Pflug [EMAIL PROTECTED] wrote:
Wouldn't it be enough to enable having the toast table on a different
table space?
Yes, but the ultimate goal would allow the allocation of a storage mechanism
that is unique to
Simon Riggs [EMAIL PROTECTED] writes:
There is a slight hole in that SERIALIZABLE transactions won't be able
to use any indexes they build during their transaction, since they may
need to be able to see prior data, but I don't think anybody is going to
complain about that restriction. Anyone?
Jan Wieck wrote:
On 3/21/2007 10:24 PM, Bruce Momjian wrote:
Ah, so you wait for me to go on vacation to apply it! Well, I am back
now, buddy. ;-)
Got to use my chances, don't I? :-p
One thing that bothers me about the patch is that it seems you are
adding functionality that
Added to TODO for CLUSTER:
o %Add VERBOSE option to report tables as they are processed,
like VACUUM VERBOSE
---
Grzegorz Jaskiewicz wrote:
On Mar 16, 2007, at 9:53 AM, Heikki Linnakangas wrote:
Added to TODO:
* Fix cases where invalid byte encodings are accepted by the database,
but throw an error on SELECT
http://archives.postgresql.org/pgsql-hackers/2007-03/msg00767.php
Is anyone working on fixing this bug?
On Thu, 2007-03-22 at 16:16 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
There is a slight hole in that SERIALIZABLE transactions won't be able
to use any indexes they build during their transaction, since they may
need to be able to see prior data, but I don't think anybody
Mike Rylander wrote:
A related question, however: Will the XML features being included in
8.3 support namespace prefix registration? If not, handling arbitrary
XML via XPath that includes unprefixed (default) namespaces (for me
that is the majority of the XML I deal with, and no, I can't
Chris,
Hmm. Are you trying to do something sort of like CStore?
http://db.csail.mit.edu/projects/cstore/
That seems to have some relevant ideas...
I think something like is a good way to put it. As you know Cstore was a
prototype for Vertica and these are in the same class as SybaseIQ
Bruce Momjian wrote:
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
We wouldn't clean up tuples that are visible to a transaction, but if
you have one long-running transaction like pg_dump in a database with
otherwise short transaction, you'll have a lot of tuples that
On Thu, 2007-03-22 at 10:36 -0500, andress calderon wrote:
Hi,
I want to contribute with new features in Data mining. In the
University of Nariño (Colombia) works in new operators and primitives
in Knowledge Discovery in Databases and We had integrated several
operators in a own version
Bruce Momjian [EMAIL PROTECTED] writes:
In researching, I found we already do this by updating PGPROC.xid for
every command in non-serialzable transactions:
Dunno how you arrived at that conclusion, but it's quite wrong.
regards, tom lane
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
In researching, I found we already do this by updating PGPROC.xid for
every command in non-serialzable transactions:
Dunno how you arrived at that conclusion, but it's quite wrong.
Looking in the function I now see you are right:
Ühel kenal päeval, N, 2007-03-22 kell 10:19, kirjutas Luke Lonergan:
Andreas,
On 3/22/07 9:40 AM, Andreas Pflug [EMAIL PROTECTED] wrote:
Wouldn't it be enough to enable having the toast table on a different
table space?
Yes, but the ultimate goal would allow the allocation of a
Bruce Momjian [EMAIL PROTECTED] writes:
So, can't this be improved to allow more aggressive vacuuming?
Not at that level. We do not keep track of the oldest still-used
snapshot in a transaction. I'm dubious that it'd be worth the
bookkeeping trouble to try --- often as not, the problem with a
Hi Hannu,
On 3/22/07 3:21 PM, Hannu Krosing [EMAIL PROTECTED] wrote:
Maybe monetdb ( http://monetdb.cwi.nl/ ) can be of some inspiration ?
btw, it may be a good idea to have a verion of bizgresMPP which has
monetdb as partition db, if monetdb is as efficient as they tell it is .
Yep - I've
Ühel kenal päeval, N, 2007-03-22 kell 11:08, kirjutas Tom Lane:
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
I found LIKE operators are slower on multi-byte encoding databases
than single-byte encoding ones. It comes from difference between
MatchText() and MBMatchText().
We've had an
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Applying newest version of this patch now; still needs documentation.
---
Nikolay Samokhvalov wrote:
On 3/5/07, Nikolay Samokhvalov [EMAIL PROTECTED] wrote:
On 3/4/07, Nikolay Samokhvalov [EMAIL PROTECTED] wrote:
Andrew Dunstan wrote:
Would it be better to use some more unlikely name for the dummy root
element used to process fragments than x ?
Why do we even need to support xpath on fragments?
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of
Bruce Momjian wrote:
Your patch has been added to the PostgreSQL unapplied patches list
at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers
reviews and approves it.
I was hoping that we're deprecating contrib/xml2, so I
Peter Eisentraut wrote:
Bruce Momjian wrote:
Your patch has been added to the PostgreSQL unapplied patches list
at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers
reviews and approves it.
I was hoping that we're
Bruce Momjian wrote:
Peter Eisentraut wrote:
I was hoping that we're deprecating contrib/xml2, so I wouldn't add more
features to it.
Author states:
I understand that XML support is planned and at least partially
implemented for 8.3, but many production instances will be unable (or,
in
Dave Page wrote:
Bruce Momjian wrote:
Peter Eisentraut wrote:
I was hoping that we're deprecating contrib/xml2, so I wouldn't add more
features to it.
Author states:
I understand that XML support is planned and at least partially
implemented for 8.3, but many production
Bruce Momjian [EMAIL PROTECTED] writes:
Peter Eisentraut wrote:
I was hoping that we're deprecating contrib/xml2, so I wouldn't add more
features to it.
Author states:
I understand that XML support is planned and at least partially
implemented for 8.3, but many production instances will
On 3/22/07, Tom Lane [EMAIL PROTECTED] wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Peter Eisentraut wrote:
I was hoping that we're deprecating contrib/xml2, so I wouldn't add more
features to it.
Author states:
I understand that XML support is planned and at least partially
Mike Rylander wrote:
A related question, however: Will the XML features being included in
8.3 support namespace prefix registration?
That is certainly the plan.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of
Peter Eisentraut wrote:
Mike Rylander wrote:
A related question, however: Will the XML features being included in
8.3 support namespace prefix registration?
That is certainly the plan.
Let me bounce my ostrich (sp?) head up here and say, thanks for your
work on this Peter.
Joshua D. Drake
Jim C. Nasby wrote:
On Mon, Mar 19, 2007 at 12:05:19PM +, Simon Riggs wrote:
I was unwilling to compromise to have HOT if only one index existed, but
IMHO allowing HOT with = 3 indexes is an acceptable compromise for this
release. (We can always use vertical partitioning techniques to
Simon Riggs wrote:
On Thu, 2007-03-22 at 16:16 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
There is a slight hole in that SERIALIZABLE transactions won't be able
to use any indexes they build during their transaction, since they may
need to be able to see prior data,
Hannu Krosing [EMAIL PROTECTED] wrote:
We've had an optimization for single-byte encodings using
pg_database_encoding_max_length() == 1 test. I'll propose to extend it
in UTF-8 with locale-C case.
If this works for UTF8, won't it work for all the backend-legal
encodings?
I
On 3/23/07, Simon Riggs [EMAIL PROTECTED] wrote:
The ShareLock taken by CREATE INDEX guarantees all transactions that
wrote data to the table have completed and that no new data can be added
until after the index build commits. So the end of the chain is visible
to CREATE INDEX and won't
Dennis Bjorklund [EMAIL PROTECTED] wrote:
The problem with the like pattern _ is that it has to know how long the
single caracter is that it should pass over. Say you have a UTF-8 string
with 2 characters encoded in 3 bytes ('ÖA'). Where the first character
is 2 bytes:
0xC3 0x96 'A'
ITAGAKI Takahiro skrev:
I guess it works well for % but not for _ , the latter has to know, how
many bytes the current (multibyte) character covers.
Yes, % is not used in trailing bytes for all encodings, but _ is
used in some of them. I think we can use the optimization for all
of the server
On 2007-03-22, Tom Lane [EMAIL PROTECTED] wrote:
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
I found LIKE operators are slower on multi-byte encoding databases
than single-byte encoding ones. It comes from difference between
MatchText() and MBMatchText().
We've had an optimization for
On 2007-03-23, ITAGAKI Takahiro [EMAIL PROTECTED] wrote:
Thanks, it all made sense to me. My proposal was completely wrong.
Actually, I think your proposal is fundamentally correct, merely incomplete.
Doing octet-based rather than character-based matching of strings is a
_design goal_ of UTF8.
72 matches
Mail list logo
