On Wednesday 20 August 2003 23:57, Andrew Dunstan wrote:
http://archives.postgresql.org/pgsql-hackers/2003-07/msg00608.php
Subject is reprise on Linux overcommit handling - is that too
deceptive? :-)
I did little searching on this and found..
Shridhar Daithankar wrote:
On 21 Aug 2003 at 0:22, Ian Barwick wrote:
* DDL
- Data definition language (table creation statements etc.) in MySQL
are not transaction based and cannot be rolled back.
Just wondering, what other databases has transactable DDLs? oracle seems to
have
I see btw that no change has been made to the docs. That's bad IMNSHO.
The situation with RH is unchanged with today's kernel errata patch,
too. I propose to submit a doc patch with the following wording, unless
someone objects or improves it:
---
Linux kernel version
Andreas Pflug [EMAIL PROTECTED] writes:
Shridhar Daithankar wrote:
On 21 Aug 2003 at 0:22, Ian Barwick wrote:
* DDL
- Data definition language (table creation statements etc.) in MySQL
are not transaction based and cannot be rolled back.
Just wondering, what other databases has
On Thu, 21 Aug 2003, Andrew Dunstan wrote:
Linux kernel version 2.4.* has poor default memory overcommit behavior,
which can result in the postmaster being killed by the kernel due to
memory demands by another process if the system runs out of memory. To
avoid this situation, run postgres
On 21 Aug 2003 at 9:21, Greg Stark wrote:
Andreas Pflug [EMAIL PROTECTED] writes:
Shridhar Daithankar wrote:
On 21 Aug 2003 at 0:22, Ian Barwick wrote:
* DDL
- Data definition language (table creation statements etc.) in MySQL
are not transaction based and cannot be rolled
On 21 Aug 2003 at 9:21, Greg Stark wrote:
Andreas Pflug [EMAIL PROTECTED] writes:
Shridhar Daithankar wrote:
Just wondering, what other databases has transactable DDLs? oracle seems to
have autonomous transactions which is arthogonal.
M$ SQL2000 has (and previous versions had too, I
Shridhar Daithankar wrote:
On 21 Aug 2003 at 9:21, Greg Stark wrote:
Andreas Pflug [EMAIL PROTECTED] writes:
Shridhar Daithankar wrote:
On 21 Aug 2003 at 0:22, Ian Barwick wrote:
* DDL
- Data definition language (table creation statements etc.) in MySQL
are not
On 8/8/2003 5:49 AM, Jason Tishler wrote:
Carlos,
On Fri, Aug 08, 2003 at 09:20:01AM +0200, Carlos Guzman Alvarez wrote:
I want to know if postgresql 7.4 beta 1 can be configured under
Cygwin with SSL support ??
If the answer is positive how can i do it ?? or where can i found
documentation
Guys,
So there's no need to wonder whether that's a source of trouble for your
PostgreSQL processes or not; just check the logs. I've had the OOM killer
go after large Perl processes and X, but never (yet) PostgreSQL, I'm happy
to say.
Well, sadly, the reason I posted is that I (apparently)
Josh Berkus [EMAIL PROTECTED] writes:
Well, sadly, the reason I posted is that I (apparently) had a client's
database fatally corrupted by this problem.
Fatally corrupted? That should not happen --- at worst, an OOM kill
should lose your current sessions. We need more details.
Tom,
Fatally corrupted? That should not happen --- at worst, an OOM kill
should lose your current sessions. We need more details.
Joe and I are diagnosing. Likely the files will come to you before the end
of the day.
--
Josh Berkus
Aglio Database Solutions
San Francisco
On Thu, Aug 21, 2003 at 01:04:13PM -0400, Tom Lane wrote:
Josh Berkus [EMAIL PROTECTED] writes:
Well, sadly, the reason I posted is that I (apparently) had a client's
database fatally corrupted by this problem.
Fatally corrupted? That should not happen --- at worst, an OOM kill
should
Alan,
You need to be careful using Alan's patch. The reason RH stopped using
this part of it in their errata kernels is that it had conflicts with
other stuff, specifically the rmap stuff (he told me that himself in
email).
Hmmm ... that leaves us without a workaround for this problem, then,
Kurt Roeckx [EMAIL PROTECTED] writes:
On Thu, Aug 21, 2003 at 01:04:13PM -0400, Tom Lane wrote:
Fatally corrupted? That should not happen --- at worst, an OOM kill
should lose your current sessions. We need more details.
Even if it kills the postmaster?
Then you'd have to start a new
(er, that's Andrew :-)
It depends how important your data is to you. A modest server probably
costs a few thousand dollars. How much does an expert to install a
custom kernel cost? Probably about the same.
I believe paranoid mode is supposed to prevent any overcommiting that
can't later be
Folks,
Well, sadly, the reason I posted is that I (apparently) had a client's
database fatally corrupted by this problem.
OK, diagnosis progresses, it's not the Linux OOM problem, it's something else.
--
-Josh Berkus
Aglio Database Solutions
San Francisco
Stephan Szabo [EMAIL PROTECTED] writes:
Within the scope of the new hashed IN stuff I believe so in at least some
cases. I have a few million row table of integers where searching for
values IN (~1 values) takes longer than creating the temp table,
copying into it and doing the in
On Thu, 21 Aug 2003, Tom Lane wrote:
Stephan Szabo [EMAIL PROTECTED] writes:
Within the scope of the new hashed IN stuff I believe so in at least some
cases. I have a few million row table of integers where searching for
values IN (~1 values) takes longer than creating the temp
On Thu, 21 Aug 2003 16:42:20 -0400, Tom Lane [EMAIL PROTECTED]
wrote:
The point is that given
WHERE a = 1 OR b = 1
you could create a plan that first indexscans on a, then indexscans on
b --- but you mustn't return any tuples in the second scan that you
already returned in the first.
Tom,
I'm toying with the notion of ripping out that logic and instead
building an in-memory hashtable of already-returned TIDs. This could
theoretically run out of memory if the multiple indexscan returns enough
tuples, but I think in practice that wouldn't happen because the planner
Manfred Koizar [EMAIL PROTECTED] writes:
WHERE a = 1 OR a = 2
are totally different things. In the latter case you don't have to
check prior conditions because the conditions are mutually exclusive.
Is this reasonably easy to find out at plan creation time?
Yeah, I know, but I see no
Joe Conway [EMAIL PROTECTED] writes:
Tom Lane wrote:
I'm toying with the notion of ripping out that logic and instead
building an in-memory hashtable of already-returned TIDs. This could
theoretically run out of memory if the multiple indexscan returns enough
tuples, but I think in practice
I'm toying with the notion of ripping out that logic and instead
building an in-memory hashtable of already-returned TIDs. This could
theoretically run out of memory if the multiple indexscan returns enough
tuples, but I think in practice that wouldn't happen because the planner
wouldn't
Andrew,
I see btw that no change has been made to the docs. That's bad IMNSHO.
The situation with RH is unchanged with today's kernel errata patch,
too. I propose to submit a doc patch with the following wording, unless
someone objects or improves it:
First, off, I'm crossing this to
I replied to Josh thus:
---
You need to be careful using Alan's patch. The reason RH stopped using
this part of it in their errata kernels is that it had conflicts with
other stuff, specifically the rmap stuff (he told me that himself in
email).
I am very wary of advising
On Thu, 21 Aug 2003 15:05:52 +0200, I wrote:
Just wondering, what other databases has transactable DDLs?
Firebird.
Stop! I withdraw that statement. I must have mis-read some feature
list :-(
Tests with InterBase 6 showed that you can change metadata within a
transaction, but when you
On Thursday 21 August 2003 21:30, Manfred Koizar wrote:
On Thu, 21 Aug 2003 15:05:52 +0200, I wrote:
Just wondering, what other databases has transactable DDLs?
Firebird.
Stop! I withdraw that statement. I must have mis-read some feature
list :-(
Tests with InterBase 6 showed that you
On Thursday 21 August 2003 11:15, Shridhar Daithankar wrote:
On 21 Aug 2003 at 0:22, Ian Barwick wrote:
* DDL
- Data definition language (table creation statements etc.) in MySQL
are not transaction based and cannot be rolled back.
Just wondering, what other databases has transactable
On Wed, 20 Aug 2003 15:39:26 -0400, Tom Lane [EMAIL PROTECTED]
wrote:
But I think the real point here is that there's no reason to think that
doing tuple deletion on-the-fly in foreground transactions is superior
to doing it in background with a vacuum process. You're taking what
should be
[ still brainstorming ... ]
On Thu, 21 Aug 2003 17:16:50 -0400, Tom Lane [EMAIL PROTECTED]
wrote:
Whenever a backend encounters a dead tuple it inserts a reference to
its page into the RSM.
This assumes that backends will visit dead tuples with significant
probability. I doubt that assumption
On Thu, 21 Aug 2003 17:56:02 -0400, Tom Lane [EMAIL PROTECTED]
wrote:
Conceivably it could be a win, though,
if you could do frequent vacuum decents and only a full-scan vacuum
once in awhile (once a day maybe).
That's what I had in mind; similar to the current situation where you
can avoid
On 21 Aug 2003 at 0:22, Ian Barwick wrote:
* DDL
- Data definition language (table creation statements etc.) in MySQL
are not transaction based and cannot be rolled back.
Just wondering, what other databases has transactable DDLs? oracle seems to
have autonomous transactions which is
On Thu, 21 Aug 2003 14:45:03 +0530, Shridhar Daithankar
[EMAIL PROTECTED] wrote:
Just wondering, what other databases has transactable DDLs?
Firebird.
Servus
Manfred
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an
34 matches
Mail list logo
