On 17 Feb 2005, Greg Stark wrote:
> Gaetano Mendola <[EMAIL PROTECTED]> writes:
>
> > We do ~4000 txn/minute so in 6 month you are screewd up...
>
> Sure, but if you ran without vacuuming for 6 months, wouldn't you notice the
> huge slowdowns from all those dead tuples before that?
Most people
On Wed, Feb 16, 2005 at 11:42:11AM -0600, Kenneth Marshall wrote:
> I have seen this algorithm described as a more generalized clock type
> algorithm. As the size of the counter increases, up to the number of
> buffers, the clock algorithm becomes LRU. One bit is the lightest
> weight approximation
Gaetano Mendola <[EMAIL PROTECTED]> writes:
> We do ~4000 txn/minute so in 6 month you are screewd up...
Sure, but if you ran without vacuuming for 6 months, wouldn't you notice the
huge slowdowns from all those dead tuples before that?
--
greg
---(end of broadcast)---
Found on a certain other DBMS' mailing list:
* InnoDB: When MySQL/InnoDB is compiled on Mac OS X 10.2 or earlier,
detect the operating system version at run time and use the
`fcntl()' file flush method on Mac OS X versions 10.3 and later.
Apple had disabled `fsync()' in Mac OS X
Gaetano Mendola <[EMAIL PROTECTED]> writes:
> BTW, why not do an automatic vacuum instead of shutdown ? At least the
> DB do not stop working untill someone study what the problem is and
> how solve it.
No, the entire point of this discussion is to whup the DBA upside the
head with a big enough cl
Tom Lane wrote:
> Bruno Wolff III <[EMAIL PROTECTED]> writes:
>
>>I don't think there is much point in making it configurable. If they knew
>>to do that they would most likely know to vacuum as well.
>
>
> Agreed.
>
>
>>However, 100K out of 1G seems too small. Just to get wrap around there
>>m
Stephan Szabo wrote:
> On Wed, 16 Feb 2005 [EMAIL PROTECTED] wrote:
>
>
>>>Once autovacuum gets to the point where it's used by default, this
>>>particular failure mode should be a thing of the past, but in the
>>>meantime I'm not going to panic about it.
>>
>>I don't know how to say this without
Greg Stark wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>
>
>>Christopher Kings-Lynne wrote:
>>
>>
>>>I wonder if I should point out that we just had 3 people suffering XID
>>>wraparound failure in 2 days in the IRC channel...
>>
>>I have had half a dozen new customers in the last six m
Richard Huxton writes:
> I seem to remember some subtle problems with dropped columns and plpgsql
> functions - could be one of those still left.
For instance:
regression=# create table usno (ra real, dec real, bmag real, rmag real,ipix
int8);
CREATE TABLE
regression=# [ create Sergey's functi
> Does starting a new backend session make the problem go away?
No
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Tom Lane wrote:
[EMAIL PROTECTED] writes:
Maybe I'm missing something, but shouldn't the prospect of data loss (even
in the presense of admin ignorance) be something that should be
unacceptable? Certainly within the realm "normal PostgreSQL" operation.
Once autovacuum gets to the point wher
"Sergey E. Koposov" <[EMAIL PROTECTED]> writes:
> But concerning to the added columns, I can say that before the column errbox
> didn't, and I revealed the problems began after adding it (together with
> index creation on that column).
Does starting a new backend session make the problem go away?
On Wed, 16 Feb 2005, Tom Lane wrote:
Oleg Bartunov writes:
I know this. I need to create inheritance for already created tables.
There is no way to do this using alter table, so I tried to
define it by hand :)
Did you remember to set relhassubclass for the parent table?
AFAIR, all that you really
Oleg Bartunov writes:
> I know this. I need to create inheritance for already created tables.
> There is no way to do this using alter table, so I tried to
> define it by hand :)
Did you remember to set relhassubclass for the parent table?
AFAIR, all that you really need are that and the pg_inhe
I think the people who've managed to shoot themselves in the foot this
way are those who decided to "optimize" their cron jobs to only vacuum
their user tables, and forgot about the system catalogs. So it's
probably more of a case of "a little knowledge is a dangerous thing"
than never having hea
Sergey E. Koposov wrote:
For the real functions which I use, instead of
query = ''SELECT * FROM usno'';
I have
query = my_C_function(some_args);
Oh? I'd make a small side bet that the underlying error is in your C
function --- possibly it's tromping on some data structure and the
damage does
On Wed, 16 Feb 2005, Richard Huxton wrote:
> This is just a shot in the dark, but I don't suppose you've dropped or
> modified any columns in "usno" have you?
>
> I seem to remember some subtle problems with dropped columns and plpgsql
> functions - could be one of those still left. It'd look li
On Wed, 16 Feb 2005, elein wrote:
You specify the inheritance on the creation of the child table.
See CREATE TABLE
I know this. I need to create inheritance for already created tables.
There is no way to do this using alter table, so I tried to
define it by hand :)
--elein
On Wed, Feb 16, 2005 at
You specify the inheritance on the creation of the child table.
See CREATE TABLE
--elein
On Wed, Feb 16, 2005 at 11:48:54PM +0300, Oleg Bartunov wrote:
> Hi there,
>
> is't possible to make table to be inherited from another table in case
> both tables already exist. I tried to insert record t
Greg Stark <[EMAIL PROTECTED]> writes:
> How are so many people doing so many transactions so soon after installing?
> To hit wraparound you have to do a billion transactions? ("With a `B'") That
> takes real work. If you did 1,000 txn/minute for every minute of every day it
> would still take a c
Hi there,
is't possible to make table to be inherited from another table in case
both tables already exist. I tried to insert record to pg_inherits,
but it doesn't helped.
openfts=# select * from pg_inherits;
inhrelid | inhparent | inhseqno
--+---+--
2617283 | 241727
> > For the real functions which I use, instead of
>
> > query = ''SELECT * FROM usno'';
>
> > I have
>
> > query = my_C_function(some_args);
>
> Oh? I'd make a small side bet that the underlying error is in your C
> function --- possibly it's tromping on some data structure and the
> damag
That the children tables do not inherit these items is mostly
by design, for better or worse. Many people take advantage
of the indexes distribution across the tables and the ability
to have triggers and keys different across the inheritance
can be useful.
This is a controversial subject. You sh
"Sergey E. Koposov" <[EMAIL PROTECTED]> writes:
> Concerning to the exact form of my functions (using cursors, but still
> collecting all the data in the memory). As I understand this is the only one
> way (or just the simplest way ???)
> to execute fully dynamic queries returned by C function in
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Christopher Kings-Lynne wrote:
>
> > I wonder if I should point out that we just had 3 people suffering XID
> > wraparound failure in 2 days in the IRC channel...
>
> I have had half a dozen new customers in the last six months that have
> had the
> looking for the way how to increase performance at Windows XP box, I
found
> the parameters
>
> #fsync = true # turns forced synchronization on or
off
> #wal_sync_method = fsync# the default varies across platforms:
> # fsync, fdatasync,
"Sergey E. Koposov" <[EMAIL PROTECTED]> writes:
> LOOP
> FETCH cur into rec;
> RETURN NEXT rec;
> EXIT WHEN NOT FOUND;
> END LOOP;
> RETURN;
Don't you think you should have the EXIT *above* the RETURN NEXT?
I would expect this to emit a bogus row of nulls after the last row
On Wed, Feb 16, 2005 at 12:33:38PM -0500, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > The advantage of using a counter instead of a simple active
> > bit is that buffers that are (or have been) used heavily will be able to
> > go through several sweeps of the clock before being
Hello everyone,
I'm working on a project which makes extensive use of the PostgreSQL table
inheritance features and am interested in fixing some bugs I have come across.
To my knowledge, triggers, primary keys, index, foreign key and unique
constraints are not inherited. I am more than willing
Hi All
I have a quite strange problem with RETURN NEXT statement.
I have a big table with 500 millions of rows running on Postgres 8.0.
Table "public.usno"
Column | Type | Modifiers
++---
ra | real |
dec| real |
bmag | real |
rmag | real
Hi all,
When I try to input a unicode caracter which code is greater than
U+2, phpPgAdmin returns the following error message :
ERROR: Unicode characters greater than or equal to 0x1 are not
supported
Could someone fix this problem ?
If yes, would you please tell me where can i downloa
On Feb 14, 2005, at 9:27 PM, Abhijit Menon-Sen wrote:
I know UTF8 is a type of unicode but do we need to rename anything
from Unicode to UTF8?
I don't know. I'll go through the documentation to see if I can find
anything that needs changing.
It's not the documentation that is wrong. Specifying the
Bruno Wolff III <[EMAIL PROTECTED]> writes:
> I don't think there is much point in making it configurable. If they knew
> to do that they would most likely know to vacuum as well.
Agreed.
> However, 100K out of 1G seems too small. Just to get wrap around there
> must be a pretty high transaction
Stephan Szabo <[EMAIL PROTECTED]> writes:
> All in all, I figure that odds are very high that if someone isn't
> vacuuming in the rest of the transaction id space, either the transaction
> rate is high enough that 100,000 warning may not be enough or they aren't
> going to pay attention anyway and
Tom Lane wrote:
Maybe
(a) within 200,000 transactions of wrap, every transaction start
delivers a WARNING message;
(b) within 100,000 transactions, forced shutdown as above.
This seems sound enough, but if the DBA and/or SA can't be bothered
reading the docs where this topic features quite pro
Stephan Szabo wrote:
On Wed, 16 Feb 2005, Tom Lane wrote:
Stephan Szabo <[EMAIL PROTECTED]> writes:
(a) within 200,000 transactions of wrap, every transaction start
delivers a WARNING message;
(b) within 100,000 transactions, forced shutdown as above.
This seems reasonable, although perhaps the fo
On Wed, Feb 16, 2005 at 09:38:31 -0800,
Stephan Szabo <[EMAIL PROTECTED]> wrote:
> On Wed, 16 Feb 2005, Tom Lane wrote:
>
> > (a) within 200,000 transactions of wrap, every transaction start
> > delivers a WARNING message;
> >
> > (b) within 100,000 transactions, forced shutdown as above.
>
> T
Hi,
looking for the way how to increase performance at Windows XP box, I found
the parameters
#fsync = true # turns forced synchronization on or off
#wal_sync_method = fsync# the default varies across platforms:
# fsync, fdatasync, open_sync
On Wed, 16 Feb 2005, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > Right, but since the how to resolve it currently involves executing a
> > query, simply stopping dead won't allow you to resolve it. Also, if we
> > stop at the exact wraparound point, can we run into problems act
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> The advantage of using a counter instead of a simple active
> bit is that buffers that are (or have been) used heavily will be able to
> go through several sweeps of the clock before being freed. Infrequently
> used buffers (such as those from a vacuum o
Stephan Szabo <[EMAIL PROTECTED]> writes:
> Right, but since the how to resolve it currently involves executing a
> query, simply stopping dead won't allow you to resolve it. Also, if we
> stop at the exact wraparound point, can we run into problems actually
> trying to do the vacuum if that's stil
>
> On Wed, 16 Feb 2005 [EMAIL PROTECTED] wrote:
>
>> > On Wed, 16 Feb 2005 [EMAIL PROTECTED] wrote:
>> >
>> >> >
>> >> > Once autovacuum gets to the point where it's used by default, this
>> >> > particular failure mode should be a thing of the past, but in the
>> >> > meantime I'm not going to pa
> Stephan Szabo <[EMAIL PROTECTED]> writes:
>> Right, but since the how to resolve it currently involves executing a
>> query, simply stopping dead won't allow you to resolve it. Also, if we
>> stop at the exact wraparound point, can we run into problems actually
>> trying to do the vacuum if that'
>
> On Wed, 16 Feb 2005, Joshua D. Drake wrote:
>
>>
>> >Do you have a useful suggestion about how to fix it? "Stop working" is
>> >handwaving and merely basically saying, "one of you people should do
>> >something about this" is not a solution to the problem, it's not even
>> an
>> >approach towa
On Sun, Feb 13, 2005 at 06:56:47PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> One thing I realized quickly is that there is no natural way in a clock
> >> algorithm to discourage VACUUM from blowing out the cache. I came up
> >> with a slightly ugly idea that's descri
On Wed, 16 Feb 2005 [EMAIL PROTECTED] wrote:
> > On Wed, 16 Feb 2005 [EMAIL PROTECTED] wrote:
> >
> >> >
> >> > Once autovacuum gets to the point where it's used by default, this
> >> > particular failure mode should be a thing of the past, but in the
> >> > meantime I'm not going to panic about
> On Wed, 16 Feb 2005 [EMAIL PROTECTED] wrote:
>
>> >
>> > Once autovacuum gets to the point where it's used by default, this
>> > particular failure mode should be a thing of the past, but in the
>> > meantime I'm not going to panic about it.
>>
>> I don't know how to say this without sounding lik
On Wed, 16 Feb 2005, Joshua D. Drake wrote:
>
> >Do you have a useful suggestion about how to fix it? "Stop working" is
> >handwaving and merely basically saying, "one of you people should do
> >something about this" is not a solution to the problem, it's not even an
> >approach towards a soluti
Christopher Kings-Lynne wrote:
At this point we have a known critical bug. Usually the PostgreSQL
community
is all over critical bugs. Why is this any different?
It sounds to me that people are just annoyed that users don't RTFM.
Get over it. Most won't. If users RTFM more often, it would put mo
Do you have a useful suggestion about how to fix it? "Stop working" is
handwaving and merely basically saying, "one of you people should do
something about this" is not a solution to the problem, it's not even an
approach towards a solution to the problem.
I believe that the ability for Postgr
At this point we have a known critical bug. Usually the PostgreSQL
community
is all over critical bugs. Why is this any different?
It sounds to me that people are just annoyed that users don't RTFM. Get
over it. Most won't. If users RTFM more often, it would put most support
companies out of bu
in the foot. We've seen several instances of people blowing away
pg_xlog and pg_clog, for example, because they "don't need log files".
Or how about failing to keep adequate backups? That's a sure way for an
ignorant admin to lose data too.
There is a difference between actively doing somet
On Wed, 16 Feb 2005 [EMAIL PROTECTED] wrote:
> >
> > Once autovacuum gets to the point where it's used by default, this
> > particular failure mode should be a thing of the past, but in the
> > meantime I'm not going to panic about it.
>
> I don't know how to say this without sounding like a jerk,
> [EMAIL PROTECTED] writes:
>> Maybe I'm missing something, but shouldn't the prospect of data loss
>> (even
>> in the presense of admin ignorance) be something that should be
>> unacceptable? Certainly within the realm "normal PostgreSQL" operation.
>
> [ shrug... ] The DBA will always be able to
[EMAIL PROTECTED] writes:
> Maybe I'm missing something, but shouldn't the prospect of data loss (even
> in the presense of admin ignorance) be something that should be
> unacceptable? Certainly within the realm "normal PostgreSQL" operation.
[ shrug... ] The DBA will always be able to find a way
>> The checkpointer is entirely incapable of either detecting the problem
>> (it doesn't have enough infrastructure to examine pg_database in a
>> reasonable way) or preventing backends from doing anything if it did
>> know there was a problem.
>
> Well, I guess I meant 'some regularly running proc
> Question 1: Is your writeback cache really disabled in Linux, on the
> harddrive? Windows fsync will *write through the disk write cache* if
> the driver is properly implemented. AFAIK, on Linux if write cache is
> enabled on the drive, fsync will only get into the cache.
> 800tps sounds unreason
> What kind of performance difference can be expected between
> Linux and Windows?
Not really known, as the native win version is a bit too new for that.
Expect linux performance to be better, though, that much is sure.
//Magnus
---(end of broadcast)---
What kind of performance difference can be expected between Linux and
Windows?
Benjamin Arai
[EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.benjaminarai.com
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Magnus Hagander
Sent: Tuesday, February 15, 200
59 matches
Mail list logo
