Re: [GENERAL] Question about updates and MVCC

2009-01-11 Thread Martijn van Oosterhout
On Sat, Jan 10, 2009 at 08:00:29AM -0800, mailingli...@net-virtual.com wrote: Hello, I have a couple of questions regarding how MVCC (in postges 8.3.3 if it makes a difference) affects vacuum. #1. If I am doing an update to a row and none of the values have changed, will that cause a hole

[GENERAL] SELECT FOR UPDATE....LIMIT ...broken

2009-01-11 Thread Darren Govoni
Hi, I have a simple scenario that is producing incorrect results with 8.3,ubuntu. I have queries attempting the same select-for update limit 1. at the same time. There are 2 rows in my test database. The first will enter the transaction and only update ONE of the rows it selected, because it

Re: [GENERAL] SELECT FOR UPDATE....LIMIT ...broken

2009-01-11 Thread Tom Lane
Darren Govoni dar...@ontrenet.com writes: This seems like a bug to me. Is it fixed in the current dev build? Or is there something else I'm missing? I think you have not read the documentation about FOR UPDATE and LIMIT on the SELECT reference page:

Re: [GENERAL] SELECT FOR UPDATE....LIMIT ...broken

2009-01-11 Thread Darren Govoni
Well, I did, but I clicked the link to Chapter 13 before scrolling down further to see the Caution section. Heheh. Thanks for the heads up. On Sun, 2009-01-11 at 12:12 -0500, Tom Lane wrote: Darren Govoni dar...@ontrenet.com writes: This seems like a bug to me. Is it fixed in the current dev

Re: [GENERAL] compile of 8.1.15

2009-01-11 Thread Joshua D. Drake
On Sat, 2009-01-10 at 17:37 -0700, Chuck Davis wrote: I have been trying to install 8.1.14 and 15 and it seems like there is an infinite loop in the make file. I do not have the skills to find it. Has anyone else had success compiling for Linux with gmake? Which linux? WHich gcc? Which make?

[GENERAL] PostgreSQL Conference / PgCon.US update

2009-01-11 Thread Joshua D. Drake
Hello, In an attempt to ensure the continued positive growth of the community, PostgreSQL Conference, U.S. is going to change its current policy toward the domain PgCon.US. The current policy is that the domain would only be used in lieu of http://www.postgresqlconference.org when space was

[GENERAL] Unexpected behavior from psql

2009-01-11 Thread Tim Hart
This is a minor issue. Not really a problem for me at the moment, but I wanted to understand if it was intended: tjhart=# \d No relations found. tjhart=# \dn List of schemas Name| Owner +-- information_schema | postgres pg_catalog

Re: [GENERAL] Unexpected behavior from psql

2009-01-11 Thread Jeff Davis
On Sun, 2009-01-11 at 15:33 -0600, Tim Hart wrote: tjhart=# set search_path to foo, public; SET tjhart=# \d List of relations Schema | Name| Type | Owner +---+---+ foo| bar_table | table | tjhart foo| foo_table | table | tjhart

Re: [GENERAL] Unexpected behavior from psql

2009-01-11 Thread Tim Hart
On Jan 11, 2009, at 4:41 PM, Jeff Davis wrote: On Sun, 2009-01-11 at 15:33 -0600, Tim Hart wrote: tjhart=# set search_path to foo, public; SET tjhart=# \d List of relations Schema | Name| Type | Owner +---+---+ foo| bar_table | table | tjhart

[GENERAL] Smartest way to resize a column?

2009-01-11 Thread Phoenix Kiula
I am trying to resize a column on a large-ish database (with 5 million rows). The column was 20 characters before, now I want to make it 35 characters. Challenge is: this is the main indexed column in a busy database. I tried looking at the ALTER TABLE commands available and there seems nothing

Re: [GENERAL] Smartest way to resize a column?

2009-01-11 Thread Ian Barwick
2009/1/12 Phoenix Kiula phoenix.ki...@gmail.com: I am trying to resize a column on a large-ish database (with 5 million rows). The column was 20 characters before, now I want to make it 35 characters. Challenge is: this is the main indexed column in a busy database. I tried looking at the

Re: [GENERAL] Smartest way to resize a column?

2009-01-11 Thread Adrian Klaver
On Sunday 11 January 2009 5:07:31 pm Phoenix Kiula wrote: I am trying to resize a column on a large-ish database (with 5 million rows). The column was 20 characters before, now I want to make it 35 characters. Challenge is: this is the main indexed column in a busy database. I tried

Re: [GENERAL] Smartest way to resize a column?

2009-01-11 Thread Phoenix Kiula
On Mon, Jan 12, 2009 at 9:12 AM, Ian Barwick barw...@gmail.com wrote: 2009/1/12 Phoenix Kiula phoenix.ki...@gmail.com: I am trying to resize a column on a large-ish database (with 5 million rows). ALTER TABLE users ALTER COLUMN name TYPE VARCHAR(35) HTH Thanks! I guess I was missing the

Re: [GENERAL] Smartest way to resize a column?

2009-01-11 Thread Adrian Klaver
On Sunday 11 January 2009 5:21:46 pm Phoenix Kiula wrote: On Mon, Jan 12, 2009 at 9:12 AM, Ian Barwick barw...@gmail.com wrote: 2009/1/12 Phoenix Kiula phoenix.ki...@gmail.com: I am trying to resize a column on a large-ish database (with 5 million rows). ALTER TABLE users ALTER COLUMN

Re: [GENERAL] Unexpected behavior from psql

2009-01-11 Thread Jeff Davis
On Sun, 2009-01-11 at 17:13 -0600, Tim Hart wrote: Would it be worthwhile to specify this in the documentation? One of the sources of my confusion was the following statement: http://www.postgresql.org/docs/8.3/interactive/app-psql.html: \distvS ... to obtain a listing of all the

Re: [GENERAL] Unexpected behavior from psql

2009-01-11 Thread Tim Hart
On Jan 11, 2009, at 8:16 PM, Jeff Davis wrote: On Sun, 2009-01-11 at 17:13 -0600, Tim Hart wrote: Would it be worthwhile to specify this in the documentation? One of the sources of my confusion was the following statement: http://www.postgresql.org/docs/8.3/interactive/app-psql.html:

Re: [GENERAL] Smartest way to resize a column?

2009-01-11 Thread Tom Lane
Adrian Klaver akla...@comcast.net writes: On Sunday 11 January 2009 5:21:46 pm Phoenix Kiula wrote: On Mon, Jan 12, 2009 at 9:12 AM, Ian Barwick barw...@gmail.com wrote: 2009/1/12 Phoenix Kiula phoenix.ki...@gmail.com: I am trying to resize a column on a large-ish database (with 5 million

Re: [GENERAL] Smartest way to resize a column?

2009-01-11 Thread Phoenix Kiula
ALTER COLUMN TYPE is intended for cases where actual transformation of the data is involved. Obviously varchar(20) to varchar(35) doesn't really require any per-row effort, but there's no operation in the system that handles that case. But if you're brave, you can do it via manipulation of

[GENERAL] Data comparison SQL in PG 8.2.9

2009-01-11 Thread Phoenix Kiula
Hi. I have a large table that has a modify_date field in it, which is timestamp without time zone. I used to be able to do queries like these in 8.2.3 -- select id from users where modify_date = '2009-01-08' limit 1; select id from users where modify_date '2009-01-08' limit 1; Suddenly

Re: [GENERAL] Data comparison SQL in PG 8.2.9

2009-01-11 Thread Thomas Markus
be sure to use correct data types. I suppose psql uses timestamps so select id from users where modify_date = '2009-01-08' limit 1; is converted to select id from users where modify_date = '2009-01-08 00:00:00'::timestamp limit 1; try select id from users where modify_date::date =