• Text Size: Normal / Large
• Donate
• Contact

Section Navigation

• Community
• Contributors
• Mailing Lists
  • Subscribe
  • User lists
  • Developer lists
  • Regional lists
  • Associations
  • User groups
  • Project lists
  • Inactive lists
    • pgsql-benchmarks
    • pgsql-chat
    • pgsql-cygwin
    • pgsql-hackers-pitr
    • pgsql-hackers-win32
    • pgsql-interfaces
    • pgsql-patches
    • pgsql-ports
• IRC
• Featured Users
• International Sites
• Propaganda
• Resources
• Weekly News
• Community login
  • Profile
  • Lost password

pgsql-patches 2008-03 Thread Index (2/3)

• Main Index
• [Prev Page]
• [Next Page]

• Re: Suppress compiler warnings on mingw, (continued)
  • Re: Suppress compiler warnings on mingw ITAGAKI Takahiro (Mon 17 03:03)
• Re: [BUGS] BUG #3681: fillers are NULL in pgbench Bruce Momjian (Wed 12 13:11)
• Re: Configurable Penalty Costs for Levenshtein Tom Lane (Wed 12 02:07)
• Re: Memory leak in nodeAgg Bruce Momjian (Wed 12 01:35)
• Re: [BUGS] psql \COPY accepts multiple NULL AS Bruce Momjian (Tue 11 23:31)
• Proposed patch for LISTEN/NOTIFY race condition Tom Lane (Tue 11 23:21)
• Re: Proposed patch for LISTEN/NOTIFY race condition Tom Lane (Wed 12 00:34)
• Re: Proposed patch for LISTEN/NOTIFY race condition Alvaro Herrera (Wed 12 13:12)
• Re: Proposed patch for LISTEN/NOTIFY race condition Tom Lane (Wed 12 19:13)
• Re: SPI-header-files safe for C++-compiler Bruce Momjian (Tue 11 21:30)
• Re: Load Distributed Checkpoints, final patch Bruce Momjian (Tue 11 21:08)
• Re: trace_checkpoint parameter patch Bruce Momjian (Tue 11 20:13)
• Re: Have vacuum emit a warning when it runs out of maintenance_work_mem Bruce Momjian (Tue 11 18:06)
• Re: actualised forgotten Magnus's patch for plpgsql MOVE statement Bruce Momjian (Tue 11 17:23)
• Re: [PERFORM] Very slow (2 tuples/second) sequential scan after bulk insert; speed returns to ~500 tuples/second after commit Heikki Linnakangas (Tue 11 12:34)
• Re: [PERFORM] Very slow (2 tuples/second) sequential scan after bulk insert; speed returns to ~500 tuples/second after commit Pavan Deolasee (Tue 11 13:13)
• Re: [PERFORM] Very slow (2 tuples/second) sequential scan after bulk insert; speed returns to ~500 tuples/second after commit Alvaro Herrera (Tue 11 13:29)
• Re: [PERFORM] Very slow (2 tuples/second) sequentialscan after bulk insert; speed returns to ~500 tuples/second aftercommit Heikki Linnakangas (Tue 11 14:04)
• Re: [PERFORM] Very slow (2 tuples/second) sequential scan after bulk insert; speed returns to ~500 tuples/second after commit Tom Lane (Tue 11 21:07)
• Re: [PERFORM] Very slow (2 tuples/second) sequential scan after bulk insert; speed returns to ~500 tuples/second after commit Heikki Linnakangas (Wed 12 13:44)
• Re: [PERFORM] Very slow (2 tuples/second) sequential scan after bulk insert; speed returns to ~500 tuples/second after commit Pavan Deolasee (Wed 12 15:48)
• Re: [PERFORM] Very slow (2 tuples/second) sequential scan after bulk insert; speed returns to ~500 tuples/second after commit Tom Lane (Wed 12 15:57)
• Re: [PERFORM] Very slow (2 tuples/second) sequential scan after bulk insert; speed returns to ~500 tuples/second after commit Pavan Deolasee (Wed 12 17:03)
• Re: [PERFORM] Very slow (2 tuples/second) sequential scan after bulk insert; speed returns to ~500 tuples/second after commit Heikki Linnakangas (Wed 12 17:17)
• Re: [PERFORM] Very slow (2 tuples/second) sequential scan after bulk insert; speed returns to ~500 tuples/second after commit Pavan Deolasee (Wed 12 17:53)
• Re: [PERFORM] Very slow (2 tuples/second) sequential scan after bulk insert; speed returns to ~500 tuples/second after commit Heikki Linnakangas (Wed 12 17:34)
• Re: [PERFORM] Very slow (2 tuples/second) sequential scan after bulk insert; speed returns to ~500 tuples/second after commit Pavan Deolasee (Wed 12 17:49)
• Re: [PERFORM] Very slow (2 tuples/second) sequential scan after bulk insert; speed returns to ~500 tuples/second after commit Tom Lane (Wed 12 17:22)
• Re: [PERFORM] Very slow (2 tuples/second) sequential scan after bulk insert; speed returns to ~500 tuples/second after commit Tom Lane (Mon 17 02:21)
• Re: [PERFORM] Very slow (2 tuples/second) sequential scan after bulk insert; speed returns to ~500 tuples/second after commit Bruce Momjian (Mon 17 02:21)
• Fix HAVE_LONG[_LONG]_INT_64 to really define to 1 Zoltan Boszormenyi (Tue 11 10:40)
• int8/float8/time/timestamp[tz]/float4 passed by value, was Re: Fix HAVE_LONG[_LONG]_INT_64 to really define to 1 Zoltan Boszormenyi (Mon 24 21:50)
• Re: int8/float8/time/timestamp[tz]/float4 passed by value, was Re: Fix HAVE_LONG[_LONG]_INT_64 to really define to 1 Gregory Stark (Mon 24 23:01)
• Re: int8/float8/time/timestamp[tz]/float4 passed by value, was Re: Fix HAVE_LONG[_LONG]_INT_64 to really define to 1 Zoltan Boszormenyi (Mon 24 23:15)
• Re: int8/float8/time/timestamp[tz]/float4 passed by value, was Re: Fix HAVE_LONG[_LONG]_INT_64 to really define to 1 Zoltan Boszormenyi (Tue 25 00:11)
• Re: int8/float8/time/timestamp[tz]/float4 passed by value, was Re: Fix HAVE_LONG[_LONG]_INT_64 to really define to 1 Gregory Stark (Mon 24 23:25)
• Re: int8/float8/time/timestamp[tz]/float4 passed by value, was Re: Fix HAVE_LONG[_LONG]_INT_64 to really define to 1 Zoltan Boszormenyi (Mon 24 23:38)
• Re: Re: int8/float8/time/timestamp[tz]/float4 passed by value, was Re: Fix HAVE_LONG[_LONG]_INT_64 to really define to 1 Zoltan Boszormenyi (Mon 24 23:46)
• Re: Re: int8/float8/time/timestamp[tz]/float4 passed by value, was Re: Fix HAVE_LONG[_LONG]_INT_64 to really define to 1 Gregory Stark (Tue 25 00:23)
• Re: Re: int8/float8/time/timestamp[tz]/float4 passed by value, was Re: Fix HAVE_LONG[_LONG]_INT_64 to really define to 1 Zoltan Boszormenyi (Tue 25 00:56)
• Re: Re: int8/float8/time/timestamp[tz]/float4 passed by value, was Re: Fix HAVE_LONG[_LONG]_INT_64 to really define to 1 Tom Lane (Tue 25 07:37)
• Re: Re: int8/float8/time/timestamp[tz]/float4 passed by value, was Re: Fix HAVE_LONG[_LONG]_INT_64 to really define to 1 Zoltan Boszormenyi (Tue 25 09:53)
• Re: Re: int8/float8/time/timestamp[tz]/float4 passed by value, was Re: Fix HAVE_LONG[_LONG]_INT_64 to really define to 1 Zoltan Boszormenyi (Tue 25 09:53)
• Re: Re: int8/float8/time/timestamp[tz]/float4 passed by value, was Re: Fix HAVE_LONG[_LONG]_INT_64 to really define to 1 Alvaro Herrera (Tue 25 14:15)
• Re: Re: int8/float8/time/timestamp[tz]/float4 passed by value, was Re: Fix HAVE_LONG[_LONG]_INT_64 to really define to 1 Zoltan Boszormenyi (Tue 25 15:13)
• float4/float8/int64 passed by value with tsearch fixup Zoltan Boszormenyi (Mon 31 11:08)
• Re: int8/float8/time/timestamp[tz]/float4 passed by value, was Re: Fix HAVE_LONG[_LONG]_INT_64 to really define to 1 Magnus Hagander (Tue 25 09:22)
• Re: Fix HAVE_LONG[_LONG]_INT_64 to really define to 1 Alvaro Herrera (Tue 25 00:25)
• Re: [HACKERS] Fix for large file support (nonsegment mode support) Tom Lane (Mon 10 20:16)
• Re: [HACKERS] Fix for large file support (nonsegment mode support) Peter Eisentraut (Mon 10 23:11)
• Re: [HACKERS] Fix for large file support (nonsegment mode support) Tom Lane (Mon 10 23:22)
• Re: [HACKERS] Fix for large file support (nonsegment mode support) Peter Eisentraut (Tue 11 07:27)
• Re: [HACKERS] Fix for large file support (nonsegment mode support) Tom Lane (Tue 11 14:42)
• Re: [HACKERS] Fix for large file support (nonsegment mode support) Zeugswetter Andreas OSB SD (Tue 11 08:50)
• Re: [HACKERS] Fix for large file support (nonsegment mode support) Tom Lane (Tue 11 14:49)
• Re: [HACKERS] Fix for large file support (nonsegment mode support) Zdenek Kotala (Tue 11 16:09)
• Re: [HACKERS] Fix for large file support (nonsegment mode support) Tom Lane (Tue 11 16:21)
• Re: [HACKERS] Fix for large file support (nonsegment mode support) Bruce Momjian (Tue 11 16:29)
• Re: [HACKERS] Fix for large file support (nonsegment mode support) Zdenek Kotala (Tue 11 16:42)
• Re: [HACKERS] Fix for large file support (nonsegment mode support) Tom Lane (Tue 11 17:20)
• Re: [HACKERS] Fix for large file support (nonsegment mode support) Peter Eisentraut (Tue 11 17:42)
• Re: [HACKERS] Fix for large file support (nonsegment mode support) Tom Lane (Tue 11 18:03)
• Re: [HACKERS] Fix for large file support (nonsegment mode support) Peter Eisentraut (Wed 19 08:38)
• Re: [HACKERS] Fix for large file support (nonsegment mode support) Martijn van Oosterhout (Wed 19 09:52)
• Re: [HACKERS] Fix for large file support (nonsegment mode support) Kenneth Marshall (Wed 19 12:25)
• Re: [HACKERS] Fix for large file support (nonsegment mode support) Zdeněk Kotala (Wed 19 12:40)
• Re: [HACKERS] Fix for large file support (nonsegment mode support) Larry Rosenman (Tue 11 14:17)
• Re: [HACKERS] Fix for large file support (nonsegment mode support) Alvaro Herrera (Tue 11 01:09)
• Re: [HACKERS] Fix for large file support (nonsegment mode support) Tom Lane (Tue 11 01:45)
• Re: [HACKERS] Fix for large file support (nonsegment mode support) Zeugswetter Andreas OSB SD (Tue 11 08:51)
• tsvector prints pointer difference as int Kris Jurka (Mon 10 05:57)
• Re: tsvector prints pointer difference as int Tom Lane (Mon 10 12:58)
• Re: [HACKERS] Include Lists for Text Search Tom Lane (Mon 10 03:03)
• Re: [HACKERS] Include Lists for Text Search Oleg Bartunov (Mon 10 06:35)
• Re: [HACKERS] Include Lists for Text Search Tom Lane (Mon 10 14:18)
• Re: [HACKERS] Include Lists for Text Search Teodor Sigaev (Mon 10 15:00)
• Re: [HACKERS] Include Lists for Text Search Tom Lane (Mon 10 15:11)
• Re: [HACKERS] Include Lists for Text Search Teodor Sigaev (Mon 10 15:21)
• Re: [HACKERS] Include Lists for Text Search Teodor Sigaev (Mon 10 16:02)
• Re: [HACKERS] Include Lists for Text Search Simon Riggs (Mon 10 10:42)
• Re: [HACKERS] Include Lists for Text Search Andrew Dunstan (Mon 10 12:24)
• Re: [HACKERS] Include Lists for Text Search Simon Riggs (Mon 10 13:30)
• Re: [HACKERS] Include Lists for Text Search Andrew Dunstan (Mon 10 13:49)
• Re: [HACKERS] Include Lists for Text Search Tom Lane (Mon 10 14:03)
• Re: [HACKERS] Include Lists for Text Search Simon Riggs (Mon 10 14:25)
• Re: [HACKERS] Include Lists for Text Search Simon Riggs (Mon 10 14:05)
• Re: [HACKERS] Include Lists for Text Search Bruce Momjian (Mon 10 14:33)
• Re: XLogCacheByte is unused Tom Lane (Mon 10 02:15)
• Re: Reduce the size of PageFreeSpaceInfo on 64bit platform Tom Lane (Mon 10 02:08)
• Re: Silly bug in pgbench's random number generator Tom Lane (Mon 10 01:23)
• Re: Proposed patch to change TOAST compression strategy Tom Lane (Fri 07 23:23)
• Re: Cleaner API for appendStringInfoVA Bruce Momjian (Fri 07 20:22)
• Re: a tsearch2 (8.2.4) dictionary that only filters out stopwords Bruce Momjian (Fri 07 20:06)
• Re: [HACKERS] Re: a tsearch2 (8.2.4) dictionary that only filters out stopwords Tom Lane (Fri 07 21:20)
• Minimum selectivity estimate for LIKE 'prefix%' Tom Lane (Thu 06 21:17)
• Re: Minimum selectivity estimate for LIKE 'prefix%' Peter Eisentraut (Fri 07 18:29)
• Re: Minimum selectivity estimate for LIKE 'prefix%' Peter Eisentraut (Mon 17 16:19)
• Re: Minimum selectivity estimate for LIKE 'prefix%' Tom Lane (Mon 17 17:02)
• NetBSD/MIPS supports dlopen Rémi Zara (Wed 05 19:29)
• Re: NetBSD/MIPS supports dlopen Alvaro Herrera (Wed 05 19:43)
• Re: NetBSD/MIPS supports dlopen Tom Lane (Wed 05 20:34)
• Re: NetBSD/MIPS supports dlopen Alvaro Herrera (Wed 05 21:29)
• Re: NetBSD/MIPS supports dlopen Tom Lane (Wed 05 21:42)
• Re: NetBSD/MIPS supports dlopen Alvaro Herrera (Wed 05 21:51)
• Re: NetBSD/MIPS supports dlopen Alvaro Herrera (Wed 05 22:03)
• Re: NetBSD/MIPS supports dlopen Magnus Hagander (Wed 05 22:22)
• Re: NetBSD/MIPS supports dlopen Alvaro Herrera (Wed 05 22:39)
• Re: NetBSD/MIPS supports dlopen Magnus Hagander (Thu 06 08:54)
• Re: NetBSD/MIPS supports dlopen Alvaro Herrera (Thu 06 12:11)
• Re: NetBSD/MIPS supports dlopen Andrew Dunstan (Wed 05 21:48)
• Re: NetBSD/MIPS supports dlopen Alvaro Herrera (Wed 05 22:02)
• Re: NetBSD/MIPS supports dlopen Andrew Dunstan (Wed 05 22:25)
• Proposed patch - psql wraps at window width Bryce Nesbitt (Wed 05 21:05)
• Re: Proposed patch - psql wraps at window width Alvaro Herrera (Wed 26 13:25)
• libpq type system 0.9a Merlin Moncure (Wed 05 18:55)
• Re: libpq type system 0.9a Florian G. Pflug (Wed 05 22:47)
• Re: libpq type system 0.9a Merlin Moncure (Wed 05 23:38)
• Re: libpq type system 0.9a Andrew Chernow (Thu 06 00:59)
• Re: libpq type system 0.9a Alvaro Herrera (Tue 25 20:21)
• Re: libpq type system 0.9a Merlin Moncure (Thu 27 20:19)
• Re: TransactionIdIsInProgress() cache Bruce Momjian (Wed 05 18:29)
• <Possible follow-ups>
• Re: TransactionIdIsInProgress() cache Heikki Linnakangas (Tue 11 12:57)
• Re: TransactionIdIsInProgress() cache Alvaro Herrera (Tue 11 13:08)
• Re: TransactionIdIsInProgress() cache Pavan Deolasee (Tue 11 13:18)
• Re: TransactionIdIsInProgress() cache Heikki Linnakangas (Tue 11 13:59)
• Re: TransactionIdIsInProgress() cache Alvaro Herrera (Tue 11 14:16)
• Re: TransactionIdIsInProgress() cache Tom Lane (Tue 11 17:16)
• Re: TransactionIdIsInProgress() cache Simon Riggs (Tue 11 17:36)
• Re: TransactionIdIsInProgress() cache Simon Riggs (Tue 11 17:27)
• Re: TransactionIdIsInProgress() cache Tom Lane (Tue 11 19:11)
• Re: TransactionIdIsInProgress() cache Tom Lane (Tue 11 19:33)
• Re: TransactionIdIsInProgress() cache Tom Lane (Tue 11 20:29)
• Re: Endless recovery Bruce Momjian (Wed 05 17:01)
• Re: [BUGS] BUG #3975: tsearch2 index should not bomb out of 1Mb limit Bruce Momjian (Wed 05 15:54)
• Re: [BUGS] BUG #3975: tsearch2 index should not bomb out of 1Mb limit Edwin Groothuis (Wed 05 20:57)
• Re: [BUGS] BUG #3975: tsearch2 index should not bomb out of 1Mb limit Euler Taveira de Oliveira (Thu 06 23:22)
• Re: [BUGS] BUG #3975: tsearch2 index should not bomb out of 1Mb limit Edwin Groothuis (Thu 06 23:42)
• Re: [BUGS] BUG #3975: tsearch2 index should not bomb out of 1Mb limit Bruce Momjian (Fri 07 12:20)
• Re: [BUGS] BUG #3975: tsearch2 index should not bomb out of 1Mb limit Tom Lane (Fri 07 01:05)
• Re: [BUGS] BUG #3975: tsearch2 index should not bomb out of 1Mb limit Euler Taveira de Oliveira (Fri 07 06:17)
• Re: [BUGS] BUG #3975: tsearch2 index should not bomb out of 1Mb limit Tom Lane (Fri 07 06:52)
• Re: [BUGS] BUG #3975: tsearch2 index should not bomb out of 1Mb limit Euler Taveira de Oliveira (Mon 10 02:11)
• Re: [BUGS] BUG #3975: tsearch2 index should not bomb out of 1Mb limit Bruce Momjian (Fri 07 12:19)
• Re: [BUGS] BUG #3975: tsearch2 index should not bomb out of 1Mb limit Tom Lane (Fri 07 13:13)
• Re: [BUGS] BUG #3975: tsearch2 index should not bomb out of 1Mb limit Bruce Momjian (Fri 07 13:23)
• Re: [BUGS] BUG #3975: tsearch2 index should not bomb out of 1Mb limit Teodor Sigaev (Fri 07 13:56)
• Re: DTrace probe patch for OS X Leopard Jorgen Austvik - Sun Norway (Wed 05 14:13)
• <Possible follow-ups>
• Re: DTrace probe patch for OS X Leopard Robert Lor (Thu 06 04:46)
• Re: DTrace probe patch for OS X Leopard Bruce Momjian (Thu 06 18:51)
• Re: DTrace probe patch for OS X Leopard Robert Lor (Thu 13 15:14)
• Re: DTrace probe patch for OS X Leopard Peter Eisentraut (Mon 17 19:46)
• Re: DTrace probe patch for OS X Leopard Dave Page (Fri 14 12:02)
• Sun Studio on Linux spinlock patch Julius Stroffek (Wed 05 08:54)
• Re: Sun Studio on Linux spinlock patch Tom Lane (Wed 05 13:56)
• Re: Sun Studio on Linux spinlock patch Zdenek Kotala (Thu 06 07:48)
• Re: Sun Studio on Linux spinlock patch Julius Stroffek (Mon 10 14:59)
• actualized SQL/PSM patch Pavel Stehule (Tue 04 20:32)
• Re: actualized SQL/PSM patch Bruce Momjian (Wed 05 03:44)
• 64-bit CommandIds Zoltan Boszormenyi (Tue 04 17:32)
• Re: 64-bit CommandIds Alvaro Herrera (Tue 04 17:41)
• Re: 64-bit CommandIds Zoltan Boszormenyi (Tue 04 18:34)
• Re: 64-bit CommandIds Zoltan Boszormenyi (Tue 04 20:52)
• Re: Fix for initdb failures on Vista Dave Page (Tue 04 15:28)
• Re: Fix for initdb failures on Vista Magnus Hagander (Tue 04 15:40)
• WIP: guc enums Magnus Hagander (Tue 04 13:25)
• Re: WIP: guc enums Heikki Linnakangas (Tue 04 21:36)
• Re: WIP: guc enums Tom Lane (Wed 05 05:48)
• Re: WIP: guc enums Heikki Linnakangas (Wed 05 09:42)
• Re: WIP: guc enums Tom Lane (Wed 05 13:18)
• Re: WIP: guc enums Heikki Linnakangas (Wed 05 13:33)
• Re: WIP: guc enums Tom Lane (Wed 05 13:41)
• Re: WIP: guc enums Andrew Dunstan (Wed 05 15:03)
• Re: WIP: guc enums Magnus Hagander (Wed 05 15:20)
• Re: WIP: guc enums Magnus Hagander (Wed 05 09:53)
• Re: [HACKERS] Show INHERIT in \du Alvaro Herrera (Tue 04 13:19)
• Re: [HACKERS] Show INHERIT in \du Bruce Momjian (Tue 04 13:51)
• <Possible follow-ups>
• Re: [HACKERS] Show INHERIT in \du Bruce Momjian (Tue 04 13:52)
• Re: [HACKERS] Show INHERIT in \du Tom Lane (Thu 20 23:27)
• Re: [HACKERS] Show INHERIT in \du Brendan Jurd (Fri 21 03:45)
• Re: [HACKERS] Show INHERIT in \du Tom Lane (Fri 21 03:51)

---

• Main Index
• [Prev Page]
• [Next Page]

---

Mail converted by MHonArc