> 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 s
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 hav
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 :-( Pe
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.
> >
> >
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" f
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 regar
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
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 a
--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 t
> 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
"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 fil
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 ...
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 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 ther
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 eit
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 f
> 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) H
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 via
> > > 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
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 s
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 doing
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. Th
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 test_id_
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 th
One of the purposes of this as I understand it is to allow clients to
get back the generated key(s). I don't see enough of the syntax to
see if this is possible with the DB2 syntax below.
Dave
On 12-Mar-06, at 11:11 AM, Jonah H. Harris wrote:
I was talking with Jonathan Gennick about the INS
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 thin
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 pus
[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
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 inte
> > 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
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 dea
31 matches
Mail list logo
