My proposal would be:
1. Begin main transaction: BEGIN { TRANSACTION | WORK }
2. Commit main (all) transaction: COMMIT { TRANSACTION | WORK }
3. Rollback main (all) transaction: ROLLBACK { TRANSACTION }
4. Begin inner transaction: BEGIN NESTED { TRANSACTION | WORK }
5. Commit inner
As far as implementing only savepoints, look at this:
BEGIN;
BEGIN;
INSERT INTO ...;
COMMIT;
BEGIN;
INSERT INTO ...;
COMMIT;
BEGIN;
INSERT INTO ...;
COMMIT;
With savepoints, it looks pretty strange:
BEGIN;
Simon Riggs wrote:
ISTM - my summary would be
1. We seem to agree we should support SAVEPOINTs
2. We seem to agree that BEGIN/COMMIT should stay unchanged...
With savepoints, it looks pretty strange:
BEGIN;
SAVEPOINT x1;
INSERT INTO ...;
SAVEPOINT x2;
I'd opt for BEGIN as a start of a subtransaction (no need for special
semantics in plpgsql), the corresponding END simply changes the
transaction context to the parent level.
But 'BEGIN' in plpgsql does not start a [sub]transaction, it starts a
statement block. Are we intending to change
Zeugswetter Andreas SB SD wrote:
I'd opt for BEGIN as a start of a subtransaction (no need for special
semantics in plpgsql), the corresponding END simply changes the
transaction context to the parent level.
But 'BEGIN' in plpgsql does not start a [sub]transaction, it starts a
statement
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi, I've prepared a patch(against CVS HEAD of today) to pg_dump.c to
make pg_dump understand multiple -t options for dumping multiple tables
in one command.
Eks:
pg_dump -t table1 -t table2 -t table3 dbname
The patch is here:
* Jonah H. Harris ([EMAIL PROTECTED]) wrote:
Out of necessity, I've implemented user quotas in 7.4.3. What would the
process be for having this reviewed and combined? I have a patch for
7.4.3 ready, but wanted to know if you suggest that I patch the latest
cvs instead. Below if some
Personally, I would love to see this in PostgreSQL. It'd be great if it
could get into 7.5. An issue I see with that is that (similar to
Oracle...) I think people would want to be able to specify
per-tablespace quotas. Perhaps that wouldn't be too hard to add?
7.5 is already closed for new
* Christopher Kings-Lynne ([EMAIL PROTECTED]) wrote:
Personally, I would love to see this in PostgreSQL. It'd be great if it
could get into 7.5. An issue I see with that is that (similar to
Oracle...) I think people would want to be able to specify
per-tablespace quotas. Perhaps that
Le jeu 08/07/2004 à 14:22, Andrew Piskorski a écrit :
You want to do clustering for failover/reliability reasons, for
performance/scalability reasons, or for both?
for all that of course :)
For some stuff to read, see the dozen or so links I posted here:
But 'BEGIN' in plpgsql does not start a [sub]transaction, it starts a
statement block. Are we intending to change that ? I think not.
There are two possibilities:
Either BEGIN *does* start a subtransaction, or BEGIN does not. I don't
see how two nesting level hierarchies in a
On Fri, 9 Jul 2004, Stephen Frost wrote:
* Christopher Kings-Lynne ([EMAIL PROTECTED]) wrote:
Personally, I would love to see this in PostgreSQL. It'd be great if it
could get into 7.5. An issue I see with that is that (similar to
Oracle...) I think people would want to be able to specify
On Fri, 9 Jul 2004, Christopher Kings-Lynne wrote:
Personally, I would love to see this in PostgreSQL. It'd be great if it
could get into 7.5. An issue I see with that is that (similar to
Oracle...) I think people would want to be able to specify
per-tablespace quotas. Perhaps that wouldn't be
On Fri, 2004-07-09 at 09:29, Stephen Frost wrote:
* Christopher Kings-Lynne ([EMAIL PROTECTED]) wrote:
Personally, I would love to see this in PostgreSQL. It'd be great if it
could get into 7.5. An issue I see with that is that (similar to
Oracle...) I think people would want to be able
Do we want to add this to TODO:
* Issue an extra message when COMMIT completes a failed transaction
---
elein wrote:
On Sun, Mar 28, 2004 at 10:23:26AM -0500, Tom Lane wrote:
Bruce Momjian [EMAIL
On Thu, 8 Jul 2004, Jonah H. Harris wrote:
Hi,
3. The maximum quota size is (currently) the maximum of int4*1024 bytes.
why is this? This is very limiting ...
Using a 64bit value would be a lot more straight foreward.
Greetings, Klaus
--
Full Name : Klaus Naumann |
On Fri, 2004-07-09 at 10:14, Rod Taylor wrote:
On Fri, 2004-07-09 at 09:29, Stephen Frost wrote:
* Christopher Kings-Lynne ([EMAIL PROTECTED]) wrote:
Personally, I would love to see this in PostgreSQL. It'd be great if it
could get into 7.5. An issue I see with that is that (similar to
* Rod Taylor ([EMAIL PROTECTED]) wrote:
I would think having would allow us to take advantage of all of the
various kernel level filesystem features without needing to implement
them directly within PostgreSQL (crypto, quotas, data mirror, etc.).
Simply setup a tablespace for a given user
Simply setup a tablespace for a given user with permissions to allow
only that user to create new objects within it and make it the default
location) -- tie their schema to their tablespace? -- then set a kernel
level quota on their tablespace.
Since the user accessing/writing to the
Is this fixed in 7.5?
---
Christopher Kings-Lynne wrote:
If you do this sequence of events, you get a failure to restore:
1. As superuser, do this:
test2=# CREATE FUNCTION plpgsql_call_handler () RETURNS
* Rod Taylor ([EMAIL PROTECTED]) wrote:
Simply setup a tablespace for a given user with permissions to allow
only that user to create new objects within it and make it the default
location) -- tie their schema to their tablespace? -- then set a kernel
level quota on their tablespace.
Since the user accessing/writing to the tablespaces would be the
postgres user I don't really think this 'solution' works in reality.
I had assumed it would be a directory based quota rather than a user
based one.
It's been a while since I played with quotas but I don't recall this
* Rod Taylor ([EMAIL PROTECTED]) wrote:
Since the user accessing/writing to the tablespaces would be the
postgres user I don't really think this 'solution' works in reality.
I had assumed it would be a directory based quota rather than a user
based one.
It's been a while
On Thu, Jul 08, 2004 at 03:27:34PM -0600, Jonah H. Harris wrote:
Out of necessity, I've implemented user quotas in 7.4.3. What would the
process be for having this reviewed and combined? I have a patch for
7.4.3 ready, but wanted to know if you suggest that I patch the latest
cvs
Andreas Pflug wrote:
Simon Riggs wrote:
ISTM - my summary would be
1. We seem to agree we should support SAVEPOINTs
2. We seem to agree that BEGIN/COMMIT should stay unchanged...
With savepoints, it looks pretty strange:
BEGIN;
SAVEPOINT x1;
INSERT INTO ...;
SAVEPOINT x2;
* Klaus Naumann ([EMAIL PROTECTED]) wrote:
On Thu, 8 Jul 2004, Jonah H. Harris wrote:
3. The maximum quota size is (currently) the maximum of int4*1024 bytes.
why is this? This is very limiting ...
It's 2TB...
Using a 64bit value would be a lot more straight foreward.
It sounded to me
On Fri, Jul 09, 2004 at 10:38:15AM -0500, Thomas Swan wrote:
visibility issue and how far do you unwind the depth of subtransactions
or transactions?
BEGIN
UPDATE A
SAVEPOINT X
BEGIN
BEGIN
UPDATE B
BEGIN
UPDATE C
ROLLBACK TO SAVEPOINT X
What happens
There are a couple of modifications that I'd still like to make to user
quotas. Because 7.5 is locked, this may be a good time to discuss the
implementation (possibly for 7.6?)
I have seen some discussion about using OS-level quotas on a user or
group level, however, like our Oracle system,
An 'END SUB' after a 'BEGIN SUB' in plpgsql could be required, and could
mean start/end block and subtx. I do not really see a downside.
But, it would imho only make sense if the 'END SUB' would commit sub
or abort sub iff subtx is in aborted state (see my prev posting)
Andreas
Hello,
Group quotas should be sufficient. Create directory readable/writable to
only the pgsql user, but have the group ownership be representative of
the user in question.
Rather ugly, and you'll run out of groups if you have alot of users (the
postgres user can only be in so many groups).
Pavel Stehule wrote:
An 'END SUB' after a 'BEGIN SUB' in plpgsql could be required, and could
mean start/end block and subtx. I do not really see a downside.
But, it would imho only make sense if the 'END SUB' would commit sub
or abort sub iff subtx is in aborted state (see my prev
Quota is currently enforced on commit. I've considered checking during
insert/update/copy and throwing an abort but within a transaction they
may be deleting data as well.
However, even as a delete may take place before a massive insert/update,
a vacuum cannot be run within a transaction
On Jul 9, 2004, at 12:04 PM, Jonah H. Harris wrote:
- Quota acts on any object owned by the user. Is this adequate for
everyone?
Does changing owner also trigger new quota calculations on both the new
and old owner?
Is there any additional functionality you would like to see in a quota
On Fri, 2004-07-09 at 11:47, Stephen Frost wrote:
* Klaus Naumann ([EMAIL PROTECTED]) wrote:
On Thu, 8 Jul 2004, Jonah H. Harris wrote:
3. The maximum quota size is (currently) the maximum of int4*1024 bytes.
why is this? This is very limiting ...
It's 2TB...
Okay.. that is good for
On Fri, 9 Jul 2004, Stephen Frost wrote:
Hi,
why is this? This is very limiting ...
It's 2TB...
Yeah, you're right. I didn't take into account, that you multiply it with
1kb - my fault.
2TB is enough - at the moment at least. But implementing it in 64 from now
on could save a lot of work in
On Fri, Jul 09, 2004 at 10:04:01AM -0600, Jonah H. Harris wrote:
I'd like to make the following changes... Let me know your thoughts.
- userquota is stored in units of kilobytes... is this adequate? Would
anyone ever use a quota 1K other than for allowing a user no space?
If the user
* Rod Taylor ([EMAIL PROTECTED]) wrote:
Group quotas should be sufficient. Create directory readable/writable to
only the pgsql user, but have the group ownership be representative of
the user in question.
Rather ugly, and you'll run out of groups if you have alot of users (the
James Robinson wrote:
On Jul 9, 2004, at 12:04 PM, Jonah H. Harris wrote:
- Quota acts on any object owned by the user. Is this adequate for
everyone?
Does changing owner also trigger new quota calculations on both the new
and old owner?
Quota calculations are performed per-owner at commit
* Rod Taylor ([EMAIL PROTECTED]) wrote:
On Fri, 2004-07-09 at 11:47, Stephen Frost wrote:
* Klaus Naumann ([EMAIL PROTECTED]) wrote:
On Thu, 8 Jul 2004, Jonah H. Harris wrote:
3. The maximum quota size is (currently) the maximum of int4*1024 bytes.
why is this? This is very
Stephen Frost wrote:
* Rod Taylor ([EMAIL PROTECTED]) wrote:
On Fri, 2004-07-09 at 11:47, Stephen Frost wrote:
* Klaus Naumann ([EMAIL PROTECTED]) wrote:
On Thu, 8 Jul 2004, Jonah H. Harris wrote:
3. The maximum quota size is (currently) the maximum of int4*1024 bytes.
why is this? This is very
On Fri, 9 Jul 2004, Bruce Momjian wrote:
I think we agreed on BEGIN NESTED/COMMIT NESTED, and START NESTED
TRANSACTION and COMMIT NESTED TRANSACTION.
Should I read this as pg will get its own implementation of sub
transactions and not implement the almost equivalent standard (sql99)
savepoint
I have an intermittent problem with PostgreSQL 7.3.2 on Solaris 8.
The backend process crashes once in a while, with this in the database log:
... ...
2004-07-05 22:43:54 LOG: database system is ready
IpcSemaphoreInitialize: semctl(id=65615, 14, SETVAL, 0) failed:
Invalid argument
2004-07-06
On Fri, 9 Jul 2004, Jonah H. Harris wrote:
- Would anyone want to use a group quota in PGSQL (rather than user-only)?
Yes ... I could see this as being more useful, not less ... where you have
a dept working on a database, but individual logins for audit logging ...
- I assume that, based on
Only if you commit my pg_dump patch that's in the queue.
Chris
Bruce Momjian wrote:
Is this fixed in 7.5?
---
Christopher Kings-Lynne wrote:
If you do this sequence of events, you get a failure to restore:
1. As superuser, do
On Fri, 2004-07-09 at 11:45, Andreas Pflug wrote:
Simon Riggs wrote:
ISTM - my summary would be
1. We seem to agree we should support SAVEPOINTs
2. We seem to agree that BEGIN/COMMIT should stay unchanged...
With savepoints, it looks pretty strange:
BEGIN;
SAVEPOINT
On Thu, 2004-07-08 at 20:14, Alvaro Herrera wrote:
On Thu, Jul 08, 2004 at 06:33:56PM +0100, Simon Riggs wrote:
On Thu, 2004-07-08 at 16:19, Alvaro Herrera wrote:
On Thu, Jul 08, 2004 at 02:58:01PM +0100, Simon Riggs wrote:
The correct solution would be to emit a XLog record for
On Fri, Jul 09, 2004 at 07:10:06PM +0200, Dennis Bjorklund wrote:
On Fri, 9 Jul 2004, Bruce Momjian wrote:
I think we agreed on BEGIN NESTED/COMMIT NESTED, and START NESTED
TRANSACTION and COMMIT NESTED TRANSACTION.
Should I read this as pg will get its own implementation of sub
On Fri, 9 Jul 2004, Alvaro Herrera wrote:
Clearly savepoints do not allow for a snapshot to be released; nested
xacts do.
Why not?
OTOH savepoints are trivial to implement once nested xacts are in place.
They are only syntactic sugar.
Not only, but simple yes. I'm just opposed to having
On Fri, 2004-07-09 at 16:47, Alvaro Herrera wrote:
On Fri, Jul 09, 2004 at 10:38:15AM -0500, Thomas Swan wrote:
visibility issue and how far do you unwind the depth of subtransactions
or transactions?
BEGIN
UPDATE A
SAVEPOINT X
BEGIN
BEGIN
UPDATE B
BEGIN
On Fri, Jul 09, 2004 at 09:07:58PM +0200, Dennis Bjorklund wrote:
On Fri, 9 Jul 2004, Alvaro Herrera wrote:
Clearly savepoints do not allow for a snapshot to be released; nested
xacts do.
Why not?
What is it?
--
Alvaro Herrera (alvherre[a]dcc.uchile.cl)
Pensar que el espectro que
While Alvarro, et al are messing with transaction syntax
this would be a good time to clarify this message.
--elein
On Fri, Jul 09, 2004 at 10:16:29AM -0400, Bruce Momjian wrote:
Do we want to add this to TODO:
* Issue an extra message when COMMIT completes a failed transaction
OK.
---
Christopher Kings-Lynne wrote:
Only if you commit my pg_dump patch that's in the queue.
Chris
Bruce Momjian wrote:
Is this fixed in 7.5?
Alvaro Herrera wrote:
On Fri, Jul 09, 2004 at 09:07:58PM +0200, Dennis Bjorklund wrote:
On Fri, 9 Jul 2004, Alvaro Herrera wrote:
Clearly savepoints do not allow for a snapshot to be released; nested
xacts do.
Why not?
What is it?
Simon posted it. It is called RELEASE:
On Fri, Jul 09, 2004 at 03:34:47PM -0400, Bruce Momjian wrote:
Alvaro Herrera wrote:
On Fri, Jul 09, 2004 at 09:07:58PM +0200, Dennis Bjorklund wrote:
On Fri, 9 Jul 2004, Alvaro Herrera wrote:
Clearly savepoints do not allow for a snapshot to be released; nested
xacts do.
On Tue, 6 Jul 2004, Zeugswetter Andreas SB SD wrote:
Should we use a different datatype than time_t for the commit timestamp,
one that offers more fine grained differentiation between checkpoints?
Imho seconds is really sufficient. If you know a more precise position
you will probably know
Atached patch fix the problem.
Serg
Andrew Dunstan wrote:
Can anyone suggest why I might be seeing this effect (each notice
comes out once per row plus once per function call)
thanks
andrew
andrew=# create function tstset() returns setof tst language plperl as $$
andrew$# elog(NOTICE,tstset
Atached patch fix this bug
Serg
Andrew Dunstan wrote:
Can anyone suggest why I might be seeing this effect (each notice
comes out once per row plus once per function call)
thanks
andrew
andrew=# create function tstset() returns setof tst language plperl as $$
andrew$# elog(NOTICE,tstset called);
I forgot to mention that in fact i will have an
ordered table of dates ( i mean by ordered i will do an order by before applying
the aggregate) for different users.
That's why i need an aggregate ( i have to do a
group by)
so i have something like this
01/01/2004 user1
08/01/2004 user1
Alvaro Herrera wrote:
We can't actually release anything (commit the subtransactions), because
they may be savepoints established after that point, and they are
logically inside the previously established ones. At RELEASE we can't
really release -- we just lose the name and thus the opportunity
Dear Sir:
I am a graduate student of computer science at University of Ottawa.
Professor Kiringa is my supervisor.
Currently, I am working on a group project. As part of the project, I
would like to implement a new feature for the trigger creation in
PostgreSQL, which defines aliases for the
Hello
I have the same problem, discussed earlier in the groups, but not even
able to solve it and run psql/creatdb etc., of postgres. I have tried
uncommenting the TCPIP_SOCKET=True and port= lines in the
postgressql.conf inside my data directory.
I am not using cygwin too on windows
Dennis Bjorklund wrote:
On Fri, 9 Jul 2004, Bruce Momjian wrote:
I think we agreed on BEGIN NESTED/COMMIT NESTED, and START NESTED
TRANSACTION and COMMIT NESTED TRANSACTION.
Should I read this as pg will get its own implementation of sub
transactions and not implement the almost
Hi,
while playing around with the tablespace stuff I noticed that on can't see
the tablespace a table is in when querying the pg_tables view.
I think the tablespace a table is in is a valuable information and should
be shown there. This also applies to any ohter related view (like
pg_indexes
On Thu, 8 Jul 2004, Simon Riggs wrote:
We don't need to mention timelines in the docs, nor do we need to alter
pg_controldata to display it...just a comment in the code to explain why
we add a large number to the LogId after each recovery completes.
I'd disagree on that. Knowing what exactly
Oliver Jowett wrote:
The 2003 draft claims that RELEASE SAVEPOINT invalidates savepoints
subsequent to the RELEASE:
subsequent to the released savepoint rather.
-O
---(end of broadcast)---
TIP 6: Have you searched our list archives?
Hi,
I would like to knwo how to extends the storage manager to other device
( i try to add remote device to postgres engine).
I saw that i have to implement the interface f_smgr describe in smgr.c
, but I do not know how to tell to postgres to use my new device .
Is anyone could help me
Thanks
We have user-defined aggregates written in C running inside the server.
We are running into some memory management issues and wondering what
is the best way to solve the problem.
The state of the aggregates is a structure with a pointer to allocated
memory. The structure and memory are
Stephen Frost wrote:
* Rod Taylor ([EMAIL PROTECTED]) wrote:
Simply setup a tablespace for a given user with permissions to allow
only that user to create new objects within it and make it the default
location) -- tie their schema to their tablespace? -- then set a kernel
level quota on their
Min Xu (Hsu) wrote:
Dear all,
I've being following the discussion of the nested transaction. I
apologize for that I can't help asking my questions as I get more
confused about what exactly are nested transactions, at least as far as
the concurrency control goes.
It seems to me there
Have you read the developers FAQ?
http://developers.postgresql.org
---
[EMAIL PROTECTED] wrote:
Dear Sir:
I am a graduate student of computer science at University of Ottawa.
Professor Kiringa is my
Jonah,
I have seen some discussion about using OS-level quotas on a user or
group level, however, like our Oracle system, not all database users
have a system account. This is why I needed to implement user-specific
quota functionality within the database itself.
Agreed. Also,
Bruce Momjian [EMAIL PROTECTED] writes:
I also don't see LOG used much in the code at all. It seems to be used
mostly by VACUUM and ANALYZE. Seems something is wrong.
There is nothing wrong except that you've forgotten how we designed
VACUUM VERBOSE to work with the new logging-levels
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I also don't see LOG used much in the code at all. It seems to be used
mostly by VACUUM and ANALYZE. Seems something is wrong.
There is nothing wrong except that you've forgotten how we designed
VACUUM VERBOSE to work with the new
Jan Wieck wrote:
I looked over the code and the only place getpwuid_r (through
pqGetpwuid) is used is in libpq to look up the default username based on
the euid for the connection to the backend. Unfortunately, I can't find
any other way to do such a lookup in a thread-safe manner unless
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
[shrug...] I'd counsel leaving this as-is.
What information are we loosing by having START and BEGIN use the same
nodes? Knowing what keyword they used to start the transaction?
Exactly.
Seems that would only be important if we
Jan Wieck wrote:
On 6/10/2004 2:11 AM, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Are people OK with requiring PGUSER, $USER, $LOGNAME, or the username to
be supplied by the connection string in libpq on platforms that want
threads and don't have getpwuid_r() (Solaris,
Where are we on this, 2x. :-)
---
Bruce Momjian wrote:
Where are we on this?
---
Tom Lane wrote:
Manfred Koizar [EMAIL PROTECTED] writes:
On Fri, Jul 09, 2004 at 11:28:23PM +0200, Dennis Bjorklund wrote:
On Fri, 9 Jul 2004, Alvaro Herrera wrote:
Yes, we free some things. Granted it's not a lot, but we have stacks
for several things that will be always be growing with savepoints,
They will not always be growing for
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
The other thing we need are these two commands:
ALTER DATABASE foo SET TABLESPACE spc;
ALTER SCHEMA foo SET TABLESPACE spc;
I think these should not be considered new features but essential
functionality left out of the original patch.
The
On Sat, Jul 10, 2004 at 09:46:56AM +1200, Oliver Jowett wrote:
Alvaro Herrera wrote:
We can't actually release anything (commit the subtransactions), because
they may be savepoints established after that point, and they are
logically inside the previously established ones. At RELEASE we
TODO item?
---
Tom Lane wrote:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
The other thing we need are these two commands:
ALTER DATABASE foo SET TABLESPACE spc;
ALTER SCHEMA foo SET TABLESPACE spc;
I
Andrew Dunstan [EMAIL PROTECTED] writes:
OK, I have a setup that instead of refusing to load trusted functions if
the Safe version is not up to date, forces them to error out by calling
elog(ERROR...), thus:
andrew=# select tval();
ERROR: trusted perl functions disabled - please upgrade
At 12:19 PM 29/06/2004, Christopher Kings-Lynne wrote:
It's hacky (although officially hacky :) ) in regards that it parses the
dropStmt on each object to get the objects name. This is necessary
because of an oversight in the initial design of the binary format.
If there's something missing in
Hello,
I know there is a patch coming Monday with a great deal of bug fixes.
J
On Fri, 9 Jul 2004, Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
OK, I have a setup that instead of refusing to load trusted functions if
the Safe version is not up to date, forces them to error
Andrew Piskorski [EMAIL PROTECTED] writes:
Another thing I've been wondering about, but haven't been able to find
any discussion of:
Just how closely tied is PostgreSQL to its use of shared memory?
Pretty damn closely. You would not be happy with the performance of
anything that tried to
If there's something missing in the format, I'd be inclined to add it.
We've never promised to make dumps made by version X readable (or
usable) by version X-1. We *do* the opposite, however, so you will
probably still need to parse dump statements from old dump files. Unless
we can
Alvaro Herrera [EMAIL PROTECTED] writes:
(We could talk about exception support in plpgsql or other language
handlers but I don't think this is going to happen for 7.5.)
Au contraire ... I think it *must* happen, and indeed that
subtransaction support in plpgsql is not different from
[ catching up on this discussion a bit late... ]
Alvaro Herrera [EMAIL PROTECTED] writes:
You haven't shown us the patch, have you?
That was pretty much the point that leapt out at me. For a change of
this magnitude, there is absolutely zero chance that we'll accept an
implementation sight
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
How come I default to Antartica in CVS?
You tell us ... what's your real timezone, and what do you get from
pushing up the log level to DEBUG4 during postmaster start?
regards, tom lane
---(end of
On Fri, 9 Jul 2004, Alvaro Herrera wrote:
I mean this:
begin;
... work ...;
savepoint foo;
... more work ...;
savepoint bar;
... yet more ... ;
release foo;
At this time I can't release savepoint foo because the implementation
(nested) requires me to keep it open as
90 matches
Mail list logo
