On Mon, 5 Jul 2004, Alvaro Herrera wrote:
begin/end because they are already in an explicit/implicit transaction
by default... How is the user/programmer to know when this is the case?
I'm not sure I understand you. Of course you can issue begin/end. What
you can't do is issue
On Tue, 2004-07-06 at 00:30, Mike Mascari wrote:
Simon Riggs wrote:
On Mon, 2004-07-05 at 23:40, Mike Mascari wrote:
hmmm...not sure I know what you mean.
It is very-very-close-to-impossible to edit the transaction logs
manually, unless some form of special-format editor were
- by time - but the time stamp on each xlog record only specifies to the
second, which could easily be 10 or more commits (we hope)
Should we use a different datatype than time_t for the commit timestamp,
one that offers more fine grained differentiation between checkpoints?
Imho
Christopher Kings-Lynne wrote:
need_paren = (PRETTY_PAREN(context) ?
!IsA(op-rarg, RangeTblRef) : true);
In a quick glance this code seems close to completely brain dead :-(
For one thing, why isn't it making separate determinations about whether
the left and right
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).
Would it help to hold the lock for a record that is the current cursor position,
iff this record
There is bad breakage in the DROP TABLESPACE command if the only thing
in that tablespace is the default tablespaces for a schema:
test=# create tablespace myspace location '/home/chriskl/loc';
CREATE TABLESPACE
test=# create schema myschema tablespace myspace;
CREATE SCHEMA
test=# drop
Andreas Pflug wrote:
Christopher Kings-Lynne wrote:
need_paren = (PRETTY_PAREN(context) ?
!IsA(op-rarg, RangeTblRef) : true);
In a quick glance this code seems close to completely brain dead :-(
This probably was about catching
expr_A UNION (expr_B INTERSECT
The same thing may also apply to the default tablespace of a database as
well...
Chris
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Christopher Kings-Lynne wrote:
The same thing may also apply to the default tablespace of a database
as well...
Well at least the database can be queried easily for usage of that
tablespace.
For the namespace issue, it would help if *some* object would be created
with that namespace (e.g. an
Well at least the database can be queried easily for usage of that
tablespace.
Yes, that's the easy part to fix. You'd just set the dattablespace back
to 0 when you dropped the tablespace.
For the namespace issue, it would help if *some* object would be created
with that namespace (e.g. an
On Tue, 6 Jul 2004, Christopher Kings-Lynne wrote:
There is bad breakage in the DROP TABLESPACE command if the only thing
in that tablespace is the default tablespaces for a schema:
test=# create tablespace myspace location '/home/chriskl/loc';
CREATE TABLESPACE
test=# create schema
Thanks. I have 2 questions regarding this.
1. Is prodesc-fn_retistuple true if and only if this is a set returning
function? (what about setof int? what about a function returning a single
composite?)
2. I am suspicious about the use of these globals to stash data (and they
should all be marked
I would like to see some tool that reported an semi-accurate value for
random page cost before adding the value per tablespace.
---
Scott Marlowe wrote:
On Thu, 2004-07-01 at 18:54, Gavin Sherry wrote:
On Thu, 1 Jul
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
The same thing may also apply to the default tablespace of a database as
well...
No, because it will always contain some files (at the very least, the
db's pg_class *must* live there). See prior thread about exactly
this issue.
Tom Lane wrote:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Would anyone else think that dumping:
SET client_min_messages TO warning;
In pg_dumps would be cool?
It would mean that while restoring a dump you can actually see the wood
for the trees when trying to see ERRORs and
Bruce Momjian [EMAIL PROTECTED] writes:
I agree changing some of those noiser notices would be good. I think
the best idea would be to add a client_min_messages level of novice for
them.
Yes ...
In fact, looking at the code, I see that the INFO level is almost
never used in our code.
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I agree changing some of those noiser notices would be good. I think
the best idea would be to add a client_min_messages level of novice for
them.
Yes ...
In fact, looking at the code, I see that the INFO level is almost
Alvaro Herrera wrote:
On Sat, Jul 03, 2004 at 02:32:44AM -0500, Thomas Swan wrote:
Alvaro Herrera wrote:
What I'd like to do is start the transaction block before the function
is called if we are not in a transaction block. This would mean that
when the function calls BEGIN it won't be
The developer's FAQ is a good place to start.
---
Jonathan Gardner wrote:
On Thursday 01 July 2004 01:10 pm, Jaime Casanova wrote:
I'm a young developer with some knowledge in various programming
languages including
Is there some way to determine the specific relation involved when a deadlock
occurs? For example in the following error message (with log level set to
verbose):
2004-07-03 20:30:44 [21347] ERROR: 40P01: deadlock detected
DETAIL: Process 21347 waits for ShareLock on transaction 104411804;
On Tue, Jul 06, 2004 at 11:37:18AM -0400, Bruce Momjian wrote:
Alvaro Herrera wrote:
On Sat, Jul 03, 2004 at 02:32:44AM -0500, Thomas Swan wrote:
Alvaro Herrera wrote:
What I'd like to do is start the transaction block before the function
is called if we are not in a transaction
Hi ppl,
What need to do (understand, to devel) to allow several
postgres instance running from several server to access to the
same data (no replication at all) hosted on a SAN ?
I'm probably wrong but i think this type of dev should
be easier to realize than replication ?
On Tue, Jul 06, 2004 at 08:15:14AM +0200, Dennis Bjorklund wrote:
On Mon, 5 Jul 2004, Alvaro Herrera wrote:
begin/end because they are already in an explicit/implicit transaction
by default... How is the user/programmer to know when this is the case?
I'm not sure I understand you.
* Alvaro Herrera ([EMAIL PROTECTED]) wrote:
We could use BEGIN NESTED for starting a subtransaction, roll it back
with ROLLBACK NESTED or some such, and commit with COMMIT NESTED. But I
like SUBBEGIN etc best, and no one had an opinion when I asked. So the
current code has SUBBEGIN,
On Tue, Jul 06, 2004 at 12:49:46PM -0400, Stephen Frost wrote:
* Alvaro Herrera ([EMAIL PROTECTED]) wrote:
We could use BEGIN NESTED for starting a subtransaction, roll it back
with ROLLBACK NESTED or some such, and commit with COMMIT NESTED. But I
like SUBBEGIN etc best, and no one had an
On Tue, Jul 06, 2004 at 18:17:16 +0200,
Yannick Lecaillez [EMAIL PROTECTED] wrote:
Hi ppl,
What need to do (understand, to devel) to allow several
postgres instance running from several server to access to the
same data (no replication at all) hosted on a SAN ?
Only once such
Yannick Lecaillez wrote:
Hi ppl,
What need to do (understand, to devel) to allow several
postgres instance running from several server to access to the
same data (no replication at all) hosted on a SAN ?
I'm probably wrong but i think this type of dev should
be easier to realize than
On Sun, 2004-07-04 at 19:57, Tom Lane wrote:
Anyone who needs this has always been able to make it trivially
(though you once had to invent a random column name for the one
required column).
In Oracle, DUAL is treated specially internally for performance reasons,
since it is so heavily used.
Gavin Sherry wrote:
On Sat, 3 Jul 2004, Tom Lane wrote:
Andreas Pflug [EMAIL PROTECTED] writes:
- what about Oracle portability.
IMHO we should rethink if we could make those people happy. How about a
loadable personality (IIRC SAPDB has something like that), to exchange
the
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Why does START have a different Node from BEGIN anyway? This seems to
be a leftover from when people thought they should behave differently.
They are the same now, so there's no point in distinguishing them, or is it?
[shrug...]
David Fetter wrote:
Kind people,
So far, I have found two places where one can find the SQLSTATE error
codes: a header file, and the errcodes-appendix doc. Those are
excellent places.
Did I miss how to get a list of them in SQL? If I missed it because
it isn't there, what would be a
Bruce Momjian wrote:
Gavin Sherry wrote:
On Sat, 3 Jul 2004, Tom Lane wrote:
Andreas Pflug [EMAIL PROTECTED] writes:
- what about Oracle portability.
IMHO we should rethink if we could make those people happy. How about a
loadable personality (IIRC SAPDB has something like
Le mar 06/07/2004 à 19:07, Alvaro Herrera a écrit :
On Tue, Jul 06, 2004 at 06:17:16PM +0200, Yannick Lecaillez wrote:
What need to do (understand, to devel) to allow several
postgres instance running from several server to access to the
same data (no replication at all) hosted on a
On Tue, 2004-07-06 at 08:38, Zeugswetter Andreas SB SD wrote:
- by time - but the time stamp on each xlog record only specifies to the
second, which could easily be 10 or more commits (we hope)
Should we use a different datatype than time_t for the commit timestamp,
one that offers
Marc G. Fournier wrote:
On Tue, 6 Jul 2004, Andreas Pflug wrote:
An external tool helping translating sql is fine, but nothing to be
defined todo for core pgsql IMHO. I still believe some minor oracle
helper behaviour (not to call it oracle compatibility, to avoid
wrong expectations) should be
On Mon, 2004-07-05 at 22:46, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
- when we stop, keep reading records until EOF, just don't apply them.
When we write a checkpoint at end of recovery, the unapplied
transactions are buried alive, never to return.
- stop where we stop,
On Tue, 2004-07-06 at 20:00, Richard Huxton wrote:
Simon Riggs wrote:
On Mon, 2004-07-05 at 22:46, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Should we use a different datatype than time_t for the commit timestamp,
one that offers more fine grained differentiation between
Andreas Pflug [EMAIL PROTECTED] writes:
- what about Oracle portability.
IMHO we should rethink if we could make those people happy. How about a
loadable personality (IIRC SAPDB has something like that), to exchange
the parser in use with a custom one (by a SET command)? This
Simon Riggs wrote:
snip
External tool is one thing, but the loadable personality seems like a
very good idea and worth discussing further.
Would an interesting, and maybe slightly different way of viewing a
loadable personality, be as a set of rules that can be applied to
parser input before the
Simon Riggs [EMAIL PROTECTED] writes:
On Tue, 2004-07-06 at 18:22, Yannick Lecaillez wrote:
I would have the pgsql-hackers genius for do that :) . I think its the
only feature which force company to buy 5$ Oracle licence ...
Fwiw, I think you've underestimated the price on those Oracle
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Other exceptions I can think of are FETCH and DEALLOCATE. DEALLOCATE is
particularly fun -- don't most of the arguments for making PREPARE
transactional also apply to DEALLOCATE? Is it actually feasible to roll
back a DEALLOCATE?
That's why
Tom already mentioned this just after committing tablespaces: 'Minor DROP
TABLESPACE issue'
http://www.mail-archive.com/[EMAIL PROTECTED]/msg46540.html
In fact, I see that you contributed to the thread :-).
I think the result of the thread was to make the error message a little
more helpful and
On Tue, 2004-07-06 at 10:25, Alvaro Herrera wrote:
On Tue, Jul 06, 2004 at 08:15:14AM +0200, Dennis Bjorklund wrote:
On Mon, 5 Jul 2004, Alvaro Herrera wrote:
begin/end because they are already in an explicit/implicit transaction
by default... How is the user/programmer to know when
Scott Marlowe [EMAIL PROTECTED] writes:
Why not rollback all or commit all?
I really really don't like subbegin and subcommit. I get the feeling
they'll cause more problems we haven't foreseen yet, but I can't put my
finger on it.
Well I've already pointed out one problem. It makes it
44 matches
Mail list logo
