From: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-patches(at)postgresql(dot)org |
Subject: | Re: COPY with no WAL, in certain circumstances |
Date: | 2007-01-06 17:54:03 |
Message-ID: | 1168106043.20486.4.camel@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
> > BEGIN;
> > CREATE TABLE foo...
> > INSERT INTO foo VALUES ('1');
> > COPY foo...
> >
> > COMMIT;
>
> On ABORT, the entire table disappears, as well as the INSERT, so I don't
> see any problem. I assume the INSERT is WAL logged.
No I don't see any problems, I am just trying to understand the
boundaries. E.g., is there some weird limitation where if I have any
values in the table before the copy (like the example above) that copy
will go through WAL.
Or in other words, does this patch mean that all COPY execution that is
within a transaction will ignore WAL?
Joshua D. Drake
>
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-01-06 18:05:01 | Re: Parsing ambiguity for ORDER BY ... NULLS FIRST/LAST |
Previous Message | Tom Lane | 2007-01-06 17:41:30 | Re: COPY with no WAL, in certain circumstances |
From | Date | Subject | |
---|---|---|---|
Next Message | Euler Taveira de Oliveira | 2007-01-06 18:41:57 | Re: COPY with no WAL, in certain circumstances |
Previous Message | Tom Lane | 2007-01-06 17:41:30 | Re: COPY with no WAL, in certain circumstances |