Bruce Momjian writes:
> Can we remove the BEOS-specific code? I don't think anyone has reported
> it working for quite a few releases. If someone wants to take it up
> later, they can pull from the CVS commit that removed it.
I think pulling it during beta is inappropriate: there's some small r
Gavin Sherry <[EMAIL PROTECTED]> writes:
> On Sat, 17 Sep 2005, Tom Lane wrote:
>> It'd be real interesting to see comparable numbers from some non-Linux
>> kernels, particularly commercial systems like Solaris.
> Did you see the Solaris results I posted?
Are you speaking of
http://archives.postg
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> So, the only callers of both has already acquired appropiate locks at
> the relation level -- nobody is going to be modifying the blocks while
> they proceed. So why bother locking the pages at all? Is there a
> reason or is this an historical accident
On Sat, 17 Sep 2005, Tom Lane wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > * Greg Stark ([EMAIL PROTECTED]) wrote:
> >> However I was under the impression that 2.6 had moved beyond that problem.
> >> It would be very interesting to know if 2.6 still suffers from this.
>
> > The tests on
Stephen Frost <[EMAIL PROTECTED]> writes:
> * Greg Stark ([EMAIL PROTECTED]) wrote:
>> However I was under the impression that 2.6 had moved beyond that problem.
>> It would be very interesting to know if 2.6 still suffers from this.
> The tests on the em64t at my place were using 2.6.12. I had t
Simon Riggs wrote:
> >Alvaro Herrera
> > On Fri, Sep 16, 2005 at 03:41:11PM -0400, Bruce Momjian wrote:
> > > > I have updated the message to:
> > > >
> > > > errmsg("canceling query due to user request or
> > statement timeout")));
> > >
> > > Oops. Did we freeze the message strings already
Can we remove the BEOS-specific code? I don't think anyone has reported
it working for quite a few releases. If someone wants to take it up
later, they can pull from the CVS commit that removed it.
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us
Simon Riggs wrote:
> > From: Bruce Momjian [mailto:[EMAIL PROTECTED]
> > I don't see why printing the query cancel from a timeout is any more
> > special than a user request for cancel or a simple query error. If
> > users want statements to be printed on error, they will
> > configure things
> >
>Alvaro Herrera
> On Fri, Sep 16, 2005 at 03:41:11PM -0400, Bruce Momjian wrote:
> > > I have updated the message to:
> > >
> > > errmsg("canceling query due to user request or
> statement timeout")));
> >
> > Oops. Did we freeze the message strings already for this release?
>
> Not yet.
>
>
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]
> I don't see why printing the query cancel from a timeout is any more
> special than a user request for cancel or a simple query error. If
> users want statements to be printed on error, they will
> configure things
> that way, if not, we should not
> Alvaro Herrera wrote
> The only caller of both is
> repair_frag, whose only caller in turn is full_vacuum_rel.
...bgwriter still needs to access blocks. The WAL system relies on the
locking behaviour for recoverability, see comments in LockBuffer() and
SyncOneBuffer().
...I do think there's lot
I'm probably wrong, but I thought vacuum may invalidate stuff which
semi-required the cache to be flushed. :) I'll go take a
look through as-well but it's hard to imagine this being overlooked for
so long.
Sorry Alvaro, I haven't gone out to look at vacuum in awhile so I ain't much help.
On 9/16
Bruce Momjian wrote:
> Well, from the application writer perspective, you are right it doesn't
> make sense,
This is exactly what the end user is going to say.
> but this is only because jdbc is using prepare internally.
Isn't this mostly irrelevant to the result we want to see? It's a detail
On Fri, Sep 16, 2005 at 04:41:39PM -0400, Jonah H. Harris wrote:
> Was it relcache related?
I don't see how -- any user of a relcache entry needs to heap_open() or
relation_open() the table and acquire an appropiate lock. Any such call
would block because of the lock that VACUUM FULL acquires on
On Fri, Sep 16, 2005 at 03:41:11PM -0400, Bruce Momjian wrote:
> pgman wrote:
> > I have updated the message to:
> >
> > errmsg("canceling query due to user request or statement timeout")));
>
> Oops. Did we freeze the message strings already for this release?
Not yet.
I'm not sure I agr
Was it relcache related?On 9/16/05, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
Hackers,I'm reading the vacuum code and I just noticed that the routinesmove_plain_tuple and move_chain_tuple expect the dest and source blocksto be locked, and unlock them at exit. The only caller of both is
repair_frag
pgman wrote:
> Simon Riggs wrote:
> > Currently, when we set a statement_timeout and a query runs over that
> > time there is no log message to say that the statement has timed out. We
> > do get a message which says
> > ERROR: canceling query due to user request
> > and so in the server log
* Greg Stark ([EMAIL PROTECTED]) wrote:
> However I was under the impression that 2.6 had moved beyond that problem.
> It would be very interesting to know if 2.6 still suffers from this.
The tests on the em64t at my place were using 2.6.12. I had thought 2.6
was better about this too, but I don'
Simon Riggs wrote:
> Currently, when we set a statement_timeout and a query runs over that
> time there is no log message to say that the statement has timed out. We
> do get a message which says
> ERROR: canceling query due to user request
> and so in the server log it is impossible to tel
Josh Berkus writes:
> Tom,
>
> > What I think this means is that the kernel is scheduling the 2 processes
> > onto 2 processors chosen-at-random, without awareness of whether those
> > two processors are on the same chip (in the Xeon case) or have closer
> > NUMA affinity (in the Opteron case).
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> Hello
>
> I am testing comformity between PostgreSQL and Oracle. I found one difference.
> Century started 1900-01-01 for Oracle and 1901-01-01 for PostgreSQL. What
> value
> is good?
out of curiosity, what was your actual test?
--
greg
'k, beta2 is bundled and available on the main ftp server ... will
propogate over the next little while to the various mirrors ... the
announcement for this will go out late Sun/early Mon, to give Dave a
chance to get the Windows Installer built and available at the same time
...
I'm going
On Fri, Sep 16, 2005 at 09:28:39AM -0600, Michael Fuhr wrote:
> FWIW, I have a Solaris 9/sparc box with gcc 3.4.2 (same setup as
> gerbil) and have no problems with REL7_2_STABLE through HEAD. I'll
> test REL8_0_STABLE with gerbil's configure options when I get a
> chance.
I just built REL8_0_STA
Added to TODO:
* Update Bonjour to work with newer cross-platform SDK
---
Sandy McArthur wrote:
> FYI: The DNSServiceDiscovery.h is Mac OS X specific and only kept
> around for Mac OS X 10.2 and older compatiabilit
Patrick Welche wrote:
> On Fri, Sep 16, 2005 at 06:36:56AM -0400, Bruce Momjian wrote:
> >
> > This has been saved for the 8.2 release:
>
> It isn't actually a patch for application yet ;-) It is the function in
> a state that is easy to test. I take it that as I have basically had
> no comments
This is now in the TODO list:
* Merge xmin/xmax/cmin/cmax back into three header fields
Before subtransactions, there used to be only three fields needed to
store these four values. This was possible because only the current
transaction looks at the cmin/cmax values. If the current transac
Tom,
> What I think this means is that the kernel is scheduling the 2 processes
> onto 2 processors chosen-at-random, without awareness of whether those
> two processors are on the same chip (in the Xeon case) or have closer
> NUMA affinity (in the Opteron case).
That would be consistent with my
Hackers,
I'm reading the vacuum code and I just noticed that the routines
move_plain_tuple and move_chain_tuple expect the dest and source blocks
to be locked, and unlock them at exit. The only caller of both is
repair_frag, whose only caller in turn is full_vacuum_rel. Same thing
for update_hin
Darcy Buskermolen wrote:
On Thursday 04 August 2005 09:37, Gavin M. Roy wrote:
You can send it to me, and ehpg will host it. I'll send you a
private email with my info.
Gavin
On Aug 4, 2005, at 8:26 AM, Mark Woodward wrote:
It is 4.4G in space in a gzip package.
I'll mail a DVD to two peo
On Fri, Sep 16, 2005 at 07:57:08AM -0700, Joshua D. Drake wrote:
> >What's holding up the back branches at the moment is that the gerbil
> >buildfarm member is showing failures in the 8.0 branch that started
> >right after I patched the vacuum/ctid-chain stuff. That probably
> >indicates a problem
Oliver Jowett wrote:
> Bruce Momjian wrote:
>
> > I think it is more verbose because no FETCH is logged in this type of
> > prepare/execute. The goal, I think, is for these type of queries to
> > look as similar to normal PREPARE/EXECUTE and DECLARE/FETCH as possible.
>
> I do not understand why
On Fri, Sep 16, 2005 at 06:36:56AM -0400, Bruce Momjian wrote:
>
> This has been saved for the 8.2 release:
It isn't actually a patch for application yet ;-) It is the function in
a state that is easy to test. I take it that as I have basically had
no comments back, I will just go ahead and make
Oliver Jowett wrote:
> Bruce Momjian wrote:
>
> > We don't have a log_statement = verbose mode.
>
> Please see my earlier email where I suggested adding one if you really
> wanted all this protocol-level detail logged.
We can't add that in feature freeze/beta, at least.
--
Bruce Momjian
What's holding up the back branches at the moment is that the gerbil
buildfarm member is showing failures in the 8.0 branch that started
right after I patched the vacuum/ctid-chain stuff. That probably
indicates a problem, but the owner of the machine has been completely
unhelpful about providi
Am Donnerstag, 15. September 2005 05:04 schrieb Tom Lane:
> I'm not sure that "inverse OR distributive law" is standard terminology,
> but I believe the implication in the other direction is usually called
> the "OR distributive law". Anyone know of better terminology?
It's still the "OR distribu
Raghavendra Reddy <[EMAIL PROTECTED]> writes:
> While inserting numeric data type into a table can you please let me
> know how you are storing the value in the database.
>From src/include/utils/numeric.h:
/*
* The Numeric data type stored in the database
*
* NOTE: by convention, values
Devrim Gunduz <[EMAIL PROTECTED]> writes:
> After / before 8.1 Beta 2, are there any plans to release new dot releases
> for the back branches?
Some day ;-)
What's holding up the back branches at the moment is that the gerbil
buildfarm member is showing failures in the 8.0 branch that started
ri
> -Original Message-
> From: Neil Conway [mailto:[EMAIL PROTECTED]
> Sent: 16 September 2005 14:57
> To: Dave Page
> Cc: Marc G. Fournier; pgsql-hackers@postgresql.org
> Subject: RE: [HACKERS] Beta2 Wrap Up ...
>
> On Fri, 2005-16-09 at 08:47 +0100, Dave Page wrote:
> > Perhaps you cou
On Fri, 2005-16-09 at 08:47 +0100, Dave Page wrote:
> Perhaps you could allow 24 hours before committing potentially
> controversial changes in future?
My apologies for the rush -- I normally would wait longer for a
consensus. In fact, I _was_ waiting for a consensus until I saw that the
wrap for
Dave Page wrote:
[mailto:[EMAIL PROTECTED] On Behalf Of Tony Caduto
With there be a win32 version of beta2? or a beta1?
There will be a beta2. There was no beta1 because it didn't compile on
Windows due to an issue with ipv6, however there is already a post-beta1
release available at
Title: Message
Hi,
I have a query on sql_numeric
datatype Can you please clarify on this?
While inserting numeric data type into a
table can you please let me know how you are storing the value in the
database.
Whether it is stored as double or character or
directly st
Pavel Stehule wrote:
Hello
I am testing comformity between PostgreSQL and Oracle. I found one
difference. Century started 1900-01-01 for Oracle and 1901-01-01 for
PostgreSQL. What value is good?
Hello,
I think that 1901 is the correct year.
( The first century started in year 1 and ended i
Bruce Momjian wrote:
I think it is more verbose because no FETCH is logged in this type of
prepare/execute. The goal, I think, is for these type of queries to
look as similar to normal PREPARE/EXECUTE and DECLARE/FETCH as possible.
I do not understand why this is a useful thing to do as part
Bruce Momjian wrote:
We don't have a log_statement = verbose mode.
Please see my earlier email where I suggested adding one if you really
wanted all this protocol-level detail logged.
-O
---(end of broadcast)---
TIP 1: if posting/reading thro
Oliver Jowett wrote:
> Simon Riggs wrote:
>
> > Are we sure there is just 3 cases?
>
> I haven't exhaustively checked, but I think those are the main cases.
>
> > Even if case (3) is not that common, I still want to know it is
> > occurring, to see what effect or overhead it has.
>
> I don't wa
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Si
It occurs to me that there is no longer any great need to have a
separate hackers list for win32 development. Perhaps we should close it
down now and keep all development on -hackers?
Regards, Dave.
---(end of broadcast)---
TIP 5: don't forget to in
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Tony Caduto
> Sent: 16 September 2005 11:19
> To: pgsql-hackers@postgresql.org
> Subject: [HACKERS] 8.1 win32 beta?
>
> With there be a win32 version of beta2? or a beta1?
There will be a beta2. Th
Tony Caduto napsal(a):
With there be a win32 version of beta2? or a beta1?
ftp://ftp.postgresql.org/pub/binary/v8.1beta/win32/
(join -hackers-win32 if you want to be informed about win32 specific stuff)
--
Regards
Petr Jelinek (PJMODOS)
www.parba.cz
---(end of broadca
Hello
I am testing comformity between PostgreSQL and Oracle. I found one
difference. Century started 1900-01-01 for Oracle and 1901-01-01 for
PostgreSQL. What value is good?
Best regards
Pavel Stehule
_
Chcete sdilet sve obrazky
This has been saved for the 8.2 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Patrick Welche wrote:
> Ilya Kovalenko posted some code at in a thread starting at
>
> http://archives.postgresql.
With there be a win32 version of beta2? or a beta1?
Thanks,
Tony
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
Hi,
After / before 8.1 Beta 2, are there any plans to release new dot releases
for the back branches?
Regards,
--
Devrim GUNDUZ
Kivi Bilişim Teknolojileri - http://www.kivi.com.tr
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Neil Conway
> Sent: 16 September 2005 06:38
> To: Marc G. Fournier
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Beta2 Wrap Up ...
>
> On Thu, 2005-15-09 at 22:06 -0400, Neil Conway wr
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Neil Conway
> Sent: 16 September 2005 03:48
> To: Tom Lane
> Cc: Marc G. Fournier; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Beta2 Wrap Up ...
>
> On Thu, 2005-15-09 at 22:31 -0400, Tom
I thought I'd throw SPARC into the equation (SPARC IIIi, in a dual SunFire
v250):
vanilla HEAD from ~1 week ago:
bash-3.00$ for i in 1 2 4; do time ./nrun.sh $i; done
real1m49.037s
user0m0.008s
sys 0m0.016s
real2m3.482s
user0m0.014s
sys 0m0.026s
real3m54.215s
user
56 matches
Mail list logo
