http://developer.postgresql.org/pgdocs/postgres/catalog-pg-opfamily.html
states that
Operator families are described at length in Section 33.14.
which does not seem to be the case. Did it get missed in a commit?
Regards, Dave.
---(end of
Sorry for delay, I was on holidays :)
Did you test patch on Windows platform?
Tatsuo Ishii wrote:
I have tested with local-enabled environment and found a bug. Included
is the new version of patches.
Teodor, Oleg, what do you think about these patches?
If ok, shall I commit to CVS head?
--
Sorry for delay, I was on holidays :)
Did you test patch on Windows platform?
No. I myself does not use Windows platform.
Do you have any concern on Windows regarding my patches?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
Tatsuo Ishii wrote:
I have tested with local-enabled environment and
Simon Riggs [EMAIL PROTECTED] writes:
Merge Joins require us to potentially Mark and Restore positions in the
tuples arriving from executor sub-nodes.
I came across an old note to myself suggesting that we handle this by
interposing a Materialize node, and then teaching Material that if it's
On Tue, 2007-01-09 at 16:31 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
...continuing this discussion about setting HEAP_XMIN_COMMITTED...
BTW, a sufficient counterexample for that kluge is that neither SPI or
SQL-function execution use a separate portal for invoked
Simon Riggs [EMAIL PROTECTED] writes:
I agree we could get this to Just Work by altering
HeapTupleSatisfies...() functions so that their first test is
if (TransactionIdIsCurrentTransactionId(xvac))
rather then
if (!(tuple-t_infomask HEAP_XMIN_COMMITTED))
Huh? That doesn't make
On Wed, 2007-01-10 at 10:37 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
I agree we could get this to Just Work by altering
HeapTupleSatisfies...() functions so that their first test is
if (TransactionIdIsCurrentTransactionId(xvac))
Oh? Sorry, I meant xmin not xvac at
On Wed, 2007-01-10 at 10:46 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Presumably we'd need to teach the Materialize node to pass straight
through when the node does not receive any of EXEC_FLAG_MARK,
EXEC_FLAG_REWIND or EXEC_FLAG_BACKWARD.
It does that already.
The
Hi,
what are the assumptions PostgreSQL normally does about atomic
operations? I see sig_atomic_t is used in signal handlers. Additionally,
there is a match for a cmpxchg instruction in some solaris ports code,
but that's about what I found in the source.
Am I safe assuming that pointer
Markus Schiltknecht wrote:
Hi Markus,
what are the assumptions PostgreSQL normally does about atomic
operations? I see sig_atomic_t is used in signal handlers. Additionally,
there is a match for a cmpxchg instruction in some solaris ports code,
but that's about what I found in the source.
Markus Schiltknecht [EMAIL PROTECTED] writes:
what are the assumptions PostgreSQL normally does about atomic
operations?
Rule of thumb: you want to touch shared memory, you use a lock.
There are a few places that violate it, but in general you'd better have
a pretty darn good reason to not
On Wed, 3 Jan 2007 10:16:41 -0500
Jim Nasby [EMAIL PROTECTED] wrote:
Given that the TODO list is the official compilation of things that
need to get done, ISTM that anything warranting a TODO or XXX in the
code should probably be on the TODO list.
There are a wide class of possible
Hi!
When running make installcheck, the DLL files for the regression tests
are loaded from the source tree ../../../contrib/ etc. While this
certainly makes a bit sense, it poses a problem for binary
distributions that want to run the regression tests. It also causes a
small problem for the msvc
Magnus Hagander [EMAIL PROTECTED] writes:
Would it make sense to have a standard way to run the regression tests
against DLL files on the *installed* system?
The RPMs do this, but their solution is pretty darn ugly: ship the test
files along with a custom Makefile (and I think they have to
Would it make sense to have a standard way to run the regression tests
against DLL files on the *installed* system?
The RPMs do this, but their solution is pretty darn ugly: ship the test
files along with a custom Makefile (and I think they have to patch the
test files, too). I'm not
Magnus Hagander [EMAIL PROTECTED] writes:
what really is the motivation for keeping some of the tested binaries in the
sourcetree when doing installcheck?
As opposed to what? We're certainly not going to *install* regress.so,
and I can't see requiring contrib to be there either. These are
On Jan 9, 2007, at 20:41 , Jim C. Nasby wrote:
On Mon, Jan 08, 2007 at 10:40:16PM -0600, Michael Glaesemann wrote:
On Jan 8, 2007, at 19:25 , Jim C. Nasby wrote:
Actually, I see point in both... I'd think you'd want to know if a
patch
worked against the CVS checkout it was written against.
On Wed, Jan 10, 2007 at 02:45:24PM -0500, Neil Conway wrote:
On Wed, 3 Jan 2007 10:16:41 -0500
Jim Nasby [EMAIL PROTECTED] wrote:
Given that the TODO list is the official compilation of things that
need to get done, ISTM that anything warranting a TODO or XXX in the
code should
On Wed, 10 Jan 2007, Jim C. Nasby wrote:
On Thu, Jan 11, 2007 at 08:04:41AM +0900, Michael Glaesemann wrote:
Wouldn't there be some value to knowing whether the patch failed
due to
bitrot vs it just didn't work on some platforms out of the gate?
I'm having a hard time figuring out what
On Wed, 10 Jan 2007, Jim C. Nasby wrote:
On Thu, Jan 11, 2007 at 08:04:41AM +0900, Michael Glaesemann wrote:
Wouldn't there be some value to knowing whether the patch failed
due to
bitrot vs it just didn't work on some platforms out of the gate?
I'm having a hard time figuring out
From: Teodor Sigaev [EMAIL PROTECTED]
Subject: Re: [HACKERS] Request for review: tsearch2 patch
Date: Wed, 10 Jan 2007 18:50:44 +0300
Message-ID: [EMAIL PROTECTED]
I have tested with local-enabled environment and found a bug. Included
is the new version of patches.
Your patch causes crash
I have tested with local-enabled environment and found a bug. Included
is the new version of patches.
Your patch causes crash on tsearch2's installcheck with 'initdb -E UTF8
--locale
C', simple way to reproduce:
# select to_tsquery('default', '''New York''');
server closed the
On Jan 11, 2007, at 10:35 , Richard Troy wrote:
On Wed, 10 Jan 2007, Jim C. Nasby wrote:
On Thu, Jan 11, 2007 at 08:04:41AM +0900, Michael Glaesemann wrote:
Wouldn't there be some value to knowing whether the patch failed
due to
bitrot vs it just didn't work on some platforms out of the
On Sep 17, 2006, at 2:34 , Tom Lane wrote:
Back when we converted src/timezone to use int64 for pg_time_t, we
wondered what to do about extending the compiled timezone data file
format for int64, so that it would work for years beyound 2038. We
shelved the problem waiting to see what the
On Jan 11, 2007, at 12:51 , Tom Lane wrote:
Michael Glaesemann [EMAIL PROTECTED] writes:
Did this get fixed? I don't see it in the release notes for 8.2 or on
the current TODO.
No, nothing's been done. It's going to be a minor PITA, likely, since
our sources have diverged from upstream ---
Bruce Momjian [EMAIL PROTECTED] writes:
Joachim Wieland wrote:
Attached is a patch that adds a --regression option to ecpg.
I have added a checklist item to update the ecpg regression output for
major release bumps. I think that is the easiest solution at this
point.
While I can't say
Michael Glaesemann wrote:
On Jan 11, 2007, at 12:51 , Tom Lane wrote:
Michael Glaesemann [EMAIL PROTECTED] writes:
Did this get fixed? I don't see it in the release notes for 8.2 or on
the current TODO.
No, nothing's been done. It's going to be a minor PITA, likely, since
our
Hi everyone
Was running a VACUUM on a database on a partition which was running out
of disk space. During VACUUM the server process died and failed to restart.
Running PostgreSQL 8.1.4
I basically want to get the system back up and running ASAP with as
little data loss as possible. All and
Warren Guy wrote:
Hi everyone
Was running a VACUUM on a database on a partition which was running out
of disk space. During VACUUM the server process died and failed to restart.
Running PostgreSQL 8.1.4
...
Jan 11 15:02:39 marshall postgres[73909]: [5-1] FATAL: the database
system is
On Wed, Jan 10, 2007 at 11:31:41PM -0500, Tom Lane wrote:
While I can't say whether Joachim's patch is the cleanest way, surely
we will not condemn ourselves to fixing this manually in every future
release cycle.
I couldn't agree more. The reason why I haven't committed Joachim's
patch yet is
On Wed, Jan 10, 2007 at 11:50:10PM -0500, Bruce Momjian wrote:
I think we need to hear from Michael wither that version number in the C
file is needed.
It certainly is not for regression testing. However, I think it should
be there for production use so people know how they created those .c
what really is the motivation for keeping some of the tested binaries in
the sourcetree when doing installcheck?
As opposed to what? We're certainly not going to *install* regress.so,
and I can't see requiring contrib to be there either. These are test
files, not part of the
Heikki Linnakangas wrote:
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Patch applied. Thanks.
I added a comment about the unused bits in the header file.
Has anyone bothered to measure the overhead added by having to mask to
fetch or store the natts
Tom Lane wrote:
Gavin Sherry [EMAIL PROTECTED] writes:
Can we be sure that a BCC build libpq is even safe to use given the
problems seen when using psql?
Well, I'd not trust it a lot, but surely we have to get it to build
before anyone can debug it ...
It does build, but the report is
Alvaro Herrera wrote:
Bruce Momjian wrote:
Tom Lane wrote:
Gavin Sherry [EMAIL PROTECTED] writes:
Can we be sure that a BCC build libpq is even safe to use given the
problems seen when using psql?
Well, I'd not trust it a lot, but surely we have to get it to build
before
On Sat, Jan 06, 2007 at 09:20:53PM -0500, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Simon Riggs wrote:
Reason for no documentation was that CREATE INDEX and CREATE TABLE AS
SELECT already use this optimisation, but to my knowledge neither was/is
documented on those command
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
in src/include/port/solaris.h we define it to little endian only for
__i386 - however in 64bit mode the compiler only defines __amd64 causing
YTE_ORDER to be undefined.
The other option would be to use __x86 which is defined on all intel
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
on an Intel based Solaris 10U2 box using Sun Studio 11 with
-xarch=generic64 we get a compile time failure in contrib/pgcrypto
because BYTE_ORDER is not defined.
After further thought I changed this to handle either __amd64 or
__x86_64 (or both).
Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
on an Intel based Solaris 10U2 box using Sun Studio 11 with
-xarch=generic64 we get a compile time failure in contrib/pgcrypto
because BYTE_ORDER is not defined.
After further thought I changed this to handle either __amd64 or
On 1/10/07, Alvaro Herrera [EMAIL PROTECTED] wrote:
What about a Mingw or VC++ psql with a BCC libpq? Is it possible to
link something like that?
It would be nice to have the libpq at least able to pass the regression
tests.
you can use microsoft/mingw compiled DLL files but not library
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
... why is NAMEDATALEN exported at all?)
I think because it used to be used in libpq's notification structure.
Yeah, you're probably right. Maybe we should take it out of
postgres_ext.h and move it to
Simon Riggs wrote:
On Fri, 2007-01-05 at 22:57 -0500, Tom Lane wrote:
Jim Nasby [EMAIL PROTECTED] writes:
On Jan 5, 2007, at 6:30 AM, Zeugswetter Andreas ADI SD wrote:
Ok, so when you need CRC's on a replicate (but not on the master) you
Which sounds to me like a good reason to
42 matches
Mail list logo
