Older blog entries for alvherre (starting at number 1)

posted the patch

Yeah, apparently what I had first thought was in fact the right idea. I'm talking about my shared-row-locks project. Due to some misunderstanding on my part, I figured that the simpler idea was wrong; so I tried a lot of other things, and of course, they were also wrong. So eventually I came back and tried the first thing again, and discovered that it works as expected (by me at least). So I posted the patch, and promptly received a comment from Tom which made me notice a gross mistake. Easily solved, but gross anyway ;-)

performance measure stupidity

I ran some performance testing to verify that my patch won't make people too angry at me. I was terrified to discover that it had dropped by 25% or so in pgbench. I spent an hour and a half looking at the patch searching for the culprit (I didn't want to compile with profiling enabled because my machine is somewhat slow) ... And then I realized that I had compiled the whole backend/access/heap directory with -O0. Recompiled, reran pgbench and now I see no measurable difference between pristine sources and my tree. That's fortunate at least. I still have to see how will the lock-spilling code perform.

28 Mar 2005 (updated 28 Mar 2005 at 15:04 UTC) »

Finally got around to creating a blog. Hopefully I'll be posting with some regularity here.

I'll begin with my current activities: I've been busy these days trying to make Postgres use shared locks, not exclusive locks, in foreign key checking. This is not as easy as it sounds, because the current locking system is limited in available memory, which means the current row-locking code does not use it at all; instead it marks tuples directly on disk, which in turn means we can't have more than one locker at a time. Hence exclusive locking. Moreover, the heap access method is not at all prepared to deal cleanly with multiple lockers. (I also want to get rid of duplicated code in the heap AM, which confuses me because the duplication is not verbatim and so it needs slight adjustments before refactoring can be done.)

So, I've been mostly reading existing code and dumping one solution after another. But eventually I'll come to it — in fact, I think I found a real solution this time that I expect to be able to try tomorrow.

Additionally, I submitted a patch to allow tracking dependencies on shared objects (users, groups, tablespaces). This means that we will be able to deny dropping a user which owns objects in other databases. IMHO this is not a very exciting new feature for the database, but for me it means correcting annoying and buggy behavior. Tom Lane found the patch missing in several respects; I'll be correcting it as soon as I get rid of the shared-row-locking issue. Hopefully I'll be able to finish both things before 8.1.

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!