> I'd like to avoid a GUC for "percent_full_warning" if we can. Can anyone
> see a way around this? Should we just assume 90% full?
Well, it was only an idea of not leaving the admin out in the rain but
giving im a hint by time of what might happen if there was no action. I
have absolutely no
Richard Huxton wrote:
David Siebert wrote:
Okay I have version 8.0.2 installed on CentOS 4.0 with all updates.
I SSH into the server and try and run pg_dump all and get a stream of
errors on the server screen but not on my ssh.
Any suggestions?
Um - post some of the errors?
There are some
On Mon, 2005-06-06 at 14:52, Edward Peschko wrote:
> hey all,
>
>
> I'm trying to convince some people here to adopt either mysql or postgresql
> as a relational database here.. However, we can't start from a clean slate;
> we have a very mature oracle database that applications point to right n
On Jun 13, 2005, at 6:48 PM, Jonah H. Harris wrote:
I wouldn't say it's enterprise-grade, but one could probably make it
work.
I totally agree--I use it relatively often. This single piece of
software opened my eyes as to the extent to which the procedure
languages can be leveraged.
Se
There is DBI-link, but this probably isn't an "enterprise" solution
http://www.pervasive-postgres.com/postgresql/tidbits.asp
Sean
On Jun 13, 2005, at 2:31 PM, Jonah H. Harris wrote:
The contrib/dblink module only works for creating a database link to
another PostgreSQL database. I'm work
Josh Berkus writes:
> Yeah, the problem is that with the upcoming "group ownership" I see
> user-based quotas as being rather difficult to implement unambiguously.
> Even more so when we get "local users" in the future. So I'd only want
> to do it if there was a real-world use case that table
Jonah,
> Was someone going to implement this? If not, I can probably get it done
> in a couple days.
Don't let me stop you.
I'd like to avoid a GUC for "percent_full_warning" if we can. Can anyone
see a way around this? Should we just assume 90% full?
--
--Josh
Josh Berkus
Aglio Database
Teodor Sigaev <[EMAIL PROTECTED]> wrote:
> ... So, if index is defined as 'using gist (a,b,c)' then, in
> principle, GiST index can speed up queries like 'a=V1 and c=V2'. But
> it will not usable for queries ( b=V3 and c=V2 ). By the way, instead
> of '=' operation may be used other operations. Nu
I wouldn't say it's enterprise-grade, but one could probably make it work.
Sean Davis wrote:
There is DBI-link, but this probably isn't an "enterprise" solution
http://www.pervasive-postgres.com/postgresql/tidbits.asp
Sean
On Jun 13, 2005, at 2:31 PM, Jonah H. Harris wrote:
The contrib/d
Well... a maximum tablespace size would be much easier to implement and
would still accomplish this level of quota for larger organizations and
database systems.
I vote for implmenting the maximum tablespace size and revisiting actual
user/group quotas when the need arises.
Was someone going
Hi Josh, hi jonah,
On Mon, Jun 13, 2005 at 12:36:12PM -0700, Josh Berkus wrote:
>
> > Don't get me wrong, I think we need tablespace maximums. What I'm
> > looking at is a user/group-based quota which would allow a superuser to
> > grant say, 2G of space to a user or group. Any object that user
On Mon, 13 Jun 2005, Andrew - Supernews wrote:
The relfilenode of the index relation changes, so it's no longer equal
to the OID. If you look on-disk for the relfilenode, you will find it.
Perfect, hadn't even thought of that ... thanks ...
Marc G. Fournier Hub.Org Networking S
On 2005-06-13, "Marc G. Fournier" <[EMAIL PROTECTED]> wrote:
>
> 'k, I've been playing around with the REINDEX stuff, and either I'm
> mis-understanding something, or there is a bug in 7.4.x ...
>
> If I do a:
>
> REINDEX TABLE pg_statistic;
>
> my 'on disk' INDEX is disappearing, altho there is n
* Josh Berkus (josh@agliodbs.com) wrote:
> Yeah, the problem is that with the upcoming "group ownership" I see
> user-based quotas as being rather difficult to implement unambiguously.
I'm not sure it'd be terribly different with roles than with
user/groups. A role gets a quota, anything which
Jonah,
> Don't get me wrong, I think we need tablespace maximums. What I'm
> looking at is a user/group-based quota which would allow a superuser to
> grant say, 2G of space to a user or group. Any object that user owned
> would be included in the space allocation.
>
> So, if the user owns three
'k, I've been playing around with the REINDEX stuff, and either I'm
mis-understanding something, or there is a bug in 7.4.x ...
If I do a:
REINDEX TABLE pg_statistic;
my 'on disk' INDEX is disappearing, altho there is no errors being
generated:
# select oid,relname from pg_class where rel
REINDEX DATABASE, as just discussed, does only the SYSTEM tables ... is
there a way of having VACUUM run only on teh system tables also, without
having to do each individually?
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: [EMAIL PROTECTED]
Josh,
Don't get me wrong, I think we need tablespace maximums. What I'm
looking at is a user/group-based quota which would allow a superuser to
grant say, 2G of space to a user or group. Any object that user owned
would be included in the space allocation.
So, if the user owns three tables
Jonah,
> A quota is significantly different from a maximum size. I was thinking
> more along the lines of the following:
Hmmm. Can you give me a case where we need per-user quotas that would not be
satisfied by tablespace maximums? I'm not understanding the rationale, and
I see several ser
On Mon, 13 Jun 2005, Andrew Dunstan wrote:
Marc G. Fournier wrote:
On Mon, 13 Jun 2005, Jan Wieck wrote:
On 6/12/2005 8:03 PM, Marc G. Fournier wrote:
Couldn't behaviour of REINDEX DATABASE not take that into account, and
'skip' the system indices if not superuser?
Silently doing some
On Mon, 13 Jun 2005, Tom Lane wrote:
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
On Mon, 13 Jun 2005, Jan Wieck wrote:
Silently doing something other than what the user requested ... I
don't think this is the right way to become the most popular open
source database in the world.
But, we
The contrib/dblink module only works for creating a database link to
another PostgreSQL database. I'm working on a dblink_ora which allows
you to connect to an 8i, 9i, or 10g system the same way. dblink_ora is
based on dblink, not dblink_tds (for SQL Server) so it has more
features. Also, I'
On Thursday 09 June 2005 22:03, Christopher Kings-Lynne wrote:
> > Someone commented to me recently that they usually use psql's \x
> > "expanded output" mode, but find that it produces pretty illegible
> > results for psql slash commands such as \d. I can't really see a reason
> > you would _want_
Marc G. Fournier wrote:
On Mon, 13 Jun 2005, Jan Wieck wrote:
On 6/12/2005 8:03 PM, Marc G. Fournier wrote:
Couldn't behaviour of REINDEX DATABASE not take that into account,
and 'skip' the system indices if not superuser?
Silently doing something other than what the user requested ...
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> On Mon, 13 Jun 2005, Jan Wieck wrote:
>> Silently doing something other than what the user requested ... I
>> don't think this is the right way to become the most popular open
>> source database in the world.
> But, we are already doing that, no? :)
On Mon, 13 Jun 2005, Jan Wieck wrote:
On 6/12/2005 8:03 PM, Marc G. Fournier wrote:
Couldn't behaviour of REINDEX DATABASE not take that into account, and
'skip' the system indices if not superuser?
Silently doing something other than what the user requested ... I don't think
this is the ri
On Mon, Jun 13, 2005 at 07:39:40PM +0530, Abhijit Menon-Sen wrote:
> At 2005-06-12 14:54:47 +0530, [EMAIL PROTECTED] wrote:
> >
> > The idea is to have spi_query call SPI_prepare/SPI_open_cursor,
> > and have an spi_fetchrow that calls SPI_cursor_fetch. It works
> > well enough, but I don't know ho
At 2005-06-12 14:54:47 +0530, [EMAIL PROTECTED] wrote:
>
> The idea is to have spi_query call SPI_prepare/SPI_open_cursor, and have
> an spi_fetchrow that calls SPI_cursor_fetch. It works well enough, but I
> don't know how to reproduce spi_exec_query's error handling (it runs the
> SPI_execute in
Am Montag, den 13.06.2005, 08:16 -0400 schrieb Jan Wieck:
> On 6/12/2005 8:03 PM, Marc G. Fournier wrote:
>
> > Couldn't behaviour of REINDEX DATABASE not take that into account, and
> > 'skip' the system indices if not superuser?
>
> Silently doing something other than what the user requested .
On 6/12/2005 8:03 PM, Marc G. Fournier wrote:
Couldn't behaviour of REINDEX DATABASE not take that into account, and
'skip' the system indices if not superuser?
Silently doing something other than what the user requested ... I don't
think this is the right way to become the most popular open
On L, 2005-06-11 at 12:25 -0400, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > On R, 2005-06-10 at 12:12 -0400, Tom Lane wrote:
> >> Have you forgotten Zeno's paradox? I don't see a
> >> reason to assume the indexer can *ever* catch up --- it's entirely
> >> likely that adding a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
On Mon, 13 Jun 2005, Weilguni Mario wrote:
In fakt, it allows users with hyphens, but you have to use quotes:
CREATE USER "foo-bar";
DROP USER "foo-bar";
Yeah quotes. I should have remembered it. Thanks Weilgunu, Dave and
Michael.
Regards
On Jun 13, 2005, at 8:30 PM, Devrim GUNDUZ wrote:
AFAIK, PostgreSQL does not allow hyphens in usernames and
databases, right?
AFAIK, you can use whatever you want if you double-quote it.
test=# create database "hyphen-test";
LOG: transaction ID wrap limit is 2147484134, limited by database
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Devrim GUNDUZ
> Sent: 13 June 2005 12:31
> To: pgsql-hackers@postgresql.org
> Subject: [HACKERS] Usernames with hyphens
>
> template1=# CREATE USER hyphen-test;
> ERROR: syntax error at or near "-"
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
AFAIK, PostgreSQL does not allow hyphens in usernames and databases,
right?
template1=# SELECT version();
version
-
--
In fakt, it allows users with hyphens, but you have to use quotes:
CREATE USER "foo-bar";
DROP USER "foo-bar";
Regards,
Mario Weilguni
-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Devrim GUNDUZ
Gesendet: Montag, 13. Juni 2005 13:31
An
36 matches
Mail list logo
