(I'm not on -hackers, but saw this in the archives)
Alvaro Herrera wrote:
On Fri, Apr 30, 2004 at 09:44:52PM -0400, Tom Lane wrote:
Alvaro Herrera alvherre ( at ) dcc ( dot ) uchile ( dot ) cl writes:
Is this expected? If so, why? I'd expect the prepared stmt to be
deallocated.
prepare.c
Hello pgsql-hackers,
Following a recent discussion on the JDBC list
(http://archives.postgresql.org/pgsql-jdbc/2004-05/msg00100.php) I'm
looking at modifying when unnamed statements received via a v3 protocol
Parse message are planned. The idea is to delay planning until the Bind
message
Tom Lane wrote:
Oliver Jowett [EMAIL PROTECTED] writes:
Following a recent discussion on the JDBC list
(http://archives.postgresql.org/pgsql-jdbc/2004-05/msg00100.php) I'm
looking at modifying when unnamed statements received via a v3 protocol
Parse message are planned. The idea is to delay
Tom Lane wrote:
Oliver Jowett [EMAIL PROTECTED] writes:
Tom Lane wrote:
I don't like that at all. Do the planning using the given parameters,
but save the plan. Otherwise you have substantially pessimized the
behavior for the case where an unnamed statement is reused.
How often is the unnamed
Tom Lane wrote:
Oliver Jowett [EMAIL PROTECTED] writes:
This leads to my next problem (which was one of the original reasons I
went with node replacement): don't we get different performance between
a parameterized query and an equivalent unparameterized query in cases
such as this? :
SELECT
Magnus Hagander wrote:
FWIW, I think reporting a differnt version is just a *terrible* idea.
Any client side program (say, pgadmin for example) that tries to
determine what version backend it's connected to in order to know if a
feature exists or not will be confused, in many cases to the point of
I notice that when using the extended query protocol, statement logging
appears to happen only when a Parse message is received. This is less
than ideal:
- statements can be logged that are not actually executed (i.e. a
Parse/Bind with no corresponding Execute).
- if statements are re-executed
Bruce Momjian wrote:
Well, at execute time, we don't have easy access to the original prepare
statement, especially at that stage in the code. Do you see anyway to
improve that?
We have portal-sourceText which looks like it should contain the
original query.
(note that I'm talking about the V3
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
First I initdb'd without TZ set. So every time I start the server I get
LOG: could not recognize system timezone, defaulting to Etc/GMT-4
HINT: You can specify the correct timezone in postgresql.conf.
I've fixed the minor issue here,
Tom Lane wrote:
Oliver Jowett [EMAIL PROTECTED] writes:
Also, unless I'm missing something, shouldn't Chile (Alvaro's timezone?)
be behind GMT (GMT-something) not ahead of it (GMT+something)?
Part of the confusion here is that the zone names in the zic database
follow POSIX rules: plus is west
Zeugswetter Andreas SB SD wrote:
LOG: database system was shut down at 2004-05-25 15:15:44 GMT-12
For comparison, 7.4.1 on the same system says:
LOG: database system was shut down at 2004-05-25 16:03:43 NZST
Can we keep the zic database convention unchanged but change the display
format in
Tom Lane wrote:
BTW, as of an hour or so ago, identify_system_timezone is a bit smarter
than before. Please try it and see if it gets it right on your machine.
Looks good:
LOG: database system was shut down at 2004-05-26 12:43:55 NZST
test=# select now();
now
Tom Lane wrote:
Oliver Jowett [EMAIL PROTECTED] writes:
I notice that when using the extended query protocol, statement logging
appears to happen only when a Parse message is received. This is less
than ideal:
I agree, but I didn't have time at the end of the 7.4 development cycle
to work out
Against current CVS HEAD:
$ ./createuser test
Shall the new user be allowed to create databases? (y/n) y
Shall the new user be allowed to create more new users? (y/n) n
CREATE USER
$ ./createdb -O test test
CREATE DATABASE
$ ./psql -U test test
Welcome to psql 7.5devel, the PostgreSQL interactive
Couple of quick protocol questions:
1) What encoding is used for strings sent and received during the
startup phase? I can set client_encoding to a known value as a parameter
in the startup packet, but the protocol spec doesn't appear to say how
the startup packet itself and the various strings
Tom Lane wrote:
Oliver Jowett [EMAIL PROTECTED] writes:
1) What encoding is used for strings sent and received during the
startup phase?
The startup packet itself will not get any encoding conversion AFAIR,
so one way to look at it is that the data therein must be in server
encoding
Heikki Linnakangas wrote:
I'm worried about plan stability if we enable it by default. It could
lead to nasty, hard to reproduce performance problems. Think about this
scenario:
This is my main concern with the approach Tom suggested.
Also keep in mind that at least some application servers have a
Tom Lane wrote:
Oliver Jowett [EMAIL PROTECTED] writes:
2) At what point in the stream does a client_encoding change take effect
-- immediately after the corresponding ParameterStatus message, or at
some other point?
ParameterStatus is sent when the change is made.
Are the strings
Marc G. Fournier wrote:
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
Alvaro Herrera wrote:
Hackers,
Is there a way to add the current transaction nesting level in the be/fe
protocol without breaking compatibility? AFAICS the ReadyForQuery
message is not expansible (sp?) :-(
Perhaps you could treat the nesting level as a runtime parameter and
generate a
Tom Lane wrote:
I've applied the patch you sent in for this, with some editorializations
--- you were being too aggressive about substituting constants, with the
net effect that the plan was not still parameterized as it was supposed
to be.
Thanks. This should make my JDBC driver changes easier to
Tom Lane wrote:
Oliver Jowett [EMAIL PROTECTED] writes:
At execution time the executor can cache the results of expressions
flagged as constant at execution, assuming there's somewhere safe to
cache the result for just that execution (ExprState?).
That would be the problem; there isn't anyplace
Tom Lane wrote:
Oliver Jowett [EMAIL PROTECTED] writes:
I guess that ExprState does not live long enough to be useful.
Actually the opposite: it lasts too long, namely the entire execution of
a query. I don't think there's any convenient way to reset it on the
timescale appropriate for STABLE
Tom Lane wrote:
Oliver Jowett [EMAIL PROTECTED] writes:
But there are still other expression trees
that would benefit, e.g. those involving an IMMUTABLE function with
parameterized arguments.
Oh, you are thinking of some very-long-lived cache. This has been
proposed and rejected before; it's
Jeroen T. Vermeulen wrote:
There was also the middleware argument--some intermediate software layer
may be in control of bracketing. But in such cases, can you even rely
on two independent transactions executing in the same session? You'd
need to assume that to make the current semantics work in
Jeroen T. Vermeulen wrote:
If it's that important, come up with a generic session-not-transaction
syntax to temporarily escape bracketing.
Do you have a proposal for this? It seems to me that if your argument is
that if you want the old behaviour, you could add this extension means
that you need
Jeroen T. Vermeulen wrote:
Just don't tell me that making
PREPARE respect rollbacks would break compatibility
Why not? It's true.
So many things are true. But _not_ doing so also breaks compatibility,
so like I said, there are counterexamples.
This is nonsense. Not changing the current
Jeroen T. Vermeulen wrote:
On Sat, Jul 03, 2004 at 11:17:18AM +1200, Oliver Jowett wrote:
So many things are true. But _not_ doing so also breaks compatibility,
so like I said, there are counterexamples.
This is nonsense. Not changing the current behaviour cannot break
compatibility, almost
Jeroen T. Vermeulen wrote:
On Sat, Jul 03, 2004 at 12:16:50PM +1200, Oliver Jowett wrote:
I stand by my original statement: making no change does not break
compatibility. Please provide an example of PREPARE/EXECUTE use that
works under 7.3/7.4 but does not work with current 7.5.
Whether
Tom Lane wrote:
I don't like using ParameterStatus because it's not designed for dealing
with values that may change many times in a single query. Also it sends
strings, which this really isn't.
What about including the new nesting level in the
SUBBEGIN/SUBCOMMIT/SUBABORT CommandStatus string?
Tom Lane wrote:
Oliver Jowett [EMAIL PROTECTED] writes:
Tom Lane wrote:
I haven't looked at JDBC, but at least in the libpq code, what we could
safely do is extend the existing no transaction/in transaction/in failed
transaction field to provide a five-way distinction: those three cases
plus
Jeroen T. Vermeulen wrote:
On Sun, Jul 04, 2004 at 02:33:53PM +1200, Oliver Jowett wrote:
Consider SET client_encoding then..
Does that really affect most middleware? In my situation for instance,
what goes through the connection either way is just bytes to the
middleware. Its interpretation
Greg Stark wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
If we change the syntax, say by using SUBCOMMIT/SUBABORT for
subtransactions, then using a simple ABORT would abort the whole
transaction tree.
This seems like a non-starter to me. That would make it impossible to write
SQL generic code
Tom Lane wrote:
Still need to agree about externally visible behavior (a different stmt
than begin/commit for subxacts? What about savepoints?) Also, what about
exposing this functionality in plpgsql? Seems like we need some kind of
exception handling syntax to make this useful. What does
Jeroen T. Vermeulen wrote:
So perhaps we should be distinguishing several
layers in a session's state, along the lines of:
SQL session - temp tables, session variables, database contents
Interchange - encoding representation
Protocol - COPY, bind/execute c.
Jeroen T. Vermeulen wrote:
Well, I'd say DEALLOCATE is implicitly lumped in with PREPARE. But as for
FETCH, are you referring to cursors that live outside transactions (but get
manipulated inside transactions)? Are those implemented yet and if so, how
does FETCH work there?
I'm thinking WITH
Jeroen T. Vermeulen wrote:
That makes me wonder why people want to maintain transactionality w.r.t.
nested transactions but not with outer ones. Odd!
Yep.
But then the FETCH should still occur before the transaction as far as I'm
concerned. You fetch a batch (if it fails, you terminate) and
Alvaro Herrera wrote:
Well, the proposal of implementing it like holdable cursors means using
a Materialize node which, if I understand correctly, means taking the
whole result set and storing it on memory (or disk). So the same
question arises: why bother implementing that at all? Of course the
Dennis Bjorklund wrote:
On Tue, 6 Jul 2004, Alvaro Herrera wrote:
We can later implement savepoints, which will have SAVEPOINT foo and
ROLLBACK TO foo as interface. (Note that a subtransaction is slightly
different from a savepoint, so we can't use ROLLBACK TO foo in
subtransactions because that
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Well, my opinion is that cursors and other resources should at least be
usable from a inner subtransaction in its parent -- because if that
can't be done we are wasting some of the benefits, because we can't just
stick everything in a
Dennis Bjorklund wrote:
On Wed, 7 Jul 2004, Oliver Jowett wrote:
So how do you propose supporting simple rollback of a subtransaction? It
seems like an extension regardless of how it's done.
If I understand you correctly what you want is a ROLLBACK TO SAVEPOINT
foo; followed by a RELEASE
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
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
Alvaro Herrera wrote:
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
Josh Berkus wrote:
3) We adopt a slightly mutated form of the SQL3 SAVEPOINT syntax. This would
have the twin benefit of both allowing us to improve our standards compliance
and make savepoints completely compliant in the next version, as well as
helping those wishing to migrate from Oracle
Bruce Momjian wrote:
elein wrote:
FYI: I'm agreeing w/Tom who is agreeing with me.
The tag change should be good. I do hope people are
not relying on seeing COMMIT when the transaction
rolled back. It does not seem that in this case
they would.
If it is a problem, hopefully we will hear about
Josh Berkus wrote:
Tom,
As much as I can understand the arguments -- many of them performance-oriented
-- for handling Portals non-transactionally, I simply don't see how we can do
it and not create huge problems for anyone who uses both cursors and NTs
together ... as those who use either are
Alvaro Herrera wrote:
On the other hand, some people supported the idea that v3 Bind portals
should behave nontransactionally, while DECLARE portals should behave
transactionally. Maybe we could make that a property of the portal, or
even a user-selectable property (where we would define a
Tom Lane wrote:
I thought about restricting the scope of the TZ testing to start in 1990
or so to avoid this, but that seems certain to fall foul of the other
problem, which is distinguishing closely-related timezones (cf Chris
K-L discovering that he lives in Antarctica, a few days back...)
How
(cc: -hackers as I think this has been raised there before)
It's going to be fun using anything more than very basic cursors via the
V3 protocol in the JDBC driver. DECLARE does not work with parameters
passed via a Parse/Bind combination -- which is how we currently always
pass parameters when
Tom Lane wrote:
Any chance of getting this fixed for 7.5?
I'm up to my keister in PITR and nested-xact issues and won't have time
to look at it soon. Do you want to take a look and see if you can find
where the ball is getting dropped?
Ok, I'll do that.
-O
---(end of
Merlin Moncure wrote:
Another way to deal with the problem is to defer plan generation until
the first plan execution and use the parameters from that execution.
When talking the V3 protocol, 7.5 defers plan generation for the unnamed
statement until parameters are received in the Bind message
Oliver Jowett wrote:
It seems like we should pass the original parameters from execution of
the DECLARE utility portal down through PortalRunUtility -
ProcessUtility - PerformCursorOpen, copy them into the newly created
portal's memory context, and pass the copies to PortalStart on the new
Tom Lane wrote:
Oliver Jowett [EMAIL PROTECTED] writes:
It'd be nice to have a predictable timezone choice made when there's a
tie. Perhaps we should order on timezone name in this case?
The Antarctica zones would tend to win with such a rule, which is
probably not what we want
Tom Lane wrote:
BTW, rather than hacking the parameter list of ProcessUtility,
I'd be inclined to just look at ActivePortal-portalParams in
PerformCursorOpen. (Come to think of it, we could also copy
ActivePortal's sourceText at the PortalDefineQuery step.)
I've done this and it seems to work
[EMAIL PROTECTED] wrote:
The only use case network byte order fixes is a BINARY COPY between
different machine types, but in doing that, it forces anyone trying to add
value to postgresql or create a utility that uses COPY to reimplement all
the data type handlers outside of the database, even if
Thomas Hallgren wrote:
Oliver Jowett wrote:
This is not true if you happen to be using Java on the client side,
which has no idea (unless you grot around in the guts of the JVM) what
the native byte order is.
The method java.nio.ByteOrder.nativeOrder() will tell you what the
native byte
Thomas Hallgren wrote:
Oliver Jowett [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
NIO is not present before JDK 1.4. The JDBC driver, at least, needs to
support earlier JVMs.
Clients only capable of network order (such as a Java 1.3 based JDBC driver)
must of course be supported still
Tom Lane wrote:
Oliver Jowett [EMAIL PROTECTED] writes:
What about refusing to change client_encoding to something other than
SQL_ASCII on SQL_ASCII databases?
Not sure that would do anything very useful. People who aren't thinking
about this probably aren't thinking about setting
Would it be possible to report the integer_datetimes GUC in the V3
startup packet?
Currently if you want to use binary-format parameters or results that
might involve dates/times, you have to explicitly check
integer_datetimes first; this means another roundtrip on startup for
generic client
Bruce Momjian wrote:
Oliver Jowett wrote:
Merlin Moncure wrote:
Another way to deal with the problem is to defer plan generation until
the first plan execution and use the parameters from that execution.
When talking the V3 protocol, 7.5 defers plan generation for the unnamed
statement until
Tom Lane wrote:
If I understood what I was reading, this would take several things:
* Remove the special UTF-8 check in pg_verifymbstr;
* Extend pg_utf2wchar_with_len and pg_utf_mblen to handle the 4-byte case;
* Set maxmblen to 4 in the pg_wchar_table[] entry for UTF-8.
Are there any other places
Bruce Momjian wrote:
Oliver Jowett wrote:
Bruce Momjian wrote:
Oliver Jowett wrote:
Merlin Moncure wrote:
Another way to deal with the problem is to defer plan generation until
the first plan execution and use the parameters from that execution.
When talking the V3 protocol, 7.5 defers plan
Tatsuo Ishii wrote:
Tom Lane wrote:
If I understood what I was reading, this would take several things:
* Remove the special UTF-8 check in pg_verifymbstr;
* Extend pg_utf2wchar_with_len and pg_utf_mblen to handle the 4-byte case;
* Set maxmblen to 4 in the pg_wchar_table[] entry for UTF-8.
Are
Against CVS HEAD:
test=# select version();
version
---
PostgreSQL 8.0.0beta1 on i686-pc-linux-gnu, compiled by GCC
David Fetter wrote:
Dennis has pointed out that mixing the call-with-named-parameter
interface with call-by-order-of-parameters one would cause confusion,
and I think it would be OK to disallow this type mixing, so
SELECT foo_func(name AS 'yet another name', 35);
would be disallowed.
Python's
Tom Lane wrote:
On a related note, it would also be nice to have default
parameters and some way to say to use them.
That is fundamentally not ever going to happen, because it blows
overloaded-function resolution out of the water: there is no way to
choose whether foo(42, 2.5) matches foo(int,
Gaetano Mendola wrote:
Oliver Jowett wrote:
David Fetter wrote:
Dennis has pointed out that mixing the call-with-named-parameter
interface with call-by-order-of-parameters one would cause confusion,
Python's equivalent syntax allows you to mix the two forms so long as
all the by-position
Gaetano Mendola wrote:
C++ manages to solve this problem, although I can't remember the exact
mechanics (and C++ is usually not a good example to follow anyway ;)
Your're wrong:
try to compile this: [...]
a.cpp:6: error: call of overloaded `foo(int, double)' is ambiguous
a.cpp:1: error:
Gaetano Mendola wrote:
Oliver Jowett wrote:
Gaetano Mendola wrote:
Oliver Jowett wrote:
David Fetter wrote:
Dennis has pointed out that mixing the call-with-named-parameter
interface with call-by-order-of-parameters one would cause confusion,
Python's equivalent syntax allows you to mix the two
Gaetano Mendola wrote:
Oliver Jowett wrote:
David Fetter wrote:
Dennis has pointed out that mixing the call-with-named-parameter
interface with call-by-order-of-parameters one would cause
confusion,
Python's equivalent syntax allows you to mix the two forms so long
as all
Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
In that context, is SIGTSTP similar to SIGSTOP in that it cannot be
caught or ignored?
Possibly. I've reproduced the problem here on an RHL 8 system
(2.4.18 kernel) and I think it's a kernel bug. Points:
[...]
I can reproduce this on a 2.6.7
Tom Lane wrote:
Oliver Jowett [EMAIL PROTECTED] writes:
I think pqsignal should be passing SA_NOCLDSTOP in sa_flags,
With that patch applied, the problem is indeed gone on my system.
However, I would still like to know why 7.4 didn't show the same
misbehavior, when it isn't using this flag
I'm trying to build 7.4.3 under Solaris 9 with gcc and static linking of
libgcc. This requires passing '-static-libgcc' when linking both
binaries and shared libraries.
Passing 'LDFLAGS=-static-libgcc' to configure only partially works.
Binaries are correctly linked with that flag, but shared
8.0.0beta1 tarball built with gcc 3.2.3 under Solaris 9 on a E250
(ultrasparc). I see the same bug as described in
http://archives.postgresql.org/pgsql-admin/2004-05/msg00248.php: a mask
of 255.255.255.255 in pg_hba.conf is rejected with
LOG: invalid IP mask 255.255.255.255 in pg_hba.conf
Tom Lane wrote:
Oliver Jowett [EMAIL PROTECTED] writes:
Is there a Right Way to pass extra options for
shared-library linking?
LDFLAGS_SL is meant for this, I believe. Dunno whether you can set it
via configure, though ... that may be an oversight. In the meantime
you could hand-hack
Tom Lane wrote:
Oliver Jowett [EMAIL PROTECTED] writes:
Since the default config now allows TCP/IP connections from localhost,
maybe we should tweak the default pg_hba.conf to work around this
problem? (e.g. use the /32 syntax which works ok)
Maybe we should press Sun to fix their bugs?
Well, I
Greg Stark wrote:
I was pretty shocked when I heard that JDBC implements the low level protocol
itself. It seems like a dead-end strategy to me. Any new protocol innovations
need to be implemented in every driver. Every implementation gets the chance
to reimplement the same bugs and same
Greg Stark wrote:
Oliver Jowett [EMAIL PROTECTED] writes:
There *are* benefits to implementing the protocol directly. First on my
personal list is that our Java application would not be able to use postgresql
at all if the driver required JNI/libpq.
Well benefits that boil down to Java sucks
Tom Lane wrote:
David Wheeler [EMAIL PROTECTED] writes:
To get initial PREPARE support, I don't think that the other DBD::Pg
developers mind sending strings to the PostgreSQL server in a SQL
PREPARE statement.
The question, in my mind, is it currently possible to do this without
specifying the
Oliver Jowett wrote:
template1= prepare s1(int) as select $1;
PREPARE
template1= execute s1('12');
?column?
--
12
(1 row)
(now replace int with unknown..)
Ok, bad example since the backend probably can't infer a type for the
PREPARE in this case. A better example:
template1
David Wheeler wrote:
On Sep 17, 2004, at 6:23 PM, Oliver Jowett wrote:
template1= prepare s1(int) as select typname from pg_type where oid
= $1;
PREPARE
template1= execute s1('16');
typname -
bool
(1 row)
You're still telling it the type via that int.
Well, obviously. I haven't
David Wheeler wrote:
On Sep 18, 2004, at 1:09 PM, Oliver Jowett wrote:
Well, obviously. I haven't modified the backend code to accept
'unknown' in PREPARE..
Right, and that's what we're looking for.
My point was the client does *not* need to know the type inferred by
the PREPARE in the 'unknown
Michael Paesold wrote:
BEGIN;
SAVEPOINT a;
INSERT INTO ...
SAVEPOINT a;
INSERT INTO ...
SAVEPOINT a;
...
(encountering an error it would just ROLLBACK TO a;)
According to the standard this is exactly the same as:
BEGIN;
SAVEPOINT a;
INSERT INTO ...
RELEASE SAVEPOINT a;
SAVEPOINT a;
INSERT INTO ...
Gavin Sherry wrote:
I don't get this multiple ResultSet stuff. All I can think of is that the
spec has this in mind:
CallableStatement cstmt = conn.prepareCall({call foo(); call bar();});
or
CallableStatement cstmt = conn.prepareCall({call foo()} {call bar();});
or some other permutation.
It's not
Tom Lane wrote:
regression=# create rule r1 as on insert to surprise do
regression-# ( select 'hello' ; select 'how are you' );
CREATE RULE
The 'hello' result was in fact computed and sent by the backend, but it
was discarded in libpq (see the documentation about PQexec: only the
last resultset
Tom Lane wrote:
How can clients distinguish multiple resultsets if they're using the
extended query protocol?
You'll get multiple repetitions of RowDescription/DataRows.
Ah, so the Execute spontaneously generates a RowDescription
spontaneously when it hits the second resultset, without needing
Tom Lane wrote:
Oliver Jowett [EMAIL PROTECTED] writes:
Tom Lane wrote:
How can clients distinguish multiple resultsets if they're using the
extended query protocol?
You'll get multiple repetitions of RowDescription/DataRows.
Ah, so the Execute spontaneously generates a RowDescription
Heikki Linnakangas wrote:
Another approach I've been thinking about is to allow anyone that knows
the (user-supplied) global transaction identifier to finish the
transaction, and hide the gids of running transactions from regular
users. That way, the gid acts as a secret token that's only known
David Garamond wrote:
So it is possible for a user connected to the DB to send random commit
or cancel commands, just in case she happens to hit a valid GID?
It is not essentially different from someone trying to bruteforce a
password. A 128bit value like a random GUID is as strong as a 16 char
Tom Lane wrote:
At the API level, I like the PREPARE/COMMIT/ROLLBACK statements, but I
think you have missed a bet in that it needs to be possible to issue
COMMIT PREPARED gid for the same gid several times without error.
Consider a scenario where the transaction monitor crashes during the
commit
Tom Lane wrote:
Oliver Jowett [EMAIL PROTECTED] writes:
At the API level, I like the PREPARE/COMMIT/ROLLBACK statements, but I
think you have missed a bet in that it needs to be possible to issue
COMMIT PREPARED gid for the same gid several times without error.
Isn't this usually where the GTM
Tom Lane wrote:
Oliver Jowett [EMAIL PROTECTED] writes:
Tom Lane wrote:
Well, the question is how long must the individual databases retain
state with which to answer recover requests.
As I understand it, you don't need to keep state for committed txns,
I think that's clearly wrong:
TM
Rod Taylor wrote:
On Wed, 2004-10-06 at 18:50, Tom Lane wrote:
Well, the question is how long must the individual databases retain
state with which to answer recover requests. I don't like forever,
so I'm proposing that there should be an explicit command to say you
can forget about this gid.
Heikki Linnakangas wrote:
On Thu, 7 Oct 2004, Oliver Jowett wrote:
Probably the next question is, do we want a database-side timeout on
how long prepared txns can stay alive before being summarily rolled back?
That sounds very dangerous to me. You could end up breaking global
atomicity if some
(Tom: this is not as severe a problem as I first thought)
If a client sends a V3 message that is sufficiently large to cause a
memory allocation failure on the backend when allocating space to read
the message, the backend gets out of sync with the protocol stream.
For example, sending this:
Tom Lane wrote:
I wrote:
Yeah. The intent of the protocol design was that the recipient could
skip over the correct number of bytes even if it didn't have room to
buffer them, but the memory allocation mechanism in the backend makes
it difficult to actually do that. Now that we have PG_TRY,
Heikki Linnakangas wrote:
The Linux fsync man page says:
It does not necessarily ensure that the entry in the directory
containing the file has also reached disk. For that an explicit fsync on
the file descriptor of the directory is also needed.
AFAIK, we don't care about it at the moment. The
Tom Lane wrote:
AFAICS the only nondestructive way to do this is to cvs delete and cvs
add, with a commit comment saying where the files were moved from. Then
when you are looking at them in CVS, you'd have to navigate over to the
previous location (by hand, probably; the commit comment isn't
Tom Lane wrote:
It's really a
performance issue: do you want to pay the penalty associated with
reassembling messages that exceed the loopback MTU [...]
BTW, the loopback MTU here is quite large:
[EMAIL PROTECTED]:~$ /sbin/ifconfig lo | grep MTU
UP LOOPBACK RUNNING MTU:16436 Metric:1
1 - 100 of 195 matches
Mail list logo
