Bhuvan A writes:
> while creating a table with a column of type 'serial', well a sequence
> has been created and the default value of that field is set to nextval
> of that sequence, fine. But while dropping that table, why aren't that
> sequence dropped?
The sequence isn't owned by the table.
hi,
Hope you might have came accross this problem earlier. it exists in
7.1.x and 7.2 as well.
while creating a table with a column of type 'serial', well a sequence
has been created and the default value of that field is set to nextval
of that sequence, fine. But while dropping that table, why
Per Winkvist writes:
> When creating a table from psql named 'tblProduct' that is turned into
> tblproduct.
Unless you double-quote it.
> However, when creating a table with the tcl/tk application pgaccess you
> can create a table that have capital letters. Isn't this a bug ?
No.
--
Peter Ei
On Wed, 13 Mar 2002, Tom Lane wrote:
>
> I don't think that can work. AFAICT what your patch does is to ensure
> a WAL record is written by the first nextval() in any given backend
> session.
That's exactly what it does, yes. It forces the WAL record to be
written at least once. I think th
I said:
> Mmm ... maybe. Is this safe if a checkpoint is currently in progress?
> Seems like you could look at RedoRecPtr and decide you are okay, but you
> really are not if checkpointer has already dumped sequence' disk
> buffer and will later set RedoRecPtr to a value beyond the old LSN.
Oh,
On Wed, 13 Mar 2002, Bruce Momjian wrote:
> Stephan, let me know if you want this considered for inclusion in CVS.
Probably a good idea in case I can't manage to rewrite the triggers which
is involving lots of looking through other code to see how to do stuff.
It's fairly safe, but probably not
On Mar 10, Stephan Szabo wrote:
> On Mon, 11 Mar 2002, Bhuvan A wrote:
>
> > here i have a problem in comparing null values in plpgsql. this exist
> > in 7.1.x and 7.2 as well.
> >
> > the condition != fails in plpgsql.
> > consider this function is triggered on every updation on a table.
> >
Stephan, let me know if you want this considered for inclusion in CVS.
Stephan Szabo wrote:
>
> On Wed, 6 Mar 2002, Eric Lu wrote:
>
> > To whom it may concern:
> >
> > I found a constraint bug on PostgreSQL lastest version (7.2).
>
> Yes, it's still seeing some invalid states of the table.
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> It seems safe to do NOT write WAL record if sequence
> LSN > system RedoRecPtr because of checkpoint started after our
> check would finish only after writing to disk sequence buffer with
> proper last_value and log_cnt (nextval keeps lock on sequence
Happens on:
PostgreSQL 7.0.3 on i686-pc-linux-gnu, compiled by gcc 2.96
PostgreSQL 7.1.3 on i686-pc-linux-gnu, compiled by GCC 2.96
-- Pgsql inserts bad timestamp (seconds 60.00):
CREATE TABLE datetest ( datecol timestamp );
INSERT INTO datetest VALUES ('2002-01-05
Hi,
When creating a table from psql named 'tblProduct' that is turned into
tblproduct. (I'm accessing pg through Qt db classes too and I experience
the same thing there too I believe)
However, when creating a table with the tcl/tk application pgaccess you
can create a table that have capital let
Ben Grimm <[EMAIL PROTECTED]> writes:
> It seems like you just need to ensure that when the sequence is loaded
> from disk that log_cnt gets updated and written back to disk before the
> sequence is used. I'm not sure of the impact, but I can't reproduce the
> bugs after making these changes.
On Tue, 12 Mar 2002, Tom Lane wrote:
>
> The "no commit record" part of the logic seems okay to me, but we need
> an independent test to decide whether to write/flush XLog. If we have
> reported a nextval() value to the client then it seems to me we'd better
> be certain that XLOG record is flu
POSTGRESQL BUG REPORT TEMPLATE
Your name : Ward Vandewege
Your email address : [EMAIL PROTECT
On Wed, 13 Mar 2002, Tom Lane wrote:
>
> Accordingly, I'm thinking that we must remove the SEQ_LOG_VALS
> functionality and force one-WAL-record-per-nextval operation.
>
> Vadim, do you see another way? This was a cool idea and I hate
> to throw it away...
>
It seems like you just need to ens
On Wed, 6 Mar 2002, Eric Lu wrote:
> To whom it may concern:
>
> I found a constraint bug on PostgreSQL lastest version (7.2).
Yes, it's still seeing some invalid states of the table. I believe
the following will fix the case (it was part of a larger patch that
was rejected, but I think this p
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I can confirm repeatable case!
Ah-hah, now I understand the problem. I think sequences are suffering
from premature optimization.
The crux of the matter: sequences try to avoid generating a WAL record
for every single nextval(). The idea is to genera
> > update pg_language set lanplcallfoid=374578 where
> > lanname='plpgsql';
>
> > Is it correct ?
>
> Right.
Ok, it's working fine now.
Thanks you very very much.
Bye
Laurent
=
The misspelling master is on the Web.
_100 % Dictionnary Free !
//(
/ Dico / /
--- Tom Lane <[EMAIL PROTECTED]> a écrit :
> Well, that looks reasonable, but what's its OID?
> (should've asked for
> select oid,* from ...)
scheduling=# select oid, * from pg_proc where
proname='plpgsql_call_handler';
oid | proname| proowner | prolang |
proisinh | proistrus
Hi all,
Oups, I forgot to put the ML in copy of my reply :-(
[...]
> > ERROR: fmgr_info: function 16594: cache lookup
> failed
> Most likely this means something happened to the
> call handler function
> for plpgsql. Look in pg_language to see the
> "lanplcallfoid" value for
> plpgsql; is i
To whom it may concern:
I found a constraint bug on PostgreSQL
lastest version (7.2).
Here is how I got the
bug.testdb=>testdb=>
create table mytest(testdb-> id int primary key,testdb-> master
21 matches
Mail list logo
