Hi,
Reading up on the release notes of v9.1 I noticed an 'add documentation for
pg_options_to_table()'. Since I didn't know of this function yet and the entry
implied that it would be there in earlier versions, I was tempted to try in
our current version:
postgres=# select version();
Hi Tom,
> Hmm ... the relevant code change seems to have been
> http://archives.postgresql.org/pgsql-committers/2009-04/msg00127.php
Well, though not during beta, the field testing did pay off ;)
> I think I might have been overenthusiastic in trying to free resources
> during a subtransaction a
Ok,
So this took a while, but here's your test case.
Turns out to be quite small actually ;)
create table t1 (id int);
CREATE FUNCTION tr_t1_after_iud()
RETURNS trigger
LANGUAGE 'plpgsql'
VOLATILE
STRICT
SECURITY INVOKER
AS 'DECLARE
BEGIN
RAISE NOTICE ''%'', ROW(NEW.*);
SELECT 1/0;
RET
Hi Tom,
> >> Those are bugs (although there is probably only one bug and the rest is
> >> collateral damage). May we have a test case?
> >
> > Scripts, triggers and stuff are a bit complex, before assigning the
> > resources for that, could we help with creating a backtrace?
>
> You did show a ba
Op donderdag 16 juli 2009, schreef Tom Lane:
> >> Those are bugs (although there is probably only one bug and the rest is
> >> collateral damage). May we have a test case?
> >
> > Scripts, triggers and stuff are a bit complex, before assigning the
> > resources for that, could we help with creatin
Hi,
> > WARNING: AbortSubTransaction while in ABORT state
> > WARNING: did not find subXID 75610 in MyProc
> > ERROR: tupdesc reference 0x7ffe74eaf028 is not owned by resource owner
> > SubTransaction
>
> Those are bugs (although there is probably only one bug and the rest is
> collateral damage).
L.S.
We're working on some conversion script which in itself ran fine. We then
added a couple of additional checks, one of which was wrong and thus bailed
out, but ran into the following (from the log):
LOG: statement: update stock_item_composition set ..
ERROR: new row for relation "site
Hi Tom,
Op dinsdag 14 juli 2009, schreef Tom Lane:
> I think the attached patch will fix it for you.
Yep, after applying it yesterday evening, we didn't see this problem at all
today, so it definitely looks as if this patch nailed it.
Thanks for the [great|quick] support !
--
Best,
Fra
Hi,
> I think the attached patch will fix it for you.
Great, thanks!
I'll apply this tonight, will get back with results tomorrow.
--
Best,
Frank.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
Hi,
> I'm convinced that 8.3 has the same bug, in the sense that it could fail
> this way if it had to revalidate a cached plan. Probably the reason you
> didn't see it before is that 8.4 has more conditions in which it will
> invalidate cached plans.
Ok
> In particular, is it possible that thi
Hi,
> Hmph. So evidently the unexpected recursion into SPI is happening when
> a cached plan has to be recomputed. I suspected something of the sort,
> but now the question is why you didn't see the same problem in 8.3 ...
Just as an additional confirmation: nothing else but the db changed when
Hi Marek,
> Could you please send me gdb
> commands - I could also provide the backtrace
Basically the flow is as follows:
- identify the backend that you expect to run in to this error by pid
- start gdb with the option "-p " to attach to this backend
- set a conditional breakpoint:
b
Hi,
> This is a normal interbackend communication signal. You need to
> configure gdb to ignore SIGUSR2 (ie, pass it on and not stop execution).
> Probably SIGUSR1 too.
Done.
Here's the result:
Breakpoint 1, 0x0054aec0 in SPI_connect ()
(gdb) bt
#0 0x0054aec0 in SPI_connect ()
Hi Tom,
Op maandag 13 juli 2009, schreef Tom Lane:
> Frank van Vugt writes:
> > Any clues as to how to gather additional information that might bring us
> > closer to a solution is appreciated also.
>
> A stack trace from the point of the error would probably tell us a gre
L.S.
After an upgrade to v8.4 one of our clients is experiencing heaps of problems,
they get errors like "ERROR: SPI_connect failed: SPI_ERROR_CONNECT".
I refer to this earlier post, it looks a lot like it:
http://archives.postgresql.org/pgsql-general/2009-07/msg00388.php
We too had no
Hi,
> As it seems, the result is actually a correct array
It's an array of xid, indeed.
> And comparing the result to for example an int, works.
Only equality only, that is.
> Sidenote: since it does solve my problem, I can now build an index
> based on such an interpretation of xmin
I w
Hi,
While trying to find a way to get indexed access to a table based on it's
xmin, I ran into the following error message that seems a bit misleading:
db=# select xmin || ' ' from limit 1;
ERROR: array value must start with "{" or dimension information
Toying a bit more with this result r
Hi,
I noticed that the example code for SELECT STRICT mentioned in the docs
(v8.2.4) under "37.6.3. Executing a Query with a Single-Row Result" mentions:
BEGIN;
SELECT * INTO STRICT myrec FROM emp WHERE empname = myname;
EXCEPTION
WHEN NO_DATA_FOUND THEN
RAISE EXCEPTI
> > Ok, so for patch-sake, when I change BeginInternalSubTransaction() in
> > xact.c by moving these two cases to the upper set
> > (TBLOCK_STARTED/INPROGRESS/SUBINPROGRESS), then I should be ok?
> Try it and see ...
Been there, done that, seems to work (both the example as well as my usecase).
> Hmm, do you get the impression that user-written constraint triggers
> aren't very well tested ;-) ?
Well, we users are here to serve ;)
> It looks to me like BeginInternalSubTransaction simply needs to allow
> TBLOCK_END (and TBLOCK_PREPARE too) as acceptable initial states
Ok, so for patch-s
Hi,
Migrating a number of sql-functions to plpgsql-functions with added
functionality resulted in a backend crash.
# select version();
version
PostgreSQL 8.2.4 on i686-pc-linux-gnu, compiled
Hi,
> In the first place, you are evidently running as superuser, which means
> that has_foo_privilege will ALWAYS say 't'
Ok, seems reasonable ;)
> (except possibly if the
> target object doesn't exist, in which case I think you get an error).
Yep, one does.
> In the second place, trying to
Hi,
While running 2 sessions in different terminals for the same user, what
happens in the second session here looks a bit weird:
=
=
db=# create temp table t_test (id int);
CREATE TABLE
db=# select table_schema from information_schema.tables
where table_name = 't_test
> I concluded that patching vacuum.c was much the cleanest way to do it.
> Here's the patch against 8.1 branch.
Great, it looks like this patch fixes the remainder of my original problem as
well !
( http://archives.postgresql.org/pgsql-bugs/2005-11/msg00276.php )
--
Best,
Frank.
---
> Can you break out a test case from the restore script and send it to
> Alvaro and me? If it's still failing on CVS tip then there's something
> else going on here ...
Mmm, I tried and created a dump of the purchaseorder_line table only, but its
restore didn't fail in 50+ attempts ;(. Obviously
> Hm, I'm wondering if the toast-vs-index bug could be relevant. Could
> you try 8.1 branch tip? Or at least apply this patch:
>
> http://archives.postgresql.org/pgsql-committers/2005-11/msg00439.php
Hmm, the patch mentioned for ExecMain.c won't apply to my base version, so I
went for a fresh c
> > I've changed autovacuum.c per this diff, I 'hope' I misinterpreted what
> > needed to be done (see below):
>
> No, that diff is exactly what I applied. But I think you must have done
> something else wrong
That's a bit harsh ;)
> , because while I can reproduce the crash easily on
> the unp
> No. There are two StartTransactionCommand calls in autovacuum.c, and
> what I'm suggesting is to add the ActiveSnapshot assignment after each
> one.
> Done.
I've changed autovacuum.c per this diff, I 'hope' I misinterpreted what needed
to be done (see below):
==
Alvaro,
> Hum, I'm unable to reproduce the problem here; could you give me the
> code for the functions in the functional indexes for tables 164956 or
> 227469? They must be non-trivial SQL functions AFAICT (I'm rather
> unable to figure out their shape based only on the backtrace.)
Obviously th
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > The attached patch should correct the problem, but I'd like to make sure
> > it does ...
> Rather than that, I'd suggest just setting ActiveSnapshot
> unconditionally after each of the StartTransactionCommand calls in
> autovacuum.c, ie make the cod
L.S.
Since I started to use v8.1 I've been seeing incidental segfaults of the
autovacuum process, probably when it is kicking in at some particular point
during the pg_restore of a database:
<-2005-11-28 09:39:12 CET>LOG: autovacuum process (PID 5075) was terminated
by signal 11
<-2005-11-28
L.S.
I noticed that after creating these necessary objects:
create table t_src(value int);
create table t_dest(value int primary key);
create or replace function tr_t_dest_before_iud()
returns trigger
language 'plpgsql'
vola
L.S.
I haven't been able to reproduce this at will, the problem probably depends on
exactly how the trigger being replaced is used at that exact moment, but it
may still be enough info.
db=# select version();
version
--
Ouch,
SS> You've analyzed the situation incorrectly I believe.
SS> In this query in the subselect the id column is an outer reference to
SS> the id column generated from full_sequence.
TL> This is not a bug, it is user error.
TL> The actual problem here is that "id" is a perfectly valid outer re
L.S.
Looking forward to your analysis of the following bug:
database=# select version();
version
PostgreSQL 8.0.3 on i586-pc-linux-gnu, compiled by GCC gcc (GCC) 3.2.3
(1 row)
ST
L.S.
This may not 'qualify' as a bug, but just in case:
# select version();
version
PostgreSQL 8.0.3 on i586-pc-linux-gnu, compiled by GCC gcc (GCC) 3.2.3
=> use pg_restore to restore a dum
Hi Tom,
> Looks like the problem is associated with DEFERRED AFTER triggers
> The attached patch fixes the test case you sent; can you
> try it against your other problem?
I patched RC1 with this and tried the conversion again. Though still running,
it's passed the point where the mem-alloc err
Hi Tom,
> Because the trigger function is plpgsql, this could happen only the
> first time the trigger is fired in a particular session (unless you are
> using EXECUTE to invoke the update command?). If the problem is related
> to the planner constant-folding environment, then the first-time-only
> > The only thing I can think of is that the handling of pol X and creation
> > of pol Y from within spawn_pol() is somehow messing things up, but..
> Certainly the mere firing of a deferred trigger isn't the problem; we do
> that all the time.
Me too ;)
I was more trying to emphase the mul
> [ scratches head ... ] AFAICS, the CopySnapshot that gets the error
> must be trying to copy one or the other of those snapshots. Maybe you
> should look at the address passed to CopySnapshot and see what it's
> really pointing at, and where it came from.
Ok, stepping through the transaction d
> > Meanwhile, one of the application developers here bumped into a way to
> > reproduce what looks like the same memory alloc problem (exactly the same
> > point in exactly the same trigger) using our application software
> > only,
>
> Oh good. Can you construct a self-contained test case then?
> Hmm. The line number referenced for CommitTransactionCommand() is
> definitely in code that is only entered after a savepoint, but I see
> it is an identical code path to some other arms of the switch()
> command. Probably the compiler decided to merge those arms. You might
> want to back off
> >> Does anything happen before the SAVEPOINT?
> >
> > Actually, the SQL involved is v7.4.6,
>
> Not with that backtrace, it isn't.
Excuse me?
I'm running v8.0.0beta5, but the sql-statements that are in my source-tree are
all still 'based on v7.4.6', i.e. there is no occurence of the word
'sav
> > A hint on the expression(s) to use would be appreciated !
> (gdb) watch SerializableSnapshotData.xcnt
I could have thought of that ;)
(I misinterpreted what you meant by SerializableSnapshotData.xcnt, wouldn't
have asked otherwise)
Anyway, I just confirmed that hardware watchpoints are avai
Ok, here are the results of the assertion TRAP (mind you, same error on the
same line, but a different machine than the original)
database log:
TRAP: FailedAssertion("!(((ntp)->t_data)->t_infomask & 0x0010)", File:
"catcache.c", Line: 1729)
gdb:
Program received signal SIGABRT, Aborted.
0x4
> > I could reproduce this case tomorrow and inspect some variables or call
> > abort() if you think that could be of any help?
>
> Do you have hardware watchpoints on that machine?
Mmm, don't know for sure, will have a look tomorrow.
> What I'd be inclined
> to try is tracing through the transac
> > #1 0x0818e9e1 in SendPostmasterSignal (reason=PMSIGNAL_PASSWORD_CHANGE)
> > at pmsignal.c:69
> >
> > As far as the other problem is concerned, I just finished the first half
> > of the conversion on a different machine that was build with assertions
> > enabled and saw a number of reports li
> > Here's what's going on when the memory alloc problem occurs:
> AFAICS this can only be explained as a memory stomp on the static data
> structures SerializableSnapshotData or LatestSnapshotData. That seems a
> tad improbable. I wonder if what you have is a build problem. Have you
> tried a
> [ raised eyebrow... ] That should definitely not be happening either.
> In fact, I find that considerably more surprising than your original
> report. I'd suggest chasing this first.
It was already well on its way, so
Here's what's going on when the memory alloc problem occurs:
(gdb) b
> > I'm wondering
> > about the best way to proceed in order to produce some helpfull input to
> > the developers.
>
> Provide a reproducible test case maybe?
Sorry, won't be that easy. I didn't encounter the problem with earlier
(smaller) data-sets and even if I would put in the hours needed in
L.S.
Situation:
- PostgreSQL v8.0.0beta5 running on x86 hardware
- a database schema that uses before/after/deferred triggers to do additional
processing on stuff like orders and invoices based on the order- and
invoice--lines; the deferred triggers are basically of the format 'update
order s
> Possibly a bug in your old glibc version?
Could be, a quick search does reveal some reports on a problem with the
combination of glibc 2.1.3 an towupper.
I'll look into the possibility of upgrading libc, but given the source of
oracle_compat.c, would it be possible to get the v7.4.6 behaviour
L.S.
I've been using a certain pgsql function (IMMUTABLE/STRICT) happily in v7.4.6,
but when trying out v8.0.0beta5 the exact same function causes the backend to
segfault.
(Further examination revealed that a simple 'select initcap('f')' is enough to
bring the backend down..)
db=# select
L.S.
I don't expect that this is the intended behaviour:
db=# SELECT version();
version
-
PostgreSQL 7.4.3 on i686-pc-linux-gnu, compiled by GCC egcs-2.91.66
If you run these commands:
CREATE TA
> The issue here is the not-nullness of a new column which isn't supported
> in 7.4 (it appears to be in 7.5).
I grok.
> > By the way, I noticed that the todo-list does not mention 'alter table
> > alter column set/drop primary key'. I'm wondering whether it should?
>
> ALTER TABLE ADD CONSTRAINT
Hi,
I guess this might not be the appropriate thing to be happening:
# select version();
version
-
PostgreSQL 7.4.3 on i686-pc-linux-gnu, compiled by GCC egcs-2.91.66
(1 row)
(verify whether temp
> anything I can verify on that one to help?
free4testing=# select timestamptz('1901-12-14 0:0:0');
timestamptz
-
1901-12-13 23:40:32
(1 row)
Frank.
---(end of broadcast)---
TIP 9: the planner will ignore your desire t
> > anything I can verify on that one to help?
>
> "show time zone"?
free4testing=# show time zone;
TimeZone
--
unknown
(1 row)
free4testing=# select now();
now
---
2003-08-22 14:36:17.994049+02
(1 row)
The latter is what I meant by 'it seem
Just verified this on another Slackware machine:
(this one is a HP Netserver LH3)
free4testing=# select version();
version
PostgreSQL 7.3.3 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.2
> > What's your time zone setting?
I'm baffled
I disconnected my psql-client, reconnected a while later to demonstrate this
problem to someone on the server I stop/started earlier, and the problem
wasn't there anymore. This is the one I stopped, set TZ and started
again. However, since
> What's your time zone setting?
> Also, are you using --enable-integer-datetimes?
I'm running Slack v8 (with some updates, but still), so TZ is not defined as
environment variable, but it's using 'Europe/Amsterdam'.
I've verified whether setting TZ made a difference (stop/starting the server),
be the old one used.
However, the encoding seems to be changed, as 'show client_encoding' will
show.
Regards,
Frank van Vugt
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
> after I upgrade my postgresql from 7.2 to 7.3, one query always makes server
> terminated
This is caused by the vacuum of a temp table.
Tom fixed it already about a week ago and provided the patch here:
*** src/backend/storage/buffer/localbuf.c.orig Wed Sep 4 16:31:25 2002
--- src/backend/
63 matches
Mail list logo
