This change isn't going to make it for RC3, and it probably not
something we want to rush.
I think there are a few issues involved:
o everyone agrees the current meaning of bgwriter_percent is
useless (percent of dirty buffers)
o removal of bgwriter_percent will caus
At 2004-12-31 23:49:35 -0500, pgman@candle.pha.pa.us wrote:
>
> With 8.0 coming out in 2005, I think I should update the copyrights on
> the files.
I don't think it actually makes any difference.
-- ams
---(end of broadcast)---
TIP 3: if posting/re
Bruce Momjian wrote:
> With 8.0 coming out in 2005, I think I should update the copyrights on
> the files.
I see Marc has already done the update. I am checking with the
src/tools/copyright to make sure he got them all. He updated legal.sgml
so I bet he got them all.
--
Bruce Momjian
With 8.0 coming out in 2005, I think I should update the copyrights on
the files.
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.
Busy day, forgot all about it :(
I've up'd all occurances of rc2 -> rc3 (so I got the win32 file in
include) ... as well as upgraded the Copyright to be 1996-2005 ... the
commit was so large that it wouldn't go through pgsql-committers, but is
in the logs ...
And I upgrade the dsssl stylesheets
Tom Lane wrote:
Pursuant to Theodore Petrosky's recent trouble report, I thought I would
see what happens if you try to build Postgres in a directory whose path
contains spaces, or if the install prefix contains spaces.
It doesn't work, not even close.
It looks to me like there are a couple of hun
On Fri, 31 Dec 2004, Tom Lane wrote:
> Michael Wildpaner <[EMAIL PROTECTED]> writes:
> > two concurrent clients try to 'COPY ... FROM ...' to the same table,
> > "feature_link".
>
> > The second one (pid 17983) is waiting for an ExclusiveLock on the table's
> > primary key index, "key__idpk__flink"
I wrote:
> A possible fix for this is to reorder the operations in FlushBuffer
> so that we share-lock the buffer before releasing BufMgrLock ... but
> I'm not sure that doesn't introduce other deadlock risks.
That's too simplistic, since at least one caller of FlushBuffer is
trying to write pages
Michael Fuhr wrote:
On Fri, Dec 31, 2004 at 03:18:39PM -0500, Andrew Dunstan wrote:
It has told you what the problem is. Use a handler for an exception that
actually exists. To see what these are, read
http://developer.postgresql.org/docs/postgres/plpgsql-errors-and-messages.html
As the
On Fri, Dec 31, 2004 at 03:18:39PM -0500, Andrew Dunstan wrote:
> It has told you what the problem is. Use a handler for an exception that
> actually exists. To see what these are, read
> http://developer.postgresql.org/docs/postgres/plpgsql-errors-and-messages.html
As the PL/pgSQL "Trapping Er
I see,
The shmem.c implementation I am using returns the OS/2 memory ID which
also happens to be the base address of the allocated memory.
Bug in shmem.c code then
Thanks
Lorne
In <[EMAIL PROTECTED]>, on 12/31/04
at 03:53 PM, Tom Lane <[EMAIL PROTECTED]> said:
>[EMAIL PROTECTED] writes:
[EMAIL PROTECTED] writes:
> I am using the sysv_shmem.c shared memory allocation api for os/2 and I
> ran into a problem when OS/2 allocates shared memory over the 2 gigabyte
> address boundary.
> The existing sysv_shmem.c tests for the return address of the segment as
> less than 0 and determines
Hi
I am using the sysv_shmem.c shared memory allocation api for os/2 and I
ran into a problem when OS/2 allocates shared memory over the 2 gigabyte
address boundary.
The existing sysv_shmem.c tests for the return address of the segment as
less than 0 and determines that a negative indicates an er
PEBKAC.
It has told you what the problem is. Use a handler for an exception that
actually exists. To see what these are, read
http://developer.postgresql.org/docs/postgres/plpgsql-errors-and-messages.html
cheers
andrew
Sibtay Abbas wrote:
hello
I am using the following sytex to handle exceptions
hello
I am using the following sytex to handle exceptions in
plpgsql (I am using postgres 8 rc1)
some code
EXCEPTION
WHEN NO_DATA THEN
RAISE NOTICE 'NO DATA';
WHEN OTHERS THEN
RAISE NOTICE 'An exception occurred';
RETURN emp_rec;
and i receive
Michael Wildpaner <[EMAIL PROTECTED]> writes:
> two concurrent clients try to 'COPY ... FROM ...' to the same table,
> "feature_link".
> The second one (pid 17983) is waiting for an ExclusiveLock on the table's
> primary key index, "key__idpk__flink".
> The first one (pid 17980) is inserting into
Tom Lane wrote:
I'm inclined to wonder why people want to run daily tests on dead
branches in the first place ;-)
Unless you explicitly force it, buildfarm will not run a test unless
there is a change on the branch being tested. I am trying gently to
persuade the buildfarm owners not to use t
Hello,
Is there any reason why TSearch (not TSearch2) is still in
contrib? TSearch is a 7.3.x module...
Sincerely,
Joshua D. Drake
--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - [EMAIL P
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> We only have a couple of buildfarm members reporting on versions older
> than 7.4. Both are RedHat based systems, and both fail the contrib
> regression suites.
> I'm inclined to have write these off as not worth fixing, and inhibit
> contrib regress
Michael Wildpaner <[EMAIL PROTECTED]> writes:
> two concurrent clients try to 'COPY ... FROM ...' to the same table,
> "feature_link".
> The second one (pid 17983) is waiting for an ExclusiveLock on the table's
> primary key index, "key__idpk__flink".
You didn't show a stack trace for this one ..
We only have a couple of buildfarm members reporting on versions older
than 7.4. Both are RedHat based systems, and both fail the contrib
regression suites.
I'm inclined to have write these off as not worth fixing, and inhibit
contrib regression tests for versions older than 7.4. in the next
r
Matthias Schmidt <[EMAIL PROTECTED]> writes:
> a) is the name uptime() OK?
Probably should use pg_uptime(), or something else starting with pg_.
> b) is the return-type 'Interval' OK?
It might be better to return the actual postmaster start time (as
timestamptz) and let the user do whatever arit
Hi,
two concurrent clients try to 'COPY ... FROM ...' to the same table,
"feature_link".
The second one (pid 17983) is waiting for an ExclusiveLock on the table's
primary key index, "key__idpk__flink".
The first one (pid 17980) is inserting into the index's btree, waiting
for a buffer lock. This
Hi Bruce,
I started to work on the uptime() for the postmaster yesterday. A
couple of questions:
a) is the name uptime() OK?
b) is the return-type 'Interval' OK?
c) does it make sense (... fit in the scheme?) to place the code here:
src/backend/utils/misc/uptime.c
d) Can I piggy-back on 'Back
On Fri, 2004-12-31 at 01:38, Marc G. Fournier wrote:
> Baring any cries of *STOP* ... I'm going to try and get it packaged first
> thing in the morning ...
>
Could I ask the Core team to vote on the bgwriter patch before RC3?
I'm in the wrong timezone to discuss this quickly.
--
Best Regards,
On Fri, 2004-12-31 at 01:14, Bruce Momjian wrote:
> Simon Riggs wrote:
> > On Mon, 2004-12-27 at 22:21, Bruce Momjian wrote:
> > > Should we consider at least adjusting the meaning of bgwriter_percent?
> >
> > Yes. As things stand, this is the only change that seems safe.
> >
> > Here's a very sh
26 matches
Mail list logo
