artifact_id;status_id;status_name;priority;submitter_id;submitter_name;assigned_to_id;assigned_to_name;open_date;close_date;last_modified_date;summary;details;"Category";"Group"
1010960;1;"Open";3;167267;"Uwe Bartels";100;"Nobody";"2010-12-13 08:40";"";"2012-09-24 02:14";"ALTER TABLE ... ALTER COLUMN TYPE";"Hi,

i tried to improve pg_reorg by locking column definitions in pg_attribute.

select * from pg_attribute where attrelid = <oid of reorganized table> and attnum>0 for update;

so far it works well. 
in session 1 i run pg_reorg on a table.
in session 2 i run a function which locks column definitions as shown above + simply sleeping for hours.
in session 3 i tried to run an alter table pgbench_accounts alter column filler type char(85);

the statement in session 3 waited as long as i did not stop the function started in session 2. So this would definetly prevent the alter table statement run during pg_reorg. 
The less WARNINGS you have - the better right?
If you need that ACCESS EXCLUSIVE lock on the table you could check if there is any sql waiting for a lock on this table and then request to the user to cancel that statement.

Then on the other hand - when i stopped the function in session 2 while pg_reorg was still running - I got an error message: 
pgbench=> alter table pgbench_accounts alter column filler type char(85);
ERROR:  cannot alter table ""pgbench_accounts"" because column ""log_16392"".""row"" uses its rowtype

So this brings up the question if I ever can change a column type during usage of the column type ""log_16392"".""row"".

It migth be that i've overseen something.
but the people will make easier use of it the less possibilities exist to destroy you data.

anyway this tool loks great and very professional. thanks.
Uwe";"Interface Improvements (example)";"Next Release (example)"
1010975;1;"Open";3;207393;"Denish Patel";105070;"Takahiro Itagaki";"2011-01-11 20:29";"";"2012-09-24 02:14";"Remove DW type database and virtualxid waiting issue";"We are trying to run pg_reorg on Data Warehouse database and there is always long running  (1-5 hours) queries on the database. When I try to rebuild table online ,the following statement gets some virtualxid to be there before it takes lock on the specified table. 

SELECT 1 FROM pg_locks WHERE locktype = 'virtualxid' AND pid <> pg_backend_pid() AND virtualtransaction = ANY($1) LIMIT 1 

The running queries are not on rebuild table but they are running on other tables. Can we change code to specify pg_reorg to ignore virtualxid if they aren't on the same table?

Looking forward for your advice or patch.

Thanks,
Denish";"None";"None"
1011010;1;"Open";3;207393;"Denish Patel";105070;"Takahiro Itagaki";"2011-04-01 18:40";"";"2012-09-24 02:14";"Option to rebuild online indexes on the target table";"I gave a talk on ""P90X your database!"" (http://denishjpatel.blogspot.com/2011/03/p90x-your-database-presentation-slides.html)  recently at pgeast2011. People are very excited about the pg_reorg tool. Many people were asking for a way to rebuild index online using pg_reorg? This tool is doing great work and I would like to add this useful feature to it. Would you give some spare to add this feature ? Let me know if you need help on testing.

My ""C"" skills are limited but if you guide me i can try to implement this feature that will give me opportunity to understand code base as well.


Looking forward for your response.
Denish";"None";"None"
1011222;1;"Open";3;207393;"Denish Patel";105070;"Takahiro Itagaki";"2012-09-10 14:12";"";"2012-09-24 02:14";"Reorg table with GIST index";"Guys,

There is a limitation to not to support table reorg using pg_reorg with GIST index on the table. What are the problems you are seeing to add support for the Gist indexes ?

Looking forward to get the discussion going!

Thanks,
Denish";"None";"None"