We (me and Oleg) are glad to present GIN to PostgreSQL. If community will agree,
we will commit it to HEAD branch.
http://www.sigaev.ru/gin/gin.gz
http://www.sigaev.ru/gin/README.txt
Install:
% cd pgsql
% zcat gin.gz | patch -p0
make and initdb, install tsearch2
Changes from previous
On Tue, 2006-04-25 at 13:43 -0400, Tom Lane wrote:
What I'm considering doing to fix that is require any change to a
btree's metapage data to send out a relcache inval message for the
index. That will force all backends to flush the stale cache item
not later than the start of their next
On Wed, 26 Apr 2006, Teodor Sigaev wrote:
We (me and Oleg) are glad to present GIN to PostgreSQL. If community will
agree, we will commit it to HEAD branch.
http://www.sigaev.ru/gin/gin.gz
http://www.sigaev.ru/gin/README.txt
Install:
% cd pgsql
% zcat gin.gz | patch -p0
make and
I just built this, and noticed that the regression test for opr_sanity
fails with your patch. I attached the regression.diffs.
Sorry, this part isn't done yet, because we are waiting of community decision..
We don't add regression test yet.
If community don't like to include GIN in core, we
I would like to start a discussion regarding the TODO item
“%Add a separate TRUNCATE permission” to gain more information.
The new TRUNCATE permission:
Is it meant to be a general truncating permission on all tables,
schema's like: “I, the DBA give you the privilege to TRUNCATE”
Or is this a
Simon Riggs [EMAIL PROTECTED] writes:
Hmmm I'm slightly worried that frequently-churning small tables will
be made even slower by this. What do you think?
How so?
So we would be able to cache other items also?
Only to the extent that you can guarantee a stale cache entry isn't a
problem.
On Wed, 2006-04-26 at 12:53 -0400, Tom Lane wrote:
So we would be able to cache other items also?
Only to the extent that you can guarantee a stale cache entry isn't a
problem. We've already done the analysis involved for the existing
metapage entries, but anything else would require more
* Gevik Babakhani ([EMAIL PROTECTED]) wrote:
The new TRUNCATE permission:
Is it meant to be a general truncating permission on all tables,
schema's like: ???I, the DBA give you the privilege to TRUNCATE???
Or is this a per-table, per-schema truncate privilege.
Could someone provide more
On Wed, 2006-04-26 at 13:31 -0400, Stephen Frost wrote:
* Gevik Babakhani ([EMAIL PROTECTED]) wrote:
The new TRUNCATE permission:
Is it meant to be a general truncating permission on all tables,
schema's like: ???I, the DBA give you the privilege to TRUNCATE???
Or is this a per-table,
* Gevik Babakhani ([EMAIL PROTECTED]) wrote:
On Wed, 2006-04-26 at 13:31 -0400, Stephen Frost wrote:
* Gevik Babakhani ([EMAIL PROTECTED]) wrote:
The new TRUNCATE permission:
Is it meant to be a general truncating permission on all tables,
schema's like: ???I, the DBA give you the
Gevik Babakhani [EMAIL PROTECTED] writes:
Would the privilege apply to the table depending on the table being
truncated?
I think the idea is to require TRUNCATE privilege on all the tables
being truncated in the command. This would substitute for the existing
ownership check.
I do have a
Stephen Frost [EMAIL PROTECTED] writes:
we need
to redesign the permission system to allow for more permission bits
because otherwise we'll run out soon.
Only if we keep inventing separate privileges for things as specific
as TRUNCATE. I was just about to raise this point as a possible reason
* Tom Lane ([EMAIL PROTECTED]) wrote:
Gevik Babakhani [EMAIL PROTECTED] writes:
Would the privilege apply to the table depending on the table being
truncated?
I think the idea is to require TRUNCATE privilege on all the tables
being truncated in the command. This would substitute for
* Tom Lane ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
we need
to redesign the permission system to allow for more permission bits
because otherwise we'll run out soon.
Only if we keep inventing separate privileges for things as specific
as TRUNCATE. I was just
Tom Lane wrote:
Stephen Frost [EMAIL PROTECTED] writes:
we need
to redesign the permission system to allow for more permission bits
because otherwise we'll run out soon.
Only if we keep inventing separate privileges for things as specific
as TRUNCATE. I was just about to raise this
Stephen Frost wrote:
The question that really ought to be answered before doing any of this
is why DELETE privilege shouldn't be sufficient to allow TRUNCATE.
TRUNCATE doesn't follow MVCC...
We can certainly talk about fixing that. (And CLUSTER at the same time,
I think.)
--
Alvaro
* Alvaro Herrera ([EMAIL PROTECTED]) wrote:
Stephen Frost wrote:
The question that really ought to be answered before doing any of this
is why DELETE privilege shouldn't be sufficient to allow TRUNCATE.
TRUNCATE doesn't follow MVCC...
We can certainly talk about fixing that. (And
On Wed, 2006-04-26 at 13:54 -0400, Tom Lane wrote:
The question that really ought to be answered before doing any of this
is why DELETE privilege shouldn't be sufficient to allow TRUNCATE.
This is actually a very good one I think. Perhaps we shouldn't code and
overkill making things more
* Stephen Frost ([EMAIL PROTECTED]) wrote:
* Alvaro Herrera ([EMAIL PROTECTED]) wrote:
Stephen Frost wrote:
The question that really ought to be answered before doing any of this
is why DELETE privilege shouldn't be sufficient to allow TRUNCATE.
TRUNCATE doesn't follow MVCC...
Stephen Frost wrote:
* Alvaro Herrera ([EMAIL PROTECTED]) wrote:
Stephen Frost wrote:
TRUNCATE doesn't follow MVCC...
We can certainly talk about fixing that. (And CLUSTER at the same time,
I think.)
The issue is that it seems to be intractable to retain MVCC-ness *and*
provide
Bruce Momjian pgman@candle.pha.pa.us writes:
Currently only the owner can TRUNCATE a table because triggers are not
called, and the table is locked in exclusive mode.
Doh. Of course the point about not calling ON DELETE triggers is why
this has to be considered a special
I ran afoul of these rules the other day when compiling pgsql 8.1 on
AIX. The configure scripts are set up to look for xlc instead of
cc, and that command invokes cc with -qalias=ansi, the ANSI-strict
pointer aliasing mode.
Specifically, in this mode, the compiler assumes that accesses via
Taral [EMAIL PROTECTED] writes:
I ran afoul of these rules the other day when compiling pgsql 8.1 on
AIX. The configure scripts are set up to look for xlc instead of
cc, and that command invokes cc with -qalias=ansi, the ANSI-strict
pointer aliasing mode.
We've looked at this before. There's
On Wed, Apr 26, 2006 at 03:45:00PM -0500, Taral wrote:
I ran afoul of these rules the other day when compiling pgsql 8.1 on
AIX. The configure scripts are set up to look for xlc instead of
cc, and that command invokes cc with -qalias=ansi, the ANSI-strict
pointer aliasing mode.
PostgreSQL
On Wed, Apr 26, 2006 at 04:58:31PM -0400, Tom Lane wrote:
We've looked at this before. There's no way we are buying into the
strict aliasing rules: it's not so much the code we know will break,
as the fear of what we don't know about. gcc, at least, is utterly
useless about warning about
Please accept my apologies for this trivial question...
I have been reading through the TODO items for the last couple of days
and I couldn't stop wondering whether there is history of discussion
kept or logged about the TODO items somewhere.
---(end of
Gevik Babakhani wrote:
Please accept my apologies for this trivial question...
I have been reading through the TODO items for the last couple of days
and I couldn't stop wondering whether there is history of discussion
kept or logged about the TODO items somewhere.
Not really, though the CVS
On Wed, Apr 26, 2006 at 11:44:52PM +0200, Gevik Babakhani wrote:
Please accept my apologies for this trivial question...
I have been reading through the TODO items for the last couple of days
and I couldn't stop wondering whether there is history of discussion
kept or logged about the TODO
Not really, though the CVS history shows when the item was added. Many
items represent complex threads of discussion, so only the general
conclusion is in the TODO list. Is there an items that is unclear?
The reason I asked this question is because I would like to contribute.
In fact I
Gevik Babakhani wrote:
Not really, though the CVS history shows when the item was added. Many
items represent complex threads of discussion, so only the general
conclusion is in the TODO list. Is there an items that is unclear?
The reason I asked this question is because I would like to
Thank you :)
On Wed, 2006-04-26 at 18:14 -0400, Bruce Momjian wrote:
Gevik Babakhani wrote:
Not really, though the CVS history shows when the item was added. Many
items represent complex threads of discussion, so only the general
conclusion is in the TODO list. Is there an items that
On 4/26/06, Martijn van Oosterhout kleptog@svana.org wrote:
Well, there are a number of fixes, it's questionable whether it's worth
the effort. In GCC you can mark structures that are aliased to avoid
the problem (attribute((may_alias)) iirc), but we don't do that.
There's also C99's restrict.
On 4/25/06 12:24 PM, Tom Lane [EMAIL PROTECTED] wrote:
I'm inclined to think that the right solution is to fix UpdateStats and
setRelhasindex so that they don't use simple_heap_update, but call
heap_update directly and cope with HeapTupleUpdated (by looping around
and trying the update from
On Wed, Apr 26, 2006 at 05:24:27PM -0500, Wes wrote:
On 4/25/06 12:24 PM, Tom Lane [EMAIL PROTECTED] wrote:
I'm inclined to think that the right solution is to fix UpdateStats and
setRelhasindex so that they don't use simple_heap_update, but call
heap_update directly and cope with
Jim C. Nasby [EMAIL PROTECTED] writes:
Try running a first index build by itself and then running them in
parallel.
Yeah, this is probably the best workaround for now. I think we should
look at making it fully concurrent-safe per upthread comments, but that
won't be happening in existing
Patch applied. Thanks.
---
Mark Kirkwood wrote:
Tom Lane wrote:
Mark Kirkwood [EMAIL PROTECTED] writes:
Good points! I had not noticed this test case. Probably NULL is better
Would setting it to 'BLCKSZ -
Patch applied. Thanks.
---
Mark Kirkwood wrote:
Mark Kirkwood wrote:
Tom Lane wrote:
I do notice a rather serious shortcoming of pg_freespacemap in its
current incarnation, which is that it *only* shows you
On Wed, Apr 26, 2006 at 06:42:53PM -0400, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
Try running a first index build by itself and then running them in
parallel.
Yeah, this is probably the best workaround for now. I think we should
look at making it fully concurrent-safe per
Jim C. Nasby [EMAIL PROTECTED] writes:
What about not updating if the tuplecount is within X percent? Would
that be safe enough to back-port?
Even if you got agreement that it was a good idea (I don't think so
myself), it wouldn't help Wes, at least not for values of X smaller
than 100.
On 4/26/06 5:34 PM, Jim C. Nasby [EMAIL PROTECTED] wrote:
Try running a first index build by itself and then running them in
parallel. Hopefully once pg_class has an exact tuple count the
conflicting update won't happen. If you actually have an exact tuple
count you could also try updating
On Wed, Apr 26, 2006 at 07:13:08PM -0400, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
What about not updating if the tuplecount is within X percent? Would
that be safe enough to back-port?
Even if you got agreement that it was a good idea (I don't think so
myself), it wouldn't
Martijn van Oosterhout kleptog@svana.org writes:
In the grandparent's case I think
the compiler is being really stupid because it can know the two
pointers are the same. But I'm sure there are more subtle cases where
it won't know. PostgreSQL typecasts pointers fairly freely.
Actually, if xlc
What changed between Try 1 and Try 2?
Teodor Sigaev wrote:
We (me and Oleg) are glad to present GIN to PostgreSQL. If community
will agree, we will commit it to HEAD branch.
---(end of broadcast)---
TIP 6: explain analyze is your friend
Oh I can't read - ignore me :)
Teodor Sigaev wrote:
Changes from previous patch:
* add support for tsearch2
* add 'fuzzy' limit
* fixes
---(end of broadcast)---
TIP 4: Have you searched our list archives?
On 4/26/06 5:42 PM, Tom Lane [EMAIL PROTECTED] wrote:
Yeah, this is probably the best workaround for now. I think we should
look at making it fully concurrent-safe per upthread comments, but that
won't be happening in existing release branches.
I changed the index build script such that for
Anyone,Hello our server had postgresql 7.4 when updated to 8.1.2 everything is working fine, but the version of pg_dunp is 7.4How do i upgrade pg_dump so I can dump / backup the database?Thanks
Bob
Tom Lane [EMAIL PROTECTED] writes:
As I read the spec, ANSI aliasing says that a given value must always be
accessed through equivalent (up to signedness) primitive types
It there a difference between C89 and C99 here?
--
greg
---(end of
Moving to -general, where this belongs.
How was PostgreSQL installed? There's no reason I know of why pg_dump
shouldn't have been upgraded.
On Thu, Apr 27, 2006 at 12:40:12PM +1000, Bob Shearer wrote:
Anyone,
Hello our server had postgresql 7.4 when updated to 8.1.2 everything is
working
On Wed, Apr 26, 2006 at 11:42:11PM -0400, Greg Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
As I read the spec, ANSI aliasing says that a given value must always be
accessed through equivalent (up to signedness) primitive types
It there a difference between C89 and C99 here?
I believe
49 matches
Mail list logo
