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:
> 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
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:
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
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
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 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
"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
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
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
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
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
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
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
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
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
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
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.
"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
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
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 ---
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
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,
>
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
26 matches
Mail list logo
