On 02/08/11, Rory Campbell-Lange (r...@campbell-lange.net) wrote:
I am trying to select arrays in a set-returning function, but receiving
the error: array value must start with { or dimension information.
This issue appears to relate to locationnodes.rs_people_c sometimes
having an empty
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
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;
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
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,
On Wed, Aug 3, 2011 at 8:03 AM, Andy Colson a...@squeakycode.net 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
Michael Graham mgra...@bloxx.com 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
On 3 August 2011 18:17, Tom Lane t...@sss.pgh.pa.us 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?
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?), the
On Wed, 2011-08-03 at 10:17 -0400, Tom Lane wrote:
Michael Graham mgra...@bloxx.com 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
On Wed, Aug 3, 2011 at 10:57 AM, Michael Graham mgra...@bloxx.com wrote:
On Wed, 2011-08-03 at 10:17 -0400, Tom Lane wrote:
Michael Graham mgra...@bloxx.com writes:
Would my applications
constant polling of the queue mean that the lock could not be easily
obtained?
Very possible,
On Wed, Aug 3, 2011 at 8:57 AM, Michael Graham mgra...@bloxx.com wrote:
On Wed, 2011-08-03 at 10:17 -0400, Tom Lane wrote:
Michael Graham mgra...@bloxx.com writes:
Would my applications
constant polling of the queue mean that the lock could not be easily
obtained?
Very possible,
In response to Michael Graham mgra...@bloxx.com:
On Wed, 2011-08-03 at 10:17 -0400, Tom Lane wrote:
Michael Graham mgra...@bloxx.com writes:
Would my applications
constant polling of the queue mean that the lock could not be easily
obtained?
Very possible, depending on what duty
Pavan Deolasee pavan.deola...@gmail.com writes:
On Wed, Aug 3, 2011 at 10:57 AM, Michael Graham mgra...@bloxx.com wrote:
On Wed, 2011-08-03 at 10:17 -0400, Tom Lane wrote:
Michael Graham mgra...@bloxx.com writes:
Would my applications
constant polling of the queue mean that the lock could not
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
Michael Graham mgra...@bloxx.com 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
Michael Graham mgra...@bloxx.com writes:
On Wed, 2011-08-03 at 10:17 -0400, Tom Lane wrote:
Michael Graham mgra...@bloxx.com 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
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
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 (auto
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
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
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.
On Wed, Aug 3, 2011 at 2:41 PM, Geoffrey Myers
li...@serioustechnology.com 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
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
Merlin Moncure wrote:
On Wed, Aug 3, 2011 at 2:41 PM, Geoffrey Myers
li...@serioustechnology.com 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
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
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 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
28 matches
Mail list logo
