there).
That actually seems simple enough?
I made some changes to multi thread handling of psqlodbc driver.
It's also better to fix the crash at backend side.
I made 2 patches.
The 1st one temporarily changes CurrentResourceOwner to
CurTransactionResourceOwner during catalog cac
Bruce Momjian wrote:
Hiroshi Inoue wrote:
Bruce Momjian wrote:
Where are we on this issue?
Oops I forgot it completely.
I have a little improved version and would post it tonight.
Ah, very good. Thanks.
Attached is an improved version.
regards,
Hiroshi Inoue
? formatting.patch
Bruce Momjian wrote:
Where are we on this issue?
Oops I forgot it completely.
I have a little improved version and would post it tonight.
regards,
Hiroshi Inoue
---
Hiroshi Inoue wrote:
Tom Lane wrote:
Alvaro
places we examine localeconv()
> output.
Attached is a patch to the current CVS.
It uses a similar way like LC_TIME stuff does.
regards,
Hiroshi Inoue
Index: pg_locale.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/utils/adt/p
rong with
urging such clients to eliminate the SET commands and use the nice
feature of FE/BE procotol?
regards,
Hiroshi Inoue
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Tom Lane wrote:
> Hiroshi Inoue writes:
>> I'm thinking of the following steps in the backend code.
>
>> 1.Set LC_MESSAGES to "C" until the client_encoding is
>> determined.
>> 2.When a client_encoding is specifed in the startup
>&
GES
overridden by step 1 before authorization step.
Then we can see properly localized authorization
failure messages.
3.Reset LC_MESSAGES to the current one in Initialize
ClientEncoding() and unbind the codeset if necessary
in SetDatabaseEncoding().
Comments?
regards,
Hiroshi Inoue
Tom Lane wrote:
> Peter Eisentraut writes:
>> Bruce Momjian wrote:
>>> Can someone comment on this?
>
>> Looks like a horrible hack to me. Recoding stuff to the client encoding
>> in the server outside the existing recoding mechanism looks pretty evil
>> to me. Plus, it does not address the p
patch exactly references the client_encoding included in
the startup message.
regards,
Hiroshi Inoue
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
driver can get
properly localized password error messages.
regards,
Hiroshi Inoue
Index: postmaster/postmaster.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/postmaster/postmaster.c,v
retrieving revision 1.570
diff -c -c -r1.570
don't fix it, all MySQL queries that are ported will be broken.
But it seems absurd to trouble existent PG users instead.
regrads,
Hiroshi Inoue
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> >> I'd say you shouldn't release it at all.
>
> > As far as I see I'm not releasing it.
>
> Oh, I hadn't looked closely at reindex_index. Hmm... okay, you are
> hold
Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > Where do I release the lock ?
>
> I'd say you shouldn't release it at all.
As far as I see I'm not releasing it.
regards,
Hiroshi Inoue
---(end of broadcast)---
Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > One backend would be blocked by another one because reindex_relation
> > calls reindex_index and reindex_index grabs an ExclusiveLock on the
> > relation.
> > Am I missing anything ?
>
how updating of
> > tables.
>
> Hmmm ... it looks like REINDEX only grabs AccessShareLock on the target
> relation, which seems very wrong.
Sorry I couldn't find where AccessShareLock is grabbed now.
AccessExclusiveLock is acquired in reindex_index but d
x27;m not sure if I could implement it at
once.
Are you in a hurry ?
regards,
Hiroshi
Inoue
Try running the postmaster
with -d2 (and without -S) and see what gets logged in its stderr output.
BTW what version of psqlodbc driver are you using ?
regards,
Hiroshi Inoue
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
exception, but with postgres I
> don't, I tried to insert the same record on PSQL and I get an error, could
> it be the ODBC driver?
>
> Please help me, if you know...
>
Try the latest ODBC driver at http://www.greatbridge.org/project/pgadmin/.
It includes an chan
ve half(or more) done it. I hope I could commit it
in a few days.
Regards,
Hiroshi Inoue
tried a vaccum:
>
> domains=# vacuum analyze;
> NOTICE: Index idx_domain_name: NUMBER OF INDEX' TUPLES (305) IS NOT THE
> SAME AS HEAP' (311).
> Recreate the index.
> VACUUM
>
This is a known bug.
Probably there's a long transaction somewhere.
It is fixed in 7.1.
Regards,
Hiroshi Inoue
ser-rewriter-planner acquires a short term lock.
This may be improved in 7.1 though I'm not sure.
Regards.
Hiroshi Inoue
4. press cntrl-D to exit the program.
5. restart postmaster.
Regards.
Hiroshi Inoue
owing other than acquiring a table level locking.
When there's no row which satisfies b = 2,two backends insert values
(500, 2) at the same time.
Regards.
Hiroshi Inoue
by using SELECT statements like
select CTID,* from myTable;
and update using CTID
update myTable set ..=.. where CTID=..;
Note that CTIDs aren't of int type.
Regards.
Hiroshi Inoue
gt;
The default transaction isolation level of PostgreSQL is READ COMMITTED.
However transaction isolation levels seems to be irrelevant to your problem.
PostgreSQL cursors don't see any changes made by other backends
after it was declared(opened) regardless of transaction isolation levels.
INSENSITIVE cursors aren't implemented yet. Cursors aren't INSENSITIVE
because they would see the changes made by the backend itself. It's also
regardless of transaction isolation levels.
Regards.
Hiroshi Inoue
block-is-referenced condition
> we'd sure like to know about it!
>
The following is an example which doesn't release the reference count.
Neither CommitTransaction() nor AbortTransaction() is called after '\q'
begin;
declare myc cursor for select * from ..;
fetch in myc;
\q
Regards.
Hiroshi Inoue
[EMAIL PROTECTED]
x27;t understand very well how
> these are used. Maybe someone else can say or you can experiment...
>
AFAIK,there's no pseudo-column like Oracle's rownum which is
dynamically allocated at execution time.
Regards.
Hiroshi Inoue
[EMAIL PROTECTED]
e user ...
commit;
This wouldn't be good for odbc/jdbc/ecpg etc.
How about starting new transaction automatically after committing
"create user ..." at backend side if "create user" is the first command
of the transaction ?
Regards.
Hiroshi Inoue
[EMAIL PROTECTED]
o the other server, in the place where the new database has been
> created ($PGDATA/base/$dbname).
Oh it seems almost same as pg_upgrade.
However you should probably copy pg_log and pg_variable to
$PGDATA as pg_upgrade does.
In addtion if postmaster is running,you should shutdown before
proces
> -Original Message-
> From: Peter Eisentraut [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, April 27, 2000 4:46 PM
> To: Hiroshi Inoue
>
> On Thu, 27 Apr 2000, Hiroshi Inoue wrote:
>
> > PostgreSQL's SERIALIZABLE isolation level would allow both inserts.
&
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Vadim
> Mikheev
> Sent: Monday, December 14, 1998 5:03 PM
> To: Hiroshi Inoue
> Cc: The Hermit Hacker; [EMAIL PROTECTED]
> Subject: Re: [GENERAL] TODO list elements
>
concurrency control.
>
What does it mean ?
LLL in 6.5 doesn't include row level locking ?
Thanks.
Hiroshi Inoue
[EMAIL PROTECTED]
32 matches
Mail list logo
