PostgreSQL 7.0.2
Debian 2.3 (woody)
Linux Kernel 2.2.15
Hi,
I am finding that I periodically have a backend process just 'freeze' on
me. It's not like it's doing something that all of a sudden get's
wildly inefficient because this can be when I'm repetitively processing
in a loop, and where res
POSTGRESQL BUG REPORT TEMPLATE
Your name : Robert B. Easter
Your email address : [EMAIL PROTECTED]
Andrew McMillan <[EMAIL PROTECTED]> writes:
> I am finding that I periodically have a backend process just 'freeze' on
> me.
Needs to be looked at, for sure.
> What can I do to tickle the backend processes to get it to tell me where
> it is at?
What I'd do is attach to it with gdb and poke arou
"Andrew Snow" <[EMAIL PROTECTED]> writes:
> # SELECT to_number('12,454.8-', '');
> pqReadData() -- backend closed the channel unexpectedly.
In current sources I get a NULL result, which seems to be what the
code author intended originally. However this seems a little bit
inconsistent --- shouldn
I wrote:
> Comments anyone? What exactly *should* be the behavior of an UPDATE
> that uses an aggregate function and a join to another table? Over what
> set of tuples should the aggregate be evaluated?
Further note on this: SQL99 specifies:
::=
UPDATE
Philip Warner <[EMAIL PROTECTED]> writes:
>> What do people think of my implicit-GROUP-BY-ctid idea?
>> That would basically say that the aggregate is computed over all the
>> tuples that join to a single target tuple.
> Sounds perfect to me...
Note that it would not meet your expectation that
Karel Zak <[EMAIL PROTECTED]> writes:
> On Sun, 9 Jul 2000, Tom Lane wrote:
>> "Andrew Snow" <[EMAIL PROTECTED]> writes:
# SELECT to_number('12,454.8-', '');
pqReadData() -- backend closed the channel unexpectedly.
>>
>> In current sources I get a NULL result, which seems to be what the
