Erwin Brandstetter writes:
> However, I have a database with dozens of schemas and hundreds of
> tables. There is a bunch of useless comments on columns I want to get
> rid of, scattered all across the db. The fastest & easiest way would
> be:
> DELETE FROM pg_description WHERE description = 'My
Craig James writes:
> On 4/22/11 1:58 PM, Tom Lane wrote:
>> Craig James writes:
>>> select objectid from archive where db_id is null limit 1 for update
>> The interaction between LIMIT and FOR UPDATE changed in 9.0 ... what
>> PG version are you using?
> 8.4.4
Well, note what it says in the 8
Hi all,
We thought we were having issues with our warm standby (postgres
8.4.6), but think we figured it out, however I'd like someone to confirm
what we think is true.
If a cluster has zero activity whatsoever, but we have archive_timeout
set (say to 60 seconds), will it create a WAL fil
On 4/22/11 1:58 PM, Tom Lane wrote:
Craig James writes:
select objectid from archive where db_id is null limit 1 for update
The interaction between LIMIT and FOR UPDATE changed in 9.0 ... what
PG version are you using?
8.4.4
thanks,
Craig
regards, tom lane
--
Craig James writes:
>select objectid from archive where db_id is null limit 1 for update
The interaction between LIMIT and FOR UPDATE changed in 9.0 ... what
PG version are you using?
regards, tom lane
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org
Craig James wrote:
> The sequence of operations goes like this (pseudo-code):
> The problem is that very occasionally the same ID will be issued
> twice. I don't see how this can be. Doesn't the "for update"
> guarantee that no other process can claim that same row?
I don't see a flaw in t
I thought I understood "select ... for update," but maybe not.
We have a number of separate databases and a unique integer identifier that's supposed to
be global across all databases. A single "archive" database is used to issue
the next available ID when a process wants to create a new objec
On 04/22/2011 04:26 PM, Cédric Villemain wrote:
ah yes.
There exist a very brutal way to do it, which will remove all stats.
(you need the server to be down to do that)
move or rm the "global/pgstat.stat" file.
To come back to your original problem : I am surprised you have too
large value for m
On 04/21/2011 12:19 PM, Marc Fromm wrote:
Is there a way to query a unix timestamp date? In the database the
orderdate field is a unix timestamp.
I would like to create the where clause to a query on a specific date
like December 17, 2010.
Select * from orders where orderdate = '12/17/2010
Hi!
It is generally not advisable to write to system catalogs directly ...
However, I have a database with dozens of schemas and hundreds of
tables. There is a bunch of useless comments on columns I want to get
rid of, scattered all across the db. The fastest & easiest way would
be:
DELETE FROM
2011/4/22 Mario Splivalo :
> On 04/22/2011 03:20 PM, Cédric Villemain wrote:
>>
>> 2011/4/21 raghu ram:
Heh, I've neglected to mention that i'm using postgres 8.4.5 on Debian
Stable. Is there a way to reset statistics on pg8.4? I've tested it on
9.0
and it works there.
On 04/22/2011 03:20 PM, Cédric Villemain wrote:
2011/4/21 raghu ram:
Heh, I've neglected to mention that i'm using postgres 8.4.5 on Debian
Stable. Is there a way to reset statistics on pg8.4? I've tested it on 9.0
and it works there.
AFAIK, I dont think we can achieve this in PG 8.4 at clus
2011/4/21 raghu ram :
>>
>> Heh, I've neglected to mention that i'm using postgres 8.4.5 on Debian
>> Stable. Is there a way to reset statistics on pg8.4? I've tested it on 9.0
>> and it works there.
>>
>
> AFAIK, I dont think we can achieve this in PG 8.4 at cluster level. Can
> anybody has the in
13 matches
Mail list logo
