On 28/05/10 04:00, Josh Berkus wrote:
Consider a table that is
regularly written but append-only. Every time autovacuum kicks in,
we'll go and remove any dead tuples and then mark the pages
PD_ALL_VISIBLE and set the visibility map bits, which will cause
subsequent vacuums to ignore the
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Bruce Momjian wrote:
This is not something we would typically backpatch because of the danger
of introducing some unexpected change in libpq. We can provide a patch
to anyone who needs it, or if the community wants it
Bruce Momjian wrote:
Yes, my defines were very messed up; updated version attached.
Hi,
I've not done a review of this patch, however I did backport it to 8.3
(as attached in unified diff). The patch wasn't made for PG purposes, so
it's not in context diff. I tested the backported patch and
Alvaro Herrera wrote:
While you're cleaning up SSL, how about the thread with this email on
it:
19212172.post%40talk.nabble.com
Yeah, I mentioned this to Magnus this morning (my time) and he said
Bruce was compiling a patch in time for the next commit fest.
I'm not sure where it's all
Hi,
As I'm interested in this topic, I thought I'd take a look at the
patch. I have no capability to test it on high end hardware but did
some basic testing on my workstation and basic review of the patch.
I somehow had the impression that instead of creating a new connection
for each restore
Andrew Dunstan wrote:
Do we know why we experience tuple concurrently updated errors if we
spawn thread too fast?
No. That's an open item.
Okay, I'll see if I can have a little more of a look into it. No
promises as the restore the restore isn't playing nicely.
the memory context is
that level of clearance to other community members is the
decision that has to be made.
So if somebody is interesting in contacting me about moving pgfoundry
forward, please do so.
Regards
Russell Smith
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Russell Smith
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Gregory Stark wrote:
It seems there's something wrong with CheckOtherDBBackends() but I haven't
exactly figured out what. There are no other sessions but drop database keeps
saying regression is being accessed by other users. I do see Autovacuum
touching tables in regression but
Andrew Dunstan wrote:
I'm not sure if you've read all the archive history on this. Here are
the pointers from the TODO list:
http://archives.postgresql.org/pgsql-hackers/2004-04/msg00818.php
http://archives.postgresql.org/pgsql-hackers/2006-10/msg01527.php
lists.
I think this is a good idea, and was expecting this to have happened
already. Is there any time line or consensus that this is going to happen?
Regards
Russell Smith
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
others with
much more experience than I.
Regards
Russell Smith
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Tom Lane wrote:
Russell Smith [EMAIL PROTECTED] writes:
As an attempt at a first PostgreSQL patch, I'd like to see if I can do
anything about this issue.
Trying that as a first patch is a recipe for failure... the short answer
is that no one can think of a solution
Hi,
As an attempt at a first PostgreSQL patch, I'd like to see if I can do
anything about this issue.
I've read both the attached threads;
http://archives.postgresql.org/pgsql-hackers/2004-04/msg00818.php
http://archives.postgresql.org/pgsql-hackers/2006-10/msg01527.php
There seems no
have a larger impact that
suspected. And at beta3/rc1 I feel it's too late in the cycle.
Regards
Russell Smith
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Alvaro Herrera wrote:
Alvaro Herrera wrote:
2. decide that the standard is braindead and just omit dumping the
grantor when it's no longer available, but don't remove
pg_auth_members.grantor
Which do people feel should be implemented? I can do whatever we
decide; if no one has a
Alvaro Herrera wrote:
Alvaro Herrera wrote:
Alvaro Herrera wrote:
2. decide that the standard is braindead and just omit dumping the
grantor when it's no longer available, but don't remove
pg_auth_members.grantor
Which do people feel should be implemented? I can do whatever we
Alvaro Herrera wrote:
Russell Smith wrote:
Alvaro Herrera wrote:
Alvaro Herrera wrote:
2. decide that the standard is braindead and just omit dumping the
grantor when it's no longer available, but don't remove
pg_auth_members.grantor
Which do people feel should
achieve this anyway.
Regards
Russell Smith
---(end of broadcast)---
TIP 6: explain analyze is your friend
Joshua D. Drake wrote:
Hello,
I ran into an interesting problem with a customer today. They are
running Jabber XCP (not the one we use). Unfortunately, the product
has a bug that causes it to leave connections persistent in a
transaction state. This is what it does:
BEGIN; SELECT 1;
sure there are use cases or this, but it seems unlikely that a high
update table is going to have an index added to it. Am I a long way
from reality when saying that?
Regards
Russell Smith
---(end of broadcast)---
TIP 1: if posting/reading
by default on tables, then we have a different
situation. And if the expectation is that HOT will be enabled by
default in future releases, then this needs to be considered now.
Regards
Russell Smith
---(end of broadcast)---
TIP 3: Have you checked
?
Again, as a person who has only a limited understand of the code, I'm
happy to be wrong about anything I have written.
Regards
Russell Smith
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating
in stone is because they are/can be an example of inlined SQL.
Particularly when views are built on views. Any further enlightenment
welcome, but probably off topic for this thread.
Russell Smith
---(end of broadcast)---
TIP 2: Don't 'kill -9
[EMAIL PROTECTED] wrote:
Hi there,
Is is possible to stop all user access to postgres, but still give
access to admin?
Just temporarily, not a security setup.
Something like, stop all users but allow user x and y.
You could restart in single user mode, or alter pg_hba.conf to allow the
of a big table was
done in multiple transactions you could reduce the effect of long
running vacuum. I'm not sure how this effects the rest of the system
thought.
Russell Smith
of what should
be done for a particular block.
Russell Smith.
on
this option.
Regards
Russell Smith
regards, tom lane
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
Andrew Dunstan wrote:
Russell Smith wrote:
Tom Lane wrote:
Stephen Frost [EMAIL PROTECTED] writes:
Force references to go through macros which implement the lookup
for the
appropriate type? ie: LOGICAL_COL(table_oid,2) vs.
PHYSICAL_COL(table_oid,1) Perhaps that's too simplistic
away from the mark. But if this
was the case it would mean that dumps would just need an alter table
statement to maintain autovacuum information. There is an advantage
that if you only dump some tables, their autovac settings would go with
them. But is that a good thing?
Reagrds
Russell Smith
, and perhaps subject to race conditions.
Thoughts?
Seems reasonable from my lowly user point of view. Would there be a
requirement to remove the extra segments at any point in the future or
would they hang around on the disk forever?
Russell Smith
regards, tom lane
Albe Laurenz wrote:
Thanks to everybody who answered.
Maybe it is really the best thing to use a tool like postgresql-relay or
pgpool - I will investigate these.
I'm not eager to reinvent the wheel.
We have considered relocating DNS entries, but the problem is that a
changed
DNS entry takes
removal dates will mean people are much more likely to
want to move.
Regards
Russell Smith
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so
at the pgcrypto code, so I can't
make further comment than that.
Regards
Russell Smith.
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
probably very unclear but that is the idea.
Regards
Russell Smith
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
offer
comments on them.
Sincerely,
Joshua D. Drake
Regards
Russell Smith
Also, as VACUUM improves, autovacuum will improve with it.
Or because of autovacuum, vacuum and autovacuum will improve.
---(end of broadcast)---
TIP 8
of the overflow from the disk back
int the FSM in memory and continue using free space.
Regards
Russell Smith
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
it
will usually get VACUUM'd more, we are just telling the users that if
they turn AV on, they don't have to manage all the VACUUMing.
Regards
Russell Smith
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
use of
information available
to the backend, and to also run functions in a way that it is not possible to
do via SQL.
Regards
Russell Smith.
---(end of broadcast)---
TIP 8: explain analyze is your friend
at this for at least 2 releases now. If it doesn't get in
now, it will just get in for 8.2 and no improvements till 8.2.
Regards
Russell Smith
---(end of broadcast)---
TIP 8: explain analyze is your friend
);
Regards
Russell Smith.
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
trying to give a bit of a perspective on the way I see things as some
who has been
around pg for about 12 months and attempted to hack the code a couple of times.
Regards
Russell Smith
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
On Wed, 18 May 2005 04:31 am, Josh Berkus wrote:
Andrew,
Last time it came up I thought the problem was that there was not a
consensus on *which* bugtracker to use.
Or whether to use one.Roughly 1/3 bugzilla, 1/3 something else, and 1/3
don't want a bugtracker. And, among the
. I'm sure if I
did, I would also miss a great number of things.
Regards
Russell Smith
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
them a little bit of support in doing it. eg, getting the cvs history
out of the PostgreSQL cvs
tree.
Regards
Russell Smith
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
think we need to get some
things going
well to get people on the site more. Once that happens, people will
instinctively look there.
Sincerely,
Russell Smith
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http
by default.
I agree with everybody else, having it enabled by default is a good idea.
Regards
Russell Smith
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
(as far as I know) second only to https://helixcommunity.org/.
Here's a list of them:
http://gforge.org/docman/view.php/1/52/gforge-sites.html
Where does all the CPU/disk time go? Do we have any idea what are the
strained parts of the system?
Is it the database?
Regards
Russell Smith
of being able to cleanup idle connection
quickly.
The VACUUM issue may not be a problem, as if BEGIN is not issued, then the
transaction
timeout would probably not be used. But the issues would remain for backups.
Just some thoughts
Regards
Russell Smith
---(end
to ship libpq as a
seperate
tarball that you can compile without postgresql server?
Regards
Russell Smith
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
everything will run inside one transaction,
effectively blocking some db functions until every table has been reindexed?
Regards
Russell Smith
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http
On Fri, 1 Apr 2005 05:40 pm, Michael Fuhr wrote:
I'd like to propose that we abandon the name PostgreSQL and rename the
project Postgre, to be pronounced either post-greh or post-gree.
This change would have a twofold purpose: it would meet popular demand,
and it would reflect my next
full I would
suggest.
Russell Smith
Chris
Neil Conway wrote:
Neil Conway wrote:
AndrewSN pointed out on IRC that ALTER TABLE ... ADD FOREIGN KEY and
CREATE TRIGGER both acquire AccessExclusiveLocks on the table they are
adding triggers to (the PK table, in the case of ALTER TABLE
.
Regards
Russell Smith.
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
as they need it, from a free space/recovery point
of view.
It also does checks to ensure that no database is nearing transaction
wraparound, if it
is, it initiates a database wide vacuum to resolve that issue.
Regards
Russell Smith
---(end of broadcast
. So not using a database
will still cause XID wraparound to occur on that database.
Regards
Russell Smith.
---(end of broadcast)---
TIP 8: explain analyze is your friend
---(end of broadcast
talking about earlier) will not
be reasonable to back-port.
Not to be rude, but if backporting is not an option, why do we not just
focus on the job of getting autovacuum into 8.1, and not have to think
about how a patch that will warn users will work?
Regards
Russell Smith
Hi All,
I am doing serious thinking about the implementation of Auto Vacuum as part of
the backend, Not using libpq, but classing internal functions directly.
It appears to me that calling internal functions directly is a better
implementation than using the external library to do the job.
I
priority, however I think we need to either be able to cast away from
unknown, or at least error when attempting to create a table with an unknown column
type.
I get the same error on 7.4.5 and 8.0b4
Regards
Russell Smith
---(end of broadcast
you cvs remove the new copy from
those branches as well. As always CVS is a bit messy with these things, but just
throwing ideas on the pile that might work.
Regards
Russell Smith
---(end of broadcast)---
TIP 3: if posting/reading through Usenet
On Fri, 1 Oct 2004 07:24 pm, Johann Robette wrote:
Hello,
I'm experiencing a strange problem. Here it is :
I've created a function with a FOR loop.
DECLARE
Current RECORD;
BEGIN
FOR current IN SELECT * FROM employees LOOP
Tmp := current.id;
END LOOP;
...
current != Current ?
61 matches
Mail list logo
