On 21 Aug 2003 at 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 tha
> 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
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 decent"s 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
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
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 that wouldn't happen because the planner
wo
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
[ 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 as
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
> wo
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.
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 te
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 n
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 su
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 transact
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 show
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 ROLLB
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
--
(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 h
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
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, th
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 ki
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
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
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.
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 PGSQ
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 (apparentl
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 fou
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 transa
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 choos
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 versi
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
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 postgr
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
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 2.4.*
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 autonomous
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 arthog
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..
http://www.ussg.iu.edu/hypermail/linux/kern
36 matches
Mail list logo
