haven't supported updatable cursors yet.
regards,
Hiroshi Inoue
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Alvaro Herrera wrote:
On Sun, Nov 17, 2002 at 06:43:38PM -0500, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
And what about REINDEX? That seems to have a different
syntax from the other two. Seems there should be some
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Refresh my memory: what is the point of inventing an additional LAST
keyword, when the behavior is exactly the same as MOVE ALL ?
SQL compatibility, per Peter.
Oh, I see. But then
Tom Lane wrote:
Sure. FETCH n in Postgres has always corresponded to FETCH RELATIVE n.
IIRC in SQL standard FETCH retrieves rows one by one.
regards,
Hiroshi Inoue
http://w2422.nsk.ne.jp/~inoue/
---(end of
Tom Lane wrote:
Hiroshi Inoue [EMAIL PROTECTED] writes:
Tom Lane wrote:
Sure. FETCH n in Postgres has always corresponded to FETCH RELATIVE n.
IIRC in SQL standard FETCH retrieves rows one by one.
Yes, Postgres' idea of FETCH is only weakly related
Tom Lane wrote:
Hiroshi Inoue [EMAIL PROTECTED] writes:
FETCH LAST should return the last one row.
That's not clear to me. Generally, I would think the cursor should
remain positioned on whatever row is returned, but the spec clearly says
that the final cursor
Tom Lane wrote:
Perhaps we could do something with a hybrid technique: don't materialize
the cursor output unless user actually asks for backwards scan.
Or we can check the existence of SCROLL keyword which is
currently ignored. In the first place SQL standard only
Zeugswetter Andreas SB SD wrote:
FETCH LAST should return the last one row.
FETCH RELATIVE m should return a row after skipping
m rows if we follow the SQL standard and so the current
implementation of FETCH RELATIVE is broken.
Yes, the syntax could probably be
Tom Lane wrote:
Hiroshi Inoue [EMAIL PROTECTED] writes:
I'm suspicios if we should implement scrollable cursors
with the combination of the current MOVE and FETCH implemen-
tation. For example the backwards FETCH operation for group
nodes isn't implemented properly yet
Honestly I'm not so enthusiastic about scrollable cursors.
Even though PostgreSQL provides an efficient scrollable
cursor, I would use it little unless it could survive
across transactions.
Anyway it's too bad that FETCH LAST means FETCH ALL.
I would remove LAST,
Bruce Momjian wrote:
Hiroshi Inoue wrote:
Honestly I'm not so enthusiastic about scrollable cursors.
Even though PostgreSQL provides an efficient scrollable
cursor, I would use it little unless it could survive
across transactions.
Anyway it's too bad
Bruce Momjian wrote:
It also clarifies the docs to mention it sits on the last row, not after
the last row.
Is it true ?
regards,
Hiroshi Inoue
http://www.geocities.jp/inocchichichi/psqlodbc/
---(end of
Hi all,
There seems a bad behavior under autocommit off mode.
1) psql -c 'set autocommit to off;select 1;commit'
causes a WARNING: COMMIT: no transaction in progress
whereas
2) psql -c 'begin;select 1;commit'
causes no error/warning.
Note that the result is
Tom Lane wrote:
"Hiroshi Inoue" [EMAIL PROTECTED] writes:
The simplest way seems to accept COMMIT any time under autocommit
off mode.
That's just hiding the most visible symptom. The real problem here is
that the SELECT is already committed, when it
Tom Lane wrote:
Hiroshi Inoue [EMAIL PROTECTED] writes:
Tom Lane wrote:
I'm thinking of modifying ReadBuffer() so that it errors out if the
What does the *error out* mean ?
Mark the buffer as having an I/O error and then elog(ERROR).
Is there a way
Tom Lane wrote:
Hiroshi Inoue [EMAIL PROTECTED] writes:
Tom Lane wrote:
Hiroshi Inoue [EMAIL PROTECTED] writes:
Is there a way to make our way around the pages ?
If the header is corrupt, I don't think so.
What I asked is how to read all other sane pages
Tom Lane wrote:
Hiroshi Inoue [EMAIL PROTECTED] writes:
Tom Lane wrote:
IIRC, the SET does *not* start a transaction,
Yes but doesn't autocommit-off mode mean that
it implicitly begins a transaction in suitable
places ? For example, 'set autocommit to off
Tom Lane wrote:
Hiroshi Inoue [EMAIL PROTECTED] writes:
Anyway should 'set autocommit to off;commit' cause
a warning or an error in the first place ?
IIRC, the SET does *not* start a transaction,
Yes but doesn't autocommit-off mode mean that
it implicitly
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Hiroshi Inoue [EMAIL PROTECTED] writes:
There seems a bad behavior under autocommit off mode.
1) psql -c 'set autocommit to off;select 1;commit'
causes a WARNING: COMMIT: no transaction in progress
Surely
Tom Lane wrote:
I think such compatibility is sufficient. We can mention in the
releases notes that they should upgrade there servers before their
clients.
I'd be really happy if we can make that stick. There's enough work to
be done here without trying to
Dave Page wrote:
It's rumoured that Hiroshi Inoue once said:
Tom Lane wrote:
"Dave Page" [EMAIL PROTECTED] writes:
No, but with them we can avoid cluttering the wire protocol with
fields for all this, and the JDBC required data. With 2 numeric
Peter Eisentraut wrote:
Dave Page writes:
Well what I *really* need has been made quite clear in other
posts, but, when I say resultset in the same sentence as
pgAdmin, I'm referring to the ability to enter an arbitrary
SQL query, have the results displayed in a
-Original Message-
From: Dave Page
-Original Message-
From: Hiroshi Inoue [mailto:[EMAIL PROTECTED]
Sent: 13 March 2003 10:04
To: Dave Page
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: Re: [HACKERS
Tom Lane wrote:
"Dave Page" [EMAIL PROTECTED] writes:
It's rumoured that Hiroshi Inoue once said:
Does looking up by the catalog keys take no cost ?
Obviously there is cost, but doing a lookup only on demand, has got to be
cheaper in the long run than
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I think our SET functionality is easy to understand and use. I don't
see pushing it into the client as greatly improving things, and could
make things worse. If we can't get it right in the backend, how many
Tom Lane wrote:
Hiroshi Inoue [EMAIL PROTECTED] writes:
Tom Lane wrote:
That means that
a lot of low-level places *do* need to know about the dropped-column
convention, else they can't make any sense of tuple layouts.
Why ? As you already mentioned, there were not that many places
Bruce Momjian wrote:
Hiroshi Inoue wrote:
Tom Lane wrote:
Hiroshi's "DROP_COLUMN_HACK" was essentially along this line, but
I think he made a representational mistake by trying to change the
attnums of dropped columns to be negative values.
Negative attnums had 2
Bruce Momjian wrote:
Hiroshi Inoue wrote:
Why ? As you already mentioned, there were not that many places
to be changed.
Well what's changed since then ?
Here is an old email from me that outlines the idea of having a
physical/logical attribute numbering system
.
regards,
Hiroshi Inoue
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Bruce Momjian wrote:
Hiroshi Inoue wrote:
If the client has to bear the some part, isn't the invisible
column approach much simpler ?
I've put a pretty much time into DROP COLUMN feature but
I am really disappointed to see the comments in this thread.
What DROP COLUMN has brought me
literal
constants involved (especially if they're not part of the WHERE clause).
Saving query plans via PREPARE seems quite sufficient, and appropriate,
to tackle the planner-overhead issue.
Just a confirmation.
Someone is working on PREPARE/EXECUTE ?
What about Karel's work ?
regards,
Hiroshi
Bruce Momjian wrote:
Hiroshi Inoue wrote:
Christopher Kings-Lynne wrote:
I think that is why Tom was suggesting making all the column values NULL
and removing the pg_attribute row for the column. With a NULL value, it
doesn't take up any room in the tuple, and with the pg_attribute
Fernando Nasser wrote:
Hiroshi Inoue wrote:
Fernando Nasser wrote:
As most things in the SQL standard, you have to collect information
from several places and add it together.
Look at 4.20, 11.1 and specially at the rules for
schema qualified name.
Then think
a foreign key a_rel/1/3
and the second column of the relation is dropped the
parameter must be changed to be a_rel/1/2. If neither
foreign key stuff nor DROP COLUMN take the other into
account, the consistency is easily broken.
regards,
Hiroshi Inoue
---(end of broadcast
is that the differene is very small.
regards,
Hiroshi Inoue
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
What does the current schema mean ?
Or What does "local" mean ?
regards,
Hiroshi Inoue
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
the TODO first and put it back
to the neutral position.
regards,
Hiroshi Inoue
http://w2422.nsk.ne.jp/~inoue/
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
s that SET commands are out of transactional
control and so the word *commit SETs even after* has no meaning
to me. Basically it's a user's responsisbilty to manage the
errors. He only knows what's to do with the errors.
regards,
Hiroshi Inoue
http://w2422.nsk.ne
Tom Lane wrote:
Hiroshi Inoue [EMAIL PROTECTED] writes:
I don't think this is *all* *should be* or *all
or nothing* kind of thing. If a SET variable has
its reason, it would behave in its own right.
Well, we could provide some kind of escape hatch to let the behavior
vary from one
Michael Loftis wrote:
Hiroshi Inoue wrote:
Tom Lane wrote:
Hiroshi Inoue [EMAIL PROTECTED] writes:
I don't think this is *all* *should be* or *all
or nothing* kind of thing. If a SET variable has
its reason, it would behave in its own right.
Well, we could provide some kind
s a *had better*
or *convenient* kind of thing not a *no alternative* kind
of thing.
regards,
Hiroshi Inoue
http://w2422.nsk.ne.jp/~inoue/
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Our current behavior is 2.
Please vote and I will tally the results.
Is it a vote in the first place ?
I will vote the current(2 + 3 + ?).
regards,
Hiroshi Inoue
http://w2422.nsk.ne.jp/~inoue/
---(end of broadcast)---
TIP 3: if posting
the search_path be put back in this case ?
As I mentioned already many times, it doesn't seem
*should be* kind of thing.
regards,
Hiroshi Inoue
http://w2422.nsk.ne.jp/~inoue/
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go
Jan Wieck wrote:
Hiroshi Inoue wrote:
Tom Lane wrote:
Right offhand, I am not seeing anything here for which there's a
compelling case not to roll it back on error.
In fact, I have yet to hear *any* plausible example of a variable
that we would really seriously want
#3
#?
Thomas Lockhart
Hiroshi Inoue
Looks like #1 is the clear winner.
I voted not only ? but also 2 and 3.
And haven't I asked twice or so if it's a vote ?
Hiroshi Inoue
http://w2422.nsk.ne.jp/~inoue/
---(end of broadcast
Bruce Momjian wrote:
Hiroshi Inoue wrote:
Bruce Momjian wrote:
OK, the votes are in:
#1
Lamar Owen
Jan Wieck
Tom Lane
Bruce Momjian
Joe Conway
Curt Sampson
Michael Loftis
Vince
are exclusive.
Well, 2 says roll back only after transaction aborts,
Sorry for my poor understanding.
Isn't it 1 ?
regards,
Hiroshi Inoue
http://w2422.nsk.ne.jp/~inoue/
---(end of broadcast)---
TIP 3: if posting/reading through Usenet
Michael Loftis wrote:
Hiroshi Inoue wrote:
What's wrong with it ? The insert command after *rollback*
would fail. It seems the right thing to me. Otherwise
the insert command would try to append the data of the
table t1 to itself. The insert command is for copying
schema1.t1 to foo.t1
Bruce Momjian wrote:
Hiroshi Inoue wrote:
Must I understand this from your previous posting
(2 says roll back only after transaction aborts,)
or original posting ? What I understood was 2 only
says that SET fails between a failure and the
subsequenct ROLLBACK call.
Yes, 2 says
Michael Loftis wrote:
Hiroshi Inoue wrote:
Where's the restriction that all objects in a schema
must be created in an transaction ? Each user has his
reason and would need various kind of command call sequence.
What I've mainly insisted is what to do with errors is
users' responsibilty
Jan Wieck wrote:
Hiroshi Inoue wrote:
Sure should it! You gave an example for the need to roll
back, because
otherwise you would end up with an invalid
search path "foo".
What's wrong with it ? The insert command after *rollback*
would fail
Bruce Momjian wrote:
Hiroshi Inoue wrote:
Hiroshi, we need a psql solution too. People are feeding query files
into psql all the time and we should have an appropriate behavior for
them.
What are you expecting for psql e.g. the following
wrong(?) example ?
[The curren schema
and you would rather ODBC handle what to do with
SETs. Not sure I like pushing that job off to the application
programmer, but I think I see your point.
Ahhh Hiroshi is talkign formt he aspect of ODBC? Well, thats an ODBC
issue, should be handled by the ODBC driver.
No.
regards,
Hiroshi
Bruce Momjian wrote:
Hiroshi Inoue wrote:
What are you expecting for psql e.g. the following
wrong(?) example ?
[The curren schema is schema1]
begin;
create schema foo;
set search_path = foo;
create table t1 (); [error occurs
schema1.t1 in case of errors.
Yes, I think that is how it would behave. If you don't roll back 'set
search_path', you are pointing to a non-existant schema.
OK I see your standpoint. If Tom agrees with Bruce I don't
object any more.
regards,
Hiroshi Inoue
---(end
* UPDATE 0 * means no tuple was updated.
regards,
Hiroshi Inoue
http://w2422.nsk.ne.jp/~inoue/
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECT
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]]
Hiroshi Inoue [EMAIL PROTECTED] writes:
Your settings probably worked well under 7.1 but
doesn't in 7.2 due to the following change in
tcop/postgres.c.
AFAIR, there is only a visible change of behavior for
INSERT
-Original Message-
From: Tom Lane
Hiroshi Inoue [EMAIL PROTECTED] writes:
Your settings probably worked well under 7.1 but
doesn't in 7.2 due to the following change in
tcop/postgres.c.
AFAIR, there is only a visible change of behavior for
INSERT/UPDATE/DELETE queries
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]]
"Hiroshi Inoue" [EMAIL PROTECTED] writes:
If you'd not like to change the behavior, I would change it, OK ?
To what? I don't want to simply undo the 7.2 change.
What I'm thinking is the following makesh
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]]
"Hiroshi Inoue" [EMAIL PROTECTED] writes:
If you'd not like to change the behavior, I would change it, OK ?
To what? I don't want to simply undo the 7.2 change.
What I'm thinking is the following mak
ordinary updatable views
in 7.2.
regards,
Hiroshi Inoue
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
COLUMN without touching the tuples. If the
machanism is lost(I believe so) by removing t_natts, I would
say good bye to PostgreSQL.
regards,
Hiroshi Inoue
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org
Neil Conway wrote:
On Mon, 6 May 2002 08:44:27 +0900
"Hiroshi Inoue" [EMAIL PROTECTED] wrote:
-Original Message-
From: Manfred Koizar
If there is interest in reducing on-disk tuple header size and I have
not missed any strong arguments against dropping t_n
the current implementaion of ADD COLUMN
(without default) together to touch tuples.
regards,
Hiroshi Inoue
http://w2422.nsk.ne.jp/~inoue/
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe
but fixes the most
siginificant case(typical updatable views).
regards,
Hiroshi Inoue
http://w2422.nsk.ne.jp/~inoue/
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Tom Lane wrote:
Hiroshi Inoue [EMAIL PROTECTED] writes:
Of cource it is nice to have a complete solution
immediately but it doesn't seem easy. My patch is
only a makeshift solution but fixes the most
siginificant case(typical updatable views).
I would like to devise a complete
Jan Wieck wrote:
Hiroshi Inoue wrote:
Tom Lane wrote:
What should the backends return for complicated rewrites ?
And how should/could clients handle the results ?
It doesn't seem easy to me and it seems a flaw of rule
system. Honestly I don't think that the psqlodbc driver
can
direction to solve the TODO is decided.
1) without UNDO for individual tuples.
2) with UNDO for individual tuples under no
overwriting smgr.
3) UNDO under overwriting smgr.
regards,
Hiroshi Inoue
http://w2422.nsk.ne.jp/~inoue/
---(end of
to me e.g.
# create view aview as select ctid, * from a_table;
ERROR: name of column "ctid" conflicts with an existing system column
If there's no objection I would remove system columns
from views and allow the second example.
regards,
Hiroshi Inoue
http://w2422.nsk.ne
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]]
Hiroshi Inoue [EMAIL PROTECTED] writes:
Tom Lane wrote:
Sorry, I don't understand ...
Let t be a table which is defined as
create table t (id serial primary key, dt text);
Then is the following function *stable
Tom Lane wrote:
"Hiroshi Inoue" [EMAIL PROTECTED] writes:
I already mentioned an opinion in 2001/09/08.
Both the command counters and the snapshots in a
function should advance except the leading SELECT
statements.
I do not like the idea of treating the fi
2.nsk.ne.jp/~inoue/ ?
regards,
Hiroshi Inoue
http://w2422.nsk.ne.jp/~inoue/
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Julian Mehnle wrote:
Hiroshi Inoue [EMAIL PROTECTED] wrote:
Julian Mehnle [EMAIL PROTECTED] wrote:
Recently I tried to use the new 7.02.0001 Win32 ODBC driver
in the new (beta) Unicode mode in conjunction with MS Access
2000 and a "UNICODE" encoded database stored in a
Julian Mehnle wrote:
Yeah, it does *not* exhibit the faulty CRLF-LF conversion behavior.
Is this a custom build of the ODBC driver done by you? Will the
official driver be fixed soon?
I would commit the fix to cvs this week.
regards,
Hiroshi Inoue
http://w2422.nsk.ne.jp/~inoue
to ignore dropped columns
- This is also up for grabs.
As I remember, Hiroshi's drop column changed the attribute number to a
special negative value, which required lots of changes to track.
??? What do you mean by *lots of* ?
regards,
Hiroshi Inoue
http://w2422.nsk.ne.jp/~inoue
Bruce Momjian wrote:
Hiroshi Inoue wrote:
As I remember, Hiroshi's drop column changed the attribute number to a
special negative value, which required lots of changes to track.
??? What do you mean by *lots of* ?
Yes, please remind me. Was your solution renumbering the attno
Bruce Momjian wrote:
Hiroshi Inoue wrote:
Bruce Momjian wrote:
Hiroshi Inoue wrote:
As I remember, Hiroshi's drop column changed the attribute number to a
special negative value, which required lots of changes to track.
??? What do you mean by *lots of* ?
Yes
that we can use. Apart from the DropColumn
function itself, what other changes did you make? Did you have
modifications for '*' expansion in the parser, etc.?
Don't mind my posting.
I'm only correcting a misunderstanding for my work.
regards,
Hiroshi Inoue
http://w2422.nsk.ne.jp/~inoue
Tom Lane wrote:
Hiroshi Inoue [EMAIL PROTECTED] writes:
Tom Lane wrote:
Actually, your trial required column dropped-ness to be checked in
many more places than the proposed approach does.
Have you ever really checked my trial implementation ?
Well, I've certainly stumbled over
.
regards,
Hiroshi Inoue
http://w2422.nsk.ne.jp/~inoue/
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
level code, and that he hasn't
found all of it.
Please don't propagate an unfair valuation without any verification.
regards,
Hiroshi Inoue
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscr
would catch
dropped columns too,
but it causes other problems that are harder to fix
so we _dropped_ the idea.
What does this mean ?
BTW would we do nothing for clients after all ?
regards,
Hiroshi Inoue
---(end of broadcast)---
TIP 3
Bruce Momjian wrote:
Hiroshi Inoue wrote:
Makes sense. Of course, we could make a syscache that didn't return
system columns either.
Actually, the original argument for negative attno's for dropped columns
was exactly for this case, that the system column check would catch
Bruce Momjian wrote:
Hiroshi Inoue wrote:
Bruce Momjian wrote:
Hiroshi Inoue wrote:
BTW would we do nothing for clients after all ?
Clients will now need to check that dropped flag.
Clients would have to check the flag everywhere
pg_attribute appears.
Why should
in attnums ? And I don't object to the attisdropped
flag implemetation as long as it doesn't scatter the
attisdropped test around client applications.
Why would you like to do nothing for clients ?
regards,
Hiroshi Inoue
http://w2422.nsk.ne.jp/~inoue/
---(end
Tom Lane wrote:
Hiroshi Inoue [EMAIL PROTECTED] writes:
Have I ever mentioned that negative attno's is better
than the attisdropped flag implemetation in the handling
of gaps in attnums ?
How so? I don't see any improvement ...
Sorry please ignore my above words if it has no meanig
Hannu Krosing wrote:
On Wed, 2002-07-17 at 09:11, Hiroshi Inoue wrote:
Bruce Momjian wrote:
From my perspective, when client coders like Dave Page and others say
they would prefer the flag to the negative attno's, I don't have to
understand. I just take their word for it.
do
I sent a draft by mistake, sorry.
Hannu Krosing wrote:
On Wed, 2002-07-17 at 09:11, Hiroshi Inoue wrote:
Bruce Momjian wrote:
From my perspective, when client coders like Dave Page and others say
they would prefer the flag to the negative attno's, I don't have to
understand. I
attnums in the same way ?
regards,
Hiroshi Inoue
http://w2422.nsk.ne.jp/~inoue/
---(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
= 18720
2) relfilenode(==oid) = 16567;
and I could find a $PGDATA/base/18720/16567 file.
Could you find such a file ?
regards,
Hiroshi Inoue
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
Joel Burton wrote:
On Wed, 21 Mar 2001, Hiroshi Inoue wrote:
Joel Burton wrote:
Postmaster crashed on me, and on restart, pg_inherits cannot be found.
I can see it in pg_class (and it shows up w/ \dS), but any attempt to
modify anything fails with "pg_inherits: No such
* 2) we are in autocommit off state and the statement isn't of type
* OTHER.
*/
regards,
Hiroshi Inoue
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddress
.
regards,
Hiroshi Inoue
---(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
es a common snapshot
for a TX. Each query in READ COMMITTED isolation level uses its own
snapshot. It seems the only difference between SERIALZABLE and READ
COMMITTED. But there's a sort of SERIALIZABLE world inside functions
even under READ COMMITTED mode.
regards,
Hiroshi Inoue
---
to replace existent relation files safely. We could
avoid running VACUUM, multiple version of tuples in
a file etc ...
regards,
Hiroshi Inoue
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail
Hi,
There's a report of startup recovery failure in Japan.
Redo done but ...
Unfortunately I have no time today.
regards,
Hiroshi Inoue
KAMI wrote:
DEBUG: database system shutdown was interrupted at 2001-04-26 22:15:00 JST
DEBUG: CheckPoint record at (1, 3923829232)
DEBUG: Redo record
w in Japan.
Probably we couldn't expect too much of him.
regards,
Hiroshi Inoue
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
to get the log with
wal_debug = 1 unless we automatically force the
log in case of recovery failures.
regards,
Hiroshi Inoue
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
Bill Studenmund wrote:
On Thu, 19 Jul 2001, Hiroshi Inoue wrote:
This step I disagree with. Well, I disagree with the automated aspect
of
the update. How does postgres know that the new table a is sufficiently
like the old table that it should be used? A way the DBA could say, "
Tom Lane wrote:
Hiroshi Inoue [EMAIL PROTECTED] writes:
Tom Lane wrote:
Could you use CTID instead of OID?
I am using both.
TIDs for fast access and OIDs for identification.
Unfortunately TIDs are transient and they aren't
that reliable as for identification.
Hmm ... within
1 - 100 of 435 matches
Mail list logo
