- 10 Jan, 2002 9 commits
-
-
Bruce Momjian authored
-
Bruce Momjian authored
-
Peter Eisentraut authored
footnote count.
-
Bruce Momjian authored
-
Bruce Momjian authored
-
Michael Meskes authored
-
Bruce Momjian authored
setting.
-
Bruce Momjian authored
-
Tom Lane authored
pgsql-hackers discussion of this date.
-
- 09 Jan, 2002 9 commits
-
-
Tom Lane authored
the difference between a run-time type cast and casting a literal string to a specific type. Minor editorial work in same area.
-
Bruce Momjian authored
-
Tom Lane authored
Oliver Elphick. A few other minor cleanups while at it.
-
Tom Lane authored
-
Bruce Momjian authored
-
Bruce Momjian authored
-
Bruce Momjian authored
-
Peter Eisentraut authored
And listing QNX 6 as both supported and unsupported is probably not helpful.
-
Tom Lane authored
-
- 08 Jan, 2002 16 commits
-
-
Peter Eisentraut authored
-
Tom Lane authored
-
Tom Lane authored
-
Tom Lane authored
pg_regress doesn't see it and you don't get any port-specific comparisons.
-
Peter Eisentraut authored
-
Bruce Momjian authored
< * Thomas is Thomas Lockhart <lockhart@alumni.caltech.edu> --- > * Thomas is Thomas Lockhart <lockhart@fourpalms.org>
-
Bruce Momjian authored
-
Tom Lane authored
-
Peter Eisentraut authored
the info to the main bibliography.
-
Tom Lane authored
multibyte encodings.
-
Peter Eisentraut authored
-
Tom Lane authored
-
Peter Eisentraut authored
-
Michael Meskes authored
-
Bruce Momjian authored
-
Bruce Momjian authored
-
- 07 Jan, 2002 5 commits
-
-
Bruce Momjian authored
-
Tom Lane authored
Marko Kreen says: This is so obvious that I would like to make it 'official'. Seems like the theology around bytea<>text casting kept me from seeing the simple :)
-
Tom Lane authored
granted the lock when awakened; the signal now only means that the lock is potentially available. The waiting process must retry its attempt to get the lock when it gets to run. This allows the lock releasing process to re-acquire the lock later in its timeslice. Since LWLocks are usually held for short periods, it is possible for a process to acquire and release the same lock many times in a timeslice. The old spinlock-based implementation of these locks allowed for that; but the original coding of LWLock would force a process swap for each acquisition if there was any contention. Although this approach reopens the door to process starvation (a waiter might repeatedly fail to get the lock), the odds of that being a big problem seem low, and the performance cost of the previous approach is considerable.
-
Michael Meskes authored
-
Peter Eisentraut authored
-
- 06 Jan, 2002 1 commit
-
-
Tom Lane authored
to the client before closing the connection. Before 7.2 this was done correctly, but new code would simply close the connection with no report to the client.
-