I think that the feature you're looking for is a SAVEPOINT.
After the import, create a savepoint, and then if the user makes a typo
revert to that savepoint.
Regards,
Jeff Davis
On Sun, 2005-02-20 at 22:05 -0500, Edwin S. Ramirez wrote:
> Hello,
>
> This may sound familiar since the
> "Sergey E. Koposov" <[EMAIL PROTECTED]> writes:
> > LOOP
> > FETCH cur into rec;
> > RETURN NEXT rec;
> > EXIT WHEN NOT FOUND;
> > END LOOP;
> > RETURN;
>
> Don't you think you should have the EXIT *above* the RETURN NEXT?
> I would expect this to emit a bogus row of null
Hello,
This may sound familiar since there was a discussion before...
I created an importing tool which allows users to load data into their
tables using a graphical interface.
The import operations occur within a transaction so that the user gets a
chance to change their mind.
After the impor
> Jim C. Nasby wrote:
>> On Mon, Feb 14, 2005 at 09:55:38AM -0800, Ron Mayer wrote:
>>
>> > I still suspect that the correct way to do it would not be
>> > to use the single "correlation", but 2 stats - one for estimating
>> > how sequential/random accesses would be; and one for estimating
>> > the
Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > The advantage of using a counter instead of a simple active
> > bit is that buffers that are (or have been) used heavily will be able to
> > go through several sweeps of the clock before being freed. Infrequently
> > used buffers (suc
On Sun, 20 Feb 2005, Tom Lane wrote:
Hmm, all of those should work (and do work here). Are the corresponding
files present in the appropriate installation directory? Look under
.../share/postgresql/timezone/
They are not; it's evidently a problem with the way the NetBSD package
installs things. I
Peter Bierman <[EMAIL PROTECTED]> writes:
> I think the intent of fsync() is closer to what you describe, but the
> convention is that fsync() hands responsibility to the disk hardware.
The "convention" was also that the hardware didn't confirm the command until
it had actually been executed...
Curt Sampson <[EMAIL PROTECTED]> writes:
> I'm running PostgreSQL 8.0.1 from the NetBSD pkgsrc package. I'm getting some
> odd behavior with time zone names:
> SET timezone TO 'EST';
> psql:z.sql:2: ERROR: unrecognized time zone name: "EST"
> SET timezone TO 'Asia/Tokyo';
> ps
Neil Conway <[EMAIL PROTECTED]> writes:
> On Sat, 2005-02-19 at 14:35 -0500, Tom Lane wrote:
>> Good catch. I've applied the attached patch (this is against 8.0/CVS
>> tip but applies with some fuzz to 7.4).
> Is there a way to repro this via SQL? (It would be nice to have a
> regression test...)
On Sat, 2005-02-19 at 14:35 -0500, Tom Lane wrote:
> Good catch. I've applied the attached patch (this is against 8.0/CVS
> tip but applies with some fuzz to 7.4).
Is there a way to repro this via SQL? (It would be nice to have a
regression test...)
-Neil
---(end of br
I'm running PostgreSQL 8.0.1 from the NetBSD pkgsrc package. I'm getting some
odd behavior with time zone names:
SET timezone TO 'JST';
psql:z.sql:1: ERROR: unrecognized time zone name: "JST"
SET timezone TO 'EST';
psql:z.sql:2: ERROR: unrecognized time zone name: "EST"
SET ti
At 12:38 AM -0500 2/20/05, Tom Lane wrote:
Dominic Giampaolo <[EMAIL PROTECTED]> writes:
I believe that what the above comment refers to is the fact that
fsync() is not sufficient to guarantee that your data is on stable
storage and on MacOS X we provide a fcntl(), called F_FULLFSYNC,
to ask th
[EMAIL PROTECTED] writes:
> Well I tried it out and on OS/2 using 8.0 it has the same problems as on
> Linux, with two clients running on a dual PIII 750 both CPUs go to 100%
> and the system is madly switching between the two processes. With a
> single client, about 35% CPU is used.
> Should the
Thanks
Well I tried it out and on OS/2 using 8.0 it has the same problems as on
Linux, with two clients running on a dual PIII 750 both CPUs go to 100%
and the system is madly switching between the two processes. With a
single client, about 35% CPU is used.
Should the new buffer manager patch el
As of CVS tip, there is no code in the system that uses SnapshotSelf.
I am wondering if we can get rid of it and thereby save one test in
the heavily used HeapTupleSatisfiesVisibility() macro.
There is one place in the foreign-key triggers that uses the underlying
HeapTupleSatisfiesItself() test d
Bruce Momjian wrote:
Jim C. Nasby wrote:
On Mon, Feb 14, 2005 at 09:55:38AM -0800, Ron Mayer wrote:
I still suspect that the correct way to do it would not be
to use the single "correlation", but 2 stats - one for estimating
how sequential/random accesses would be; and one for estimating
the numbe
Tom Lane wrote:
The question is whether we are willing to back-patch a fairly large
amount of not-very-well-tested code into 8.0. See
http://archives.postgresql.org/pgsql-patches/2005-02/msg00123.php
http://archives.postgresql.org/pgsql-committers/2005-02/msg00127.php
http://archives.postgresql.or
>> One point that I no longer recall the reasoning behind is that xlog.c
>> doesn't think O_SYNC is a preferable default over fsync.
>
>For larger (>8k) transactions O_SYNC|O_DIRECT is only good
>with the recent
>pending patch to group WAL writes together. The fsync method
>gives the OS a
>cha
Jim C. Nasby wrote:
> On Mon, Feb 14, 2005 at 09:55:38AM -0800, Ron Mayer wrote:
>
> > I still suspect that the correct way to do it would not be
> > to use the single "correlation", but 2 stats - one for estimating
> > how sequential/random accesses would be; and one for estimating
> > the numbe
[EMAIL PROTECTED] writes:
> There was a mention of a "context-swap-storm" test in the posts on the ARC
> patent. Where might I obtain a copy of this test procedure?
http://archives.postgresql.org/pgsql-performance/2004-04/msg00280.php
(The archiver seems to have lost the message's separation into
>> Portability, or rather the complete lack of it. Stuff that
>isn't in the
>> Single Unix Spec is a hard sell.
>
>O_DIRECT is reasonably common among modern Unixen (it is supported by
>Linux, FreeBSD, and probably a couple of the commercial variants like
>AIX or IRIX); it should also be reason
There was a mention of a "context-swap-storm" test in the posts on the ARC
patent. Where might I obtain a copy of this test procedure?
Thanks
--
---
[EMAIL PROTECTED]
---
---
Peter Bierman <[EMAIL PROTECTED]> writes:
> > In most cases you do not need such a heavy handed operation and fsync() is
> > good enough.
Really? Can you think of a single application for which this definition of
fsync is useful?
Kernel buffers are transparent to the application, just as the di
Robert Treat <[EMAIL PROTECTED]> writes:
> One of us is not understanding the other :-) I'm asking if I have a piece of
> code that does something like select attname from pg_attribute where attrelid
> = 'stock'::regclass::oid with the intent of displaying all those attnames,
> then the "system a
>> Magnus prepared a trivial patch which added the O_SYNC flag
>> for windows and mapped it to FILE_FLAG_WRITE_THROUGH in
>> win32_open.c.
>
>Attached is this trivial patch. As Merlin says, it needs some more
>reliability testing. But the numbers are at least reasonable - it
>*seems* like it's d
On Sun, 20 Feb 2005 [EMAIL PROTECTED] wrote:
> > On Sun, 20 Feb 2005 [EMAIL PROTECTED] wrote:
> >
> >> > On Sat, Feb 19, 2005 at 18:04:42 -0500,
> >> >>
> >> >> Now, lets imagine PostgreSQL is being developed by a large company.
> >> QA
> >> >> announces it has found a bug that will cause all the
On Sunday 20 February 2005 00:25, Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > If I am understanding this correctly, they could only be displayed if
> > selected explicitly right?
>
> That's always been true. The behavior at the level of SQL commands
> wouldn't change. The quest
> On Sun, 20 Feb 2005 [EMAIL PROTECTED] wrote:
>
>> > On Sat, Feb 19, 2005 at 18:04:42 -0500,
>> >>
>> >> Now, lets imagine PostgreSQL is being developed by a large company.
>> QA
>> >> announces it has found a bug that will cause all the users data to
>> >> disappear if they don't run a maintenenc
On Sun, 20 Feb 2005 [EMAIL PROTECTED] wrote:
> > On Sat, Feb 19, 2005 at 18:04:42 -0500,
> >>
> >> Now, lets imagine PostgreSQL is being developed by a large company. QA
> >> announces it has found a bug that will cause all the users data to
> >> disappear if they don't run a maintenence program c
On Sunday 20 February 2005 00:30, Tom Lane wrote:
> Mark Kirkwood <[EMAIL PROTECTED]> writes:
> > To be fair to Mark, there does seem to be an increasing number of
> > reports of this issue. In spite of the in-the-works fix for 8.1, it
> > would be a pity to see customers losing data from xid wrap-
> On Sat, Feb 19, 2005 at 18:04:42 -0500,
>>
>> Now, lets imagine PostgreSQL is being developed by a large company. QA
>> announces it has found a bug that will cause all the users data to
>> disappear if they don't run a maintenence program correctly. Vacuuming
>> one
>> or two tables is not enoug
On Sat, Feb 19, 2005 at 18:04:42 -0500,
>
> Now, lets imagine PostgreSQL is being developed by a large company. QA
> announces it has found a bug that will cause all the users data to
> disappear if they don't run a maintenence program correctly. Vacuuming one
> or two tables is not enough, you ha
32 matches
Mail list logo
