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 ignor
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
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 an
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 a
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 memor
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 it
I'm not convinced it's the
best use of their time either. But others in the community may be at
their best supporting something like pgFoundry. But whether it's safe
to hand out that level of clearance to other community members is the
decision that has to be made.
So if som
hat
going to be the biggest win on big hardware as I don't have any. Just
something to think about.
Thanks
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 CheckOthe
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
> http://archives.postgresql.org
ackers, patches, and www because this does affect all
> those 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 (pgsq
pect that is not of significant value as there are many 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 t
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 conse
stuff as we don't know the exact side effects a
change like that could have. It could 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:
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
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:
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 stro
by any role, as
if you drop and recreate the object you can 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;
Basica
feature. We do
not want to go breaking existing code.
However HOT is enabled 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
---
o be a usable reality.
I'm 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)
g, that the reason we have views set
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)--
e of
a re plan when something has changed from underneath the original query?
My very brief thought gives me the impression that they are the same
thing, however they may not be.
Comments?
Again, as a person who has only a limited understand of the code, I'm
happy to be wrong
[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
users
ffective anyway will it? If vacuum 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
Again I'd be careful saying that FSM = DSM for handling of what should
be done for a particular block.
Russell Smith.
ttings to be set. I may be totally 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 g
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
ble to code this at all, but I'm interested in feedback on
this option.
Regards
Russell Smith
regards, tom lane
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
nvent some new
signaling mechanism to force closure of open files, but that seems
ugly, complex, 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 t
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 lon
ecessarily about the total shutdown,
but feature 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
n't have a "starting point" for modification.
That's 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
t
every time you call them. I've not looked 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
q means you are locked
into only using commands that are available to all users via SQL. If you don't
use
libpq, you open up the ability to use functions that can make 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
> without moving data around). But if AV is on and the settings are
> reasonable, then a table shouldn't bloat much or at all. Also, I don't
> think we are telling people to VACUUM less, in fact tables that need it
> will usually get VACUUM'd more, we are just tellin
. You could just load part 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
have an integrated vacuum none of that can really happen.
>
> Heaven knows it would make my life easier if it was integrated but anyway...
>
I understand these are not nessecarily Josh's view, but I thought I would offer
comments on them.
> Sincerely,
>
ple shooting themselves in the foot.
I'm not sure what strict rules are imposed by Feature freeze, but there may be
time for others to make some improvements before 8.1.
We have also looked 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
possible.
DO INSTEAD SELECT * FROM function(rowtype);
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
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
t get into something
that is
being duplicated by somebody else?
I'm just 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
-
x27;t.
A hardening script would be helpful, but some clear information on what is
also available to the average user would be good too. I know I should
probably step up to do this and don't have time at the moment. 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
it may be work asking them the question about getting
their contrib module onto pgfoundry if that is the best place for it. And then
giving 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
if the only one ever.
> Personally, I think it should be installed 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
despite the apparent large number of complaints. I think pgFoundry is a
very good
idea, and will work well in the long run. I just 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 S
me go? Do we have any idea what are the
strained parts of the system?
Is it the database?
Regards
Russell Smith.
> Yours,
>
> Tom Copeland
>
>
>
> ---(end of broadcast)---
> TIP 1: subscribe and unsubscribe commands go to [E
UM and backup could take, and set the timeout longer.
Which
in some senses defeats the purpose 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
no visibility
information.
The possibly of the bit method or full tuples is probably a decision for
others, but having
the flexibility to choose in this would be a great thing.
Regards
Russell Smith
---(end of broadcast)---
TIP 3: if posting/read
tell us what it is.
>
Does this pose a problem where 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 search
upport
Install postgresql with pl/php
Rebuild php with postgresql support (Unless you only want it available in the
db)
I may be a bad man for suggesting it... But is it possible 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
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 ne
of issue as vacuum 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 tab
resuming development after about half a
> > year of doing other stuff.
> >
> > Shachar
> >
>
I have complained about this in the past, and would also suggest that it be
treated as a
string value.
CREATE table b AS SELECT 'unknown', col2 from a;
Will even create a table with a column type as unknown, which doesn't have any
operators
to convert to anything, including text.
Regards
Russell Smith.
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
ix (eg the forcible stop we were 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 w
o the pg cluster, or installation. 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
>
>
-
every N number of transactions
> (e.g., 500 million)?
>
autovacuum already checks for both Transaction wraparound, and table updates.
It vacuums individual tables as they need it, from a free space/recovery point
of view.
It also does checks to ensure that no datab
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 kn
lso made some comments about unknown being as issue that has a low
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
as well as keeping the old version.
The second problem still exists where it's in 2 locations in previous releases. unless
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.
Regard
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 != Curre
62 matches
Mail list logo
