>>> Now, when I launch a query which includes "crosstab()" as a postgres user,
>>> everything works fine. However, if I launch it as user XXX, it complaints:
>
>> Are you schema qualifying the function name when you use it?
>> If not, does user XXX have schema tablefunc in their search_path?
>
>
Tom Lane wrote:
> Andreas Kretschmer writes:
> > production=*# explain analyse select * from boxes;
> > QUERY PLAN
> > ---
> > Seq Scan o
> Hi,
>
> I have a small question about the site of PostgreSQL source.
> http://www.postgresql.org/ftp/source/
>
> Now I can see some directories of PostgreSQL 9.2beta1/2.
> - v9.2.0beta1
> - v9.2.0beta2
> - v9.2beta1
> - v9.2beta2
>
> It seems to be pointed the same direcotory with each version
Hi,
I have a small question about the site of PostgreSQL source.
http://www.postgresql.org/ftp/source/
Now I can see some directories of PostgreSQL 9.2beta1/2.
- v9.2.0beta1
- v9.2.0beta2
- v9.2beta1
- v9.2beta2
It seems to be pointed the same direcotory with each version.
- v9.2beta1 => v9.2.0b
On Tue, Jul 3, 2012 at 2:47 PM, Bartosz Dmytrak wrote:
[snip]
> FOR v_row IN
> SELECT attname
> FROM pg_attribute
> WHERE attrelid = (quote_ident(TG_TABLE_SCHEMA) || '.' ||
> quote_ident(TG_TABLE_NAME))::text::regclass
> AND attnum > 0
> ORDER BY attnum
> LOOP
> EXECUTE 'SELECT NOT ($1.' || quot
Hi,
how about this one?
SELECT n.nspname, c.relname, a.attname
FROM pg_depend d
INNER JOIN pg_class c ON (c.oid = refobjid)
INNER JOIN pg_attribute a ON (c.oid = a.attrelid AND d.refobjsubid =
a.attnum)
INNER JOIN pg_namespace n ON (c.relnamespace = n.oid)
INNER JOIN pg_rewrite rw ON
I have restarted the cluster with "ignore_system_indexes=true" and was able
to connect to databases.
I have started re-indexing, seems to be working fine. Will get back if i
find further issues.
Regards,
Venkat
On Wed, Jul 4, 2012 at 3:35 PM, Raghavendra <
raghavendra@enterprisedb.com> wrote
>
> Re-index option did not work.
>
> Single user mode option did not work as well -
>
> [postgres@localhost bin]$ postgres --single oltp_db -E -D
> /usr/local/postgresql-9.0.1/data
> 2012-07-04 04:30:47 CDT [26072]: [1-1] user=,db= FATAL: index
> "pg_attribute_relid_attnum_index" contains unexpe
On Wed, Jul 4, 2012 at 2:12 PM, Raghavendra <
raghavendra@enterprisedb.com> wrote:
> On Wed, Jul 4, 2012 at 2:11 PM, Raghavendra <
> raghavendra@enterprisedb.com> wrote:
>
>> \
>>> postgres=# \c oltp_db
>>> FATAL: index "pg_attribute_relid_attnum_index" contains unexpected
>>> zero page
On Wed, Jul 4, 2012 at 2:11 PM, Raghavendra <
raghavendra@enterprisedb.com> wrote:
> \
>> postgres=# \c oltp_db
>> FATAL: index "pg_attribute_relid_attnum_index" contains unexpected zero
>> page at block 0
>> HINT: Please REINDEX it.
>> Previous connection kept
>>
>> Can anyone please help
>
> \
> postgres=# \c oltp_db
> FATAL: index "pg_attribute_relid_attnum_index" contains unexpected zero
> page at block 0
> HINT: Please REINDEX it.
> Previous connection kept
>
> Can anyone please help us.
>
>
You have HINT given to REINDEX it. Use reindexdb from OS.
---
Regards,
Raghavendra
En
Hello Community,
We have a critical situation where-in our production database server got
effected by "Root Kit".
When tried to build a replication site by copying the data directory to a
different server, so many files got missed while copying (this is due to
root kit effect).
So, we moved the
12 matches
Mail list logo
