Re: [BUGS] BUG #5269: postgres backend terminates with SIGSEGV
On Tue, 12 Jan 2010, Tom Lane wrote: preparing something as trivial as a ROLLBACK is pretty silly so nobody does it. Actually the JDBC driver has been preparing BEGIN, COMMIT, and ROLLBACK since the 8.0 release. http://archives.postgresql.org/pgsql-jdbc/2006-10/msg00149.php Kris Jurka -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5269: postgres backend terminates with SIGSEGV
Justin Pitts writes:
> It went seriously heisenbug since I added %p. It took all day to crash it
> since I added that to the configuration. Except this latest crash is
> completely different - signal 6 ABRT, different place.
Specifically:
2010-01-13 01:50:42 UTC 5455 ERROR: snapshot reference 0xba6ac0 is not owned
by resource owner TopTransaction
2010-01-13 01:50:42 UTC 5455 STATEMENT: COMMIT
2010-01-13 01:50:42 UTC 5455 WARNING: AbortTransaction while in COMMIT state
2010-01-13 01:50:42 UTC 5455 PANIC: cannot abort transaction 777554, it was
already committed
This looks different, but it matches what I had concluded from the
previous dumps: snapmgr.c thinks it has a valid serializable snapshot,
but it doesn't. In your previous crashes, CurrentSnaphot was pointing
at trashed memory; here, it's still a valid-looking snapshot, but it's
not registered in the TopTransactionResourceOwner like it's supposed to
be (it wasn't in the other cases either).
After puzzling over this for many hours, I have a theory that seems to
fit the facts. What I think must be happening is that
GetTransactionSnapshot is getting called outside any transaction ---
that is, after AtEOXact_Snapshot but before CleanupTransaction (thus,
the old TopTransactionResourceOwner is still there, so its attempt
to register the snap doesn't dump core). Your build isn't
assert-enabled so the extra snapshot registration wouldn't be noticed
by the eventual ResourceOwnerDelete. Then, when we next start a
transaction and request a serializable snapshot, GetTransactionSnapshot
thinks it has nothing to do and happily hands back a pointer to garbage.
Now, how the heck did GetTransactionSnapshot get called that way?
Your log shows that you're using client software that likes to abort
failed transactions with a previously prepared statement:
2010-01-13 01:50:41 UTC 5455 LOG: execute S_2: ROLLBACK
This means that to get to CleanupTransaction, we have to look up a
cached plan while in aborted transaction state. And that will call
RevalidateCachedPlan, which does this if the plan is marked dead:
/*
* If a snapshot is already set (the normal case), we can just use
* that for parsing/planning. But if it isn't, install one. Note: no
* point in checking whether parse analysis requires a snapshot;
* utility commands don't have invalidatable plans, so we'd not get
* here for such a command.
*/
if (!ActiveSnapshotSet())
{
PushActiveSnapshot(GetTransactionSnapshot());
snapshot_set = true;
}
As the comment indicates, it should not be possible to get here for a
ROLLBACK plan. But look what got added in 8.4: ResetPlanCache(), which
marks plans dead *unconditionally*. And one of the ways that that can
get invoked is via a SI queue overrun event, which triggers a general
cache flush and in particular calls PlanCacheSysCallback().
So what is needed to make this scenario happen is a SI queue overrun,
which isn't a common event unless your application does a lot
of catalog manipulations. I suppose that the reason your reporting
query manages to tickle it is that it creates/deletes temp tables.
And even then, you'd need an actual failure on the side receiving
the overrun notification. In the cases at hand that failure is
2010-01-13 01:50:41 UTC 5455 ERROR: could not serialize access due to
concurrent update
which doesn't happen real often in your app, but does happen.
So this theory explains what I found in the core dumps, which is
otherwise dang hard to explain (I spent a lot of time looking for
code paths that could bypass AtEOXact_Snapshot, but there aren't
any). It explains why the failure is uncommon. It explains why the
failures come in bunches (since a SI overrun is broadcast, and
would thereby poison all active sessions with "dead" ROLLBACK
plans; and the subsequent serialization errors could easily come
in bunches too). It explains why we haven't seen similar stuff
in testing --- preparing something as trivial as a ROLLBACK is
pretty silly so nobody does it. And it explains why we didn't
see it before 8.4 --- the bug was in fact introduced here:
http://archives.postgresql.org/pgsql-committers/2008-09/msg00084.php
So even though I haven't actually reproduced the problem, I have a
fair amount of confidence in the explanation.
We could perhaps fix this by changing the above-quoted code, but
I'm inclined to teach ResetPlanCache that utility statements should
never be marked dead. They don't have plans in the normal sense
of the word so there's no point in forcing a revalidation cycle.
I'm kinda beat right now but will work on a patch tomorrow.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5273: Unexpected function behavior/failure
On Tue, Jan 12, 2010 at 7:45 PM, Tom Lane wrote:
> "Vee" writes:
>> -- The problem query
>> select data, regexp_matches(data, '(h..l)')
>> from test;
>
>>> hello {hell}
>
>> Since I have no "where" clause, I would expect to see all the rows in the
>> result of the second case, with possibly a NULL value for the non-matched
>> rows.
>
> No. regexp_matches() returns setof something, meaning a row per match.
> When you have no match, you get no rows. And that in turn means that
> the calling select produces no rows --- just as it could also produce
> more than one row from a given table row.
>
> I think the behavior you are after is probably more like that of
> substring().
Or maybe the ~ operator.
...Robert
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5273: Unexpected function behavior/failure
"Vee" writes:
> -- The problem query
> select data, regexp_matches(data, '(h..l)')
> from test;
>> hello{hell}
> Since I have no "where" clause, I would expect to see all the rows in the
> result of the second case, with possibly a NULL value for the non-matched
> rows.
No. regexp_matches() returns setof something, meaning a row per match.
When you have no match, you get no rows. And that in turn means that
the calling select produces no rows --- just as it could also produce
more than one row from a given table row.
I think the behavior you are after is probably more like that of
substring().
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5273: Unexpected function behavior/failure
The following bug has been logged online:
Bug reference: 5273
Logged by: Vee
Email address: se...@hotmail.com
PostgreSQL version: 8.4.2
Operating system: Linux
Description:Unexpected function behavior/failure
Details:
Hi,
I have an odd problem using certain regular expressions (as opposed to any
other function) with PostgreSql 8.4.2, I was hoping you could enlighten me
as to what am I doing wrong.
-- Create the table and populate it.
create table test ( data text );
insert into test
values ('hello'), ('world'), ('bridge');
-- Test query.
select data, upper(data)
from test;
> hello HELLO
> world WORLD
> bridgeBRIDGE
-- The problem query
select data, regexp_matches(data, '(h..l)')
from test;
> hello {hell}
Since I have no "where" clause, I would expect to see all the rows in the
result of the second case, with possibly a NULL value for the non-matched
rows.
But I would not expect a "select" clause to effectively filter out results
for me.
I'd appreciate your input on the matter.
Thanks,
Vee.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #2197: PostgreSQL error- 'could not read block 0 of relation'
BUG #2197: PostgreSQL error- 'could not read block 0 of relation' I found this bug has nothing to do with hardware. I was attemping to copy large amounts of data from text files into tables with a primary and many foreign keys. I found that upon truncating the tables not all key references had been cleaned up by the database asa they had been in prior day successful runs. After truncating all tables with a truncate table xx cascade and then loading back into the same table, my problem was resolved. -Ted
Re: [BUGS] Bug report: Wrong version in pg_config
Tom Lane writes: > You would need to take that up with whoever packages Postgres for > Ubuntu. It sounds like they have some glitch in the package setup. > AFAIK, whoever that is doesn't read this list, which is mainly for > upstream Postgres development. I think Martin Pitt reads this list, he's maintaining both for ubuntu and debian. The problem itself is tied to the multi-major version support in the packaging, and in the tools. # dpkg -S /usr/bin/pg_config libpq-dev: /usr/bin/pg_config The libpq-dev should be independant of the major version you target, but contains pg_config. Using the direct path works too: postgresql-server-dev-8.4: /usr/lib/postgresql/8.4/bin/pg_config postgresql-server-dev-8.3: /usr/lib/postgresql/8.3/bin/pg_config You could even adjust your PATH to prepend it with the bin tools you need for a specific debian major. Regards, -- dim -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Bug report: Wrong version in pg_config
Adam Matan writes: > I'm using postgresql 8.3 in my Ubuntu 8.04 dekstop computer. I have tried to > install postgresql 8.4 for some testing, and removed it afterwards > using *apt-get purge*. > But still, pg_config remains with the removed version, after postresql > restart and even total reboot: You would need to take that up with whoever packages Postgres for Ubuntu. It sounds like they have some glitch in the package setup. AFAIK, whoever that is doesn't read this list, which is mainly for upstream Postgres development. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Bug report: Wrong version in pg_config
Adam Matan writes: > But still, pg_config remains with the removed version, after postresql > restart and even total reboot: > > $ pg_config > BINDIR = /usr/lib/postgresql/8.4/bin [...] > This creates confusion with external software packages trying to use pgxs, > for example. > Any ideas how to solve this? Use /usr/lib/postgresql/$version/bin/pg_config, and adapt your extension's Makefile to target that. For example with the following in the Makefile: PG_CONFIG ?= pg_config And the call like this from debian/rules or elsewhere: make PG_CONFIG=/usr/lib/postgresql/$version/bin/pg_config I'm preparing some tools to automate all this for debian packaging extensions, see the following: http://lists.alioth.debian.org/pipermail/pkg-postgresql-public/2010-January/000546.html Regards, -- dim -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Bug report: Wrong version in pg_config
Hi, I'm using postgresql 8.3 in my Ubuntu 8.04 dekstop computer. I have tried to install postgresql 8.4 for some testing, and removed it afterwards using *apt-get purge*. There are currently no 8.4 packages installed: *$ dpkg --get-selections | grep postgresql* postgresql-8.3 install postgresql-8.3-postgis install postgresql-client-8.3 install postgresql-client-commoninstall postgresql-common install postgresql-contrib-8.3 install postgresql-doc-8.3 install postgresql-plpython-8.3 install postgresql-server-dev-8.3 install But still, pg_config remains with the removed version, after postresql restart and even total reboot: *$ pg_config* BINDIR = /usr/lib/postgresql/8.4/bin DOCDIR = /usr/share/doc/postgresql HTMLDIR = /usr/share/doc/postgresql INCLUDEDIR = /usr/include/postgresql PKGINCLUDEDIR = /usr/include/postgresql INCLUDEDIR-SERVER = /usr/include/postgresql/8.4/server LIBDIR = /usr/lib PKGLIBDIR = /usr/lib/postgresql/8.4/lib LOCALEDIR = /usr/share/locale MANDIR = /usr/share/postgresql/8.4/man SHAREDIR = /usr/share/postgresql/8.4 SYSCONFDIR = /etc/postgresql-common PGXS = /usr/lib/postgresql/8.4/lib/pgxs/src/makefiles/pgxs.mk CONFIGURE = '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=/usr/include' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--libexecdir=/usr/lib/postgresql-8.4' '--disable-maintainer-mode' '--disable-dependency-tracking' '--srcdir=.' '--mandir=/usr/share/postgresql/8.4/man' '--with-docdir=/usr/share/doc/postgresql-doc-8.4' '--sysconfdir=/etc/postgresql-common' '--datadir=/usr/share/postgresql/8.4' '--bindir=/usr/lib/postgresql/8.4/bin' '--includedir=/usr/include/postgresql/' '--enable-nls' '--enable-integer-datetimes' '--enable-thread-safety' '--enable-debug' '--disable-rpath' '--with-tcl' '--with-perl' '--with-python' '--with-pam' '--with-krb5' '--with-gssapi' '--with-openssl' '--with-libxml' '--with-libxslt' '--with-ldap' '--with-ossp-uuid' '--with-gnu-ld' '--with-tclconfig=/usr/lib/tcl8.5' '--with-tkconfig=/usr/lib/tk8.5' '--with-includes=/usr/include/tcl8.5' '--with-system-tzdata=/usr/share/zoneinfo' '--with-pgport=5432' 'CFLAGS=-g -O2 -g -Wall -O2 -fPIC' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,--as-needed' 'build_alias=x86_64-linux-gnu' 'CC=cc' 'CPPFLAGS=' CC = cc CPPFLAGS = -D_GNU_SOURCE -I/usr/include/libxml2 -I/usr/include/tcl8.5 CFLAGS = -g -O2 -g -Wall -O2 -fPIC -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -g CFLAGS_SL = -fpic LDFLAGS = -Wl,-Bsymbolic-functions -Wl,--as-needed -Wl,--as-needed LDFLAGS_SL = LIBS = -lpgport -lxslt -lxml2 -lpam -lssl -lcrypto -lkrb5 -lcom_err -lgssapi_krb5 -lz -lreadline -lcrypt -ldl -lm This creates confusion with external software packages trying to use pgxs, for example. Any ideas how to solve this? Thanks, Adam
Re: [BUGS] Failed to run initdb - not resolved bug 5130
Hi all
after a long time of trying to install PostgreSQL with ...
Computer:
- Windows2000 (Jurassic Parc, I know ...)
- PostGreSQL 8.3.9 and msi-file
or PostGreSQL 8.4.2 and one click installer
- Data in
/8.4/data (default path)
or D:\PostgresDaten (with 1 level)
or D:\Postgres\PostgreSQLDaten (parent dir createt by me)
Testing race:
The result of all rounds is always the same:
- Installation:
runns through, but is not complete with error, when trying to initate
the db: no postgresql.conf-file.
The programdirectorys under c:\Programme\PostgreSQL\8.4 (or 8.3) are
created and seem to be complete.
But there are no datadirectorys or datafiles createt.
- Running directly initdb.exe:
stops with error "access denied" when trying to create something (for
the template database) in \PostgreSQLDaten\base\1\.
(\bin\initdb.exe -U postgres -D D:\Postgres\PostgreSQLDaten -W -n
The parameter -n prevents from deleting of the createt files/dirs in
case of errors.)
Some datadirectorys, a postgresql.conf-file, a PG_VERSION-file, others
*.conf-files are createt but the
\base and \base\1\ are empty.
- running pg_ctl.exe to start the server:
complains about missing file pg_control and stopps.
(\bin\pg_ctl.exe start -w -t 10 -D D:\Postgres\PostgreSQLDaten -l
D:\Postgres\PostgreSQLKonfigInfos\logfile02.txt.
Error in logfile is: D:/Postgres/PostgreSQLDaten/global/pg_control ...
No such file or directory.
This pg_ctl.exe wants the path- and filenames written exactly, with
upper and lower cases. Only pg_ctl.exe ?)
Somme more results:
- In windows, the createt datadirectorys belong to the windows-user
"thomas", with permissions for "administrator" and "postgres",
but not allways (I missed to register this in every round of the race ...).
- When running the initdb.exe without parameter -n, it allways could
remove all artefacts.
- on http://forums.enterprisedb.com/posts/list/1802.page can be seen,
that running initdb.exe sometimes works.
- The Windows-user postgres can create files and dirs in [\data]\base\1\.
Diagnosis:
The initdb is not allowed write to [\data]\base\1\ ("access denied"),
but could create it.
It is most likely, that the bug is inside initdb.exe.
You can guess, that there is a conflict between windows-permissions and
db-permissions.
Windows-version, PostgreSQL-version, paths, locals, ... all seem not to
matter.
... I now must hope.
Thomas Specker
If somebody has an installation with a SMALL, empty, and working
data-section including the template-db, this could be tested (if just
copying is possible).
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
