On Fri, 2004-10-15 at 15:30, Tom Lane wrote:
> Au contraire: every row that gets locked will be returned to the client.
> The gripe at hand is that the number of such rows may be smaller than
> the client wished, because the LIMIT step is applied before we do the
> FOR UPDATE step
Ah, my apologies
Neil Conway <[EMAIL PROTECTED]> writes:
> On Fri, 2004-10-15 at 14:22, Tom Lane wrote:
>> What if some of the locked rows didn't get returned to the client?
> In the case of SELECT ... FOR UPDATE LIMIT x, exactly the same condition
> applies: some number of locked rows will not be returned to the
On Fri, 2004-10-15 at 14:22, Tom Lane wrote:
> Allowing FOR UPDATE in sub-selects opens a can of worms that I do not
> think we'll be able to re-can (at least not without the proverbial
> larger size of can).
Ah, I see. I had tried some trivial queries to determine if we supported
FOR UPDATE in su
Neil Conway <[EMAIL PROTECTED]> writes:
> On Wed, 2004-10-13 at 10:23, Fahad G. wrote:
>> I checked and I don't have 'readline' installed. --without-readline did the
>> trick, but shouldn't this be handled automatically?
> This is intentional
Indeed. A few releases back we did actually behave th
Neil Conway <[EMAIL PROTECTED]> writes:
> I agree backward compat is a concern, but it seems pretty clear to me
> that this is not the optimal behavior. If there are any people who
> actually need the old behavior, they can nest the FOR UPDATE in a
> FROM-clause subselect:
> SELECT * FROM foo FOR
Federico Di Gregorio <[EMAIL PROTECTED]> writes:
> On Thu, 2004-10-14 at 06:54 -0400, Tom Lane wrote:
>> I do not believe that you remembered to ANALYZE after restore.
> unfortunately for your belief, i remembered. :)
> also, this problem can be replicated at will. i can send a dump that
> expose
On Fri, Oct 15, 2004 at 12:03:39PM +1000, Neil Conway wrote:
> On Wed, 2004-10-13 at 10:23, Fahad G. wrote:
> > I checked and I don't have 'readline' installed. --without-readline did the
> > trick, but shouldn't this be handled automatically?
>
> This is intentional -- what's wrong with stopping?
On Thu, 2004-10-14 at 14:02, Tom Lane wrote:
> The FOR UPDATE part executes after the LIMIT part. Arguably this is a
> bad thing, but I'm concerned about the compatibility issues if we change
> it.
I agree backward compat is a concern, but it seems pretty clear to me
that this is not the optimal
On Wed, 2004-10-13 at 10:23, Fahad G. wrote:
> I checked and I don't have 'readline' installed. --without-readline did the
> trick, but shouldn't this be handled automatically?
This is intentional -- what's wrong with stopping? ISTM that stopping
and letting the user know what went wrong is probab
Tom,
> The FOR UPDATE part executes after the LIMIT part. Arguably this is a
> bad thing, but I'm concerned about the compatibility issues if we change
> it.
In that case, maybe I should do a doc patch warning people not to combine
them?
Hmmm come to think of it, is there any easy way to
Hi,
I just downloaded a fresh distribution of postgresql-8.0.0beta3 and tried
compiling it on a Mac OS X 10.3.5 (Panther -- fresh install), and it gave me
the following error:
sledge:~/tmp/postgresql-8.0.0beta3 sfg900$ ./configure
--prefix=/opt/postgresql-8.0.0beta3 --with-python --with-openssl -
Tom Lane wrote:
OS X has an unreasonably small limit on shared memory size; if you don't
raise it (IIRC you can do this in /etc/rc) then you don't get to have
more than one postmaster at a time.
OK, I see what you're talking about from looking in /etc/rc. You might
want to put something about
"PostgreSQL Bugs List" <[EMAIL PROTECTED]> writes:
> After a pg_dump/pg_restore (using the tar format) queries that were using
> the indices don't use them anymore until the indices are dropped and
> recreated. After that the indices are used the correct way.
I do not believe that you remembere
The following bug has been logged online:
Bug reference: 1286
Logged by: Federico Di Gregorio
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.4.5
Operating system: Debian GNU/Linux sarge
Description:indices not used after a pg_restore
Details:
We have a
> The following bug has been logged online:
>
> Bug reference: 1273
> Logged by: Werner Bohl
>
> Email address: [EMAIL PROTECTED]
>
> PostgreSQL version: 8.0 Beta
>
> Operating system: Windows XP pro
>
> Description:bad path for english.stop in tsearch2
>
> Detail
15 matches
Mail list logo
