On Fri, Jan 25, 2013 at 11:55:12AM -0800, Jeff Janes wrote:
> On Fri, Jan 25, 2013 at 9:42 AM, Robert Haas <robertmh...@gmail.com> wrote:
> > On Fri, Jan 25, 2013 at 11:59 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> >> Bruce Momjian <br...@momjian.us> writes:
> >>> On Fri, Jan 25, 2013 at 02:48:37AM +0100, Andres Freund wrote:
> >>>> FWIW, and I won't annoy anyone further after this email, now that its
> >>>> deterministic, I still think that this should be an ERROR not a WARNING.
> >>
> >>> As the FREEZE is just an optimization, I thought NOTICE, vs WARNING or
> >>> ERROR was fine. If others want this changed, please reply.
> >>
> >> The previous argument about it was "if you bothered to specify FREEZE,
> >> you probably really want/need that behavior". So I can definitely see
> >> Andres' point. Perhaps WARNING would be a suitable compromise?
> >
> > I'll vote for ERROR. I don't see why this sound be a best-effort thing.
> >
>
> +1. If I had no objection to my database getting stuffed to the gills
> with unfrozen tuples, I wouldn't have invoked the feature in the first
> place.
>
> As far as can tell, this ERROR/WARNING must occur immediately, because
> once the first tuple is inserted frozen it is too late to change ones
> mind. So the problem can be immediately fixed and retried.
>
> Except, is there perhaps some way for the user to decide to promote
> WARNINGs to ERRORs on for a given command/transaction?
OK, updated patch attached that throws an error with a more specific
message.
--
Bruce Momjian <br...@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
diff --git a/src/backend/commands/copy.c b/src/backend/commands/copy.c
new file mode 100644
index 8778e8b..ec7c311
*** a/src/backend/commands/copy.c
--- b/src/backend/commands/copy.c
*************** CopyFrom(CopyState cstate)
*** 2009,2023 ****
*
* As noted above rd_newRelfilenodeSubid is not set in all cases
* where we can apply the optimization, so in those rare cases
! * where we cannot honour the request we do so silently.
*/
! if (cstate->freeze &&
! ThereAreNoPriorRegisteredSnapshots() &&
! ThereAreNoReadyPortals() &&
! (cstate->rel->rd_newRelfilenodeSubid == GetCurrentSubTransactionId() ||
! cstate->rel->rd_createSubid == GetCurrentSubTransactionId()))
! hi_options |= HEAP_INSERT_FROZEN;
}
/*
* We need a ResultRelInfo so we can use the regular executor's
--- 2009,2029 ----
*
* As noted above rd_newRelfilenodeSubid is not set in all cases
* where we can apply the optimization, so in those rare cases
! * where we cannot honor the request.
*/
! if (cstate->freeze)
! {
! if (ThereAreNoPriorRegisteredSnapshots() &&
! ThereAreNoReadyPortals() &&
! (cstate->rel->rd_newRelfilenodeSubid == GetCurrentSubTransactionId() ||
! cstate->rel->rd_createSubid == GetCurrentSubTransactionId()))
! hi_options |= HEAP_INSERT_FROZEN;
! else
! ereport(ERROR, (errmsg("cannot perform FREEZE operation due to invalid table or transaction state")));
! }
}
+ else if (cstate->freeze)
+ ereport(ERROR, (errmsg("cannot perform FREEZE operation due to invalid table or transaction state")));
/*
* We need a ResultRelInfo so we can use the regular executor's
diff --git a/src/test/regress/expected/copy2.out b/src/test/regress/expected/copy2.out
new file mode 100644
index 78c601f..e19cc5b
*** a/src/test/regress/expected/copy2.out
--- b/src/test/regress/expected/copy2.out
*************** SELECT * FROM vistest;
*** 334,355 ****
COMMIT;
TRUNCATE vistest;
COPY vistest FROM stdin CSV FREEZE;
BEGIN;
INSERT INTO vistest VALUES ('z');
SAVEPOINT s1;
TRUNCATE vistest;
ROLLBACK TO SAVEPOINT s1;
COPY vistest FROM stdin CSV FREEZE;
! SELECT * FROM vistest;
! a
! ----
! p
! g
! z
! d3
! e
! (5 rows)
!
COMMIT;
CREATE FUNCTION truncate_in_subxact() RETURNS VOID AS
$$
--- 334,347 ----
COMMIT;
TRUNCATE vistest;
COPY vistest FROM stdin CSV FREEZE;
+ ERROR: cannot perform FREEZE operation due to invalid table or transaction state
BEGIN;
INSERT INTO vistest VALUES ('z');
SAVEPOINT s1;
TRUNCATE vistest;
ROLLBACK TO SAVEPOINT s1;
COPY vistest FROM stdin CSV FREEZE;
! ERROR: cannot perform FREEZE operation due to invalid table or transaction state
COMMIT;
CREATE FUNCTION truncate_in_subxact() RETURNS VOID AS
$$
diff --git a/src/test/regress/sql/copy2.sql b/src/test/regress/sql/copy2.sql
new file mode 100644
index 55568e6..87b847c
*** a/src/test/regress/sql/copy2.sql
--- b/src/test/regress/sql/copy2.sql
*************** COPY vistest FROM stdin CSV FREEZE;
*** 242,248 ****
d3
e
\.
- SELECT * FROM vistest;
COMMIT;
CREATE FUNCTION truncate_in_subxact() RETURNS VOID AS
$$
--- 242,247 ----
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
