Re: [HACKERS] pgbench vs. wait events

Robert, This contention on WAL reminds me of another scenario I've heard about that was similar. To fix things what happened was that anyone that the first person to block would be responsible for writing out all buffers for anyone blocked behind "him". The for example if you have many thr

Re: [HACKERS] pgbench vs. wait events

Robert, This contention on WAL reminds me of another scenario I've heard about that was similar. To fix things what happened was that anyone that the first person to block would be responsible for writing out all buffers for anyone blocked behind "him". The for example if you have many thr

Re: [HACKERS] pgbench vs. wait events

On 10/7/16 10:42 AM, Andres Freund wrote: Hi, On 2016-10-06 20:52:22 -0700, Alfred Perlstein wrote: This contention on WAL reminds me of another scenario I've heard about that was similar. To fix things what happened was that anyone that the first person to block would be responsibl

[HACKERS] PGCON meetup FreeNAS/FreeBSD: In Ottawa Tue & Wed.

constraints I can not attend the entire conference and I am only in town until Wednesday at noon. I'm hoping there's a good time to talk to a few developers about Postgresql + FreeNAS before I have to depart back to the bay area. Some info on me: My name is Alfred Perlstein, I am a FreeBSD

[HACKERS] Question about durability and postgresql.

Hello, We have a combination of 9.3 and 9.4 databases used for logging of data. We do not need a strong durability guarantee, meaning it is ok if on crash a minute or two of data is lost from our logs. (This is just stats for our internal tool). I am looking at this page: http://www.postgres

[HACKERS] Question about durability and postgresql.

Hello, We have a combination of 9.3 and 9.4 databases used for logging of data. We do not need a strong durability guarantee, meaning it is ok if on crash a minute or two of data is lost from our logs. (This is just stats for our internal tool). I am looking at this page: http://www.postgresq

Re: [HACKERS] Why we lost Uber as a user

On 7/28/16 4:39 AM, Geoff Winkless wrote: On 28 Jul 2016 12:19, "Vitaly Burovoy" > wrote: > > On 7/28/16, Geoff Winkless > wrote: > > On 27 July 2016 at 17:04, Bruce Momjian > wrote: > > > >> Well, their bi

Re: [HACKERS] Why we lost Uber as a user

On 7/28/16 7:08 AM, Merlin Moncure wrote: *) postgres may not be the ideal choice for those who want a thin and simple database This is a huge market, addressing it will bring mindshare and more jobs, code and braintrust to psql. -Alfred -- Sent via pgsql-hackers mailing list (pgsql-hacke

Re: [HACKERS] Why we lost Uber as a user

On 7/26/16 9:54 AM, Joshua D. Drake wrote: Hello, The following article is a very good look at some of our limitations and highlights some of the pains many of us have been working "around" since we started using the software. https://eng.uber.com/mysql-migration/ Specifically: * Ineffic

Re: [HACKERS] Why we lost Uber as a user

> On Aug 2, 2016, at 2:33 AM, Geoff Winkless wrote: > >> On 2 August 2016 at 08:11, Alfred Perlstein wrote: >>> On 7/2/16 4:39 AM, Geoff Winkless wrote: >>> I maintain that this is a nonsense argument. Especially since (as you >>> pointed out and

Re: [HACKERS] Why we lost Uber as a user

On 8/2/16 2:14 PM, Tom Lane wrote: Stephen Frost writes: With physical replication, there is the concern that a bug in *just* the physical (WAL) side of things could cause corruption. Right. But with logical replication, there's the same risk that the master's state could be fine but a repl

Re: [HACKERS] Why we lost Uber as a user

> On Aug 3, 2016, at 3:29 AM, Greg Stark wrote: > >> > > Honestly the take-away I see in the Uber story is that they apparently > had nobody on staff that was on -hackers or apparently even -general > and tried to go it alone rather than involve experts from outside > their company. As a resu

Re: [HACKERS] Why we lost Uber as a user

On 8/4/16 2:00 AM, Torsten Zuehlsdorff wrote: On 03.08.2016 21:05, Robert Haas wrote: On Wed, Aug 3, 2016 at 2:23 PM, Tom Lane wrote: Robert Haas writes: I don't think they are saying that logical replication is more reliable than physical replication, nor do I believe that to be true. I

Re: [HACKERS] Why we lost Uber as a user

On 8/2/16 10:02 PM, Mark Kirkwood wrote: On 03/08/16 02:27, Robert Haas wrote: Personally, I think that incremental surgery on our current heap format to try to fix this is not going to get very far. If you look at the history of this, 8.3 was a huge release for timely cleanup of dead tuple.

Re: [HACKERS] Why we lost Uber as a user

On 8/3/16 3:29 AM, Greg Stark wrote: Honestly the take-away I see in the Uber story is that they apparently had nobody on staff that was on -hackers or apparently even -general and tried to go it alone rather than involve experts from outside their company. As a result they misdiagnosed their

Re: [HACKERS] 7.1 vacuum

how's > that for all of the vacuum? > > An 7.0.3 db we have here we are forced to run vacuum every hour to get an > acceptable speed, and while doing that vacuum (5-10 minutes) it totaly > blocks our application that's mucking with the db. http://people.freebsd.org/~alfr

[HACKERS] Re: 7.1 vacuum

* mlw <[EMAIL PROTECTED]> [010427 05:50] wrote: > Alfred Perlstein wrote: > > > > * Magnus Naeslund(f) <[EMAIL PROTECTED]> [010426 21:17] wrote: > > > How does 7.1 work now with the vacuum and all? > > > > > > Does it go for indexes by defaul

Re: [HACKERS] Re: SAP-DB

ut is something that does miniscule part X of massive part Y and by then you're too engrossed to write a little banner for the file or dir explaining what it's for and incorrectly assume that even if you did, it wouldn't help that user unless he went through the same painful steps that

Re: [HACKERS] Thanks, naming conventions, and count()

flat file is in the form of: 123456;"tablename " 33;"another_table " ie, each line is a fixed length. -- -Alfred Perlstein - [[EMAIL PROTECTED]] Daemon News Magazine in your snail-mail! http://magazine.daemonnews.org

Re: [HACKERS] Thanks, naming conventions, and count()

ly doubt that an automated method > for exporting the mapping would be worth the cycles it would cost, > even if it could be made reliable which it can't. Perhaps an external tool to rebuild the symlink state that could be run on an offline database. But I'm sure you have more impo

[HACKERS] COPY commands could use an enhancement.

e the feilds in the tables in different orders. Basically: COPY "webmaster" FROM stdin; could become: COPY "webmaster" FIELDS "id", "name", "ssn" FROM stdin; this way when sourcing it would know where to place the feilds. -- -Alfred Perlstein -

Re: [HACKERS] COPY commands could use an enhancement.

* Tom Lane <[EMAIL PROTECTED]> [010430 08:37] wrote: > Alfred Perlstein <[EMAIL PROTECTED]> writes: > > It would be very helpful if the COPY command could be expanded > > in order to provide positional parameters. > > I think it's a bad idea to try to expa

Re: [HACKERS] 7.1 startup recovery failure

f attempts to solve the trouble or debug. > You run your database over NFS? They must be made of steel. :) -- -Alfred Perlstein - [[EMAIL PROTECTED]] Daemon News Magazine in your snail-mail! http://magazine.daemonnews.org/ ---(end of broadcast)---

Re: [HACKERS] New Linux xfs/reiser file systems

er, if the user is able to use the O_FSYNC option rather than fsync he may see a performance increase. But his guess is probably nearly as good as mine. :) -- -Alfred Perlstein - [[EMAIL PROTECTED]] http://www.egr.unlv.edu/~slumos/on-netbsd.html ---(end of broadcast)

Re: [HACKERS] New Linux xfs/reiser file systems

pending meta-data to be updated (even metadata not related to the postgresql files). Do you know if reiser or xfs have this problem? -- -Alfred Perlstein - [[EMAIL PROTECTED]] Daemon News Magazine in your snail-mail! http://magazine.daemonnews.org/ ---(end of broadcas

Re: [HACKERS] elog(LOG), elog(DEBUG)

optionally sending DEBUG output to the frontend, as has > been requested a few times. INFO makes sense as afaik it maps to syslog. -- -Alfred Perlstein - [[EMAIL PROTECTED]] Daemon News Magazine in your snail-mail! http://magazine.daemonnews.org/ ---(end of broadc

Utilizing "direct writes" Re: [HACKERS] File system performance and pg_xlog

r: it _was_ > big on OS'es and fs' in year 1990. Today's fs are lot of > better and there should be a os/fs combo that is 95% perfect. Well, here's an idea, has anyone tried using the "direct write" interface that some OS's offer? I doubt FreeBSD d

Re: [HACKERS] 7.0.2 crash (maybe linux kernel bug??)

le to handle kernel NULL pointer dereference at virtual address 0100 Yes, your kernel basically segfaulted, I would get a traceback from your crashdump and discuss it with the kernel developers. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I k

[HACKERS] Query cache import?

I never saw much traffic regarding Karel's work on making stored proceedures: http://people.freebsd.org/~alfred/karel-pgsql.txt What happened with this? It looked pretty interesting. :( -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I ke

Re: [HACKERS] Query cache import?

* Karel Zak <[EMAIL PROTECTED]> [001031 16:18] wrote: > > On Tue, 31 Oct 2000, Alfred Perlstein wrote: > > > I never saw much traffic regarding Karel's work on making stored > > proceedures: > > > > http://people.freebsd.org/~alfred/karel-pgsql.txt

Re: [HACKERS] VACUUM causes violent postmaster death

fix should be in the latest 7.0.2-patches/7.0.3 release. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk."

Re: [HACKERS] VACUUM causes violent postmaster death

mmands/vacuum.c is at: revision 1.148.2.1 date: 2000/09/19 21:01:04; author: tgl; state: Exp; lines: +37 -19 Back-patch fix to ensure that VACUUM always calls FlushRelationBuffers. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk."

Re: [HACKERS] Alpha FreeBSD port of PostgreSQL !!!

here I faltered when initially trying to compile on FreeBSD. I have access to a FreeBSD box through the FreeBSD project and would like to have another shot at it, but I was hoping one of the guys more initmate with autoconf could lend me a hand. thanks, -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL

[HACKERS] Re: [GENERAL] Query caching

TECTED]> Implemented stored proceedures for postgresql but still hasn't been approached to integrated them. You can find his second attempt to get a response from the developers here: http://people.freebsd.org/~alfred/karel-pgsql.txt -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk."

Re: [HACKERS] Restricting permissions on Unix socket

n(2) then > there's a race condition, but doing savegid; create socket; restoregid > might be too awkward? Any hints? Set your umask to 777 then go to town. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk."

[HACKERS] 7.0.2 dies when connection dropped mid-transaction

x0, 0x0, 0x0, 0x0}} (gdb) print pointer $3 = 0x84e0018 "" These sources are the current CVS sources with the exception of some removed files by Marc. Is there any more information I can provide? -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk."

Re: [HACKERS] 7.0.2 dies when connection dropped mid-transaction

* Alfred Perlstein <[EMAIL PROTECTED]> [001109 17:07] wrote: > I have a program that does a: > DECLARE getsitescursor CURSOR FOR select... > > I ^C'd it and it didn't properly shut down the channel to > postgresql and I got this crash: [snip] > These source

Re: [HACKERS] 7.0.2 dies when connection dropped mid-transaction

3. > Comments? I dunno, having the database crash because a errant client disconnected without shutting down, or needed to abort a transaction looks like a show stopper. We do track CVS and wouldn't have a problem shifting to 7_0_3_PATCHES, but I'm not sure if the rest of the userbase i

Re: [HACKERS] 7.0.2 dies when connection dropped mid-transaction

to crash the backend by just dropping a connection during a pretty trivial query is a bad thing and it'd be more prudent to wait. I have no problem syncing with your guys CVS, but people using redhat RPMS and FreeBSD Packages are going to wind up with this bug if you cut the release before sq

Re: [HACKERS] 7.0.2 dies when connection dropped mid-transaction

info to > the WWW site, followed by putting out an official announcement ... > > Great work, as always :) Tom rules. *thinking freebsd port should add user tgl rather than pgsql* :) -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk."

Re: [HACKERS] RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)

s the power while the OS in the midst of fsync, will all be ok? -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk."

Re: [HACKERS] 7.0.2 dies when connection dropped mid-transaction

info to > the WWW site, followed by putting out an official announcement ... > > Great work, as always :) Just wanted to confirm that we haven't experianced the bug since we've applied Tom's patch several days ago. thanks for the excellent work! -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk."

Re: [HACKERS] cygwin gcc problem.

* Gary MacDougall <[EMAIL PROTECTED]> [00 11:28] wrote: > I'm trying to compile postgresql on Windows 2000. I've followed the directions >accordingly. > > When I run the "configure" script, and I get the following error message: > > > configure: error installation or configuration proble

Re: [HACKERS] RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)

ially valid one is. I haven't looked at the log structure in > any detail...) This could be fixed by using O_FSYNC on the open call for the WAL data files on *BSD, i'm not sure of the sysV equivelant, but I know it exists. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk."

Re: [HACKERS] 486 Optimizations...

; > univel:CFLAGS='-v -O -K i486,host,inline,loop_unroll -Dsvr4' > $ pwd > /home/ler/pg-dev/pgsql/src/template > $ I have a patch pending for FreeBSD to support alpha builds that also disables -m486 so if you left the freebsd template alone it would be ok. -- -Alfred Perlstein -

Re: [HACKERS] 486 Optimizations...

86) CFLAGS="$CFLAGS -m486";; > > freebsd:CFLAGS='-O2 -m486 -pipe' > > univel:CFLAGS='-v -O -K i486,host,inline,loop_unroll -Dsvr4' > > Why would you want to? Not all gccs support -mpentium/mpentiumpro etc. The idea is to remove it entirely (I

Re: [HACKERS] 486 Optimizations...

* Larry Rosenman <[EMAIL PROTECTED]> [001114 13:47] wrote: > * Alfred Perlstein <[EMAIL PROTECTED]> [001114 15:46]: > > * Larry Rosenman <[EMAIL PROTECTED]> [001114 13:42] wrote: > > > Anyone care if I build a patch to kill the -m486 type options in the > &

[HACKERS] IRC?

I remeber a few developers used to gather on efnet irc, there was a lot of instability recently that seems to have cleared up even more recently. Are you guys planning on coming back? Or have you all moved to a different network? -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED

Re: One more [HACKERS] 486 Optimizations...

re that some compilers can emit broken code when pushed to thier highest optimization levels. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk."

Re: [HACKERS] RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)

ptimized in the library > to just return? sleep(3) should conform to POSIX specification, if anyone has the reference they can check it to see what the effect of sleep(0) should be. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk."

Re: [HACKERS] location of Unix socket

thing? :) It would make more sense to fix tempreaper to ignore non regular files. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk."

Re: [HACKERS] RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)

me better fsync me. b) anyone updating me better fsync me as well as fsyncing anything else they touch. I swear one of these days I'm going to get more familiar with the codebase and actually submit some useful patches for the backend. :( -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]

Re: [HACKERS] 486 Optimizations...

till has a market niche, and they are actively porting to more platforms. > > I do feel more strongly about removing '-pipe', but it's not something I'm > going to pursue. Why? -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk."

Re: [HACKERS] Alpha FreeBSD port of PostgreSQL !!!

* Peter Eisentraut <[EMAIL PROTECTED]> [001103 16:16] wrote: > Alfred Perlstein writes: > > > Part of the problem is that Postgresql assumes FreeBSD == -m486, > > If that's all then go into src/template/freebsd and remove it. ok, thanks for the pointer, I'

Re: [HACKERS] RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)

this 1/200 second delay for every transaction. Seems > bad to me. I think as long as it becomes a tunable this isn't a bad idea at all. Fixing it at 1/200 isn't so great because people not wrapping large amounts of inserts/updates with transaction blocks will suffer. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk."

Re: [HACKERS] RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)

unning. > > > > This sounds like an interesting approach, yes. > > In OS kernel design, you try to avoid process herding bottlenecks. > Here, we want them herded, and giving up the CPU may be the best way to > do it. Yes, but if everyone yeilds you're back where you sta

Re: [HACKERS] RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)

* Tom Lane <[EMAIL PROTECTED]> [001116 13:31] wrote: > Alfred Perlstein <[EMAIL PROTECTED]> writes: > > It might make more sense to keep a private copy of the last time > > the file was modified per-backend by that particular backend and > > a timestamp of the

Re: [HACKERS] RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)

nc if "it hasn't been dirtied by me since the last fsync" This would provide a rendevous point for the fsync call although cost more as one would need to periodically call gettimeofday to set the modified by me timestamp as well as the post-fsync shared timestamp. -- -Alfred Perlste

Re: [HACKERS] Re: LOCK Fixes/Break on FreeBSD 4.2-STABLE

until > tonite. > > I can make you an account on the box if you'd like My signifigant other just installed a fresh copy of 4.2 last night, unfortunetly the poor box is only a 233mhz, it'll be a while before we build -stable on it. However I'm confident I can have a fix within a couple of days. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk."

Re: [HACKERS] Initdb not running on beos

Afaik the atomicity of rename() (the same as a link()/unlink() pair) is specified by POSIX. Sorry for jumping in late in the thread, but rename() sure sounds a lot better than a link()/unlink() pair, but I'm probably taking it out of context. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk."

Re: [HACKERS] Re: LOCK Fixes/Break on FreeBSD 4.2-STABLE

x27;s possible to forget about a computer... http://people.freebsd.org/~alfred/images/lab.jpg :) -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk."

Re: [HACKERS] COPY BINARY is broken...

pro or con about that? BINARY COPY scared the bejeezus out of me, anyone using the interface is asking for trouble and supporting it seems like a nightmare, I would rip it out. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk."

Re: [HACKERS] COPY BINARY is broken...

* Tom Lane <[EMAIL PROTECTED]> [001201 14:57] wrote: > Alfred Perlstein <[EMAIL PROTECTED]> writes: > > I would rip it out. > > I thought about that too, but was afraid to suggest it ;-) I think you'd agree that you have more fun and important things to do than t

Re: [HACKERS] Re: LOCK Fixes/Break on FreeBSD 4.2-STABLE

s/src/usr.bin/fstat/fstat.c,v retrieving revision 1.21.2.2 diff -u -r1.21.2.2 fstat.c --- usr.bin/fstat/fstat.c 2000/07/02 10:28:38 1.21.2.2 +++ usr.bin/fstat/fstat.c 2000/12/04 20:01:08 @@ -66,8 +66,8 @@ #include #include #include -#undef _KERNEL #include +#undef _KERNEL #include #include #include -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk."

[HACKERS] Spinlocks may be broken.

osed to be protected by the lock not getting flushed out to main memory until possibly after the unlock happens. I'm pretty sure you guys need memory barrier ops. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk."

[HACKERS] Need help with phys backed shm segments (Postgresql+FreeBSD).

0048048) -> 0 tas (0x3004804d) -> 0 tas (0x3004804c) -> 0 S_UNLOCK: (0x30048048) -> 1 tas (0x30048048) -> 0 S_UNLOCK: (0x3004804c) -> 1 S_UNLOCK: (0x3004804d) -> 1 S_UNLOCK: (0x30048048) -> 1 tas (0x30048048) -> 0 tas (0x3004804d) -> 4 tas (0x3004804d) -> 1 tas (0x3004804d) -> 1 tas (0x3004804d) -> 1 tas (0x3004804d) -> 1 tas (0x3004804d) -> 1 tas (0x3004804d) -> 1 tas (0x3004804d) -> 1 repeats (it's stuck) -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk."

Re: [HACKERS] Re: LOCK Fixes/Break on FreeBSD 4.2-STABLE

* Tom Lane <[EMAIL PROTECTED]> [001205 07:14] wrote: > Alfred Perlstein <[EMAIL PROTECTED]> writes: > > Anyhow, to address the problem I've removed struct mount from > > userland visibility in both FreeBSD 5.x (current) and FreeBSD 4.x > > (stable). > &g

Re: [HACKERS] Spinlocks may be broken.

* Tom Lane <[EMAIL PROTECTED]> [001205 07:24] wrote: > Alfred Perlstein <[EMAIL PROTECTED]> writes: > > I'm pretty sure you guys need memory barrier ops. > > On a machine that requires such a thing, the assembly code for UNLOCK > should include it. Want t

Re: [HACKERS] Need help with phys backed shm segments (Postgresql+FreeBSD).

* Tom Lane <[EMAIL PROTECTED]> [001205 07:43] wrote: > Alfred Perlstein <[EMAIL PROTECTED]> writes: > > Here's the log, the number in parens is the address of the lock, > > on tas() the value printed to the right is the value in _ret, > > for the others, i

Re: [HACKERS] Need help with phys backed shm segments (Postgresql+FreeBSD).

you are seeing some bug in FreeBSD's handling of tiny shm > segments? Good call, i think I found it! :) -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk."

Re: [HACKERS] beta testing version

ersion of Postgresql. We can also look at it another way, let's say ER server was meant to be closed source, if the code it was derived from was GPL'd then that chance was gone before it even happened. Hence no reason to develop it. *poof* no ER server. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk."

Re: [HACKERS] Need help with phys backed shm segments (Postgresql+FreeBSD).

* Alfred Perlstein <[EMAIL PROTECTED]> [001205 12:30] wrote: > * Tom Lane <[EMAIL PROTECTED]> [001205 08:37] wrote: > > BTW, I just remembered that in 7.0.*, the SLocks that are managed by > > SpinAcquire() all live in their own little shm segment. On a machine >

[HACKERS] Re: Sorry

* Randy Jonasz <[EMAIL PROTECTED]> [001205 14:31] wrote: > > Sorry about that email. I was trying to forward your comments to a friend > and due to a lack of sleep I just typed "R" in pine. Doh! That's ok, you work with Dan Moschuk right? -- -Alfred Perlste

Re: [HACKERS] Need help with phys backed shm segments (Postgresql+FreeBSD).

e performance problems because of the amount of swap structures needed per-process to manage swappable segments. I'm going to be enabling this on one of our boxes and see if it makes a noticeable difference. I'll let you guys know. > > Date: Tue, 5 Dec 2000 13:04:45 -0800 >

[HACKERS] Patches with vacuum fixes available for 7.0.x

tches are for 7.0.x I'm hoping that they can be forward ported (if Vadim hasn't done it already) to 7.1. enjoy! -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk."

[HACKERS] abstract: fix poor constant folding in 7.0.x, fixed in 7.1?

- const - const const then eval the query. You may want to allow a function to have a hook where it can eval a const because depending on the const it may or may not be able to return a const, for instance if some str

Re: [HACKERS] abstract: fix poor constant folding in 7.0.x, fixed in 7.1?

'24 hours'::timespan > > to: > > '2000-12-07 14:27:24-08'::timestamp > > You mean '2000-12-06', don't you? Yes, typo. :) > > > Each function should have a marker that explains whether when given a > > const input if the

Re: [HACKERS] abstract: fix poor constant folding in 7.0.x, fixed in 7.1?

* Tom Lane <[EMAIL PROTECTED]> [001207 16:45] wrote: > Alfred Perlstein <[EMAIL PROTECTED]> writes: > > Each function should have a marker that explains whether when given > > a const input if the output might vary, that way subexpressions can > > be collapsed

Re: [HACKERS] Patches with vacuum fixes available for 7.0.x

* Tom Lane <[EMAIL PROTECTED]> [001207 17:10] wrote: > Alfred Perlstein <[EMAIL PROTECTED]> writes: > > Basically Vadim has been able to reduce the amount of time > > taken by a vacuum from 10-15 minutes down to under 10 seconds. >

Re: [HACKERS] Patches with vacuum fixes available for 7.0.x

* Tom Samplonius <[EMAIL PROTECTED]> [001207 18:55] wrote: > > On Thu, 7 Dec 2000, Alfred Perlstein wrote: > > > We recently had a very satisfactory contract completed by > > Vadim. > > > > Basically Vadim has been able to reduce the amount of time > &

Re: [HACKERS] Re: CRC

t certainly loaded into level-2 > cache memory. Curious that you don't get the same result --- what is > the memory cache architecture on your box? > > As Nathan remarks nearby, this is just minutiae, but I'm interested > anyway... I would try unrolling the loop some (if possible) and retesting. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk."

[HACKERS] (one more time) Patches with vacuum fixes available.

rwarded message from Alfred Perlstein <[EMAIL PROTECTED]> ----- From: Alfred Perlstein <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: [HACKERS] Patches with vacuum fixes available for 7.0.x Date: Thu, 7 Dec 2000 14:57:32 -0800 Message-ID: <[EMAIL PROTECTED]> User-Agent: Mut

Re: [HACKERS] (one more time) Patches with vacuum fixes available.

* The Hermit Hacker <[EMAIL PROTECTED]> [001211 14:27] wrote: > On Mon, 11 Dec 2000, Bruce Momjian wrote: > > > > Alfred Perlstein <[EMAIL PROTECTED]> writes: > > > > Basically Vadim left it up to me to campaign for acceptance of this > > > > w

Re: [HACKERS] (one more time) Patches with vacuum fixes available .

xx] -rw--- 1 pgsql wheel 273670144 Dec 11 22:15 link -rw--- 1 pgsql wheel 641048576 Dec 11 22:15 link_triple_idx time is ~19seconds, table is 273 megs, and index 641 megs. dual 800mhz, raid 5 disks. I think the users deserve this patch. :) -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk."

Re: [HACKERS] Why vacuum?

you're having problems because vacuum locks up your tables for too long you might want to check out: http://people.freebsd.org/~alfred/vacfix/ It has some tarballs that have patches to speed up vacuum depending on how you access your tables you can see up to a 20x reduction in vacuum time. --

Re: [HACKERS] Idea for reducing planning time

it over the current code? 2x? 3x? 20x? :) There's a difference between a slight performance increase and something too good to pass up. thanks, -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk."

Re: [HACKERS] Why vacuum?

* xuyifeng <[EMAIL PROTECTED]> [001213 18:54] wrote: > I have this nasty problem too, in early time, I don't know the problem, but we used >it for a while, > than we found our table growing too fast without insert any record( we use update), >this behaviour > most like M$ MSACCESS database I h

Re: [HACKERS] Why vacuum?

make vacuum optional such that it either: 1) always overwrites 2) will not overwrite data until a vacuum is called (perhaps with a date option to specify how much deleted data you wish to reclaim) data can be marked free but not free for re-use until vacuum is run. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk."

Re: [HACKERS] Why vacuum?

(high > > volume modified table) your system won't work > > Why ? I have plenty of CPU time available on my server, even if one of > my table is highly volatile, fast-changing. When your table grows to be very large you'll see what we're talking about. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk."

Re: [HACKERS] Why vacuum?

like Postgres to perform statistics, one and a while, on > it own. I like vacuum in general. > > I would rather trade unused disk space for performace. The last thing > you need during high loads is the database thinking that it is time to > clean up. Even worse is having to scan a fil

Re: [HACKERS] Idea for reducing planning time

so we had the patch handy, and it made sense to post it. Now > that we have remote cvs, we don't do it as much, but in this case, cvs > diff -c is a big help. It seems that Tom has committed his fixups but we're still waiting on Vadim? -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]

[HACKERS] externalizing PGresult?

Is there anything for encoding a PGresult struct into something I can pass between processes? Like turning it into a platform independant stream that I can pass between machines? -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar

Re: [HACKERS] Unable to check out REL7_1 via cvs

g. > cvs [server aborted]: cannot write /home/projects/pgsql/cvsroot/CVSROOT/val-tags: >Permission denied > > I can check out HEAD perfectly alright > > Anybody else seeing similar results ? Try using "cvs -Rq ..." or just use CVSup it's (cvsup) a lot quicker. -- -Al

Re: [HACKERS] Unable to check out REL7_1 via cvs

* Yusuf Goolamabbas <[EMAIL PROTECTED]> [001222 15:47] wrote: > Nope, no luck with cvs -Rq also. Me thinks its some repository > permission issue. Don't know if CVSup would help either. I don't have > cvsup installed on this machine. CVSup would work, that's what

Re: [HACKERS] GNU readline and BSD license

i/man.cgi?query=editline&apropos=0&sektion=0&manpath=FreeBSD+4.2-RELEASE&format=html -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk."

Re: [HACKERS] Re: Too many open files (was Re: spinlock problems reported earlier)

forms. getdtablesize(2) on BSD should tell you the per-process limit. sysconf on FreeBSD shouldn't lie to you. getdtablesize should take into account limits in place. later versions of FreeBSD have a sysctl 'kern.openfiles' which can be checked to see if the system is approach

Re: [HACKERS] Upper limit on number of buffers?

27;m just going to guess that you need to consult your OS's documentation and figure out how to raise the amount of system V shared memory available. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk."

Re: [HACKERS] Assuming that TAS() will succeed the first time is verboten

s on another CPU and spinning might be benificial. One trick that may help is calling sched_yield(2) on a lock miss, it's a POSIX call and quite new so you'd need a 'configure' test for it. http://www.freebsd.org/cgi/man.cgi?query=sched_yield&apropos=0&sektion=0&ma

Re: [HACKERS] GNU readline and BSD license

> "feature" ... > > My thought would be to put 'make history feaure standard using libedit' > onto the TODO list and take it from there ... I doubt I'd have the time to do it, but if you guys want to use libedit it'd probably be a good idea at least to red

Re: [HACKERS] GNU readline and BSD license

permits linking without lincense issues, it is GPL which means that if you link to it, you must be GPL as well. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk."

  1   2   3   >