Sent: Tuesday, March 27, 2007 6:39 AM
To: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Concurrent connections in psql
Would people be interested in this feature? There was some positive reaction
from users but I'm not sure how excited developers are about complicating
the
logic in psql
Tom Lane wrote:
"Simon Riggs" <[EMAIL PROTECTED]> writes:
I would love, love, love to be able to use this syntax within pg_dump as
well, so we can create multiple indexes in parallel at restore time.
I can hardly conceive of greater folly than putting an *experimental*
psql facility into pg_du
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> I would love, love, love to be able to use this syntax within pg_dump as
> well, so we can create multiple indexes in parallel at restore time.
I can hardly conceive of greater folly than putting an *experimental*
psql facility into pg_dump scripts, ther
Simon Riggs wrote:
On Tue, 2007-03-27 at 17:11 -0400, Andrew Dunstan wrote:
Simon Riggs wrote:
I would love, love, love to be able to use this syntax within pg_dump as
well, so we can create multiple indexes in parallel at restore time.
Anyone fancy adding that as well? We should be abl
On Tue, 2007-03-27 at 17:11 -0400, Andrew Dunstan wrote:
> Simon Riggs wrote:
> >
> > I would love, love, love to be able to use this syntax within pg_dump as
> > well, so we can create multiple indexes in parallel at restore time.
> > Anyone fancy adding that as well? We should be able to speed up
Simon Riggs wrote:
I would love, love, love to be able to use this syntax within pg_dump as
well, so we can create multiple indexes in parallel at restore time.
Anyone fancy adding that as well? We should be able to speed up overall
index builds by x2 using concurrent builds.
You will need
On Tue, 2007-03-27 at 18:16 +0100, Heikki Linnakangas wrote:
> Bruce Momjian wrote:
> > Yes, yes. I would like to have used it when testing the MyProc->xmin
> > improvements. The only thing that has held it back from being applied
> > was that there was no documentation/examples of how it would b
Sent: Tuesday, March 27, 2007 6:39 AM
To: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Concurrent connections in psql
Would people be interested in this feature? There was some positive reaction
from users but I'm not sure how excited developers are about complicating
the
logic in psql
Bruce Momjian wrote:
Yes, yes. I would like to have used it when testing the MyProc->xmin
improvements. The only thing that has held it back from being applied
was that there was no documentation/examples of how it would be used.
Hear hear! I had trouble writing regression tests for the MVCC-
Yes, yes. I would like to have used it when testing the MyProc->xmin
improvements. The only thing that has held it back from being applied
was that there was no documentation/examples of how it would be used.
---
Gregory S
Would people be interested in this feature? There was some positive reaction
from users but I'm not sure how excited developers are about complicating the
logic in psql (which is already pretty tangled).
This code bitrotted severely when Tom added the cursor support to psql. I
don't mind redoing
Sounds like good reason to get it in early... :)
It would be nice if there were some tests for this/that used this...
wasn't there a patch for that floating around somewhere?
On Sat, Jan 20, 2007 at 05:11:25PM -0500, Bruce Momjian wrote:
>
> What are people's opinions on this patch? (It is at t
What are people's opinions on this patch? (It is at the URL below.)
I like the capability, and am impressed it allowed testing that found
some concurrency bugs in our server, but it is a large patch to psql.
---
Gregory St
On Tue, 2006-12-12 at 18:54 -0500, Gregory Stark wrote:
> A brief explanation including an example regression test (the SAVEPOINT
> locking bug discovered recently) and the patch here:
>
> http://community.enterprisedb.com/concurrent/index.html
>
One of the original inspirations for this was
I mentioned this a while back, now that 8.2 is out perhaps others will be more
interested in new code.
Currently Postgres regression tests only test functionality within a single
session. There are no regression tests that test the transaction semantics or
locking behaviour across multiple transa
15 matches
Mail list logo
