Patrick Welche writes:
> Does this count a string change? :)
Yes, but it's also a documentation bug fix.
Anyway, you got it in before the freeze. :)
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 2: you can get off all lis
Alvaro Herrera writes:
> The only things left that I can see are
>
> #: commands/tablecmds.c:4093
> msgid "tables \"%s\" already has a TOAST table"
> "tables" -> "table"
Fixed.
> #: commands/user.c:651 commands/user.c:1357
> msgid "sysid %d is already assigned"
> "sysid" -> "user ID"? Not sure,
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 cach
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 rem
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 'qu
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 tha
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
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 perfo
"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 ou
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 b
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 handl
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 "v
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 wh
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 o
Manfred Koizar <[EMAIL PROTECTED]> writes:
> db=> SET disable-fk-verification = true;
> ERROR: "disable-fk-verification" can only be set in single user mode
I don't really see the point of such a restriction. Restricting the
system to a single user has nothing to do with making
disable-fk-verific
"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 cr
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 think the ones in the main functions n
As the subject says, anybody sitting on anything that they wish to get
into beta4? 'translation stuff' not withstanding, of course ...
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
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 th
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]
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 th
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
"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:
"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 he
"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
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 o
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 exist
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 delet
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 li
The following code is in initdb.sh:
exit_nicely(){
stty echo > /dev/null 2>&1
echo 1>&2
echo "$CMDNAME: failed" 1>&2
if [ "$noclean" != yes ]; then
if [ "$made_new_pgdata" = yes ]; then
echo "$CMDNAME: removing data directory \"$PGDATA\"" 1>&2
rm -rf "$PGDA
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 wh
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.
---
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 r
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 b
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
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 removed
[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 sourc
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
>
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 address
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
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
The query takes about 1/4 of a second.
But, for:
=# BEGIN;
=# DECLARE mycursor BINARY CURSOR FOR SELECT ;
=# FETCH ALL IN mycursor;
The same [SQL] q
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
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
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 fea
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 , t
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 http://www.bestsellers.indiati
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 sp
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 release
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 quer
unsubscribe
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
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
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 step
> 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
-
> 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
> \timin
On Tue, Sep 30, 2003 at 09:37:26AM -0700, Joshua D. Drake wrote:
>
> Of course the theory being that we backport "some" features and fix
> any bugs that
> we find?
I would argue _very strongly_ against backporting features.
The backporting of features into the Linux kernel is an extremely
good
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
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 layo
On Tue, Sep 30, 2003 at 11:31:26PM -0700, James Rogers wrote:
> The problem: My working set is typically several million rows (and growing)
> at any one time, which has a tendency to thrash the buffers mercilessly.
> Records are inserted in an order that does not reflect typical retrieval
> such t
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,
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 h
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 u
"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, t
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
-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.
http://home.offi
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
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
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, 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 upg
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 no
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 p
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, hopefu
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 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 upgrad
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 ar
74 matches
Mail list logo
