Обсуждение: Making changes visible to other connections

Поиск
Список
Период
Сортировка

Making changes visible to other connections

От
andrew@ugh.net.au
Дата:
Hi,

If I run an UPDATE operation from one connection the changed data is only
visible from that connection. How do make the change visible from other
connections? Do I have to wrap everything in a transaction?

I'm using libpq if that makes a difference.

Thanks,

Andrew



Is there any caveats on toasted fields?

От
"He Weiping (Laser Henry)"
Дата:
Hi, there

    I want to make a little db and want to use it to store some kind of text
file,
I'm using current CVS tree, the table is simple:

create table toastest(
name text,
content text);

then I do some insert using sql script, and some work fine, but others
always
got such kind of messages like:

psql:scriptname:1615: ERROR:  parser: parse error at or near "ll"

(1615 is the totally line of that file);
and I also try to use pltcl to do this, and the problem is the same.
Am I doing wrong, or are there some caveats to care?
How can I explain these?
Any suggestions?

P.S. I'm using MB encoding of EUC_CN.

Regards

Laser


Re: Making changes visible to other connections

От
Дата:
On Tue, 10 Oct 2000 andrew@ugh.net.au wrote:

> If I run an UPDATE operation from one connection the changed data is only
> visible from that connection. How do make the change visible from other
> connections? Do I have to wrap everything in a transaction?

I would venture to say yes.  If you are doing any kind of multi-user
activity, you should be using transactions and committing or rolling back
your data to maintain integrity.  This applies whether you are using
libpq, DBI, ODBC, or whatever.

Brett W. McCoy
                                              http://www.chapelperilous.net
---------------------------------------------------------------------------
The problem with the gene pool is that there is no lifeguard.


Re: Making changes visible to other connections

От
andrew@ugh.net.au
Дата:

On Tue, 10 Oct 2000 bmccoy@chapelperilous.net wrote:

> I would venture to say yes.  If you are doing any kind of multi-user
> activity, you should be using transactions and committing or rolling back
> your data to maintain integrity.  This applies whether you are using
> libpq, DBI, ODBC, or whatever.

Ahh OK. I was hoping I wouldnt have to for single statement transactions
as there is nothing to roll back if it fails. I'll try it and see how I
go.

Thanks,

Andrew


Re: Making changes visible to other connections

От
andrew@ugh.net.au
Дата:

On Tue, 10 Oct 2000 bmccoy@chapelperilous.net wrote:

> On Tue, 10 Oct 2000 andrew@ugh.net.au wrote:

<snip>

> > connections? Do I have to wrap everything in a transaction?
>
> I would venture to say yes.  If you are doing any kind of multi-user

<snip>

Alas that doesn't work either. I PQExeced BEGIN, UPDATE, COMMIT and still
the change can't be seen from other connections :-(

Andrew


Re: Making changes visible to other connections

От
andrew@ugh.net.au
Дата:
Hmm...It seems I was barking up completely the wrong tree. Everything now
works as I would expect without having to use a transaction.

I'm not exactly sure why but I think it may have been permissions...I
dropped the database and recreated it so it was owned by the user trying
to do the update and now it works fine.

Questions that now come to mind:

1) If it was permissions why did the returned result from PQExec indicate
everything was OK?
2) If it was permissions how come nothing is logged in errlog?
3) If it wasn't permissions what was it?
4) Is there any way to chown a database and tables? I'm guessing its an
update on some system table?

Thanks to Brett McCoy for his assistance,

Andrew



Re: Is there any caveats on toasted fields?

От
Tom Lane
Дата:
"He Weiping (Laser Henry)" <laser@zhengmai.com.cn> writes:
> I'm using current CVS tree, the table is simple:
> then I do some insert using sql script, and some work fine, but others
> always
> got such kind of messages like:

> psql:scriptname:1615: ERROR:  parser: parse error at or near "ll"

> P.S. I'm using MB encoding of EUC_CN.

Hm.  TOAST doesn't care one way or the other about multibyte encodings.
I think you've just found some garden-variety parser bug, or possibly
a psql bug.  Try running the postmaster with -d2 so that received
queries are logged in the postmaster's stdout log file, and then you
can see exactly what query is triggering this error.

            regards, tom lane