On Mar 24, 2007, at 1:55 AM, Joshua D. Drake wrote:
Hello,
We have had several customers get bit by the 8.2.3 stats collector
bug.
It is also starting to get reported in areas such as IRC. The
really bad
thing about this bug is that you won't know what is wrong unless you
know where to lo
Am Sat, 24 Mar 2007 13:19:28 +0100 hat Grzegorz Jaskiewicz
<[EMAIL PROTECTED]> geschrieben:
On Mar 24, 2007, at 1:55 AM, Joshua D. Drake wrote:
Hello,
We have had several customers get bit by the 8.2.3 stats collector bug.
It is also starting to get reported in areas such as IRC. The reall
On Fri, Mar 23, 2007 at 05:30:27PM -0500, Kevin Grittner wrote:
> I don't understand -- TRUE OR UNKNOWN evaluates to TRUE, so why would
> the IN need to continue? I'm not quite following the rest; could you
> elaborate or give an example? (Sorry if I'm lagging behind the rest
> of the class here.
tsearch2 regression tests are also failing on win32/msvc, with attached
diffs.
Any pointers on where to start? ;)
//Magnus
*** ./expected/tsearch2.out 2006-09-10 19:36:52.0 +0200
--- ./results/tsearch2.out 2007-03-24 15:03:01.59375 +0100
***
*** 799,806
/us
I've always been annoyed by the implementation of
HeapTupleSatisfiesVisibility (in src/include/utils/tqual.h):
the normal case of an MVCC snapshot is the last one handled,
and we can't expand the set of special cases without slowing
it down even more. Also, as noted in tqual.h, the way we
represen
On Sat, Mar 24, 2007 at 02:00:30PM -0400, Tom Lane wrote:
> I had an idea about how to make this cleaner and faster at
> the same time. Make all snapshots be real pointers to
> SnapshotData structures (except InvalidSnapshot, which remains
> an alias for NULL). Add a struct field that is a pointe
Martijn van Oosterhout writes:
> On Sat, Mar 24, 2007 at 02:00:30PM -0400, Tom Lane wrote:
>> HeapTupleSatisfiesVisibility reduces to something like
>> ((*(snapshot)->satisfies) ((tuple)->t_data, snapshot, buffer))
> Sounds like a winner. Essentially snapshots becomes objects that have
> methods
On Mar 21, 2007, at 5:11 AM, Tom Lane wrote:
constraint_exclusion
I'm inclined not to worry about these, since changing them can't
affect
the semantics of the query, at worst its performance.
Hrm... wasn't that option added in case there was a bug in the
exclusion code? I certainl
Should anyone be looking for me for some reason... I'll be in New
Zealand from Mar 24 - Apr 8, and will have very limited access to email.
--
Jim Nasby[EMAIL PROTECTED]
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
-
Added to TODO:
o Add more logical syntax CLUSTER table ORDER BY index;
support current syntax for backward compatibility
---
Simon Riggs wrote:
> On Sun, 2007-03-11 at 11:22 +, Heikki Linnakangas wrote
> Tom Lane wrote:
>> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>>> It should be standard docs imo. PDF is a heck of a lot easier to read if
>>> you have a good PDF reader.
>>
>> Just out of curiosity, what would that be? I've used both Acrobat and
>> Preview, and I do not like either.
Have yo
> HeapTupleSatisfiesVisibility reduces to something like
>
> ((*(snapshot)->satisfies) ((tuple)->t_data, snapshot, buffer))
>
> which ought to be faster than it is now.
It sounds like a fine idea from the point of view of flexibility. But as far
as faster... I guess it depends on how often
(perhaps with the committing and then reversing of the custom variables
patch?)
postgres=# show datestyle;
DateStyle
---
ISO, DMY
(1 row)
postgres=# set datestyle='DMY,ISO';
SET
postgres=# show datestyle;
DateStyle
---
ISO, DMY
(1 row)
--
Gregory Stark
EnterpriseDB
"Jim Nasby" <[EMAIL PROTECTED]> writes:
> On Mar 21, 2007, at 5:11 AM, Tom Lane wrote:
>> constraint_exclusion
>>
>> I'm inclined not to worry about these, since changing them can't affect
>> the semantics of the query, at worst its performance.
>
> Hrm... wasn't that option added in case the
Someone has pointed out to me that we have non-PostgreSQL/Berkeley
copyrights on a number of files:
src/port/rint.c
* Copyright (c) 1999, repas AEG Automation GmbH
src/backend/port/dynloader/aix.c
* This is an unpublished work copyright (c) 1992 HEL
Someone has pointed out that the following files have the 4-part BSD
copyright, which includes the advertising clause:
src/backend/port/darwin/system.c
src/backend/port/dynloader/freebsd.c
src/backend/port/dynloader/openbsd.c
src/backend/port/dynloader/netbsd.c
Tom Lane wrote:
> "Postgres User" <[EMAIL PROTECTED]> writes:
> > On 3/1/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> >> "Postgres User" <[EMAIL PROTECTED]> writes:
> >>> ref_entry = 'c_entry';
> >>> MOVE Backward All In c_entry;
> >>
> >> You have to use EXECUTE for the latter.
>
> > I had t
Bruce Momjian wrote:
Someone has pointed out that the following files have the 4-part BSD
copyright, which includes the advertising clause:
src/backend/port/darwin/system.c
src/backend/port/dynloader/freebsd.c
src/backend/port/dynloader/openbsd.c
src/backend/port/
Bruce Momjian wrote:
> Someone has pointed out to me that we have non-PostgreSQL/Berkeley
> copyrights on a number of files:
>
> src/port/rint.c
> * Copyright (c) 1999, repas AEG Automation GmbH
>
> src/backend/port/dynloader/aix.c
> * This is an unpublished wo
Bruce Momjian wrote:
Someone has pointed out that the following files have the 4-part BSD
copyright, which includes the advertising clause:
src/backend/port/darwin/system.c
src/backend/port/dynloader/freebsd.c
src/backend/port/dynloader/openbsd.c
src/backend/port/
Bruce Momjian wrote:
Someone has pointed out to me that we have non-PostgreSQL/Berkeley
copyrights on a number of files:
src/port/rint.c
* Copyright (c) 1999, repas AEG Automation GmbH
src/backend/port/dynloader/aix.c
* This is an unpublished work
Alvaro Herrera wrote:
Bruce Momjian wrote:
Someone has pointed out to me that we have non-PostgreSQL/Berkeley
copyrights on a number of files:
src/port/rint.c
* Copyright (c) 1999, repas AEG Automation GmbH
src/backend/port/dynloader/aix.c
* This
22 matches
Mail list logo
