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
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 u
Darren Govoni 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:
http://www.postgresql.org/docs/8.3/static/sql-select.html#SQL-F
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 writes:
> > This seems like a bug to me. Is it fixed in the current dev build? Or is
> >
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 mak
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 signi
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 |
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 | tj
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
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
2009/1/12 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 comman
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
On Mon, Jan 12, 2009 at 9:12 AM, Ian Barwick wrote:
> 2009/1/12 Phoenix Kiula :
>> 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 word "TYPE". This won't affect
On Sunday 11 January 2009 5:21:46 pm Phoenix Kiula wrote:
> On Mon, Jan 12, 2009 at 9:12 AM, Ian Barwick wrote:
> > 2009/1/12 Phoenix Kiula :
> >> 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)
> >
> >
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
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:
\distvS
Adrian Klaver writes:
> On Sunday 11 January 2009 5:21:46 pm Phoenix Kiula wrote:
>> On Mon, Jan 12, 2009 at 9:12 AM, Ian Barwick wrote:
>>> 2009/1/12 Phoenix Kiula :
I am trying to resize a column on a large-ish database (with 5 million
rows).
>>>
>>> ALTER TABLE users ALTER COLUMN na
> 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
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 the
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 = '2009-01-
20 matches
Mail list logo
