Ok, I've coded up a patch that changes the code to use a
mutex instead.
Are we asserting the problem is caused by the spinlock random
wake-up order?
Not asserting, more making a wild guess. Which I, as I said, no lnoger
really beleive in - but since the patch was already coded up it's
Simon Riggs [EMAIL PROTECTED] wrote:
Zeugswetter Andreas DCP SD [EMAIL PROTECTED] wrote:
Ok, we cannot reuse a dead tuple. Maybe we can reuse the space of a dead
tuple by reducing the tuple to it's header info.
Attached patch realizes the concept of his idea. The dead tuples will be
Greg Sabino Mullane wrote:
I think everyone realizes at this point that the PGDG is not
an official legal entity, but do we at least have a modern
statement from Core as to what it is unofficially? In other
words, the PostgreSQL Global Development Group is
composed of
Under
[Please use reply to all so the list is CC-d]
Charlie,
I guess what you're after is to make sure the WAL buffers are shipped to
the stand-by at the same time as they are committed to disk. In any
other case your desire to have the stand-by EXACTLY in sync with the
primary server will not gonna
Mark Kirkwood wrote:
Christopher Kings-Lynne wrote:
The point here is that if tuples require 50 bytes, and there are 20
bytes free on a page, pgstattuple counts 20 free bytes while FSM
ignores the page. Recording that space in the FSM will not improve
matters, it'll just risk pushing out FSM
On Sunday 12 March 2006 09:40, Magnus Hagander wrote:
Looking a my system while testing this it still loooked like it was
hanging on that plac ein the code, even though I saw no problems. So I'm
not convinced we can actually trust the stacktrace from the non-default
threads. So I don't think
On Monday 13 March 2006 09:26, Jan de Visser wrote:
On Sunday 12 March 2006 09:40, Magnus Hagander wrote:
Looking a my system while testing this it still loooked like it was
hanging on that plac ein the code, even though I saw no problems. So I'm
not convinced we can actually trust the
On 3/13/06, Dave Cramer [EMAIL PROTECTED] wrote:
One of the purposes of this as I understand it is to allow clients toget back the generated key(s). I don't see enough of the syntax tosee if this is possible with the DB2 syntax below.
I believe it would be something like
CREATE SEQUENCE
Jonah H. Harris wrote:
Again, I haven't really used it, but have read over the docs briefly.
I'm just wondering if anyone has used it and likes/dislikes it.
I guess you could get the same effect from a transaction. If there is
much network overhead you could also write a stored procedure.
On 3/13/06, Lukas Smith [EMAIL PROTECTED] wrote:
I guess you could get the same effect from a transaction. If there ismuch network overhead you could also write a stored procedure. This isobviously more direct. Due to caching I am not sure how much
performance improvement there is in doingthe
Jonah H. Harris wrote:
In the end, how is this more efficient or easy than:
INSERT INTO test_tbl VALUES (nextval('test_id_seq'), 'John Doe')
RETURNING test_id;
OR
SELECT test_id FROM NEW TABLE INSERT INTO test_tbl VALUES
(nextval('test_id_seq'), 'John Doe');
Based on your statement, this
Looking a my system while testing this it still loooked
like it was
hanging on that plac ein the code, even though I saw no
problems. So
I'm not convinced we can actually trust the stacktrace from the
non-default threads. So I don't think this patch will
actually work
:-(
Dear PostgreSQL Hackers,We got a PG 8.1 on a Debian 64 bits, which does a full backup (PITR) daily.Then we installed a Debian 32 bits (actually, it's on VMWare) and wanted to restore the previous PG cluster on it.
As there are a lot of indexes, specially GiST, pg_dump and pg_restore are not viable
On Monday 13 March 2006 12:27, Magnus Hagander wrote:
Great. That'll certainly help - now you don't have to wait for
binaries from me.
What I'd be interested in seeing is new stackdumps from a version
where
you:
1) Do *not* have the patch for mutexes applied
2) Have removed
On Sun, 12 Mar 2006, Jonah H. Harris wrote:
I was talking with Jonathan Gennick about the INS/UPD/DEL RETURNING stuff,
and he recommended looking into the way DB2 handles similar functionality.
After looking into it a bit, it's more inline with what Tom's suggestion was
regarding a query from
Gavin Sherry [EMAIL PROTECTED] writes:
On Sun, 12 Mar 2006, Jonah H. Harris wrote:
SELECT * FROM (FINAL | NEW | OLD) TABLE (INSERT | UPDATE | DELETE)
This doesn't solve the generated keys problem that the Java and probably
.NET interfaces have. Mind, RETURNING doesn't solve anything either.
On Mon, Mar 13, 2006 at 02:56:00PM -0300, Rodrigo Hjort wrote:
Dear PostgreSQL Hackers,
We got a PG 8.1 on a Debian 64 bits, which does a full backup (PITR) daily.
Then we installed a Debian 32 bits (actually, it's on VMWare) and wanted to
restore the previous PG cluster on it.
As there are
On 3/13/06, Rodrigo Hjort [EMAIL PROTECTED] wrote:
As
the architecture on both Linuxes are different (32 and 64 bits), I
think PGDATA/global/pg_control might contains 64 bit data such that
the 32 bits binary won't recognize or even mispell it. Am I right?
Yes, the platform architecture is key.
On 3/13/06, Tom Lane [EMAIL PROTECTED] wrote:
Also, is the front SELECT allowed to have its own WHERE, or is itconstrained to return exactly one row per inserted/updated/deleted row?
If it can have a WHERE then there's a syntactic ambiguity inSELECT ... FROM NEW TABLE UPDATE ... WHERE ...
Yes, I
Rodrigo Hjort [EMAIL PROTECTED] writes:
What could be done in order to fix it? Is there any kind of application to
translate it or the only solution was to pg_dumpall and pg_restore the
cluster?
Unfortunately pg_dump/pg_restore is going to be your only option here. The
database files are
Do you have the ability to test 8.0 on the same machine? We did some
extensive modifications to the signal stuff between 8.0 and 8.1, it'd be
interesting to see if that changed things.
I had very similar behavior some weeks back on a machine that had not
been upgraded to 8.1. It was a dual
--On Sonntag, März 12, 2006 23:52:12 -0500 Neil Conway [EMAIL PROTECTED]
wrote:
On Fri, 2006-03-10 at 11:21 +0100, Bernd Helmle wrote:
Please find attached a patch that implements SQL92-compatible updatable
views.
I'm currently reviewing this. Comments later...
ok
Please note
Hello,
Here are some background information to explain our issue and request.
We are currently planning a migration from PostgreSQL 7.4 to
PostgreSQL 8.1. We work on a medium sized database (2GB) with a rather
important activity (12 millions queries a day with peaks up to 1000
queries/s).
We are
On Mon, 13 Mar 2006, Tom Lane wrote:
Gavin Sherry [EMAIL PROTECTED] writes:
On Sun, 12 Mar 2006, Jonah H. Harris wrote:
SELECT * FROM (FINAL | NEW | OLD) TABLE (INSERT | UPDATE | DELETE)
This doesn't solve the generated keys problem that the Java and probably
.NET interfaces have. Mind,
On Sun, 2006-03-12 at 11:11 -0500, Jonah H. Harris wrote:
I was talking with Jonathan Gennick about the INS/UPD/DEL RETURNING
stuff, and he recommended looking into the way DB2 handles similar
functionality. After looking into it a bit, it's more inline with
what Tom's suggestion was
On Monday 13 March 2006 12:27, Magnus Hagander wrote:
Great. That'll certainly help - now you don't have to wait for binaries
from me.
What I'd be interested in seeing is new stackdumps from a version where
you:
1) Do *not* have the patch for mutexes applied
2) Have removed static from all
On 3/13/06, Bernd Helmle [EMAIL PROTECTED] wrote:
--On Sonntag, März 12, 2006 23:52:12 -0500 Neil Conway [EMAIL PROTECTED]
wrote:
On Fri, 2006-03-10 at 11:21 +0100, Bernd Helmle wrote:
Please find attached a patch that implements SQL92-compatible updatable
views.
I'm currently
On Sun, 2006-03-12 at 23:39 +0800, William ZHANG wrote:
Maybe you can fix it like UNIONJOIN.
Indeed, that is one option. Because the syntax is WITH [ LOCAL |
CASCADED ] CHECK OPTION, ISTM we'll actually need three new tokens:
WITH_LOCAL, WITH_CASCADED, and WITH_CHECK, which is even uglier :-(
Neil Conway [EMAIL PROTECTED] writes:
On Sun, 2006-03-12 at 23:39 +0800, William ZHANG wrote:
Maybe you can fix it like UNIONJOIN.
Indeed, that is one option.
Not any more ;-)
It would be unfortunate to revert the change, but I doubt the overhead
is very significant. Does anyone have any
A quick look at the grammar suggests that the key problem is the
opt_timezone production --- it might be that if we removed that in
favor of spelling out the alternatives at the call sites, the conflict
would go away. bison-fu is all about postponing shift/reduce decisions
until you've seen
30 matches
Mail list logo
