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 value? This is not a zero-cost imp
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Has anyone bothered to measure the overhead added by having to mask to
fetch or store the natts value? This is not a zero-cost improvement.
I haven't tested it. Agreed, it does add an AND operation to places
where t_n
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 broadcast)-
Is there any reason for not back porting the fix into 8.1?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> Log Message:
> ---
> Change Windows rename and unlink substitutes so that they time out after
> 30 seconds instead of retrying forever. Also modify xlog.c so that if
> it fails to rename an ol
> "BM" == Bruce Momjian <[EMAIL PROTECTED]> writes:
BM> Uh, if you supply just a number with no units, is that bytes or
BM> kilobytes? Do you have to say "0B".
If you supply 0, all units should be ignored. GUC probably doesn't do
that, but it should.
/Benny
---(en
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?
--
T
Nice, thanks a lot.
Tom Lane wrote:
Teodor Sigaev <[EMAIL PROTECTED]> writes:
Just a freshing for clean applying..
http://www.sigaev.ru/misc/user_defined_typmod-0.11.gz
Applied with some revisions, and pg_dump support and regression tests
added.
regards, tom lane
---
> 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
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> Is there any reason for not back porting the fix into 8.1?
I didn't think it was adequately tested, and I'm not in a position to
test it. (Note that a lack of 8.2 bug reports isn't a sufficient test,
since I think we whacked related code around for 8.2 -
Dave Page <[EMAIL PROTECTED]> writes:
> 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?
No, I haven't got round to updating xi
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> What? I'm completely lost here. What does log_temp_files have to do with
> the bits on the tuple header?
Nothing, it looks like Bruce replied to the wrong message at one point
while these two threads were active ...
regards
Tom Lane wrote:
Dave Page <[EMAIL PROTECTED]> writes:
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?
No, I haven't got round to
"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
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
What version of PG do you use and what is your ./configure options?
Zdenek
Stefan Kaltenbrunner napsal(a):
On solaris 10U2 using the Sun compiler we get segmentation faults in
nearly all of the ECPG regression tests on a 64bit built. the resulting
cores look similiar to:
Cur
On Wed, 2007-01-10 at 10:10 -0500, Tom Lane wrote:
> "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
> interp
"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 doe
"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 Materialize node would have to communicate with the
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 connection unexpe
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
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 alre
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 assi
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 sour
Zdenek Kotala wrote:
> What version of PG do you use and what is your ./configure options?
This is on -HEAD and with the following box and setup:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=clownfish&dt=2007-01-10%2014:18:23
one does not need the --with-perl and --with-python flags t
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 imp
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 ms
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 p
> > 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
"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 a
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 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 that value would be. How
> would th
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 shoul
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 figu
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 fi
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
> > 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 gat
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 upstr
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 --- someone will have to go
through the upstre
Is there a TODO here?
---
Dave Page wrote:
> Dave Page wrote:
> >> I don't object to it in principle, but I think a bit more thought is
> >> needed as to what's the goal. A stupid "append" option would be enough
> >> for pg
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 --
Joachim Wieland wrote:
> On Fri, Jan 05, 2007 at 05:55:45PM -0500, Bruce Momjian wrote:
> > > The idea of having to do this at every version number bump is pretty
> > > unappetizing. Shouldn't we fix things so that the version number
> > > doesn't appear in the ecpg regression files?
>
> > It wou
Tom Lane wrote:
> Markus Schiltknecht <[EMAIL PROTECTED]> writes:
> > I've just found the stumbling block: the -c option of psql wraps all in
> > a transaction, as man psql says:
> > ...
> > Thank you for clarification, I wouldn't have expected that (especially
> > because CREATE DATABASE itself
Tom Lane wrote:
> 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 th
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 s
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,
Tom Lane <[EMAIL PROTECTED]> wrote:
> > What do you think dynamic allocation from shared_buffers? ie, remove
> > a buffer page in the shared buffer pool and use the 8kB of memory
> > for another purpose.
>
> The problem with that is that (a) it creates more contention load on the
> shared buffer
Hi,
i'm trying to share some info between backends but i cannot figure how
to do it...
i was reading bgwriter.c and autovacuum.c hoping there is something
that can show me the way to go...
can you, please, guide me on this?
--
regards,
Jaime Casanova
"Programming today is a race between softwa
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 a
I'd just like to point out that Warren is a mate of mine :)
I recall a time when a related issue occurred years ago:
http://groups-beta.google.com/group/comp.databases.postgresql.hackers/browse_thread/thread/c97c853f640b9ac1/d6bc3c75eed6c2a4?q=could+not+access+status+of+transaction#d6bc3c75eed6c
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 star
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 i
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 fi
> > 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 ins
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
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 rep
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 anyone can debug
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
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 th
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
> ar
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 bot
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 __
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 fi
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 i
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 goo
66 matches
Mail list logo
