Tom Lane wrote:
> I notice that five different buildfarm members are about to slide off
> the HEAD list for not having reported in within a month. Do we have any
> process for pestering their owners to revive them? If the hardware went
> south, or there was some other deliberate decision to retir
Tom,
> I notice that five different buildfarm members are about to slide off
> the HEAD list for not having reported in within a month. Do we have any
> process for pestering their owners to revive them? If the hardware went
> south, or there was some other deliberate decision to retire them,
>
On Tuesday 28 August 2007 15:38, Tom Lane wrote:
> Therefore, I propose the same choices as before for table-size (no
> restriction) and database-size (must have CONNECT priv), and this
> for tablespace-size: you must have the ability to create tables in
> the target tablespace. This could be eith
I notice that five different buildfarm members are about to slide off
the HEAD list for not having reported in within a month. Do we have any
process for pestering their owners to revive them? If the hardware went
south, or there was some other deliberate decision to retire them,
that's fine ---
I've been working on converting the current README files for all contrib
modules into sgml and add it to the documentation. There are still some fixes
to do but i'd like to have some feedback. Indeed, it wasn't agreed to have
all if any of the modules together with the core documentation.
You c
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> btreefuncs.c is a security hole a mile wide: it will happily dump the
>> entire data content of an index for you. It's a good thing this hasn't
>> shipped in any release yet. While we could possibly make it look up
>> the index
We seem to be down to arguing about what permissions are needed to
execute the tablespace-size functions. I wrote:
> * tablespace-size function requires being owner of current DB.
> There is nothing particularly principled about the last choice, but
> it's not superuser and not wide open either.
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Alvaro Herrera wrote:
>>> That, or we create the makefiles in a fixed system and keep the
>>> Makefiles in CVS (though would be derived files).
>
>> IIRC, we previously looked into cmake and concluded it supported a lot
>> fewer plat
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
This particular issue could be implemented just by adding
-DCLOBBER_CACHE_ALWAYS to CFLAGS (or CPPFLAGS if you want to be anal
about it). I suppose that no new buildfarm mechanism is required ---
someone just
Has anyone come across this error before?
LOG: PickSplit method of 2 columns of index
'asset_position_lines_asset_cubespacetime_idx' doesn't support secondary split
This is a multi-column GiST index on an integer and a cube (a data type from
the postgres cube extension module).
I traced the
Dave Page <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> * tablespace-size function requires being owner of current DB.
> I assume superusers will also be able to use it, not just the actual owner?
Right --- it'd be an "ownercheck" call which means that superusers and
anyone who's been granted
Andrew Dunstan wrote:
> Tom Lane wrote:
>>
>> No, we have the ability to run a contrib module that's already been
>> installed. pg_regress cannot assume it has write privileges on
>> $SHAREDIR --- consider the "make installcheck" case.
>
> How big are these files? If small, is there a reason we c
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Luke Lonergan wrote:
> Below is a patch against Greenplum Database that fixes the problem.
>
> - Luke
>
> -- Fo
Tom Lane wrote:
> * no restriction on database-size function *when applied to the current
> database* (again, you could look into pg_class); to apply to some other
> database, you must have connect privileges. (Actually, on the
> assumption that you must have connect privs to current DB, I guess w
Josh Berkus <[EMAIL PROTECTED]> writes:
> Well, that puts us back in the position of requiring a "read" or "metadata"
> permission for tablespaces, or requiring superuser access. The latter is
> unpalatable because there are existing tools in the field which work without
> superuser access; the
Tom,
> ... in particular, that restriction seems pretty content-free for most
> practical layouts. And it's got interesting security behaviors:
> DBA A, by more-or-less innocently allowing some tables in his database B
> to be created in tablespace C, might be allowing his unrelated user D to
> f
Tom Lane wrote:
No, we have the ability to run a contrib module that's already been
installed. pg_regress cannot assume it has write privileges on
$SHAREDIR --- consider the "make installcheck" case.
How big are these files? If small, is there a reason we can't
At 11:48 PM 8/27/2007, Trevor Talbot wrote:
On 8/27/07, Jonah H. Harris <[EMAIL PROTECTED]> wrote:
> On 8/27/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> > that and the lack of evidence that they'd actually gain anything
>
> I find it somewhat ironic that PostgreSQL strives to be fairly
> non-corrup
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> The difficulty in testing these is that they require configuration
>> files, which the regression tests really can't install. (If the
>> configuration were all inside the database it wouldn't be such a
>> problem, but that's a l
(On the GENERAL list) Kamil Srot wrote:
Kynn Jones wrote:
I'm hoping to get some advice on a design question ...
...we use pgsql partitioning for other reasons
and it has some of the features you want (data separation, query
performance, ...).
It can be worth reading:
http://www.postgresql
Tom Lane wrote:
> I was a bit unhappy to realize just now that the patch Heikki sent in,
> and I reviewed and applied, actually broke dict_synonym. (Modifying a
> string tends to modify the result of strlen() ...) While we can't
> cover *everything* in the regression tests, it now seems like a ba
On Tue, 28 Aug 2007 10:15:41 +0200
Enrico <[EMAIL PROTECTED]> wrote:
> E troppo bello!!!
I'm sorry , I apoligize.
I select the wrong address.
I'm sorry again.
--
Enrico Pirozzi
Web: http://www.enricopirozzi.info
E-Mail: [EMAIL PROTECTED]
Skype: sscotty71
---(end o
E troppo bello!!!
http://www.youtube.com/watch?v=VU-VsLpHC3w&mode=related&search=
Buona giornata
Enrico
--
Enrico Pirozzi
Web: http://www.enricopirozzi.info
E-Mail: [EMAIL PROTECTED]
Skype: sscotty71
---(end of broadcast)---
TIP 2: Don't 'kill -9'
Tom Lane wrote:
> btreefuncs.c is a security hole a mile wide: it will happily dump the
> entire data content of an index for you. It's a good thing this hasn't
> shipped in any release yet. While we could possibly make it look up
> the index's parent table and check if you have SELECT privilege
Dawid Kuroczko wrote:
> [...] and it also would be valuable to
> add into pg_service.conf.sample an example ldap:// stanza, so if
> person opens the file, she will be enlightened.
I like that idea.
> And a missing feature. Or rather treat it as feature request. :-)
> A "wildcard entry". I would
Tom Lane wrote:
Would it be an option to have a checksum somewhere in each
data block that is verified upon read?
>
>>> That's been proposed before and rejected before. See the
>>> archives ...
>
> I think
> the prior discussions were around the same time WAL was initially put
> in, a
26 matches
Mail list logo
