On Wed, 25 Aug 2004, Mark Kirkwood wrote:
>
>
> Greg Stark wrote:
>
> > It's only allowed when the transaction is in READ UNCOMMITTED
> > isolation level.
> >
> >Something Postgres doesn't currently support. In fact I'm not aware of any SQL
> >database that supports it, though I'm sure there's one
On Wed, 25 Aug 2004 03:54 pm, Mark Kirkwood wrote:
> Greg Stark wrote:
> > It's only allowed when the transaction is in READ UNCOMMITTED
> > isolation level.
> >
> >Something Postgres doesn't currently support. In fact I'm not aware of any
> > SQL database that supports it, though I'm sure there's
Greg Stark wrote:
It's only allowed when the transaction is in READ UNCOMMITTED
isolation level.
Something Postgres doesn't currently support. In fact I'm not aware of any SQL
database that supports it, though I'm sure there's one somewhere.
FYI - DB2 supports this isolation level, I don't kn
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> > OK, TODO updated:
> > * Implement dirty reads or shared row locks and use them in RI triggers
>
> Can someone explain to me what a dirty read is and how it relates to RI
> triggers?
A dirty read is a read that includes data that hasn't bee
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> If we agree to never implement UNDO, there's a bunch of other code that
> could be removed.
Yeah, I've been thinking of going around and cleaning out the deadwood,
but beta is not the time for it.
> The commit xlog record also carries dropped table inf
Gavin Sherry <[EMAIL PROTECTED]> writes:
> As for extending the length of xl_len, what happens if someone now has
> 2^30 subtransaction IDs (as unlikely as that sounds)?
They'll have run out of RAM to store the subxact-related storage before
that (not to mention most likely have exhausted the Comm
On Wed, Aug 25, 2004 at 11:21:49AM +1000, Gavin Sherry wrote:
> On Tue, 24 Aug 2004, Tom Lane wrote:
> > 1. Allow XLOG records to be larger than 64K.
> >
> > 2. Split transaction commit into multiple XLOG records when there are
> >many subtransactions.
>
> [snip]
>
> > I'm inclined to go with
Gaetano,
> I knew there was an evaluation on the futex vs spinlock,
> and Josh Berkus on IRC told me that there was only a 20%
> performance increase, is this increase to throw away ?
Before we get totally off track here
I evaluated futexes strictly as an attempt to solve the context switch
Is this enough? I'm seeing that with --enable-debug only the
option -g is passed to the compiler and the option -O2 is
still there, is it not better compile with -O0 if you are
going to debug it?
Well, I use the following:
./configure --prefix=blah --enable-debug --enable-cassert
--enable-depend -
OK, TODO updated:
* Implement dirty reads or shared row locks and use them in RI triggers
Can someone explain to me what a dirty read is and how it relates to RI
triggers?
Chris
---(end of broadcast)---
TIP 9: the planner will ignore your desire to
Any Australian hackers interested in this?
Original Message
Subject: [Announce] AUUG announces Code Con 2004
Date: Tue, 24 Aug 2004 23:41:12 +1000
From: David Purdue <[EMAIL PROTECTED]>
Organization: AUUG Incorporated
To: [EMAIL PROTECTED]
NOTE: Linux Australia members may attend
On Tue, 24 Aug 2004, Tom Lane wrote:
> I wrote:
> > What is happening of course is that more than 16K subtransaction IDs
> > won't fit in a commit record (since XLOG records have a 16-bit length
> > field). We're gonna have to rethink the representation of subxact
> > commit in XLOG.
>
> After so
Hi all,
I knew there was an evaluation on the futex vs spinlock,
and Josh Berkus on IRC told me that there was only a 20%
performance increase, is this increase to throw away ?
Regards
Gaetano Mendola
---(end of broadcast)---
TIP 8: explain analyze i
I wrote:
> What is happening of course is that more than 16K subtransaction IDs
> won't fit in a commit record (since XLOG records have a 16-bit length
> field). We're gonna have to rethink the representation of subxact
> commit in XLOG.
After some further thought, I think there are basically two
Neil Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
> > Associating such a thing with spinlocks seems certain to be a dead loss,
> > as the amount of time we normally hold a spinlock is much less than the
> > time to make one kernel call, let alone two.
>
> Yeah, I was thinking about this.
4year old technology based on, if I recall right, 5 year old server code
:( Not sure if they've updated to more recent code or not ...
On Fri, 20 Aug 2004, Mischa Sandberg wrote:
http://www.cs.mcgill.ca/~kemme/papers/vldb00.html
ARC buffer replacement policy supersedes LRU.
-
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I wonder instead if it will be possible to store a timestamp without
> timezone in one field, and a timezone in another field. So I can get
> back a timestamp at the second-field timezone.
"f1 AT TIME ZONE f2" would be exactly the way to do that.
> I
On Tue, Aug 24, 2004 at 03:16:30PM -0400, Shahbaz Javeed wrote:
People,
> I wonder whether this TODO item also covers cases such as inserting
> into a table where one field is time in the local timezone and the
> other is time in GMT. Not sure if such a thing is desirable or even
> possible (in
Folks,
I wonder whether this TODO item also covers cases such as inserting
into a table where one field is time in the local timezone and the
other is time in GMT. Not sure if such a thing is desirable or even
possible (in the SQL standard). The syntax I'm imagining feels pretty
awkward.
I gues
Darcy Buskermolen <[EMAIL PROTECTED]> writes:
> I was thinking of changing the way EFC is handled, having it retrived via code
> (much the same way top does it) rather than relying on the user to specify
> the value. This value would then be checked/updated every so often.
Even assuming that yo
Philip Warner <[EMAIL PROTECTED]> writes:
> On the question of schemas, how would you expect:
> SET magic_tablespace_variable = some_ts;
> CREATE SCHEMA foo;
> to behave? Would foo have a default tablespace of some_ts?
Yeah, I would think so. I sure don't see a value in inventi
Ummm time to get a 'Unix in 21 days' book,
because what you're relating indicates you are battling with
some beginner basics:
Try:
$ cd /usr/local
or:
$ cd /usr
$ cd local
not:
$ cd /usr
$ cd /local
And you can't execute a program in the current directo
http://www.cs.mcgill.ca/~kemme/papers/vldb00.html
ARC buffer replacement policy supersedes LRU.
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Hello
Exceptions are very usefull and nice, thanks. But, I didn't find any
possibility to get any information about exception when I use
EXCEPTION WHEN OTHERS THEN.
Oracle has two wariables SQLCODE and SQLERRM.
Regards
Pavel Stehule
---(end of broadcast)--
Tom Lane wrote:
> Gaetano Mendola <[EMAIL PROTECTED]> writes:
>
>>Christopher Kings-Lynne wrote:
>>
>>>./configure --enable-debug
>
>
>>Is this enough? I'm seeing that with --enable-debug only the
>>option -g is passed to the compiler and the option -O2 is
>>still there, is it not better compile wi
I was thinking of changing the way EFC is handled, having it retrived via code
(much the same way top does it) rather than relying on the user to specify
the value. This value would then be checked/updated every so often.
Does anybody have any thoughts on this. Especially on if this would be a
Neil Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> On the count-the-number-of-CPUs patch, what sort of coverage are you
>> expecting to get?
> I haven't yet seen a platform that doesn't provide some means to get the
> # of CPUs, but I suppose there might be one...
It might be worth exp
Gaetano Mendola <[EMAIL PROTECTED]> writes:
> Christopher Kings-Lynne wrote:
>> ./configure --enable-debug
> Is this enough? I'm seeing that with --enable-debug only the
> option -g is passed to the compiler and the option -O2 is
> still there, is it not better compile with -O0 if you are
> going
Tom Lane wrote:
Associating such a thing with spinlocks seems certain to be a dead loss,
as the amount of time we normally hold a spinlock is much less than the
time to make one kernel call, let alone two.
Yeah, I was thinking about this. ISTM the only way that Sun would bother
to provide an API l
Neil Conway <[EMAIL PROTECTED]> writes:
> Speaking of improving spinlock behavior, there's a Solaris API that I
> think might be worth using: schedctl_start() asks the scheduler to not
> pre-empt the current process, and schedctl_stop() cancels the request.
> The idea the first extremely short p
Christopher Kings-Lynne wrote:
in order to debug "step by step" the postmaster,
just to understand better the code, is it enough
to compile it after having exported:
CFLAGS='-O0 -g' ?
do you have any hint and/or tips ?
BTW what do you use for this task ?
./configure --enable-debug
Is this enough?
Tom Lane wrote:
But yes, a yield primitive would be nice, and so would knowing the
number of CPUs.
I'm planning on submitting a patch shortly that determines the number of
CPUs in the machine and adjusts the spinlock behavior accordingly (there
are various APIs for getting the # of CPUs, like sys
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
> But it can contain newer blocks than WAL records would expect.
> Will it not matter if e.g. a page split for a btree index is already in the
> index file, but a WAL record exists, that references the not yet split page?
No. This is not dif
Bruce Momjian <[EMAIL PROTECTED]> writes:
> TODO entry?
* Merge hardwired timezone names with the TZ database; allow either kind
everywhere a TZ name is currently taken
* allow customization of the known set of TZ names (generalize the
present australian_timezones hack)
I'm not sure whether w
Daniel Kalchev <[EMAIL PROTECTED]> writes:
> (found out 7.2.3 does not have pg_database)
You think not?
> By the way, I had to copy over the 'new' files from pg_clog and pg_xlog (this
> is the second possible error) to get the postmaster running.
That was *not* part of the recipe, and is guarant
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
> I guess it could still save some CPU cycles in the single CPU case,
> if you yield() instead of tight loop around TAS in the failure case.
> Problem is yield and detecting single CPU is not portable.
Sure, but that's still a spinlock --- yo
Richard Huxton <[EMAIL PROTECTED]> writes:
> ... Don't forget having to deal with a backend dying without being able to
> decrement the count (not my idea, Bruce (iirc) mentioned it last time
> this was discussed). I think at the least you'd need a
> max-trans-id-with-lock number stored next to
TODO entry?
---
Tom Lane wrote:
> Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> > With the new timezone stuff, is there any reason this shouldn't be made
> > to work now in CVS:
> > test=# select current_timestamp a
Christopher Kings-Lynne wrote:
> > I think the speed complaint I was just raising could possibly be
> > answered by setting an infomask bit indicating that the row might
> > be present in a separate table of active row locks. (I'm not sure
> > how the bit would get cleared without race conditions,
Richard Huxton wrote:
> Christopher Kings-Lynne wrote:
> >> Uh ... the interesting question is usually not "does this backend hold
> >> any row locks", it is "is this row locked by any backends". If the
> >> latter question is not *exceedingly* cheap to answer, at least in the
> >> normal case whe
Tom I did the following:
(found out 7.2.3 does not have pg_database)
1. saved old data etc.
2. created new database, and the database. database oid was 16556;
3. moved data/global to the old data directory.
4. though, that postmaster would actually use the database oid to locate the
directory
Ah, you said 'is NOT missing'.
Chris
Daniel Kalchev wrote:
data/base/global is missing and this is where postgres gets all it's startup
data from (database oids, next oid, transaction id etc).
Let's see how easy to recover from this it will turn to be.
Daniel
Christopher Kings-Lynne said:
> If
data/base/global is missing and this is where postgres gets all it's startup
data from (database oids, next oid, transaction id etc).
Let's see how easy to recover from this it will turn to be.
Daniel
>>>Christopher Kings-Lynne said:
> If you're not missing your data dir, clog or xlog then wha
> Re-thinking the whole purpose of the additional full page images appended to
> the xlog records, I now understand and agree with Tom's comment in the docs
> that we don't need to include those additional full page images for PITR -
> they only exist to correctly recover the database in the event
> >> Think harder... one processor != one process...
>
> > Well sure, but you don't want a spinlock in that case.
>
> Actually you do, when the normal case is that you don't have to block.
> You want it to fall through as quickly as possible in the success case
> (the blocking case is going to s
Christopher Kings-Lynne wrote:
Uh ... the interesting question is usually not "does this backend hold
any row locks", it is "is this row locked by any backends". If the
latter question is not *exceedingly* cheap to answer, at least in the
normal case where the answer is no, you don't have a workab
> PS: but something you *could* do in 8.0 is replace "cp" by "gzip" to
> archive compressed files that way.
How about replacing the page image records with a same size dummy record
that only contains a dummy header and all 0's. If the archiver cares about
space he will use some sort of compress
I think the speed complaint I was just raising could possibly be
answered by setting an infomask bit indicating that the row might
be present in a separate table of active row locks. (I'm not sure
how the bit would get cleared without race conditions, but let's
suppose that can be done.) A little
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Gaetano Mendola
> Sent: 23 August 2004 22:41
> To: Bruce Momjian; [EMAIL PROTECTED]
> Subject: Re: [HACKERS] Interactive docs
>
>
> However I see now the right documentation in place
>
'Twas t
strk <[EMAIL PROTECTED]> writes:
> I meant scribbling actually.
> Would PG_DETOAST_DATUM_COPY() make it safe then ?
Yup, that's what it's for.
regards, tom lane
---(end of broadcast)---
TIP 1: subscribe and unsubscribe comma
Greg Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> Think harder... one processor != one process...
> Well sure, but you don't want a spinlock in that case.
Actually you do, when the normal case is that you don't have to block.
You want it to fall through as quickly a
> Bruce Momjian...
> Alvaro Herrera wrote:
> > Anyway I think we are way past feature freeze, and XLog "compression"
> > could made it into 8.1 without loss of functionality. At that point we
> > will say "now PITR uses less space on the archiver" and that's it.
> >
> > (Maybe we could even think
52 matches
Mail list logo
