[HACKERS] Question about postgresql-8.1.2-1-binaries-no-installer.zip(win32)

2006-01-28 Thread Tony Caduto
Hi, I noticed that when I install via the msi setup there is a extra DLL in the bin directory called pthreadGC2.dll. (Posix thread library for windows) This dll is not in the postgresql-8.1.2-1-binaries-no-installer.zip file. Postgresql seems to run fine without out when I do a manual install

Re: [HACKERS] A note about testing EXEC_BACKEND on recent Linuxen

2006-01-28 Thread Mitchell Skinner
On Thu, 2006-01-26 at 18:40 -0500, Tom Lane wrote: > You can work around this by doing (as root) > echo 0 >/proc/sys/kernel/randomize_va_space > before starting the postmaster. You'll probably want to set it back to > 1 when done experimenting with EXEC_BACKEND, since address randomization >

Re: [HACKERS] Surrogate keys (Was: enums)

2006-01-28 Thread Leandro Guimarães Faria Corcete Dutra
Em Qui, 2006-01-19 às 22:29 +0100, Martijn van Oosterhout escreveu: > Possibly nowhere. But when you send invoices to customers, any details > on there *are* immutable. Sure, in your database you don't care if > things change, but then they don't match reality anymore do they? Then what yo

Re: [HACKERS] stats for failed transactions (was Re: [GENERAL] VACUUM

2006-01-28 Thread Josh Berkus
Tom, I'd argue it's fine: there are tons of people using row-level stats via autovacuum, and (AFAICT) just about nobody using 'em for any other purpose. Certainly you never see anyone suggesting them as a tool for investigating problems on pgsql-performance. Actually, I use the stats for pe

Re: [HACKERS] stats for failed transactions (was Re: [GENERAL] VACUUM Question)

2006-01-28 Thread Tom Lane
"Matthew T. O'Connor" writes: > Tom Lane wrote: >> the only full solution will involve backends doing some extra work at >> subtransaction commit/abort so that they can report properly classified >> update counts. > Any guess as to the performance implications? Pushing some counts from one place

Re: [HACKERS] stats for failed transactions (was Re: [GENERAL] VACUUM

2006-01-28 Thread Matthew T. O'Connor
Tom Lane wrote: I'd argue it's fine: there are tons of people using row-level stats via autovacuum, and (AFAICT) just about nobody using 'em for any other purpose. Certainly you never see anyone suggesting them as a tool for investigating problems on pgsql-performance. Sure, it's a repurposing

Re: [HACKERS] stats for failed transactions (was Re: [GENERAL] VACUUM Question)

2006-01-28 Thread Tom Lane
"Matthew T. O'Connor" writes: > None of this directly addresses the question of what the stats system > *should* track, but perhaps it is wrongheaded to totally redesign the > stats system for the purposes of autovacuum. I'd argue it's fine: there are tons of people using row-level stats via au