Re: [HACKERS] [GENERAL] Transactions within a function body

[Bob Henkel]

Have you looked at creating a function in perl and creating a new
connection? Or using a dblink query which can create a new connection?
These two methods work. I have used them to insert to a log table regardless
of the parent transaction being commited or rolled back.

A old example I posted of using pl/perl can be found here ->
http://www.postgresqlforums.com/forums/viewtopic.php?f=4&t=647

The key is opening a new session which using dblink or pl/perl dbi
connection will do. This is not ideal or efficient.  It would be nice if you
could just do autonomous transactions natively in pl/pgsql, but I find this
method works for the cases where you need it(logging, huge batch processing
tasks where it's not ideal to process everything in one transaction).

Bob

"Hi all.
Is there a way to have (sub)transactions within a function body?
I'd like to execute some code (a transaction!) inside a function and later
decide whether that transaction is to be committed or not.
Thanks."

On Thu, Oct 2, 2008 at 10:40 AM, Alvaro Herrera
<[EMAIL PROTECTED]>wrote:

> Gurjeet Singh escribió:
>
> > I have seen this feature being asked for, and this work-around suggested
> so
> > many times. If plpgql does it internally, why not provide a clean
> interface
> > for this? Is there some road-block, or that nobody has ever tried it?
>
> Initially we aimed at just exposing SAVEPOINT and ROLLBACK TO in
> functions, but ran into the problem that the SPI stack needs to be dealt
> with appropriately and you can't do it if the user is able to modify it
> arbitrarily by calling transaction-modifying commands.  That's when the
> EXCEPTION idea came up.  We never went back and studied whether we could
> have fixed the SPI limitation, but it's not trivial.
>
> --
> Alvaro Herrera
> http://www.CommandPrompt.com/ 
> The PostgreSQL Company - Command Prompt, Inc.
>
> --
> Sent via pgsql-general mailing list ([EMAIL PROTECTED])
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>

Re: [HACKERS] Socket communication for contrib

[Bob . Henkel]

"Doesn't this encourage violation of the basic notion of a transaction?
The message will be sent immediately, whether or not the sending
transaction actually commits."

Any postgresql C coders out there that can help us out with nested
transactions?

This pretty much comes down to having nested transactions for this to be of
real use.  For example.
BEGIN

update table;
commit;
send remote message that table was updated;

when ANY exception
do error logic

END

Otherwise it doesn't really tell you anything of much value.  Though I
imagine in some rare/special case it could be of use as it stands.

Bob Henkel  651-738-5085
Mutual Funds I/T Woodbury
Hartford Life
500 Bielenberg Drive
Woodbury, MN 55125


|-+-->
| |   Tom Lane   |
| |   <[EMAIL PROTECTED]>|
| |   Sent by:   |
| |   [EMAIL PROTECTED]|
| |   tgresql.org|
| |  |
| |  |
| |   04/05/2004 09:57 AM|
| |  |
|-+-->
  
>--|
  |
  |
  |   To:   Hans-Jürgen Schönig <[EMAIL PROTECTED]>
   |
  |   cc:   [EMAIL PROTECTED]  
   |
  |   Subject:  Re: [HACKERS] Socket communication for contrib 
  |
  
>--|




=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <[EMAIL PROTECTED]> writes:
> People asked me to put a simple extension for PostgreSQL Open Source.
> The attached package contains a simple functions whichs tells a remote
> TCP socket that somebody is about to modify a certain table.

Doesn't this encourage violation of the basic notion of a transaction?
The message will be sent immediately, whether or not the sending
transaction actually commits.

 regards, tom lane

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html






*
PRIVILEGED AND CONFIDENTIAL: This communication, including attachments, is for the 
exclusive use of addressee and may contain proprietary, confidential and/or privileged 
information.  If you are not the intended recipient, any use, copying, disclosure, 
dissemination or distribution is strictly prohibited.  If you are not the intended 
recipient, please notify the sender immediately by return e-mail, delete this 
communication and destroy all copies.
*


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Re: [HACKERS] Socket communication for contrib

[Bob . Henkel]

I would be FOR it if the README states the dangers



Bob Henkel  651-738-5085
Mutual Funds I/T Woodbury
Hartford Life
500 Bielenberg Drive
Woodbury, MN 55125


|-+>
| |   Hans-Jürgen  |
| |   Schönig  |
| |   <[EMAIL PROTECTED]|
| |   c.at>|
| ||
| |   04/05/2004 10:59 |
| |   AM   |
| ||
|-+>
  
>--|
  |
  |
  |   To:   Tom Lane <[EMAIL PROTECTED]>   
  |
  |   cc:   [EMAIL PROTECTED], [EMAIL PROTECTED]   
 |
  |   Subject:  Re: [HACKERS] Socket communication for contrib 
  |
  
>--|




Tom Lane wrote:
> =?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <[EMAIL PROTECTED]> writes:
>
>>Nested transactions: I don't think nested transactions will really help
>>to resolve the core problem. Committing a subtransaction will most
>>likely not imply that a parent transaction can be committed as well.
>
>
> Agreed.
>
>
>>As I said: Some people MIGHT find it useful in some special cases.
>>If the community decides that it does not enough sense to integrate it
>>into contrib I can live with that.
>
>
> I won't take a position on whether it's useful enough to put in contrib,
> but if people want it there, I'd just ask that the README be extended to
> point out the transactional risks.

this should not be a problem.
I can intregrate all necessary information there.

folks, let's do a poll ...
who is for it - who is against it ...

 regards,

 Hans


--
Cybertec Geschwinde u Schoenig
Schoengrabern 134, A-2020 Hollabrunn, Austria
Tel: +43/2952/30706 or +43/664/233 90 75
www.cybertec.at, www.postgresql.at, kernel.cybertec.at








*
PRIVILEGED AND CONFIDENTIAL: This communication, including attachments, is for the 
exclusive use of addressee and may contain proprietary, confidential and/or privileged 
information.  If you are not the intended recipient, any use, copying, disclosure, 
dissemination or distribution is strictly prohibited.  If you are not the intended 
recipient, please notify the sender immediately by return e-mail, delete this 
communication and destroy all copies.
*


---(end of broadcast)---
TIP 8: explain analyze is your friend

Re: [HACKERS] PITR, nested transactions, tablespaces, 2-phase commit:

[Bob . Henkel]

Just so you know I'm very thankful for your hard work and I'm sure many of
us are.  I have been waiting for this kind of functionally in Postgresql!


|-+-->
| |   Heikki Linnakangas |
| |   <[EMAIL PROTECTED]>  |
| |   Sent by:   |
| |   [EMAIL PROTECTED]|
| |   tgresql.org|
| |  |
| |  |
| |   04/23/2004 12:56 PM|
| |  |
|-+-->
  
>|
  |
|
  |   To:   [EMAIL PROTECTED]  
 |
  |   cc:  
|
  |   Subject:  Re: [HACKERS] PITR, nested transactions, tablespaces, 2-phase 
commit: Status   |
  
>|




On Sat, 17 Apr 2004, Bruce Momjian wrote:

> Would folks report on the current status of these projects:
>
>o nested transactions (Alvaro Herrera)
>o tablespaces (Gavin Sherry)
>o PITR (Simon Riggs)
>o 2-phase commit (Heikki Linnakangas)

I've been very busy with at work, and haven't had much time to work on the
2-phase commit patch.

I'm keeping a close eye on Alvaro's nested transactions stuff, because it
touches the same areas as 2-phase commits.

One day, while reading postgresql code, I realized that my two-phase
code doesn't do the right thing with snapshots. GetSnapshotData scans
through all running backends, and collects the xids of all running
transactions. I suppose all pre-committed transactions should go to the
snapshot too.

So there's still some work to be done, but I'm still hoping to finish it
in time for 7.5.

- Heikki


---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly






*
PRIVILEGED AND CONFIDENTIAL: This communication, including attachments, is for the 
exclusive use of addressee and may contain proprietary, confidential and/or privileged 
information.  If you are not the intended recipient, any use, copying, disclosure, 
dissemination or distribution is strictly prohibited.  If you are not the intended 
recipient, please notify the sender immediately by return e-mail, delete this 
communication and destroy all copies.
*


---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings

Re: [HACKERS] 7.5 features

[Bob . Henkel]

I think great would be an understatement.

Great work all!




|-+-->
| |   Bruce Momjian  |
| |   <[EMAIL PROTECTED]|
| |   >  |
| |   Sent by:   |
| |   [EMAIL PROTECTED]|
| |   tgresql.org|
| |  |
| |  |
| |   04/27/2004 08:27 AM|
| |  |
|-+-->
  
>--|
  |
  |
  |   To:   PostgreSQL-development <[EMAIL PROTECTED]> 
   |
  |   cc:  
  |
  |   Subject:  [HACKERS] 7.5 features 
  |
  
>--|




Here are features that are being worked on, hopefully for 7.5:

 o  tablespaces (Gavin)
 o  nested transactions (Alvaro)
 o  two-phase commit (Heikki Linnakangas)
 o  integrated pg_autovacuum (O'Connor)
 o  PITR (Riggs)
 o  Win32 (Claudio, Magnus)

If we get the majority of them, and I think we will, this will be a
great release.

--
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania
19073

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html






*
PRIVILEGED AND CONFIDENTIAL: This communication, including attachments, is for the 
exclusive use of addressee and may contain proprietary, confidential and/or privileged 
information.  If you are not the intended recipient, any use, copying, disclosure, 
dissemination or distribution is strictly prohibited.  If you are not the intended 
recipient, please notify the sender immediately by return e-mail, delete this 
communication and destroy all copies.
*


---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] ~ crashes backend

[Bob . Henkel]

I have binary install from snapshot from the other night on WINDOWS 2000
PRO and had same problem.




|-+-->
| |   "Merlin Moncure"   |
| |   <[EMAIL PROTECTED]|
| |   ne.com>|
| |   Sent by:   |
| |   [EMAIL PROTECTED]|
| |   tgresql.org|
| |  |
| |  |
| |   05/21/2004 10:28 AM|
| |  |
|-+-->
  
>--|
  |
  |
  |   To:   <[EMAIL PROTECTED]>
 |
  |   cc:   <[EMAIL PROTECTED]>
   |
  |   Subject:  [HACKERS] ~ crashes backend
  |
  
>--|




In the current build on the anon cvs server, if I try to \d a table from
psql, the backend comes down.  I played with the query a bit and
discovered any query using '~' operator in the where clause on any table
(catalog or otherwise) causes an immediate backend crash.

Can anybody confirm that this is not happening on a win32/non-win32
build? (I had to change a couple of things to compile, just want to make
sure I didn't break anything).

I did a make clean and a brand new initdb just to be safe.

Merlin


LOG:  statement: select * from pg_catalog.pg_class where relname ~
'test';
LOG:  server process (PID 4544) was terminated by signal 5
LOG:  terminating any other active server processes
WARNING:  terminating connection because of crash of another server
process
DETAIL:  The postmaster has commanded this server process to roll back
the current transaction and exit, because another server proc
ess exited abnormally and possibly corrupted shared memory.
HINT:  In a moment you should be able to reconnect to the database and
repeat your command.
FATAL:  the database system is in recovery mode
LOG:  all server processes terminated; reinitializing
LOG:  database system was interrupted at 2004-05-21 11:22:35 Eastern
Daylight Time
LOG:  checkpoint record is at 0/EEC050
LOG:  redo record is at 0/EEC050; undo record is at 0/0; shutdown TRUE
LOG:  next transaction ID: 7678; next OID: 33592
LOG:  database system was not properly shut down; automatic recovery in
progress
LOG:  record with zero length at 0/EEC090
LOG:  redo is not required
LOG:  database system is ready
LOG:  statement: select * from chevy.cusfil limit 1;
LOG:  statement: select * from chevy.cusfil where cust_addr1 ~ 'test';
LOG:  server process (PID 5500) was terminated by signal 5
LOG:  terminating any other active server processes
WARNING:  terminating connection because of crash of another server
process
DETAIL:  The postmaster has commanded this server process to roll back
the current transaction and exit, because another server proc
ess exited abnormally and possibly corrupted shared memory.
HINT:  In a moment you should be able to reconnect to the database and
repeat your command.

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html






*
PRIVILEGED AND CONFIDENTIAL: This communication, including attachments, is for the 
exclusive use of addressee and may contain proprietary, confidential and/or privileged 
information.  If you are not the intended recipient, any use, copying, disclosure, 
dissemination or distribution is strictly prohibited.  If you are not the intended 
recipient, please notify the sender immediately by return e-mail, delete this 
communication and destroy all copies.
*


---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

Re: [HACKERS] ~ crashes backend

[Bob . Henkel]

I downloaded it this morning around 8:00 AM CENTRAL TIME.  Thanks for the
builds by the way!




|-+-->
| |   "Merlin Moncure"   |
| |   <[EMAIL PROTECTED]|
| |   online.com>|
| |  |
| |   05/21/2004 10:39 AM|
| |  |
|-+-->
  
>--|
  |
  |
  |   To:   <[EMAIL PROTECTED]>
|
  |   cc:   <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>   
  |
  |   Subject:  RE: [HACKERS] ~ crashes backend
  |
  
>--|




> I have binary install from snapshot from the other night on WINDOWS
2000
> PRO and had same problem.
>
well, I'm the one compiling the snapshot :), so I trying to confirm that
I have not busted anything...when did you download the snapshot, though?
I switched to gcc 3.4 yesterday, was it earlier than that?

Merlin






*
PRIVILEGED AND CONFIDENTIAL: This communication, including attachments, is for the 
exclusive use of addressee and may contain proprietary, confidential and/or privileged 
information.  If you are not the intended recipient, any use, copying, disclosure, 
dissemination or distribution is strictly prohibited.  If you are not the intended 
recipient, please notify the sender immediately by return e-mail, delete this 
communication and destroy all copies.
*


---(end of broadcast)---
TIP 8: explain analyze is your friend

Re: [HACKERS] Nested xacts: looking for testers and review

[Bob . Henkel]

I think before this can be tested fully by a wide audience there needs to
be some basic documentation.  Or is there?
What is the new syntax?
Can we see some basic examples that you have used in your testing?

Regards
Bob


|-+-->
| |   Tatsuo Ishii   |
| |   <[EMAIL PROTECTED]>|
| |   Sent by:   |
| |   [EMAIL PROTECTED]|
| |   tgresql.org|
| |  |
| |  |
| |   05/28/2004 02:51 AM|
| |  |
|-+-->
  
>--|
  |
  |
  |   To:   [EMAIL PROTECTED]  
 |
  |   cc:   [EMAIL PROTECTED]  
   |
  |   Subject:  Re: [HACKERS] Nested xacts: looking for testers and review 
  |
  
>--|




I have tested the patches with May 28 16:20 JST snapshot. Here is my
first impression:

1) errors, rules regression tests are failed (I'm not sure this is due
   to your patches)

2) certain behavior was different from what I expected (please correct me
   if my expectation is wrong).

test=# begin;
BEGIN
test=# insert into t1 values(1);
INSERT 17216 1
test=# begin;
BEGIN
test=# aaa;
ERROR:  syntax error at or near "aaa" at character 1
ERROR:  syntax error at or near "aaa" at character 1
LINE 1: aaa;
^
test=# end;
COMMIT
test=# select * from t1; <-- I thought this should work since
subtransaction was closed
ERROR:  current transaction is aborted, commands ignored until end of
transaction block
ERROR:  current transaction is aborted, commands ignored until end of
transaction block
test=# end;
COMMIT
test=# select * from t1;
 i
---
(0 rows)

3) no docs found in the patches.

> Hackers,
>
> Ok, I've finally coded solutions to most problems regarding nested
> transactions.  This means:
>
> - reversing for the lock manager, catcache, relcache, buffer manager,
>   asynchronous notifies, storage manager.
>
> - transaction block state support, including appropiate XLog recording
>
> - pg_subtrans subsystem (including changing state from SUBTRANS
>   COMMITTED to COMMITTED when appropiate).  Also pg_clog XLog recovery
>   was handed to SLRU so pg_subtrans and pg_clog share a rmgr identity.
>
> - visibility rules.
>
> I'm missing one item: deferred triggers.  The problem with this is that
> the deftrig queue is not implemented using normal Lists, so there's no
> efficient way to reassign to the parent when the subtransaction commits.
> Also I'm not sure what should happen to the "immediate" pointer --- a
> subtransaction should have it's own private copy, or it should inherit
> the parent's?  Please whoever implemented this speak up (Stephan
> Szabo?), as I'm not sure of the semantics.
>
>
> I have tested it and it passes all regression tests (including ones I
> added), plus some more tests I threw at it mainly for concurrency.
> Everything behaves as expected.  At this time I'd like to have it
> reviewed by the critic eye of the committers, and tested by whoever
> would be using it.
>
> I'm open for comments and suggestions and general input.  Thank you.
>
> --
> Alvaro Herrera ()
> La web junta la gente porque no importa que clase de mutante sexual seas,
> tienes millones de posibles parejas. Pon "buscar gente que tengan sexo
con
> ciervos incendiánse", y el computador dirá "especifique el tipo de
ciervo"
> (Jason Alexander)
>
>
> ---(end of broadcast)---
> TIP 7: don't forget to increase your free space map settings
>

---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings






*
PRIVILEGED AND CONFIDENTIAL: This communication, including attachments, is for the 
exclusive use of addressee and may contain proprietary, confidential and/or privileged 
information.  If you are not the intended recipient, any use, copying, disclosure, 
dissemination or distribution is strictly prohibited.  If you are not the intended 
recipient, please notify the sender immediately by return e-mail, delete this 
communication and destroy all copies.
*


-

Re: [HACKERS] Nested xacts: looking for testers and review

[Bob . Henkel]

This reply was meant to be directed to Alvaro.


|-+-->
| |   [EMAIL PROTECTED]|
| |   .com   |
| |   Sent by:   |
| |   [EMAIL PROTECTED]|
| |   tgresql.org|
| |  |
| |  |
| |   05/28/2004 07:45 AM|
| |  |
|-+-->
  
>--|
  |
  |
  |   To:   Tatsuo Ishii <[EMAIL PROTECTED]>   
  |
  |   cc:   [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
 |
  |   Subject:  Re: [HACKERS] Nested xacts: looking for testers and review 
  |
  
>--|









I think before this can be tested fully by a wide audience there needs to
be some basic documentation.  Or is there?
What is the new syntax?
Can we see some basic examples that you have used in your testing?

Regards
Bob


|-+-->
| |   Tatsuo Ishii   |
| |   <[EMAIL PROTECTED]>|
| |   Sent by:   |
| |   [EMAIL PROTECTED]|
| |   tgresql.org|
| |  |
| |  |
| |   05/28/2004 02:51 AM|
| |  |
|-+-->
  >
--|

  |
|
  |   To:   [EMAIL PROTECTED]
|
  |   cc:   [EMAIL PROTECTED]
|
  |   Subject:  Re: [HACKERS] Nested xacts: looking for testers and
review   |
  >
--|





I have tested the patches with May 28 16:20 JST snapshot. Here is my
first impression:

1) errors, rules regression tests are failed (I'm not sure this is due
   to your patches)

2) certain behavior was different from what I expected (please correct me
   if my expectation is wrong).

test=# begin;
BEGIN
test=# insert into t1 values(1);
INSERT 17216 1
test=# begin;
BEGIN
test=# aaa;
ERROR:  syntax error at or near "aaa" at character 1
ERROR:  syntax error at or near "aaa" at character 1
LINE 1: aaa;
^
test=# end;
COMMIT
test=# select * from t1; <-- I thought this should work since
subtransaction was closed
ERROR:  current transaction is aborted, commands ignored until end of
transaction block
ERROR:  current transaction is aborted, commands ignored until end of
transaction block
test=# end;
COMMIT
test=# select * from t1;
 i
---
(0 rows)

3) no docs found in the patches.

> Hackers,
>
> Ok, I've finally coded solutions to most problems regarding nested
> transactions.  This means:
>
> - reversing for the lock manager, catcache, relcache, buffer manager,
>   asynchronous notifies, storage manager.
>
> - transaction block state support, including appropiate XLog recording
>
> - pg_subtrans subsystem (including changing state from SUBTRANS
>   COMMITTED to COMMITTED when appropiate).  Also pg_clog XLog recovery
>   was handed to SLRU so pg_subtrans and pg_clog share a rmgr identity.
>
> - visibility rules.
>
> I'm missing one item: deferred triggers.  The problem with this is that
> the deftrig queue is not implemented using normal Lists, so there's no
> efficient way to reassign to the parent when the subtransaction commits.
> Also I'm not sure what should happen to the "immediate" pointer --- a
> subtransaction should have it's own private copy, or it should inherit
> the parent's?  Please whoever implemented this speak up (Stephan
> Szabo?), as I'm not sure of the semantics.
>
>
> I have tested it and it passes all regression tests (including ones I
> added), plus some more tests I threw at it mainly for concurrency.
> Everything behaves as expected.  At this time I'd like to have it
> reviewed by the critic eye of the committers, and tested by whoever
> would be using it.
>
> I'm open for comments and suggestions and general input.  Thank you.
>
> --
> Alvaro Herrera ()
> La web junta la gente porque no importa que clase de mutante sexual seas,
> tienes millones de posibles parejas. Pon "buscar gen

Re: [HACKERS] Nested xacts: looking for testers and review

[Bob . Henkel]

This may be out of scope but I'm goign to mention it. Would error trapping
help any of these issues. In Oracle PL/SQL you have an exception section to
handle any known or unknown errors.  Is this for the future or does the
nested xacts code include this at all?


|-+-->
| |   Bruce Momjian  |
| |   <[EMAIL PROTECTED]|
| |   >  |
| |   Sent by:   |
| |   [EMAIL PROTECTED]|
| |   tgresql.org|
| |  |
| |  |
| |   05/28/2004 03:05 PM|
| |  |
|-+-->
  
>--|
  |
  |
  |   To:   Alvaro Herrera <[EMAIL PROTECTED]> 
 |
  |   cc:   Tatsuo Ishii <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
   |
  |   Subject:  Re: [HACKERS] Nested xacts: looking for testers and review 
  |
  
>--|




Alvaro Herrera wrote:
> On Fri, May 28, 2004 at 01:43:16PM -0400, Bruce Momjian wrote:
>
> > In this case, I want to try all of the inserts, but any of them can
> > fail, then I want the bottom part done.
>
> I wonder where everyone eas when I asked this question a lot of time
> ago.  I said I thought the behavior should be like I described, and no
> one objected.

Sorry, I didn't understand the question at the time, or wasn't paying
attention.

> Personally I think it would be a mistake to allow the COMMIT for the
> subtransaction to ignore the fact that the subxact was aborted.  However
> I realize what you are proposing, and maybe this can be implemented
> using a parameter to COMMIT (indicating to not propagate the error if
> it's in aborted state, but commit normally otherwise).
>
> However if everyone disagrees, I can take that part out, and the code
> would be simpler.  IMHO however, it would be less reliable.

Imagine this case used in a script:

 BEGIN;
 DROP TABLE test;
 CREATE TABLE test(x int);
 COMMIT;

This will not work because the drop might fail.  However you could use
this:

 BEGIN;
 BEGIN;
 DROP TABLE test;
 COMMIT;
 CREATE TABLE test(x int);
 COMMIT;

It is done in a transaction so the table replace is an atomic operation.

One interesting idea would be for COMMIT to affect the outer
transaction, and END not affect the outer transaction.  Of course that
kills the logic that COMMIT and END are the same, but it is an
interesting idea, and doesn't affect backward compatibility because
END/COMMIT behave the same in non-nested transactions.

If this is the type of issue we are dealing with for the patch, I feel
very good.  Good job Alvaro.

--
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania
19073

---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org






*
PRIVILEGED AND CONFIDENTIAL: This communication, including attachments, is for the 
exclusive use of addressee and may contain proprietary, confidential and/or privileged 
information.  If you are not the intended recipient, any use, copying, disclosure, 
dissemination or distribution is strictly prohibited.  If you are not the intended 
recipient, please notify the sender immediately by return e-mail, delete this 
communication and destroy all copies.
*


---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] Official Freeze Date for 7.5: July 1st, 2004

[Bob . Henkel]

Sounds like a project manager type should be put into place to organize
this information into a straight stream instead of 50 random mists of water




|-+-->
| |   Andrew Dunstan |
| |   <[EMAIL PROTECTED]>  |
| |   Sent by:   |
| |   [EMAIL PROTECTED]|
| |   tgresql.org|
| |  |
| |  |
| |   06/01/2004 11:10 AM|
| |  |
|-+-->
  
>--|
  |
  |
  |   To:   [EMAIL PROTECTED]  
   |
  |   cc:  
  |
  |   Subject:  Re: [HACKERS] Official Freeze Date for 7.5: July 1st, 2004 
  |
  
>--|




Marc G. Fournier wrote:

>
> Just so that everyone is aware, we are going to push the freeze date
> for 7.5 to July 1st.
>
> Although we feel that there are enough improvements and features
> already in place for 7.5, Tom's felt that if we gave it that extra
> month, we could also have PITR in place for 7.5 ...
>
> If anyone is working on other features that they feel can be polished
> off before the July 1st deadline, we would be most happy to
> incorporate those as well, but do recommend submitting patches for
> review *sooner*, rather then later, so that any recommended
> corrections can be addressed before teh deadline.
>

I welcome this, as I always thought June 1 was too soon. However, I
think that the process by which the date was eventually arrived at was
unfortunate.

I would modestly suggest that there should be a minimum period of notice
of a feature freeze - 6 weeks or 2 months seems about right to me, given
the development cycle we seem to have, and the fact that many of the
critical things people are working on are quite large.

(I'd also like to see someone who would get regular progress reports
from people who have undertaken to work on large/critical items, so that
we don't get into a position of thinking they will make a cutoff date
and then finding out late in the piece that they will not, but maybe
that's a discussion for another day).

cheers

andrew

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster






*
PRIVILEGED AND CONFIDENTIAL: This communication, including attachments, is for the 
exclusive use of addressee and may contain proprietary, confidential and/or privileged 
information.  If you are not the intended recipient, any use, copying, disclosure, 
dissemination or distribution is strictly prohibited.  If you are not the intended 
recipient, please notify the sender immediately by return e-mail, delete this 
communication and destroy all copies.
*


---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html

Re: [HACKERS] Official Freeze Date for 7.5: July 1st, 2004

[Bob . Henkel]

I really hate seeing all the developers wasting time and brain cycles on
this type of stuff.  I would much rather that time and brain cycles be put
to the design and development of the code.

Would a project manager type position be of any value to take some of this
off the developers and onto the project manager.? They would be the focal
point for this type of stuff and responsible to get updates from the
developers and check statuses and things of that nature.


|-+-->
| |   Andrew Dunstan |
| |   <[EMAIL PROTECTED]>  |
| |   Sent by:   |
| |   [EMAIL PROTECTED]|
| |   tgresql.org|
| |  |
| |  |
| |   06/01/2004 12:26 PM|
| |  |
|-+-->
  
>--|
  |
  |
  |   To:   [EMAIL PROTECTED]  
   |
  |   cc:  
  |
  |   Subject:  Re: [HACKERS] Official Freeze Date for 7.5: July 1st, 2004 
  |
  
>--|




Marc G. Fournier wrote:

> On Tue, 1 Jun 2004, Andrew Dunstan wrote:
>
>> Marc G. Fournier wrote:
>>
>>>
>>> Just so that everyone is aware, we are going to push the freeze date
>>> for 7.5 to July 1st.
>>>
>>> Although we feel that there are enough improvements and features
>>> already in place for 7.5, Tom's felt that if we gave it that extra
>>> month, we could also have PITR in place for 7.5 ...
>>>
>>> If anyone is working on other features that they feel can be
>>> polished off before the July 1st deadline, we would be most happy to
>>> incorporate those as well, but do recommend submitting patches for
>>> review *sooner*, rather then later, so that any recommended
>>> corrections can be addressed before teh deadline.
>>>
>>
>> I welcome this, as I always thought June 1 was too soon. However, I
>> think that the process by which the date was eventually arrived at
>> was unfortunate.
>>
>> I would modestly suggest that there should be a minimum period of
>> notice of a feature freeze - 6 weeks or 2 months seems about right to
>> me, given the
>
>
> Oh, you mean the original freeze date that was set at the start of the
> dev cycle 6 months ago?
>

I am far from being the only person to whom this was less than clear. I
also know that when I discussed this with one or two members of the core
team *they* were not clear about it either.

Maybe I missed something in an email somewhere ...

In any case, I think a target date should be set at the beginning of a
dev cycle and a hard date should be set closer to the end of the cycle.
Trying to adhere rigidly to a date set nine or twelve months previously
doesn't strike me as good practice.

cheers

andrew

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]






*
PRIVILEGED AND CONFIDENTIAL: This communication, including attachments, is for the 
exclusive use of addressee and may contain proprietary, confidential and/or privileged 
information.  If you are not the intended recipient, any use, copying, disclosure, 
dissemination or distribution is strictly prohibited.  If you are not the intended 
recipient, please notify the sender immediately by return e-mail, delete this 
communication and destroy all copies.
*


---(end of broadcast)---
TIP 8: explain analyze is your friend