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

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

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

[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

[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

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

> On 4/22/14, 5: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? >&g

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 hardwa

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 for a

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 it

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, 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 sen

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

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'

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

we need to add GUC to control 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 chan

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 impr

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 complexi

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 mailto:and...@2ndquadrant.com>> wrote: On 2014-04-21

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

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

On 4/21/14 8:58 AM, Tom Lane wrote: Andres Freund 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 need to make that decisi

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 mailto:and...@2ndquadrant.com>> wrote: On 2014-04-21 10:45:24 -0400, Tom Lane wrote: > Andres Freund mailto:and...@2ndquadrant.com>> writes: > >

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 Fra

[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

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

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

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

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

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

Re: [HACKERS] CVS commits

ould be able to check that via the cvsweb interface off the developer's corner on the postgresql website. Just find your files and see if there's a new tag for 7.1 and whether or not your code is against HEAD or against the tag (if it exists) for 7.1. -- -Alfred Perlstein - [[EMAIL PR

Re: [ADMIN] Re: [HACKERS] Re: [PORTS] pgmonitor and Solaris

* Karel Zak <[EMAIL PROTECTED]> [010329 03:10] wrote: > On Wed, Mar 28, 2001 at 04:10:52PM -0800, Alfred Perlstein wrote: > > * Tom Lane <[EMAIL PROTECTED]> [010328 16:07] wrote: > > > Larry Rosenman <[EMAIL PROTECTED]> writes: > > > > FYI, the WU-

Re: [ADMIN] Re: [HACKERS] Re: [PORTS] pgmonitor and Solaris

... is this all for "pgmonitor"? sorry, just my opinion... If it for pgmonitor then you guys ought to just mark it broken on these platforms, the non-"ps based" solution could have been implemented with all the time wasted trying to get the "ps based" hack working. :

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

* The Hermit Hacker <[EMAIL PROTECTED]> [010327 05:31] wrote: > On Tue, 27 Mar 2001, Alfred Perlstein wrote: > > > * The Hermit Hacker <[EMAIL PROTECTED]> [010327 04:53] wrote: > > > On Mon, 26 Mar 2001, Matthias Juchem wrote: > > > > > > >

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

; > > > REL_7_1_BETA2 > > REL_7_1_BETA3 > > REL_7_1 > > > > 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

Re: [HACKERS] pgindent run?

s. > > I would liken running pgindent to having a nice looking store or > website. No one is going to go to a website or a store only because it > looks nice, but having it look nice does keep people coming back. I'm not saying I don't like pgindent, I'm saying I don&#

Re: [HACKERS] pgindent run?

ode through pgindent as explained in the contributor's guide at http://www.postgresql.org/faq/cont?" > On a side note, the idea of having people submit patches only against > current CVS seems bad to me. If people are running production machines > and they develop a p

Re: [HACKERS] pgindent run?

ing curve ahead of them, making pgindent as patches are applied should work. There's also the argument that a developer's 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 en

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

space required for each attached > > process, as well as the use of large pages which reduce the amount > > of TLB faults your processes will incurr. > > That is interesting. BSDi has SysV shared memory as non-pagable, and I > always thought of that as a bug. Seems you are sayin

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 stil

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 stra

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

NATIVE. > > I want the two to talk, using ODBC. > > How do I make this happen? rpm2cpio > pg_rpmfile.cpio cpio -i < pg_rpmfile.cpio tar xzvf pg_rpmfile.tgz -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] ---(end of broadcast)---

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

n-pageable, this allows signifigant savings in kernel space required for each attached process, as well as the use of large pages which reduce the amount of TLB faults your processes will incurr. Anyhow, if you could make this a runtime option it wouldn't be so evil, but

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

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

> the whole set...which may not be that bad. Actually it can be 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]] --

Re: [HACKERS] Performance monitor signal handler

MSGSND(3) ERRORS msgsnd() will fail if: [EAGAIN] There was no space for this message either on the queue, or in the whole system, and IPC_NOWAIT was set in msgflg. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTEC

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

xWare, you need to add -Kthread, which CHANGES a LOT > of primitives to go through threads wrappers and scheduling. > > See the doc on the http://UW7DOC.SCO.COM or http://www.lerctr.org:457/ > web pages. > > Also, some functions are NOT available without the -Kthread or -Kpthread >

Re: [HACKERS] Performance monitor signal handler

nstead of sending deltas, you send totals? This would allow you to loose messages and still maintain accurate stats. You can also enable SIGIO on the socket, then have a signal handler buffer packets that arrive when not actively select()ing on the UDP socket. You can then use sigsetmask(2) to p

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

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

7;ed so I don't see a big win. This isn't simply handing off the sync to this other process, it requires an ack from the syncer before returning 'COMMIT'. -- -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

x27;s somewhat of a good idea. > > I am not a DBMS guru. Hah, same here. :) > 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 sw

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

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

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

Re: [HACKERS] Performance monitor signal handler

People will depend on the data returned making sense. -- -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] 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 adja

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

han one, what might work is using mmap() to map the files in adjacent areas, 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 o

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 i

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

* Peter Eisentraut <[EMAIL PROTECTED]> [010315 11:33] wrote: > Alfred Perlstein writes: > > > Sorry, what's a GUC? :) > > Grand Unified Configuration system > > It's basically a cute name for the achievement that there's now a single > name spa

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

d > > use O_DSYNC by default. > > Hm. We 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, wha

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 PROTECT

[HACKERS] Re: Performance monitor signal handler

ile, assuming it exists it will always have a complete and consistant snapshot of whatever the backends agreed on. -- -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

non > memory (allocated via brk() or mmap() of /dev/zero). What about userland device drivers that want to send parts of a disk backed file to a driver's dma routine? -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] Daemon News Magazine in your snail-mail! http://magazine.daemonne

Re: [HACKERS] Performance monitor signal handler

pshot of the stats. Actually, what makes the most sense (although 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.da

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

Re: [HACKERS] Performance monitor signal handler

ndlers one could just periodically poll 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

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'

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

erstanding of how Unix is supposed to run. What they really need to do is hire 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)

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

et: old struct -> old syscall (ok) new struct -> old syscall (boom) old 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, th

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

kidding about Linux going out of its way to defeat the 'shm_nattch' trick... *sigh* As a FreeBSD developer I'm 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

* 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, bu

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 availa

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

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 str

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

ly-starting > postmaster, I think, not on the old backends. > > > Should a set of backends detect a new postmaster coming up and try to > > 'sync up' with that postmaster, > > Nice try ;-). How will you persuade the kernel that these processes are >

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

stuff, afaik it can be used to track the number 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] preproc.y error

ted this broken a couple of months ago, but it was too late to add the check to configure 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

) expire old and unused auto-created indecies. Generally 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?

gt; messages. Did you run vacuum with verbose option or do you have > postmaster' logs? With LAZY vacuum writes messages like > > Index _name_: deleted XXX unfound YYY > > YYY supposed 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."

Re: [HACKERS] Re: 1024 limits??

* Mathieu Dube <[EMAIL PROTECTED]> [010205 09:32] wrote: > cc -o therver therver.c -g -lflipr -lpq -L. -lpthread -D_REENTRANT > ./libpq.a(fe-auth.o): In function `pg_password_sendauth': > /usr/local/postgresql-7.0.3/src/interfaces/libpq/fe-auth.c:465: undefined reference >to `crypt' > collect2: l

[HACKERS] Index grows huge, possible leakage?

side note, 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

p() runs > around. It's not perfect 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

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

Re: [HACKERS] Libpq async issues

set call will block the > > application until it finishes. Really, what is needed to close down a > > COPY safely in nonblock mode is a pair of entry points along the line of > > "PQendcopyStart" and "PQendcopyPoll", with API conventions similar to > > PQresetStart/PQresetPoll. This gives you the ability to do the reset > > (if one is necessary) without blocking the application. PQendcopy > > itself will only be useful to blocking applications. > > > > > I'm sorry if they don't work for some situations other than COPY IN, > > > but it's functionality that I needed and I expect to be expanded on > > > by myself and others that take interest in nonblocking operation. > > > > I don't think that the nonblock code is anywhere near production quality > > at this point. It may work for you, if you don't stress it too hard and > > never have a communications failure; but I don't want to see us ship it > > as part of Postgres unless these issues get addressed. > > > > regards, tom lane > > > > > > > > > -- > Bruce Momjian| http://candle.pha.pa.us > [EMAIL PROTECTED] | (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] Does Oracle store values in indices?

used > > > to restore valid version of entire index/table page. > > > > Are there any plans to have something like this? I mean overwriting storage > > manager. > > We hope to have it some day, hopefully soon. Vadim says that he hopes it to be done by 7.2, so if thi

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

http://people.freebsd.org/~alfred/vacfix/vlazy.tgz > > > > only lazy vacuum option to only scan from start of modified > > data: > > http://people.freebsd.org/~alfred/vacfix/mnmb.tgz > > > > Although the patches are for 7.0.x I'm hoping that they > >

Re: [HACKERS] Re: [GENERAL] postgres memory management

mory 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 PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk."

  1   2   3   >