On Wed, Mar 15, 2006 at 01:10:41PM -0500, Tom Lane wrote:
> Joe Sunday <[EMAIL PROTECTED]> writes:
> > On Tue, Mar 14, 2006 at 11:29:57PM -0500, Tom Lane wrote:
> >> What I'd try is first letting the problem case run for a bit, then
> >> stopping it wi
1 0x100ef8a8 in ExecProcNode ()
#12 0x100edea8 in ExecutorRun ()
#13 0x1018519c in ProcessQuery ()
#14 0x10185850 in PortalRun ()
#15 0x1018084c in exec_simple_query ()
#16 0x101825b0 in PostgresMain ()
#17 0x1015510c in ServerLoop ()
#18 0x10155d80 in PostmasterMain ()
#19 0x101101e8 in main ()
On Tue, Mar 14, 2006 at 11:13:38PM -0500, Tom Lane wrote:
> Joe Sunday <[EMAIL PROTECTED]> writes:
> > On Tue, Mar 14, 2006 at 03:56:51PM -0500, Tom Lane wrote:
> >> This error should result in dumping a list of per-context memory usage
> >> into the postmaste
On Tue, Mar 14, 2006 at 03:56:51PM -0500, Tom Lane wrote:
> Joe Sunday <[EMAIL PROTECTED]> writes:
> > 8.1 grows until it uses about 4 GB, at which point it dies with the
> > following error:
> > ERROR: out of memory
> > DETAIL: Failed on request of size 8224.
mp table.
Memory according to top never goes much above 25 megs in use during the query.
8.1 grows until it uses about 4 GB, at which point it dies with the
following error:
ERROR: out of memory
DETAIL: Failed on request of size 8224.
--Joe
--
Joe Sunday <[EMAI
primary key id for my "recipe" table:
>
>SELECT NEXTVAL('recipe_id_seq') FROM receipt;
You're going to get a value for every row in receipt, which is what you're
seeing.
What you want is
SELECT NEXTVAL( 'recipe_id_seq');
--Joe
--
Joe
; the numbers when need arises is MUCH faster than subtracting timestamps and
> parsing the result of such a subtraction.
>
> Note: The 'date' data type does not have this problem. The result of two
> dates subtraction is an integer (not 'interval') which I
POSTGRESQL BUG REPORT TEMPLATE
Your name : Joe Sunday
Your email address : [EMAIL
