Hi,
On Feb 1, 2012, at 10:35 PM, download...@hotmail.com wrote:
> 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
> De
Excerpts from Tom Lane's message of mié feb 01 18:06:27 -0300 2012:
> Robert Haas 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 ge
Sergey Burladyan 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 trace,
may be this
Tom Lane 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 using gin
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 pr
Robert Haas 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 the time t
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 d
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
Andrew Schetinin writes:
> 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.
Usually, that's an appropriate change for a small LIMIT. It's certainly
n
Duncan Rance 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 realised
>
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 wa
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 s
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.
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 L
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, when
On Wed, Feb 1, 2012 at 11:04 AM, Tom Lane wrote:
> Have you read the thread about bug #6200? I'm suspicious that this is
> the same or similar problem, with a slightly different visible symptom
> because of pickier hardware. I'm afraid we don't know what's going on
> yet there either, but the id
On Wed, Feb 1, 2012 at 11:19 AM, Tom Lane wrote:
> Robert Haas 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.
On 1 Feb 2012, at 16:04, Tom Lane wrote:
> 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 alw
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,
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 seconds
Merlin Moncure 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 GMT'::timestamp);
> d
On Wed, Feb 1, 2012 at 10:00 AM, Tom Lane 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
>>
Robert Haas 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 routine that hasn't been
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 t
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)
On Tue, Jan 31, 2012 at 4:25 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Jan 31, 2012 at 12:05 AM, Tom Lane 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 it seemingly doesn't match
>>> the tuple descript
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
postgre
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 th
The following bug has been logged on the website:
Bug reference: 6424
Logged by: Olaf
Email address: o.bous...@krohne.com
PostgreSQL version: 9.1.2
Operating system: Windows 7 - 64bits
Description:
Should the query
select
extract(epoch
from cast('2012-01-01 14:
29 matches
Mail list logo
