Hi,
I am running a large and mature mission-critical PostgreSQL implementation
with multiple tables that are growing at a rate of several million rows per
month (the rate of addition is growing as well). It is a 24x7 operation, so
downtime is a party foul and apparent performance has to be
Regarding the NOTICE
CREATE TABLE will create implicit triggers for foreign-key checks
Does anyone care?
The other helpful notices about sequences for serial columns and indexes
for unique constraints have some merit, because they inform the user
objects that the user might be interested in are
On Tue, 30 Sep 2003, Joshua D. Drake wrote:
Hello,
With the recent stint of pg_upgrade statements and the impending
release of 7.4 what do people think about having a dedicated maintenance
team for 7.3? 7.3 is a pretty solid release and I think people will be
hard pressed to upgrade to
On Wed, 1 Oct 2003, Christopher Kings-Lynne wrote:
Just use FreeBSD 5 - background fsck.
Trust me, I'm soo looking forward to 5.x to be rated 'stable enough
for a production server' .. I spent a good portion of yesterday aft
chatting on the -current mailng list about how slow fsck was :(
On Wed, 1 Oct 2003, Tom Lane wrote:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Just use FreeBSD 5 - background fsck.
Apparently Marc doesn't think FreeBSD 5 is stable enough to use yet.
Trust me, if I felt confident enough with it, we'd already be moved ...
after Xmas, hopefully be
On Wed, 2003-10-01 at 08:36, Marc G. Fournier wrote:
On Tue, 30 Sep 2003, Joshua D. Drake wrote:
Hello,
With the recent stint of pg_upgrade statements and the impending
release of 7.4 what do people think about having a dedicated maintenance
team for 7.3? 7.3 is a pretty solid
Bruce Momjian wrote:
Jan Wieck wrote:
Just committed a small fix for PL/Tcl.
I don't find it on the TODO, but you might want to add it to the release
notes.
* Fixed PL/Tcl's spi_prepare to accept full qualified type names in
the parameter type list.
Oops, properly added to release
On Tue, 30 Sep 2003, Joshua D. Drake wrote:
Hello,
With the recent stint of pg_upgrade statements and the impending
release of 7.4 what
do people think about having a dedicated maintenance team for 7.3? 7.3
is a pretty
solid release and I think people will be hard pressed to upgrade
Peter Eisentraut wrote:
Regarding the NOTICE
CREATE TABLE will create implicit triggers for foreign-key checks
Does anyone care?
I don't care but is a way for a beginner to understand that behind
a foreign key there is a TRIGGER that have not a 0 cost.
The other helpful notices about
On Tue, 30 Sep 2003, Tom Lane wrote:
It seems some junior electrician in Panama pulled the wrong circuit
breaker ... and then the mail.postgresql.org server spent an
unreasonable number of hours fsck'ing. (Why is Marc a FreeBSD fan
anyway? Don't ask me, I work for Red Hat.) Anyhow, due to
On Wed, 1 Oct 2003, Robert Treat wrote:
Maybe I've mis-read Joshua's intentions, but I got the impression that
this 7.3 maintainer would follow the patches list and backport patches
whenever possible. This way folks coding for 7.4/7.5 can stay focused on
that, but folks who can't upgrade to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This si my first look at the pg-code, so it may not comply with the
coding-standards. I haven't coded in C for a while either, so if someone
finds a better way to implement this, go ahead, but this patch works for me
with 7.4beta3.
Peter Eisentraut [EMAIL PROTECTED] writes:
Regarding the NOTICE
CREATE TABLE will create implicit triggers for foreign-key checks
Does anyone care?
I was thinking just the other day that it seemed to be useless clutter.
The other helpful notices about sequences for serial columns and indexes
Marc G. Fournier [EMAIL PROTECTED] writes:
On Tue, 30 Sep 2003, Joshua D. Drake wrote:
Of course the theory being that we backport some features and fix
any bugs that we find?
Not saying that if someone submit'd patches to v7.3, they wouldn't get
applied ... only that, to date, the
On Wed, 2003-10-01 at 09:14, Robert Treat wrote:
Maybe I've mis-read Joshua's intentions, but I got the impression that
this 7.3 maintainer would follow the patches list and backport patches
whenever possible. This way folks coding for 7.4/7.5 can stay focused on
that, but folks who can't
On Wed, 1 Oct 2003, Peter Eisentraut wrote:
Regarding the NOTICE
CREATE TABLE will create implicit triggers for foreign-key checks
Does anyone care?
Probably not anymore. It doesn't give names (as Tom noticed), but at least
it gave a starting point to look for them back when you still had
Peter Eisentraut [EMAIL PROTECTED] writes:
[ some questions about --help-config ]
I got this reply from Fernando Nasser of Red Hat. I suggested he should
post it for himself, but since he hasn't yet...
regards, tom lane
--- Forwarded Message
Date:Tue, 30
James Rogers [EMAIL PROTECTED] writes:
Now, I've actually hacked commercial MVCC engines back in the day, and am
comfortable playing around in database internals. I have an itch to
scratch for improving the scalability of Really Large Tables by explicitly
allowing control of table layouts as
On Wed, 2003-10-01 at 10:49, Neil Conway wrote:
On Wed, 2003-10-01 at 09:14, Robert Treat wrote:
Maybe I've mis-read Joshua's intentions, but I got the impression that
this 7.3 maintainer would follow the patches list and backport patches
whenever possible. This way folks coding for 7.4/7.5
eh.. i could see some things, like tsearch2 or pg_autovacuum, which
afaik are almost if not completely compatible with 7.3, which will not
get back ported. Also fixes in some of the extra tools like psql could
be very doable, I know I had a custom psql for 7.2 that back patched the
\timing
I would argue _very strongly_ against backporting features.
For massive features sure but an example of a feature that works
very well and easily with 7.3 is the preloading of libs.
Sincerely,
Joshua Drake
--
Co-Founder
Command Prompt, Inc.
The wheel's spinning but the hamster's dead
On Wed, 2003-10-01 at 09:41, Marc G. Fournier wrote:
On Wed, 1 Oct 2003, Robert Treat wrote:
Several linux distros already do this for many packages, and personally
I've always been surprised that, given postgresql's major release
upgrade issues, that no commercial company has stepped in
Alvaro Herrera [EMAIL PROTECTED] writes:
As for other indexes, I'm not sure why you say this precludes the use of
other indexes. The only thing they have to do is keep pointers to index
elements, instead of heap elements. Doesn't sound impossible to me.
However, btree feels free to move
unsubscribe
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
On Wed, Oct 01, 2003 at 11:37:38AM -0400, Tom Lane wrote:
James Rogers [EMAIL PROTECTED] writes:
Both of these things really are attempts to address the same basic problem,
which is optimizing the number of buffers a given query uses by making the
tables layout reflect typical queries.
On Wed, Oct 01, 2003 at 08:49:51AM -0700, Joshua D. Drake wrote:
I would argue _very strongly_ against backporting features.
For massive features sure but an example of a feature that works
very well and easily with 7.3 is the preloading of libs.
Then let people patch the stable releases
On Wed, 2003-10-01 at 11:48, Joshua D. Drake wrote:
Sure but businesses don't like to upgrade unless they have too.
Granted, but maintaining old releases doesn't come at zero cost. It may
benefit some users, but the relevant question is whether that benefit is
worth the cost. The time someone
Hi
I want to change the buffer policy page structure of pgsql from which file I should
start?Is any document which describe the code of buffer manager og pgsql?
Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com
Buy The Best In BOOKS at
With 7.4 I'm finding upgrading to be easier. I'll likely upgrade out
production servers to 7.4.0 when it comes out and wind up skipping 7.3
altogether.
Sure but I talking about people who are running 7.3 and are happy with
it. The reality is that for probably 95% of the people
out there ,
Maybe I've mis-read Joshua's intentions, but I got the impression that
this 7.3 maintainer would follow the patches list and backport patches
whenever possible. This way folks coding for 7.4/7.5 can stay focused on
that, but folks who can't upgrade to 7.4 for whatever reason can still
get some
I don't believe anyone would work against this, nor could I imagine that
anyone would think it was a bad idea, I'm just curious as to how
possible it is to do ...
For most things probably not that possible. For things like:
Simple feature enhancements (preloading of libs)
Fixing pl/Language
On Tue, 30 Sep 2003 08:00:07 -0400, Christopher Browne
[EMAIL PROTECTED] wrote:
I would be pretty game for a near-single-user-mode approach that
would turn off some of the usual functionality that we knew we didn't
need because the data source was an already-committed-and-FK-checked
set of data.
I've been noticing query planning to be different for a cursor-based
select and normal select.
For example, my query looks like this:
=# SELECT select clause
The query takes about 1/4 of a second.
But, for:
=# BEGIN;
=# DECLARE mycursor BINARY CURSOR FOR SELECT select clause;
=# FETCH ALL IN
Joshua D. Drake wrote:
For most things probably not that possible. For things like:
Simple feature enhancements (preloading of libs)
How long is a piece of string? When does something stop being simple?
Fixing pl/Language bugs (and making sure they still work on 7.3)
Buffer overflow fixes
Two mails with updated translations for /src/backend/po/hr.po are lost.
First time I send clear po file, second tar.gz - no result.
Is something blocking mails with attachment ? I didn't receive notification
that mail is blocked or something like that.
Can I try to send it to some other
On Wed, 1 Oct 2003, Joshua D. Drake wrote:
With 7.4 I'm finding upgrading to be easier. I'll likely upgrade out
production servers to 7.4.0 when it comes out and wind up skipping 7.3
altogether.
Sure but I talking about people who are running 7.3 and are happy with
it. The
[EMAIL PROTECTED] (Manfred Koizar) writes:
On Tue, 30 Sep 2003 08:00:07 -0400, Christopher Browne
[EMAIL PROTECTED] wrote:
I would be pretty game for a near-single-user-mode approach that
would turn off some of the usual functionality that we knew we didn't
need because the data source was an
then maybe they would be willing to donate some small amount each ($500 or
so) to pay for backporting issues. Since mostly what I'd want on an older
version would be bug / security fixes, that $500 should go a long way
towards backporting.
Sure.
I was under the imporession that 7.4
On Wed, Oct 01, 2003 at 11:53:12AM -0700, Joshua D. Drake wrote:
Eh? In 7.4 you should not need to reindex.
I thought tom was saying that the index bloat was better in 7.4 but it
was not gone... thus we would still need reindex yes?
The problem has been corrected enough for there to be no
On Wed, 2003-10-01 at 15:31, Joshua D. Drake wrote:
then maybe they would be willing to donate some small amount each ($500 or
so) to pay for backporting issues. Since mostly what I'd want on an older
version would be bug / security fixes, that $500 should go a long way
towards
On Mon, Sep 29, 2003 at 11:50:23PM +0200, Peter Eisentraut wrote:
Tom Lane writes:
At the very least we need to set a strings freeze soon, so the
translators can catch up. Peter, are you getting close to done with the
message revisions you've been making?
Yes, I think we're ready for
Hi,
Using PG under Cygwin we having following error message during INSERT
INTO
FreeSpaceMap hashtable out of memory.
What does that mean?
And if for a moment step out of knowledge 'PG under Cygwin', what in
general
this message is about and more important how to fix it?
Thank you.
and the question as i thought was being discussed (or should be
discussed) was what is the level of interest in having this work kept in
the community cvs tree vs. someone else's quasi-forked branch...
It is my thinking that regardless of commercial backing that the
PostgreSQL project as a
The following code is in initdb.sh:
exit_nicely(){
stty echo /dev/null 21
echo 12
echo $CMDNAME: failed 12
if [ $noclean != yes ]; then
if [ $made_new_pgdata = yes ]; then
echo $CMDNAME: removing data directory \$PGDATA\ 12
rm -rf $PGDATA || echo
On Wed, 1 Oct 2003, Darko Prenosil wrote:
Two mails with updated translations for /src/backend/po/hr.po are lost.
First time I send clear po file, second tar.gz - no result.
Is something blocking mails with attachment ? I didn't receive notification
that mail is blocked or something like
Andrew Dunstan writes:
So if the data directory previously existed and was empty, we don't
clean it out on error, even if we didn't use the noclean flag. Is this
intended behaviour or a bug? (If a bug it's trivially easy to fix.)
If the data directory already existed, we don't want to delete
Stephan Szabo [EMAIL PROTECTED] writes:
On Tue, 30 Sep 2003, Tom Lane wrote:
I think I can implement it and it will act as stated in my proposal.
Whether people like the proposed behavior is the big question in my
mind.
I think it's more reasonable than the current behavior or any of
the
Maksim Likharev [EMAIL PROTECTED] writes:
Using PG under Cygwin we having following error message during INSERT
INTO
FreeSpaceMap hashtable out of memory.
Hm, that's not supposed to happen. Can you create a reproducible
example?
regards, tom lane
Darko Prenosil [EMAIL PROTECTED] writes:
Two mails with updated translations for /src/backend/po/hr.po are lost.
First time I send clear po file, second tar.gz - no result.
Is something blocking mails with attachment ?
How big were they --- over 40K? If so, they're probably being held for
Joshua D. Drake [EMAIL PROTECTED] writes:
... having to reindex the database (which 7.4 doesn't fix),
It's supposed to fix it. What are you expecting not to be fixed?
regards, tom lane
---(end of broadcast)---
TIP 4:
On Wed, 1 Oct 2003, Tom Lane wrote:
Stephan Szabo [EMAIL PROTECTED] writes:
On Tue, 30 Sep 2003, Tom Lane wrote:
I think I can implement it and it will act as stated in my proposal.
Whether people like the proposed behavior is the big question in my
mind.
I think it's more reasonable
Hello,
When I was reading hackers about the fixes you had made, it stated
that the index bloat problems should be better. I took
that as meaning that although it won't be required nearly as often, we
still may need to reindex occassionaly. It was later
pointed out to me that this may not be
Following up to the discussion a few weeks ago and in accordance with the
criteria developed there about how a message should be classified NOTICE
or WARNING, I have identified the following cases that ought to be
reclassified:
change WARNING to NOTICE:
table %s has no indexes [during REINDEX]
On Wed, 1 Oct 2003, Tom Lane wrote:
Darko Prenosil [EMAIL PROTECTED] writes:
Two mails with updated translations for /src/backend/po/hr.po are lost.
First time I send clear po file, second tar.gz - no result.
Is something blocking mails with attachment ?
How big were they --- over
Bruce Momjian writes:
I would rebuild it right now but the cross-links I added to INSTALL to
allow a mention of shared_buffers and sort_mem as part of the tuning
recommendation has broken the INSTALL build:
You need to do it like this:
para
commandpg_dumpall/command does not
Joshua D. Drake [EMAIL PROTECTED] writes:
When I was reading hackers about the fixes you had made, it stated
that the index bloat problems should be better. I took
that as meaning that although it won't be required nearly as often, we
still may need to reindex occassionaly.
The critical
It is problematic to produce small enough subset, due to large DB and
randomness of the situation.
But here is what we see in server log file, see below:
It seems like
WARNING: ShmemAlloc: out of memory
ERROR:FreeSpaceMap hashtable out of memory
goes together, does it related to the size
David Blasby [EMAIL PROTECTED] writes:
I've been noticing query planning to be different for a cursor-based
select and normal select.
IIRC, in a DECLARE context the planner puts more weight on the startup
cost than the total cost, on the theory that you might not be planning
to fetch the whole
Alvaro Herrera [EMAIL PROTECTED] writes:
I think what Tom is concerned about is that this hasn't been tested
enough with big datasets. Also there a little loss of index pages but
it's much less (orders of magnitude, I think) than what was before.
This is because the index won't shrink
On Wed, 1 Oct 2003, Tom Lane wrote:
Stephan Szabo [EMAIL PROTECTED] writes:
On Wed, 1 Oct 2003, Tom Lane wrote:
I've committed the attached patch. One thing I wanted to double-check
with you is that the SELECT FOR UPDATES done in the noaction cases are
being correctly handled.
I
Robert Treat [EMAIL PROTECTED] writes:
and the question as i thought was being discussed (or should be
discussed) was what is the level of interest in having this work kept in
the community cvs tree vs. someone else's quasi-forked branch...
I see no reason that the maintenance shouldn't be
Maksim Likharev [EMAIL PROTECTED] writes:
It seems like
WARNING: ShmemAlloc: out of memory
ERROR:FreeSpaceMap hashtable out of memory
goes together, does it related to the size of Shared Memory
Yeah, the FSM hashtable is in shared memory, so your problem is that
you're running out of
Hi,
From the document, it seems that PREPARE/EXECUTE works only in the same
session. I am wondering whether postgres can prepare a query (save the plan)
for difference backends.
I am working on a project which requires executing psql -c 'query' in
command line multiple times. Since the
On Wed, 2003-10-01 at 20:25, Jingren Zhou wrote:
From the document, it seems that PREPARE/EXECUTE works only in the same
session. I am wondering whether postgres can prepare a query (save the plan)
for difference backends.
The decision to store prepared statements per-backend, rather than in
Peter Eisentraut wrote:
Regarding the NOTICE
CREATE TABLE will create implicit triggers for foreign-key checks
Does anyone care?
I don't.
The other helpful notices about sequences for serial columns and indexes
for unique constraints have some merit, because they inform the user
objects that
On Wed, 1 Oct 2003, Jingren Zhou wrote:
Hi,
From the document, it seems that PREPARE/EXECUTE works only in the same
session. I am wondering whether postgres can prepare a query (save the plan)
for difference backends.
I am working on a project which requires executing psql -c 'query' in
Neil Conway [EMAIL PROTECTED] writes:
The decision to store prepared statements per-backend, rather than in
shared memory, was made deliberately. In fact, an early version of the
PREPARE/EXECUTE patch (written by Karel Zak) stored prepared statements
in shared memory. But I decided to remove
On Wed, 2003-10-01 at 22:43, Tom Lane wrote:
Another issue is that we currently don't have a mechanism for flushing
query plans when they become obsolete (eg, an index is added or
removed). Locally-cached plans are relatively easy to refresh: just
start a fresh session. A shared plan cache
Peter Eisentraut wrote:
Andrew Dunstan writes:
So if the data directory previously existed and was empty, we don't
clean it out on error, even if we didn't use the noclean flag. Is this
intended behaviour or a bug? (If a bug it's trivially easy to fix.)
If the data directory already
69 matches
Mail list logo
