Ryan Kelly writes:
> It seems that ALTER TABLE ... OWNER TO does not change the ownership of
> any inheriting tables. The documentation states:
>> If ONLY is specified, only that table is altered. If ONLY is not
>> specified, the table and any descendant tables are altered.
If you read further (
"Alex Hunsaker" writes:
> Namely it does not disable the rule... Enabling inside of the
> transaction seems to work though
Fixed, thanks ...
Index: relcache.c
===
RCS file: /cvsroot/pgsql/src/backend/utils/cache/relcache.c,v
retriev
On Mon, Dec 29, 2008 at 15:07, Alex Hunsaker wrote:
> Namely it does not disable the rule...
> Enabling inside of the transaction seems to work though
Hrm the above turned out to be false... must have gotten confused when
testing with triggers
If i turn on RELCACHE_FORCE_RELEASE or CLOBBER_CACH
On 9 Srp, 19:38, [EMAIL PROTECTED] (Gregory Stark) wrote:
> <[EMAIL PROTECTED]> writes:
> > ALTER TABLE name RENAME TO new_name;
> > ALTER TABLE new_name
> > RENAME COLUMN x TO y;
>
> ...
> > I think the issue might be reproducible by creating table with a lot
> > of rows, setting high work_mem a
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Apparently, rd_indexattr needs to get cleared someplace where it
> isn't being cleared right now. I'm sure this is related to the
> fancy dance we do for pg_class reindexing, but not sure yet where
> to fix it.
Yeah, doing the equivalent of this in gdb se
Gregory Stark <[EMAIL PROTECTED]> writes:
> Uhm. Is it possible we're mistakenly doing a HOT update because we're lying
> about what indexes exist?
Yup, exactly. Here's my proposed fix...
regards, tom lane
Index: src/backend/catalog/index.c
==
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Also, I can still reproduce it with just REINDEX TABLE pg_class instead
> of REINDEX DATABASE.
Ah, I had tried just a reindex xxx but not a reindex pg_class.
* reindex_index will attempt to update the pg_class rows for the
relation
* an
I wrote:
> What I suspect is we've broken the logic that manages REINDEX applied to
> pg_class itself.
Hm, this is a HOT bug. (Unless the OP found it on something older
than 8.3, in which case we might have more than one issue involved.)
What I'm seeing is that when heap_update checks to see if t
Gregory Stark <[EMAIL PROTECTED]> writes:
> On the other hand the problem does not occur if the CREATE TABLE is in the
> same session. Nor if the REINDEX DATABASE is skipped.
It appears that you have to do the RENAME TABLE in the same session as
the REINDEX DATABASE. Furthermore, the failure then
"Alvaro Herrera" <[EMAIL PROTECTED]> writes:
>> > I could not reproduce it here, but didn't try very hard.
>>
>> Did you try running the script he provided? It happened for me first try.
>
> Yep. No luck. I didn't try changing the args in generate_series though.
>
> How many CPUs are you runnin
Gregory Stark escribió:
> Either a) we're not actually issuing a CommandCounterIncrement() or b) the
> command is not being properly marked as non-read-only when the update happens
> or, uh, c) something else is broken with generating or executing those
> invalidation messages.
Well, the CommandC
"Alvaro Herrera" <[EMAIL PROTECTED]> writes:
> Gregory Stark escribió:
>>
>> <[EMAIL PROTECTED]> writes:
>>
>> > Here is a script that is able to reproduce the problem (on my machine
>> > anyway), you may need to play with the number of rows or workmem
>> > settings to be able to reproduce it:
>
Gregory Stark escribió:
>
> <[EMAIL PROTECTED]> writes:
>
> > Here is a script that is able to reproduce the problem (on my machine
> > anyway), you may need to play with the number of rows or workmem
> > settings to be able to reproduce it:
>
> Egads, i can confirm that this script reproduces t
<[EMAIL PROTECTED]> writes:
> Here is a script that is able to reproduce the problem (on my machine
> anyway), you may need to play with the number of rows or workmem
> settings to be able to reproduce it:
Egads, i can confirm that this script reproduces the problem on my machine as
well:
ALTER
Here is a script that is able to reproduce the problem (on my machine
anyway), you may need to play with the number of rows or workmem
settings to be able to reproduce it:
regards,
Ondrej Jirman
#!/bin/sh
dropdb bug
createdb bug
psql bug << EOF
CREATE TABLE xxx (id SERIAL, col1 TEXT, col2
<[EMAIL PROTECTED]> writes:
> ALTER TABLE name RENAME TO new_name;
> ALTER TABLE new_name
> RENAME COLUMN x TO y;
>
...
> I think the issue might be reproducible by creating table with a lot
> of rows, setting high work_mem and issuing the commands, but I did not
> try to reproduce it this way.
Oh, I've forgot to mention that the commands are issued from the
script. When issued by hand there is no problem at all (probably
because I'm a slow typist :-D).
Thank you and regards,
Ondrej Jirman
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subs
"Donald Fraser" <[EMAIL PROTECTED]> writes:
> When issuing the following type of command:
> ALTER TABLE table RENAME COLUMN x TO y
> The column name change is not cascading through to RULEs on a VIEW.
More specifically, INSERTs and UPDATEs contained in rules don't have
their target column names ad
TODO has:
o Have ALTER TABLE rename SERIAL sequences
However, I didn't realize the seriousness of the problem.
---
Mirek Hankus wrote:
>
> Postgresql 7.3.4 on Linux.
>
> Problem is that when you create a table wi
"Diego Cattelan" <[EMAIL PROTECTED]> writes:
> gesart=3D>alter table a add column c integer references xxx(id);
> =20
> NOTICE: ALTER TABLE will create implicit trigger(s) for FOREIGN KEY check(s)
> ALTER TABLE
> =20
> The table xxx doesn't exist.
> =20
> Is that correct or postgreSQL shoul
Vince Vielhaber <[EMAIL PROTECTED]> writes:
> If this:
> alter table foobar add column address varchar(50) default 'none';
> is the incorrect syntax, why does it not fail or at least give a
> warning?
Because it's incompletely implemented: the parser takes the full syntax
but the ALTER TABLE rout
On 8 May 2001, Nabil Sayegh wrote:
> On 05 May 2001 12:23:37 -0400, [EMAIL PROTECTED] wrote:
> > Vince Vielhaber ([EMAIL PROTECTED]) reports a bug with a severity of 3
> > The lower the number the more severe it is.
> >
> > Short Description
> > Alter table add column ignores default
> >
> > Long
On 8 May 2001, Nabil Sayegh wrote:
> On 08 May 2001 10:31:17 -0400, Vince Vielhaber wrote:
> > > http://hermes.swu.bg/postgres/postgres/sql-altertable.htm
> > > The correct syntax is:
> > > ALTER TABLE foobar add column address varchar(50);
> > > ALTER TABLE foobar alter column address set defaul
On 08 May 2001 10:31:17 -0400, Vince Vielhaber wrote:
> > http://hermes.swu.bg/postgres/postgres/sql-altertable.htm
> > The correct syntax is:
> > ALTER TABLE foobar add column address varchar(50);
> > ALTER TABLE foobar alter column address set default 'none';
>
> If this:
>
> alter table fooba
On 05 May 2001 12:23:37 -0400, [EMAIL PROTECTED] wrote:
> Vince Vielhaber ([EMAIL PROTECTED]) reports a bug with a severity of 3
> The lower the number the more severe it is.
>
> Short Description
> Alter table add column ignores default
>
> Long Description
> Alter table add column ignores the
> It appears that the triggers were never updated to now refer to 'old'
> instead of to current_usage when it was renamed, but were still
> associated with 'old' for purposes of dropping them. (i presume this
> is because the triggers were attached to 'old' by oid, which didnt
> change when it wa
> template1=> insert into n2 values(154.23);
> INSERT 360703 1
> template1=> alter table n1 rename to oldn1;
> RENAME
> template1=> alter table n2 rename to n1;
> RENAME
> template1=> insert into n1 values(154.23);
> ERROR: overflow on numeric ABS(value) >= 10^2 for field with precision 4 scale 2
Stephan Szabo <[EMAIL PROTECTED]> writes:
> I believe these are all the cases I saw of heap_openr with no lock
> and no check in the actual trigger functions (patch to
> hopefully elog(ERROR) instead of crashing attached).
> [ patch snipped ]
We had a discussion about that on 11-July and the cons
Stephan Szabo <[EMAIL PROTECTED]> writes:
>> Yes, this is a known bug. Two bugs actually, first being that the
>> trigger definitions don't track the rename (they should probably be
>> storing OID not relname, although that would complicate dump/restore).
> I do plan on trying to move all the ta
Gena Gurchonok <[EMAIL PROTECTED]> writes:
> When I renaming table using ALTER TABLE,
> it doesn't change table name in RI triggers. This results in backend
> crash due to invalid arguments for RI_Check trigger procedure.
Yes, this is a known bug. Two bugs actually, first being that the
trigger
I can confirm that this is a bug, and crashes in the current development
tree.
>
> POSTGRESQL BUG REPORT TEMPLATE
>
>
31 matches
Mail list logo
