The following bug has been logged on the website:
Bug reference: 6425
Logged by: orval
Email address: postg...@dunquino.com
PostgreSQL version: 9.0.6
Operating system: Solaris 10 u9
Description:
This is intermittent and hard to reproduce but crashes consistently in
So here's a better stack trace for the segfault issue (again, just to
summarize, since this is a long thread, we're seeing two issues: 1) alloc
errors that do not crash the DB (although we modified postgres to panic
when this happens in our test environment, and posted a stack earlier) 2) a
On Tue, Jan 31, 2012 at 4:25 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Jan 31, 2012 at 12:05 AM, Tom Lane t...@sss.pgh.pa.us wrote:
BTW, after a bit more reflection it occurs to me that it's not so much
that the data is necessarily *bad*, as that
o.bous...@krohne.com writes:
Should the query
select
extract(epoch
from cast('2012-01-01 14:30:1' as
timestamp) -
cast('1970-01-01 0:0:0' as
timestamp))) -
extract(epoch
from (cast('2012-01-01 14:30:1' as
timestamp)))
postg...@dunquino.com writes:
This is intermittent and hard to reproduce but crashes consistently in the
same place. That place is backend/access/common/heaptuple.c line 1104:
...
This system is using streaming replication, and the problem always occurrs
on the secondary.
Have you read the
Robert Haas robertmh...@gmail.com writes:
No, I wasn't thinking about a tuple descriptor mismatch. I was
imagining that the page contents themselves might be in flux while
we're trying to read from it.
Oh, gotcha. Yes, that's a horribly plausible idea. All it'd take is
one WAL replay
On Wed, Feb 1, 2012 at 10:00 AM, Tom Lane t...@sss.pgh.pa.us wrote:
o.bous...@krohne.com writes:
Should the query
select
extract(epoch
from cast('2012-01-01 14:30:1' as
timestamp) -
cast('1970-01-01 0:0:0' as
timestamp))) -
extract(epoch
Merlin Moncure mmonc...@gmail.com writes:
TBH, I think the behavior of the example given is 100% correct *if a
timezone isn't specified', which the OP didn't. It's only weird if
you do this: ...
which really boils down to this:
postgres=# select extract(epoch from '1970-01-01 0:0:0
The following bug has been logged on the website:
Bug reference: 6426
Logged by: Andrew Schetinin
Email address: ascheti...@gmail.com
PostgreSQL version: 9.1.2
Operating system: Debian Linux
Description:
I have a complex query that, when unlimited, runs in 2.5
The following bug has been logged on the website:
Bug reference: 6427
Logged by: MN
Email address: download...@hotmail.com
PostgreSQL version: 9.1.2
Operating system: Windows 2008 server R2 SP1
Description:
With a fresh new installation of Windows 2008 server R2 SP1,
ascheti...@gmail.com wrote:
The following bug has been logged on the website:
Bug reference: 6426
Logged by: Andrew Schetinin
Email address: ascheti...@gmail.com
PostgreSQL version: 9.1.2
Operating system: Debian Linux
Description:
I have a complex query that,
Andrew Schetinin wrote:
Hi Alex,
Thank you. I played with subqueries, but in this case I did not see a
good enough improvement.
In my specific case, what I've seen from the query execution plans, is
that without LIMIT the query uses Hash Joins, but once I add LIMIT, it
starts using Nested
Hi Alex,
Thank you. I played with subqueries, but in this case I did not see a good
enough improvement.
In my specific case, what I've seen from the query execution plans, is that
without LIMIT the query uses Hash Joins, but once I add LIMIT, it starts
using Nested Loop Joins almost everywhere.
On 1 Feb 2012, at 18:10, Robert Haas wrote:
I went looking for commits that might be relevant to this that are new
in 9.0.6, also present in 9.1.2 (per 6200), and related to t_hoff, and
came up with this one:
Branch: master [039680aff] 2011-11-04 23:22:50 -0400
I looked at this and it seems
Excerpts from Duncan Rance's message of mié feb 01 17:43:48 -0300 2012:
I mentioned in the bug report that I has asserts in places were t_hoff is
set. I've been doing it like so:
if (hoff % 4 != 0) {
elog(ERROR, wrong hoff: %d,hoff);
abort();
}
I've been sitting here waiting for
Duncan Rance postg...@dunquino.com writes:
I mentioned in the bug report that I has asserts in places were t_hoff is
set. I've been doing it like so:
if (hoff % 4 != 0) {
elog(ERROR, wrong hoff: %d,hoff);
abort();
}
I've been sitting here waiting for the server to abort and only just
Thanks for Your answer.
Works as designed - I have to get used.
Please notice the return message from REVOKE ALL command:
myDatabase=# REVOKE ALL(Column1) ON public.tblTest FROM public;
REVOKE
myDatabase=# \dp public.tblTest
Access privileges
Schema | Name | Type | Access privileges | Column
The following bug has been logged on the website:
Bug reference: 6428
Logged by: Keith
Email address: ke...@omniti.com
PostgreSQL version: 9.1.2
Operating system: Any
Description:
Working on a tool that iterates through the pg_restore -l list for doing
more advanced
Robert Haas robertmh...@gmail.com writes:
No, I wasn't thinking about a tuple descriptor mismatch. I was
imagining that the page contents themselves might be in flux while
we're trying to read from it.
It would be nice to get a dump of what PostgreSQL thought the entire
block looked like at
On 1 Feb 2012, at 21:43, Tom Lane wrote:
Client 87 aborted in state 8: ERROR: wrong hoff: 134
Yowza. Is this just the standard pgbench test, or something else?
This is pgbench with a custom script (-f option.)
If you could post complete instructions for duplicating this, we
could
Tom Lane t...@sss.pgh.pa.us writes:
d...@rosfirm.ru writes:
When making in query to fiels with gin index, server crashes. Below
create table tmp(id serial not null primary key, f1 integer, f2 text);
insert into tmp (f1,f2) values (1,'a'),(2,'b'),(3,'c');
create index tmp_f1_idx on tmp
Sergey Burladyan eshkin...@gmail.com writes:
#1 0x7fe1efbbc2b2 in get_leftop (clause=0x7fe1f1d85230) at
/home/martin/debian/psql/9.1/build-area/postgresql-9.1-9.1.2/build/../src/backend/optimizer/util/clauses.c:189
I set breakpoint at src/backend/optimizer/util/clauses.c:188 and do some
Excerpts from Tom Lane's message of mié feb 01 18:06:27 -0300 2012:
Robert Haas robertmh...@gmail.com writes:
No, I wasn't thinking about a tuple descriptor mismatch. I was
imagining that the page contents themselves might be in flux while
we're trying to read from it.
It would be nice
23 matches
Mail list logo
