[BUGS] Bug #544: Upgrade to 7.1 - sequence permissions not restored
John Bradshaw ([EMAIL PROTECTED]) reports a bug with a severity of 4 The lower the number the more severe it is. Short Description Upgrade to 7.1 - sequence permissions not restored Long Description Permissions on sequences are not restored when upgrading to 7.1 Got a write error stating that I don't have permission to update .nextval Sample Code No file was uploaded with this report ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[BUGS] After ~Crash Sequence not correct
Severity: Annoyance Setup: PostgreSQL 7.1.2 on Dual PIII WinNT4 server + Cygwin 1.3.2 PostgreSQL is run as a service and when rebooting (which doesn't shutdown - previously on cygwin list (hence the ~Crash in title)) I have twice noticed that a sequence was not properly updated, however records with Primary keys based upon the sequence where present in the table. (I *think* it was a different table & sequence last time). - Stuart ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] Bug #544: Upgrade to 7.1 - sequence permissions not restored
[EMAIL PROTECTED] writes: > Permissions on sequences are not restored when upgrading to 7.1 > Got a write error stating that I don't have permission to update .nextval Actually, the permissions *are* restored; the problem is that 7.1 is making more permission checks than prior versions did. You'll need to GRANT the appropriate permissions on the sequence. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [BUGS] After ~Crash Sequence not correct
"Henshall, Stuart - WCP" <[EMAIL PROTECTED]> writes: > Setup: PostgreSQL 7.1.2 on Dual PIII WinNT4 server + Cygwin 1.3.2 > PostgreSQL is run as a service and when rebooting (which doesn't shutdown - > previously on cygwin list (hence the ~Crash in title)) I have twice noticed > that a sequence was not properly updated, however records with Primary keys > based upon the sequence where present in the table. Hmm. You're about the third person to report something like this, so there's clearly something not right. I'm guessing a bug in the WAL logging or redo code for sequences ... regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [BUGS] After ~Crash Sequence not correct
I have verified that killing the postmaster after a few nextval's leaves things in a bad state after restart. I think I see the problem: in nextval(), the sequence data written to the WAL log is different from that written to the data page. Isn't that bogus? To WAL: seq->last_value = next; seq->is_called = true; seq->log_cnt = 0; To disk: seq->last_value = last; /* last fetched number */ seq->is_called = true; seq->log_cnt = log; /* how much is logged */ (also, "log" has been changed between these two points) regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] After ~Crash Sequence not correct
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes: > It was made to avoid WAL-loging on each nextval call, ie it should work > like OID pre-fetching: value stored in WAL must always "exceed" values > returned by nextval so on the after-crash-restart sequence should be > advanced to value which was never returned by nextval (for non-cycled > sequences). Maybe I made some mistakes in implementation? Oh, okay. What I saw was that the next nextval() after restart was higher than what I was expecting; but that's correct given the prefetch behavior. But we've seen several reports wherein the value appeared to go backwards after a crash. Stuart, you weren't running with -F (fsync off) by any chance, were you? regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] Unable to compare _bpchar for similarity in WHERE-clause
On Mon, 17 Dec 2001, Tom Lane wrote: > Justin <[EMAIL PROTECTED]> writes: > > On Saturday 15 December 2001 03:06, Tom Lane wrote: > >> It's too late to fix this in the standard catalogs for 7.2, but I'll > >> make a note for 7.3. > > > Suitable for 7.2.1? > > Nyet. We don't do initdbs for dot-releases. But whouldn't a patch script be enough for this change? A few insert with fixed oid commands would do it. No initdb needed, and the oid numbers could be taken from what will be used for 7.3. The script would need to make sure there isn't already something at that oid, and that it hadn't been run already. But nothing should get inserted with oids in the reserved space anyway. :-) Take care, Bill ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
