On 08/03/11 10:03 PM, Earth Analizer wrote:
Hi,
I am new to Postgres and I would like to know how I can get the last
error message.
I am using a programming language called "Paradox" and, when an error
occurs,
it converts the Postgres error code to its own error code.
Sometimes Paradox displa
Hi,
I am new to Postgres and I would like to know how I can get the last error
message.
I am using a programming language called "Paradox" and, when an error
occurs,
it converts the Postgres error code to its own error code.
Sometimes Paradox displays a funny message, if it does not recognize the
Dear all,
Today I do some changes in postgresql.conf &shmmax parameters as :
root~# cat /proc/sys/kernel/shmall
8388608
root~# cat /proc/sys/kernel/shmmax
4294967296
max_connections= 80
shared_buffers= 2048MB
work_mem = 32MB
maintenance_work_mem = 512MB
fsync=off
full_page_writes=off
sy
On Wednesday, August 03, 2011 04:24:32 PM Joshua D. Drake wrote:
> On 08/03/2011 12:41 PM, Geoffrey Myers wrote:
> > Am I correct in assuming that the 'running out of oids' issue was
> > resolved with a design change within Postgresql?
>
> Yes, many, many, many years ago. The only way to encounter
On 08/03/2011 12:41 PM, Geoffrey Myers wrote:
Am I correct in assuming that the 'running out of oids' issue was
resolved with a design change within Postgresql?
Yes, many, many, many years ago. The only way to encounter the problem
now is through user error, e.g; don't use WITH OIDS when creat
Merlin Moncure wrote:
On Wed, Aug 3, 2011 at 2:41 PM, Geoffrey Myers
wrote:
Am I correct in assuming that the 'running out of oids' issue was resolved
with a design change within Postgresql?
not exactly -- for quite some time now the use of oids in user tables
has been discouraged. The right
Hi,
I am planning to use the contrib module hstore
but I would like to install it on a separate schema, not public,
and include the schema in the search_path.
Do you know if there are any issues with this scenario.
In the hstore.sql script I see it forces it into public:
-- Adjust this settin
On Wed, Aug 3, 2011 at 2:41 PM, Geoffrey Myers
wrote:
> Am I correct in assuming that the 'running out of oids' issue was resolved
> with a design change within Postgresql?
not exactly -- for quite some time now the use of oids in user tables
has been discouraged. The right way to deal with this
Am I correct in assuming that the 'running out of oids' issue was
resolved with a design change within Postgresql?
--
Until later, Geoffrey
"I predict future happiness for America if they can prevent
the government from wasting the labors of the people under
the pretense of taking care of them.
Hi, List,
We're trying to calculate the amount of time that a Hot Standby slave is
lagging behind its master, and our results look wrong (average of 7 seconds,
with some over 1 minute), so we were thinking that we're probably
calculating it wrong.
We're currently just using the timestamps from ls
At 19:32 03/08/2011, you wrote:
On 08/03/11 10:21 AM, Eduardo Morras wrote:
One question, while you run your tests, does "IDLE IN TRANSACTION"
messages happen? If you run your tests with a permanent connection
to database, the tables are locked and autovacuum cannot work.
its not that tables
On 08/03/11 10:21 AM, Eduardo Morras wrote:
One question, while you run your tests, does "IDLE IN TRANSACTION"
messages happen? If you run your tests with a permanent connection to
database, the tables are locked and autovacuum cannot work.
its not that tables are locked, its that vacuum (aut
At 16:35 03/08/2011, Michael Graham wrote:
Yeah it said it last ran yesterday (and is currently running now), but I
did I notice in the log:
2011-08-02 19:43:35 BST ERROR: canceling autovacuum task
2011-08-02 19:43:35 BST CONTEXT: automatic vacuum of table
"traffic.public.logdata5queue"
Which
Michael Graham writes:
> On Wed, 2011-08-03 at 10:17 -0400, Tom Lane wrote:
>
>> Michael Graham writes:
>> > Would my applications
>> > constant polling of the queue mean that the lock could not be easily
>> > obtained?
>>
>> Very possible, depending on what duty cycle is involved there.
>
> Hm
Michael Graham writes:
> Ah! This looks like it is very much the issue. Since I've got around
> 150GB of data that should be truncatable and a select every ~2s.
> Just to confirm would postgres write:
> 2011-08-03 16:09:55 BST ERROR: canceling autovacuum task
> 2011-08-03 16:09:55 BST CONTEXT
On Wed, 2011-08-03 at 11:40 -0400, Tom Lane wrote:
> The other problem is that once autovacuum has gotten the lock, it has
> to keep it for long enough to re-scan the truncatable pages (to make
> sure they're still empty). And it is set up so that any access to the
> table will kick autovacuum off
Pavan Deolasee writes:
> On Wed, Aug 3, 2011 at 10:57 AM, Michael Graham wrote:
>> On Wed, 2011-08-03 at 10:17 -0400, Tom Lane wrote:
> Michael Graham writes:
Would my applications
constant polling of the queue mean that the lock could not be easily
obtained?
>>> Very possible, d
In response to Michael Graham :
> On Wed, 2011-08-03 at 10:17 -0400, Tom Lane wrote:
> > Michael Graham writes:
> > > Would my applications
> > > constant polling of the queue mean that the lock could not be easily
> > > obtained?
> >
> > Very possible, depending on what duty cycle is involved t
On Wed, Aug 3, 2011 at 8:57 AM, Michael Graham wrote:
> On Wed, 2011-08-03 at 10:17 -0400, Tom Lane wrote:
>> Michael Graham writes:
>> > Would my applications
>> > constant polling of the queue mean that the lock could not be easily
>> > obtained?
>>
>> Very possible, depending on what duty cycl
On Wed, Aug 3, 2011 at 10:57 AM, Michael Graham wrote:
> On Wed, 2011-08-03 at 10:17 -0400, Tom Lane wrote:
>> Michael Graham writes:
>> > Would my applications
>> > constant polling of the queue mean that the lock could not be easily
>> > obtained?
>>
>> Very possible, depending on what duty cyc
On Wed, 2011-08-03 at 10:17 -0400, Tom Lane wrote:
> Michael Graham writes:
> > Would my applications
> > constant polling of the queue mean that the lock could not be easily
> > obtained?
>
> Very possible, depending on what duty cycle is involved there.
Hmm. The clients aren't that aggressive
On Wed, 2011-08-03 at 09:03 -0500, Andy Colson wrote:
> Depending on how long you ran your test, and the conf settings, and
> the size of your database, autovacuum may never have even tried.
I know that the vacuum is definitely running (in fact isn't it the
vacuum that set the reltuples to 0?), th
On 3 August 2011 18:17, Tom Lane wrote:
>> Would my applications
>> constant polling of the queue mean that the lock could not be easily
>> obtained?
>
> Very possible, depending on what duty cycle is involved there.
Is there any ways of guaranteed concurrent obtaining it?
>
>
Michael Graham writes:
> From reading the documentation I see that postgres would return this
> space to that system after a normal vacuum if "one or more pages at the
> end of a table become entirely free and an exclusive table lock can be
> easily obtained".
> What does "easily obtained" mean i
On Wed, Aug 3, 2011 at 8:03 AM, Andy Colson wrote:
> If you have lots and lots of tables, autovacuum only checks one at a time,
> then wait's a bit. Did you run your test for several days?
Not true. autovac naps by default 1 minute between each db. i.e. if
you have 5 dbs it takes 5 minutes by d
On 8/3/2011 4:47 AM, Michael Graham wrote:
Hi all,
I have an application that is reading from a queue table, as part of my
testing I stressed the table to check performance, but after the test
was completed I have the a very large empty table:
SELECT relname, pg_size_pretty(pg_relation_size(oid
Hi all,
I have PostgreSQL 9.0.3 installed on my Gentoo Linux box. The
configuration is default. There is no any activity in the database but
the described below.
What I am trying to achieve is the effect described in this article
http://blog.endpoint.com/2010/09/reducing-bloat-without-locking.htm
Hi all,
I have an application that is reading from a queue table, as part of my
testing I stressed the table to check performance, but after the test
was completed I have the a very large empty table:
SELECT relname, pg_size_pretty(pg_relation_size(oid)) AS size,
reltuples::bigint FROM pg_class;
bubba postgres wrote:
> No takers?
> Some background I've changed my TOAST type from EXTENDED to MAIN.
> After some changes on my DB I notice that where I used to have a large
pg_toast_X table, I
> now have a large pg_largeobject table.
> Can't find an explanation of the difference between the
29 matches
Mail list logo
