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
Sorry about the delay on this. Just managed to find some time to look
into it again.
I've made a couple of patches, for 8.3.3 and 8.2.9, which enable cross
compilation for windows (mingw32) from a unix platform.
The changes are in these areas:
1. configure.in detecting the target system ver
<[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
Hello,
I don't know if this is expected behaviour or not, but I've found that
this sequence of commands does not work all the time:
ALTER TABLE name RENAME TO new_name;
ALTER TABLE new_name
RENAME COLUMN x TO y;
It usually works with small work_mem and maintenance_work_mem values.
If I increas
