"John Sweeney" <[EMAIL PROTECTED]> writes:
> If a user logs on using md5 authentication, being the member of a role does
> not give the user permissions to see a table. This is VERY VERY VERY
> frustrating!
You really ought to provide some details ...
regards, tom lane
--
On Thu, Apr 06, 2006 at 10:04:03AM +, Alex Fomin wrote:
> While using the following function:
> ---
> nextval(sequence_name) returns currval(sequence_name) -1
> ---
> while +1 is expected. It happens only sometimes, no dependency can be found.
Could you provide a complete test case? That is,
Tom Lane wrote:
> Philip suggested to me off-list that the initial error may have been the
> VACUUM FULL (xid 32902872) creating duplicate moved copies of a single
> valid row. That seems plausible because VACUUM FULL suppresses
> duplicate-index checks, and it's real hard to see any other way tha
On Wed, 5 Apr 2006, Pavel Golub wrote:
> The following bug has been logged online:
>
> Bug reference: 2377
> Logged by: Pavel Golub
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: 8.1.0
> Operating system: Windows XP
> Description:pg_constraint didnt't updated
The following bug has been logged online:
Bug reference: 2377
Logged by: Pavel Golub
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.0
Operating system: Windows XP
Description:pg_constraint didnt't updated when table columns deleted
Details:
To illustrate t
The following bug has been logged online:
Bug reference: 2376
Logged by: John Sweeney
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.3
Operating system: fedora 3
Description:permission roles not respected
Details:
If a user logs on using md5 authentication
I'm reporting this as a PostgreSQL bug because it involves an index
corruption. I can't see any other way our application should be able to
corrupt an index. I will attach the tail of the log when the corruption
was detected (and the postmaster shut itself down), as well as the
subsequent attempt
The following bug has been logged online:
Bug reference: 2378
Logged by:
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.1
Operating system: windown XP, sp2
Description:installtation fail with error in Runinitdb
Details:
I follow the document of installati
The following bug has been logged online:
Bug reference: 2380
Logged by: Alex Fomin
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.3
Operating system: Ubuntu Linux
Description:Sequence problem
Details:
While using the following function:
---
nextval(sequen
> JiangWei <[EMAIL PROTECTED]> writes:
> > LANG=zh_CN.UTF-8
> > [ set client_encoding to LATIN1 and provoke an error ]
>
> OK, I can reproduce the crash after initdb'ing with that LANG setting
> (in an nls-enabled build). The postmaster log fills with a whole lot
> of occurrences of
>
>
Version(8.1.3)
Bug in window xp:
C:\Documents and Settings\openbase>pg_ctl
start
LOG: database system was shut down at 2006-4-04 15:54:43
中国标准时间LOG: checkpoint record is at 0/38C2E0LOG: redo record
is at 0/38C2E0; undo record is at 0/0; shutdown TRUELOG: next
transaction ID:
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> wrote:
>> Anyway, that explains your "heap_clean_redo: no block" failure. I think
>> you're stuck risking a pg_resetxlog to try to get back into the
>> database.
> Will do. Before I do that, though, is it worth making a
>>> On Thu, Apr 6, 2006 at 1:26 pm, in message
<[EMAIL PROTECTED]>,
> "Kevin Grittner" <[EMAIL PROTECTED]> writes:
>> Tom Lane <[EMAIL PROTECTED]> wrote:
>>> You weren't by any chance running with full_page_writes = off
>>> were you?
>
>> Yes we were. Apparently I have misunderstood the implica
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> wrote:
>> You weren't by any chance running with full_page_writes = off
>> were you?
> Yes we were. Apparently I have misunderstood the implications of this.
So had we all :-(. It just plain doesn't work in 8.1.*, and
>>> On Thu, Apr 6, 2006 at 12:57 pm, in message
<[EMAIL PROTECTED]>,
Tom Lane <[EMAIL PROTECTED]> wrote:
> "Kevin Grittner" <[EMAIL PROTECTED]> writes:
>> Right now the postmaster refuses to start. What is the best way to
get
>> past that to try what you suggest?
>
>> [2006- 04- 06 07:22:50.378
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> Right now the postmaster refuses to start. What is the best way to get
> past that to try what you suggest?
> [2006-04-06 07:22:50.378 ] 3984 PANIC: heap_clean_redo: no block
Hm, did this start happening immediately after the other problem?
That wo
Right now the postmaster refuses to start. What is the best way to get
past that to try what you suggest?
[2006-04-06 07:22:50.347 ] 3984 LOG: database system was interrupted
while in recovery at 2006-04-06 02:19:59 Central Daylight Time
[2006-04-06 07:22:50.347 ] 3984 HINT: This probably means
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> [2006-04-06 02:19:57.460 ] 3848 PANIC:
> right sibling is not next child in "Panel_pkey"
This should be repeatable by re-attempting a VACUUM, right? Please find
out which page exactly it's unhappy about (either gdb the crash or add a
printout of t
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Philip Warner wrote:
>> Item 7 -- Length: 168 Offset: 3920 (0x0f50) Flags: USED
>> XMIN: 32902771 CMIN: 20 XMAX: 0 CMAX|XVAC: 32902872
>> Block Id: 0 linp Index: 7 Attributes: 34 Size: 36
>> infomask: 0x2913
>> (HASNULL|HASVARWIDTH|HASOID|XM
Philip Warner wrote:
> Item 7 -- Length: 168 Offset: 3920 (0x0f50) Flags: USED
> XMIN: 32902771 CMIN: 20 XMAX: 0 CMAX|XVAC: 32902872
> Block Id: 0 linp Index: 7 Attributes: 34 Size: 36
> infomask: 0x2913
> (HASNULL|HASVARWIDTH|HASOID|XMIN_COMMITTED|XMAX_INVALID|UPDATED)
> t_b
Apologies if this is a duplicate, but my original post stalled and I
noticed I had omitted the postgres version, which you will want.
I'm reporting this as a PostgreSQL bug because it involves an index
corruption. I can't see any other way our application should be able to
corrupt an index. I wi
Oops. Minor change. Last two fields are updated by rules.
Tom Lane wrote:
> Philip Warner <[EMAIL PROTECTED]> writes:
>
>> aView_update_r1 AS
>> ON UPDATE TO aView DO INSTEAD UPDATE brokenTable SET f1 = new.f1
>> WHERE brokenTable.id = new.id
>> aView_update_r2 AS
>> ON UPDATE TO a
Tom Lane wrote:
> Philip Warner <[EMAIL PROTECTED]> writes:
>
>> aView_update_r1 AS
>> ON UPDATE TO aView DO INSTEAD UPDATE brokenTable SET f1 = new.f1
>> WHERE brokenTable.id = new.id
>> aView_update_r2 AS
>> ON UPDATE TO aView DO INSTEAD UPDATE brokenTable SET f2 = new.f2
>> WH
Philip Warner <[EMAIL PROTECTED]> writes:
> aView_update_r1 AS
> ON UPDATE TO aView DO INSTEAD UPDATE brokenTable SET f1 = new.f1
> WHERE brokenTable.id = new.id
> aView_update_r2 AS
> ON UPDATE TO aView DO INSTEAD UPDATE brokenTable SET f2 = new.f2
> WHERE brokenTable.id = new.id
Tom Lane wrote:
> OK, I'm a bit confused by the obfuscation here. The table with the
> duplicates is xxx, or qqq?
Possibly less obscure version:
public | tg_update_anotherTable_date | "trigger"
| | mail | plpgsql |
Declare
uid bigint;
Begin
Tom Lane wrote:
> OK, I'm a bit confused by the obfuscation here. The table with the
> duplicates is xxx, or qqq?
Yes, xxx is the broken table. The two rewrite rules map updates on a
view to an underlying table (the broken one).
Updates on the view occur very frequently. Perhaps 400,000 per day?
Philip Warner <[EMAIL PROTECTED]> writes:
> public | tg_update_qqq_date | "trigger"
> | | mail | plpgsql |
> Declare
> uid bigint;
> Begin
> uid = (select owner_id from yyy m where m.f1 = NEW.f1);
> if (uid <> 0 and not uid i
Tom Lane wrote:
>> Updates happen regularly from many sources, but the procedure that does
>> the most updates is a trigger. Do you want to see that?
>>
>
> Please.
>
public | tg_update_qqq_date | "trigger"
| | mail | plpgsql |
Declare
uid
Philip Warner <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> The thing that is striking though is
>> that the xmin/cmin values are all the same, indicating that all six
>> tuples were inserted by the same command. That seems pretty odd. Can
>> you show us the procedure by which rows are inserte
Tom Lane wrote:
> Philip Warner <[EMAIL PROTECTED]> writes:
>
>> mail=# set enable_indexscan=off;
>> mail=# SELECT xmin, xmax, cmin, cmax,ctid FROM xxx where id = 24613;
>>xmin | xmax | cmin | cmax | ctid
>> --+--+--+--+-
>> 32902771 |0
Philip Warner <[EMAIL PROTECTED]> writes:
> mail=# set enable_indexscan=off;
> mail=# SELECT xmin, xmax, cmin, cmax,ctid FROM xxx where id = 24613;
>xmin | xmax | cmin | cmax | ctid
> --+--+--+--+-
> 32902771 |0 | 20 | 32902872 | (0,7)
Alvaro Herrera wrote:
> Do the triggers involved have EXCEPTION clauses? (I assume they are
> written in PL/pgSQL -- are there any in other languages?)
Triggers that update this table are in pl/pgsql, and can *raise*
exceptions (using RAISE) if that is what you mean. They do not handle
them -- is t
Tom Lane wrote:
> For completeness, could we also see ctid in that query?
mail=# set enable_indexscan=off;
mail=# SELECT xmin, xmax, cmin, cmax,ctid FROM xxx where id = 24613;
xmin | xmax | cmin | cmax | ctid
--+--+--+--+-
32902771 |0 | 2
Philip Warner wrote:
> # set enable_indexscan=off;
> # SELECT xmin, xmax, cmin, cmax FROM xxx where id = 24613;
>xmin | xmax | cmin | cmax
> --+--+--+--
> 32902771 |0 | 20 | 32902872
> 32902771 |0 | 20 | 32902872
> 32902771 |0
Philip Warner <[EMAIL PROTECTED]> writes:
> # set enable_indexscan=off;
> # SELECT xmin, xmax, cmin, cmax FROM xxx where id = 24613;
>xmin | xmax | cmin | cmax
> --+--+--+--
> 32902771 |0 | 20 | 32902872
> 32902771 |0 | 20 | 32902872
>
On Apr 5, 2006, at 7:28 AM, William Leite Araújo wrote:
On 4/3/06, Tom Lane <[EMAIL PROTECTED]> wrote:
(...)
You need to read up on SECURITY DEFINER functions.
regards, tom lane
Ok, I'll do this way, but still don't understand why it doesn't
returns.
I'm doing t
On Apr 2, 2006, at 8:36 PM, Anthony Ransley wrote:
The Windows version of PostgreSQL 8.1.3.6044 has randomly crashed a
few times now. Can anyone supply me with the symbol set for the
8.1.3.6044 Windows release, so I can provide more information and
maybe even debug it.
What's the data c
Michael Fuhr wrote:
> On Thu, Apr 06, 2006 at 08:12:31AM -0400, Alvaro Herrera wrote:
>
>> Please do a
>>
>> SELECT xmin, xmax, cmin, cmax FROM xxx where id = 24613;
>>
# set enable_indexscan=off;
# SELECT xmin, xmax, cmin, cmax FROM xxx where id = 24613;
xmin | xmax | cmin | cma
On Thu, Apr 06, 2006 at 08:12:31AM -0400, Alvaro Herrera wrote:
> Please do a
>
> SELECT xmin, xmax, cmin, cmax FROM xxx where id = 24613;
>
> if you still have that particular manifestation.
Also, you'll probably need to set enable_indexscan to off prior to
running the above query.
--
Michael
Philip Warner wrote:
> We have an intermittent bug that occurs on a table which is updated several
> times per second. The bug occurs every few days/weeks. It is usually
> preceeded by a "tuple concurrently updated" messages, but I could not swear
> it is always preceeded by it.
>
> The result of
40 matches
Mail list logo
