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 responsible

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

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

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] 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

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

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

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

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

> On Aug 2, 2016, at 2:33 AM, Geoff Winkless <pgsqlad...@geoff.dj> wrote: > >> On 2 August 2016 at 08:11, Alfred Perlstein <alf...@freebsd.org> wrote: >>> On 7/2/16 4:39 AM, Geoff Winkless wrote: >>> I maintain that this is a nonsense argument. Especial

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: *

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

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

[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:

[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:

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

:01 PM, Alfred Perlstein wrote: We also have colo space and power, etc. So this would be the whole deal. The cluster would be up for as long as needed. Are the machine specs sufficient? Any other things we should look for? CC'd Tom on this email. Did anyone respond to this off-list

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On 4/22/14, 8:26 AM, Andrew Dunstan wrote: On 04/22/2014 01:36 AM, Joshua D. Drake wrote: On 04/21/2014 06:19 PM, Andrew Dunstan wrote: If we never start we'll never get there. I can think of several organizations that might be approached to donate hardware. Like .Org? We have a

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On 4/21/14 4:10 AM, Andres Freund wrote: Hi, On 2014-04-20 11:24:38 +0200, Palle Girgensohn wrote: I see performance degradation with PostgreSQL 9.3 vs 9.2 on FreeBSD, and I'm wondering who to poke to mitigate the problem. In reference to this thread [1], who where the FreeBSD people that

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On 4/21/14 8:45 AM, Andrew Dunstan wrote: On 04/21/2014 11:39 AM, Magnus Hagander wrote: On Mon, Apr 21, 2014 at 4:51 PM, Andres Freund and...@2ndquadrant.com mailto:and...@2ndquadrant.com wrote: On 2014-04-21 10:45:24 -0400, Tom Lane wrote: Andres Freund and...@2ndquadrant.com

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On 4/21/14 8:58 AM, Tom Lane wrote: Andres Freund and...@2ndquadrant.com writes: On 2014-04-21 11:45:49 -0400, Andrew Dunstan wrote: That seems to make more sense. I can't imagine why this would be a runtime parameter as opposed to build time. Because that implies that packagers and porters

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On 4/21/14 9:13 AM, Stephen Frost wrote: * Alfred Perlstein (alf...@freebsd.org) wrote: Can the package builder not set the default for the runtime tunable? Yeah, I was thinking about that also, but at least in this case it seems pretty clear that the 'right' answer is known at build time

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On 4/21/14 9:24 AM, Andrew Dunstan wrote: On 04/21/2014 11:59 AM, Alfred Perlstein wrote: On 4/21/14 8:45 AM, Andrew Dunstan wrote: On 04/21/2014 11:39 AM, Magnus Hagander wrote: On Mon, Apr 21, 2014 at 4:51 PM, Andres Freund and...@2ndquadrant.com mailto:and...@2ndquadrant.com wrote

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On 4/21/14 9:34 AM, Stephen Frost wrote: * Alfred Perlstein (alf...@freebsd.org) wrote: There is definitely hope, however changes to the FreeBSD vm are taken as seriously as changes to core changes to Postresql's store. In addition changes to vm is somewhat in the realm of complexity

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On 4/21/14 9:38 AM, Andrew Dunstan wrote: On 04/21/2014 12:25 PM, Alfred Perlstein wrote: 1. OS developers are not the target audience for GUCs. If the OS developers want to test and can't be botherrd with building with a couple of different parameters then I'm not very impressed. 2

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

wether anon mmap() or sysv shmem is to be used. In 9.3. Greetings, Andres Freund Andres, thank you. Speaking as a FreeBSD developer that would be a good idea. -- Alfred Perlstein -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On 4/21/14, 9:51 AM, Andrew Dunstan wrote: On 04/21/2014 12:44 PM, Alfred Perlstein wrote: On 4/21/14 9:38 AM, Andrew Dunstan wrote: On 04/21/2014 12:25 PM, Alfred Perlstein wrote: 1. OS developers are not the target audience for GUCs. If the OS developers want to test and can't

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On 4/21/14, 9:51 AM, Andres Freund wrote: On 2014-04-21 09:42:06 -0700, Alfred Perlstein wrote: Sure, to be fair, we are under the gun here for a product, it may just mean that the end result of that conversation is mysql. Personally arguments in that vain are removing just about any

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On 4/21/14, 9:52 AM, Alvaro Herrera wrote: Alfred Perlstein wrote: I am unsure of the true overhead of making this a runtime tunable so pardon if I'm asking for a lot. From the perspective of both an OS developer and postgresql user (I am both) it really makes more sense to have it a runtime

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On 4/21/14, 11:14 AM, Stephen Frost wrote: Alfred, * Alfred Perlstein (alf...@freebsd.org) wrote: On 4/21/14, 9:51 AM, Andres Freund wrote: On 2014-04-21 09:42:06 -0700, Alfred Perlstein wrote: Sure, to be fair, we are under the gun here for a product, it may just mean that the end result

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On 4/21/14, 12:47 PM, Stephen Frost wrote: Asking for help to address the FreeBSD performance would have been much better received. Thanks, Stephen That is exactly what I did, I asked for a version of postgresql that was easy to switch at runtime between two behaviors. That would make

Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On 4/21/14, 2:23 PM, Stephen Frost wrote: Alfred, * Alfred Perlstein (alf...@freebsd.org) wrote: On 4/21/14, 12:47 PM, Stephen Frost wrote: Asking for help to address the FreeBSD performance would have been much better received. Thanks, Stephen That is exactly what I did, I asked

[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 developer

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

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)--- TIP 3: if posting/reading through Usenet, please send

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

if reiser or xfs have this problem? -- -Alfred Perlstein - [[EMAIL PROTECTED]] Daemon News Magazine in your snail-mail! http://magazine.daemonnews.org/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

[HACKERS] COPY commands could use an enhancement.

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 - [[EMAIL PROTECTED]] Daemon News Magazine in your snail-mail! http

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 expand COPY into a full-tilt data import/conversion

Re: [HACKERS] Re: SAP-DB

help that user unless he went through the same painful steps that you did. Been there, done that.. er, actually, still there, mostly still doing that. :) -- -Alfred Perlstein - [[EMAIL PROTECTED]] http://www.egr.unlv.edu/~slumos/on-netbsd.html ---(end of broadcast

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

;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/ ---(end of broadcast)--- TIP 2

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

, 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 important things to do. :) -- -Alfred Perlstein - [[EMAIL PROTECTED]] Daemon News Magazine in your snail-mail! http

Re: [HACKERS] 7.1 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/~alfred/vacfix/ -- -Alfred Perlstein - [[EMAIL PROTECTED]] Instead

[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 default, even when i haven't run a vacuum at all? Does vacuum lock up

Re: [HACKERS] CVS tags for betas and release candidate

Aren't there tags for the versions I am looking for? Nope ... doing the tags didn't work as well as was hoped, so we've just been using date ranges instead ... release itself will be tag'd ... You know you can nuke tags right? -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] Daemon

Re: [HACKERS] pgindent run?

pgindent may force a contributor to resolve conflicts, while this is true, it's also true that you guys expect diffs to be in context format, comments to be in english, function prototypes to be new style, etc, etc.. I think contributors can deal with this. just my usual 20 cents. :) -- -Alfred

Re: [HACKERS] Fw: [vorbis-dev] ogg123: shared memory by mmap()

that having it pagable has a significant performance penalty. Interesting. Yes, having it pageable is actually sort of bad. It doesn't allow you to do several important optimizations. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] ---(end of broadcast

Re: [HACKERS] Final Call: RC1 about to go out the door ...

* Tom Lane [EMAIL PROTECTED] [010320 10:21] wrote: The Hermit Hacker [EMAIL PROTECTED] writes: Speak now, or forever hold your piece (where forever is the time between now and RC1 is packaged) ... I rather hope it's *NOT* And still no LAZY vacuum. *sigh* -- -Alfred Perlstein

Re: [HACKERS] Fw: [vorbis-dev] ogg123: shared memory by mmap()

TLB faults your processes will incurr. Anyhow, if you could make this a runtime option it wouldn't be so evil, but as a compile time option, it's a really bad idea for Solaris and FreeBSD. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] ---(end of

Re: [HACKERS] ODBC/FreeBSD/LinuxEmulation/RPM?

ODBC. How do I make this happen? rpm2cpio pg_rpmfile.rpm pg_rpmfile.cpio cpio -i pg_rpmfile.cpio tar xzvf pg_rpmfile.tgz -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] ---(end of broadcast)--- TIP 5: Have you checked our

Re: [HACKERS] ODBC/FreeBSD/LinuxEmulation/RPM?

* Alfred Perlstein [EMAIL PROTECTED] [010319 11:27] wrote: * Larry Rosenman [EMAIL PROTECTED] [010319 10:35] wrote: Is there any way to get just the ODBC RPM to install with OUT installing the whole DB? I have a strange situation: StarOffice 5.2 (Linux) Running under FreeBSD

Re: [HACKERS] Allowing WAL fsync to be done via O_SYNC

pretty bad. Locked bus cycles needed for mutex operations are very, very expensive, not something you want to do unless you really really need to do it. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] ---(end of broadcast)--- TIP 6

Re: [HACKERS] Allowing WAL fsync to be done via O_SYNC

* Larry Rosenman [EMAIL PROTECTED] [010318 14:17] wrote: * Tom Lane [EMAIL PROTECTED] [010318 14:55]: Alfred Perlstein [EMAIL PROTECTED] writes: Just by making a thread call libc changes personality to use thread safe routines (I.E. add mutex locking). Use one thread feature, get

Re: Re[4]: [HACKERS] Allowing WAL fsync to be done via O_SYNC

) IPC latency, the amount of time it takes to call fsync will increase by at least two context switches. 2) a working set (number of files needed to be fsync'd) that is larger than the amount of files you wish to keep open. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED

Re: Re[2]: [HACKERS] Allowing WAL fsync to be done via O_SYNC

'. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: Re[4]: [HACKERS] Allowing WAL fsync to be done via O_SYNC

* Tom Lane [EMAIL PROTECTED] [010316 08:16] wrote: Alfred Perlstein [EMAIL PROTECTED] writes: couldn't the syncer process cache opened files? is there any problem I didn't consider ? 1) IPC latency, the amount of time it takes to call fsync will increase by at least two context

Re: [HACKERS] Allowing WAL fsync to be done via O_SYNC

* Tom Lane [EMAIL PROTECTED] [010315 09:35] wrote: BTW, are there any platforms where O_DSYNC exists but has a different spelling? Yes, FreeBSD only has: O_FSYNC it doesn't have O_SYNC nor O_DSYNC. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED

Re: [HACKERS] Allowing WAL fsync to be done via O_SYNC

e could do that reasonably painlessly as a compile-time test in xlog.c, but I'm not clear on how it would play out as a GUC option. Peter, what do you think about configuration-dependent defaults for GUC variables? Sorry, what's a GUC? :) -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL

Re: [HACKERS] Allowing WAL fsync to be done via O_SYNC

* Tom Lane [EMAIL PROTECTED] [010315 11:45] wrote: Alfred Perlstein [EMAIL PROTECTED] writes: And since we're sorta on the topic of IO, I noticed that it looks like (at least in 7.0.3) that vacuum and certain other routines read files in reverse order. Vacuum does that because it's

Re: [HACKERS] Allowing WAL fsync to be done via O_SYNC

, then calling msync() on the entire range, this would allow you to batch fsync the data. The only problem is that I'm not sure: 1) how portable msync() is. 2) if msync garauntees metadata consistancy. Another benifit of mmap() is the 'zero' copy nature of it. -- -Alfred Perlstein - [[EMAIL PROTECTED

Re: [HACKERS] Allowing WAL fsync to be done via O_SYNC

* Tom Lane [EMAIL PROTECTED] [010315 14:54] wrote: Alfred Perlstein [EMAIL PROTECTED] writes: How many files need to be fsync'd? Only one. If it's more than one, what might work is using mmap() to map the files in adjacent areas, then calling msync() on the entire range, this would

Re: [HACKERS] Performance monitor signal handler

. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html

Re: [HACKERS] Performance monitor signal handler

* Philip Warner [EMAIL PROTECTED] [010315 16:46] wrote: At 16:17 15/03/01 -0800, Alfred Perlstein wrote: Lost data is probably better than incorrect data. Either use locks or a copying mechanism. People will depend on the data returned making sense. But with per-backend data

Re: [HACKERS] Performance monitor signal handler

* Philip Warner [EMAIL PROTECTED] [010315 17:08] wrote: At 16:55 15/03/01 -0800, Alfred Perlstein wrote: * Philip Warner [EMAIL PROTECTED] [010315 16:46] wrote: At 16:17 15/03/01 -0800, Alfred Perlstein wrote: Lost data is probably better than incorrect data. Either use locks

Re: Re[2]: [HACKERS] Allowing WAL fsync to be done via O_SYNC

* Xu Yifeng [EMAIL PROTECTED] [010315 22:25] wrote: Hello Tom, Friday, March 16, 2001, 6:54:22 AM, you wrote: TL Alfred Perlstein [EMAIL PROTECTED] writes: How many files need to be fsync'd? TL Only one. If it's more than one, what might work is using mmap() to map the files

Re: [HACKERS] Performance monitor signal handler

* Philip Warner [EMAIL PROTECTED] [010312 18:56] wrote: At 13:34 12/03/01 -0800, Alfred Perlstein wrote: Is it possible to have a spinlock over it so that an external utility can take a snapshot of it with the spinlock held? I'd suggest that locking the stats area might be a bad idea

Re: [HACKERS] Performance monitor signal handler

it may be a performance killer) is to have the backends update a system table that the external app can query. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] Daemon News Magazine in your snail-mail! http://magazine.daemonnews.org/ ---(end of broadcast

Re: [HACKERS] WAL SHM principles

to a driver's dma routine? -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] Daemon News Magazine in your snail-mail! http://magazine.daemonnews.org/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http

[HACKERS] Re: Performance monitor signal handler

e backends agreed on. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] Daemon News Magazine in your snail-mail! http://magazine.daemonnews.org/ ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate

Re: [HACKERS] Performance monitor signal handler

a region of the shared segment. just some ideas.. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] Daemon News Magazine in your snail-mail! http://magazine.daemonnews.org/ ---(end of broadcast)--- TIP 2: you can get off all lists

Re: [HACKERS] How to shoot yourself in the foot: kill -9 postmaster

* Tom Lane [EMAIL PROTECTED] [010306 10:10] wrote: Alfred Perlstein [EMAIL PROTECTED] writes: I'm sure some sort of encoding of the PGDATA directory along with the pids stored in the shm segment... I thought about this too, but it strikes me as not very trustworthy. The problem

Re: [HACKERS] How to shoot yourself in the foot: kill -9 postmaster

* Tom Lane [EMAIL PROTECTED] [010306 10:35] wrote: Alfred Perlstein [EMAIL PROTECTED] writes: What about encoding the shm id in the pidfile? Then one can just ask how many processes are attached to that segment? (if it doesn't exist, one can assume all backends have exited) Hmm

Re: [HACKERS] How to shoot yourself in the foot: kill -9 postmaster

* Tom Lane [EMAIL PROTECTED] [010306 11:03] wrote: Alfred Perlstein [EMAIL PROTECTED] writes: Are there any portability problems with relying on shm_nattch to be available? If not, I like this a lot... Well it's available on FreeBSD and Solaris, I'm sure Redhat has some deamon

Re: [HACKERS] How to shoot yourself in the foot: kill -9 postmaster

* Tom Lane [EMAIL PROTECTED] [010306 11:30] wrote: Alfred Perlstein [EMAIL PROTECTED] writes: * Tom Lane [EMAIL PROTECTED] [010306 11:03] wrote: I notice that our BeOS and QNX emulations of shmctl() don't support IPC_STAT, but that could be dealt with, at least to the extent of stubbing

Re: [HACKERS] How to shoot yourself in the foot: kill -9 postmaster

wondering if Linux keeps compatibility calls around for old binaries or not. Any idea? -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] How to shoot yourself in the foot: kill -9 postmaster

struct - new syscall (boom) new struct - new syscall (ok) Honestly I think this problem should be left to the vendor to fix properly (if it needs fixing), the sysV API was published at least 6 years ago, they ought to have it mostly correct by now. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL

Re: [HACKERS] How to shoot yourself in the foot: kill -9 postmaster

some grey beards (old school Unix folks) to QA the releases and keep stuff like this from happening/shipping. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http

Re: [HACKERS] How to shoot yourself in the foot: kill -9 postmaster

Alfred Perlstein [EMAIL PROTECTED] writes: Are there any portability problems with relying on shm_nattch to be available? If not, I like this a lot... Well it's available on FreeBSD and Solaris, I'm sure Redhat has some deamon that resets the value to 0 periodically just for kicks

Re: [HACKERS] How to shoot yourself in the foot: kill -9 postmaster

of consumers of a reasource. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] How to shoot yourself in the foot: kill -9 postmaster

that these processes are now children of the new postmaster? Oh, easy, use ptrace. :) -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] preproc.y error

for 7.0. byacc doesn't work, you need bison (or maybe some special flags to byacc). -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk."

Re: [HACKERS] Auto-indexing

Postgresql assumes the user knows what he's doing, but it couldn't hurt too much to provide an option to have it assist the user. -- -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: Index grows huge, possible leakage?

to be 0... With what you explained (indecies normally growing) I don't think VLAZY is the problem here. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk."

[HACKERS] Index grows huge, possible leakage?

, the space requirement is actually 'ok' it's just that performance gets terrible once the indecies reach such huge sizes. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk."

Re: [HACKERS] Sure enough, the lock file is gone

but it should work in practice. Why not have the RPM/configure scripts stick it in where ever redhat says it's safe to? -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk."

Re: [HACKERS] Libpq async issues

| (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk."

Re: [HACKERS] Libpq async issues

* Tom Lane [EMAIL PROTECTED] [010124 10:27] wrote: Alfred Perlstein [EMAIL PROTECTED] writes: * Bruce Momjian [EMAIL PROTECTED] [010124 07:58] wrote: I have added this email to TODO.detail and a mention in the TODO list. The bug mentioned here is long gone, Au contraire, the misdesign

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

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." -- Bruce Momjian

Re: [HACKERS] Does Oracle store values in indices?

manager. We hope to have it some day, hopefully soon. Vadim says that he hopes it to be done by 7.2, so if things go well it shouldn't be that far off... -- -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: [GENERAL] postgres memory management

long time the 'free' memory will probably never go higher that 10megs, the rest is being used as cache. The main things you have to worry about is: a) really running out of memory (are you useing a lot of swap?) b) not cleaning up IPC as Peter suggested. -- -Alfred Perlstein - [[EMAIL PROTECT

Re: [HACKERS] Transactions vs speed.

the writing (at least in 7.0.x) is done syncronously. There's a boatload of email out there that explains various ways to tune the system. Here's some of the flags that I use: -B 32768 # uses over 300megs of shared memory -o "-F" # tells database not to call fsync on each update -

[HACKERS] Re: Transactions vs speed.

* mlw [EMAIL PROTECTED] [010113 19:37] wrote: Alfred Perlstein wrote: * mlw [EMAIL PROTECTED] [010113 17:19] wrote: I have a question about Postgres: Take this update: update table set field = 'X' ; This is a very expensive function when the table has millions

Re: [HACKERS] Quite strange crash

of SIGTERM is used for ABORT + EXIT (pg_ctl -m fast stop), but shouldn't ABORT clean up everything? Er, shouldn't ABORT leave the system in the exact state that it's in so that one can get a crashdump/traceback on a wedged process without it trying to clean up after itself? -- -Alfred Perlstein

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

rg/~alfred/vacfix/mnmb.tgz Oops! The permissions should be fixed now, if anyone wants to grab these feel free. Peter, thanks for pointing 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] Assuming that TAS() will succeed the first time is verboten

* Bruce Momjian [EMAIL PROTECTED] [010101 23:59] wrote: Alfred Perlstein [EMAIL PROTECTED] writes: 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. The author of the current s_lock code seems

Re: [HACKERS] GNU readline and BSD license

ng 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 reduce the amount of potential GPL tainting in the source code. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED

Re: [HACKERS] GNU readline and BSD license

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."

Re: [HACKERS] GNU readline and BSD license

ely forces anyone wishing to derive a viable commercial product based on Postgresql to switch to the GPL or port to libedit anyway. If readline is completely optional then there's really no problem. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I k

Re: [HACKERS] GNU readline and BSD license

argument ... but I don't want to see us bulking up our distro with something that people could and should get directly from its source. ~350k -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk."

Re: [HACKERS] GNU readline and BSD license

* The Hermit Hacker [EMAIL PROTECTED] [001229 17:06] wrote: On Fri, 29 Dec 2000, Tom Lane wrote: Alfred Perlstein [EMAIL PROTECTED] writes: My understanding (from the recent discussion) is that Postgresql has certain dependancies on libreadline and won't compile/work without

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

ed_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_yieldapropos=0sektion=0manpath=FreeBSD+4.2-RELEASEformat=html -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of

Re: [HACKERS] GNU readline and BSD license

-- -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)

d 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 approaching the systemwide limit. -- -Alfred Perlstein - [[EMAIL

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

/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. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I

  1   2   >