In dump file statement which grants permissions on view exists before
statement which create view.
--TOC Entry ID 124 (OID 150248)
GRANT ALL on my_view to group sales;
... skipped
--TOC Entry ID 123 (OID 194103)
CREATE VIEW my_view ...
---(end of broadcast)---
On Mon, 8 Oct 2001, Nick Fankhauser wrote:
> I have no answer to this, but I'll add my experience to the question.
>
> I'm getting the same message, but in my case it is not consistent. It is
> always during a cron job that does a vacuum analyze in the middle of the
> night, but not every time t
Thanks Stephan- we'll quit worrying about the messages unless they coincide
with other problems.
Regards,
-Nick
> They should be safe (mostly a debugging message). IIRC, there were
> known bugs in earlier versions that happened on the reset, but that these
> were fixed and noone has found any
"Summer S. Wilson" <[EMAIL PROTECTED]> writes:
> I'm running PostgreSQL 7.1 with Slackware 8 on a dual processor Dell server.
> I have a database with 17 tables. I started VacuumDB with the analyze
> option on Friday around 3pm...when I came in this morning at 8 it was still
> not done. From the
"lt" <[EMAIL PROTECTED]> writes:
> OS: Redhat 7.1
What glibc version are you using? There's a serious bug in strcoll()
in glibc versions before 2.2.3 --- see
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=36539
In a multibyte-enabled Postgres this can lead to core dumps and
corrupted
Hi all,
Database: 7.1.3 (RPM)
OS: Redhat 7.1
Table: Create table jquserdata (
Username varchar(20) not null, primary
key,
¡)
Copy some corrupted data from a 7.1.3 (Encoding ASCII) with pg_dump,
Hi all,
I'm running PostgreSQL 7.1 with Slackware 8 on a dual processor Dell server.
I have a database with 17 tables. I started VacuumDB with the analyze
option on Friday around 3pm...when I came in this morning at 8 it was still
not done. From the verbose info, it seems to be "stuck" on one t
I have no answer to this, but I'll add my experience to the question.
I'm getting the same message, but in my case it is not consistent. It is
always during a cron job that does a vacuum analyze in the middle of the
night, but not every time the job runs. If I do the same thing interactively
(the
Hi,
To improve the database preformence, I tried to monitor all the query's and
the system usage by using the settings debug_print_query and show_query_stats
in the /etc/postgres/postgres.conf. The only problem is that I can't find a
relationship between the query and the stats, so I can't tel
