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 patch
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
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, w
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 pe
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
prob
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
* 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 m
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-
* 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
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 re
* 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 substit
* 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
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 rai
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.)
--
Alvar
* 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 fixin
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 comp
* 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 does
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 *an
Bruce Momjian 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 privilege.
Never mind me,
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
p
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 befor
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.
Postg
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 broadcast)
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
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 pro
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
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 it
On 4/26/06, Martijn van Oosterhout 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".
> 4. Find t
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
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 w
"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 i
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*
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 concurren
"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. P
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 upda
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), i
Martijn van Oosterhout 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 is behaving a
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?
http://archives.postgre
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 tha
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 broadcast)--
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 bel
49 matches
Mail list logo
