[HACKERS] statically linked pg_dump

2005-08-20 Thread Andrew Dunstan
ISTR this question coming up before, but I couldn't find an answer. Is there a reason we don't build versions of pg_dump and pg_dumpall that are statically linked against libpq so they can be run uninstalled as part of a migration process? I should have thought that this would be extremely ea

Re: [HACKERS] Win32 unicode vs ICU

2005-08-20 Thread Alvaro Herrera
On Sat, Aug 20, 2005 at 12:17:47PM -0400, Tom Lane wrote: > I think that ICU would be interesting as the base for a much larger > patch that gets us away from depending on libc's locale support at all > (in particular, getting rid of the "one locale per database" problem). > But it seems like a he

Re: [HACKERS] Win32 unicode vs ICU

2005-08-20 Thread Tom Lane
[ moving to -hackers for wider discussion ] "Magnus Hagander" <[EMAIL PROTECTED]> wrote in http://archives.postgresql.org/pgsql-patches/2005-08/msg00039.php >> I've been working with Palles ICU patch to make it work on >> win32, and I believe I have it done. While doing it I noticed >> that ICU

Re: [HACKERS] Why is lock not released?

2005-08-20 Thread Tom Lane
Alvaro Herrera <[EMAIL PROTECTED]> writes: > Oh, so is RowExclusiveLock not exclusive? (pokes) yeah, I guess it > isn't ... I'm not sure where we got our lock mode names from, but there are a number of things that aren't great about the choices. In particular "Exclusive" doesn't always mean "ex

Re: VACUUM/t_ctid bug (was Re: [HACKERS] GiST concurrency commited)

2005-08-20 Thread Tom Lane
Gavin Sherry <[EMAIL PROTECTED]> writes: > I've written some quick scripts. One just vacuums constantly (999 vacuums > to 1 vacuum full) while three other scripts three randomly insert > into, update and delete from 3 tables. There's a mix of small and large > transactions. The tables have a single

Re: [HACKERS] Why is lock not released?

2005-08-20 Thread Alvaro Herrera
On Sat, Aug 20, 2005 at 12:23:38AM -0400, Tom Lane wrote: > Alvaro Herrera <[EMAIL PROTECTED]> writes: > >> The "drop" way probably allows slightly more concurrency, but given that > >> people should seldom be taking exclusionary locks on system catalogs, > >> I'm not sure this is really an issue.

Re: VACUUM/t_ctid bug (was Re: [HACKERS] GiST concurrency commited)

2005-08-20 Thread Gavin Sherry
On Sat, 20 Aug 2005, Tom Lane wrote: > I have committed changes that I believe fix this problem: > http://archives.postgresql.org/pgsql-committers/2005-08/msg00213.php > But it needs more testing. Would you update to CVS tip and see if you > still see the failure? I've written some quick scripts