Toby Murray writes:
> On Fri, Feb 1, 2013 at 3:58 PM, Tom Lane wrote:
>> It's conceivable that this was a software glitch not a hardware glitch,
>> ie Postgres forgetting the dirty-bits for a batch of pages, but we've
>> not seen any similar reports elsewhere. So I'm leaning to the hardware
>> e
On Fri, Feb 1, 2013 at 3:58 PM, Tom Lane wrote:
> Toby Murray writes:
>> On Thu, Jan 31, 2013 at 5:43 PM, Tom Lane wrote:
>>> Could we see the full results of heap_page_items(get_raw_page()) for
>>> each of the pages where any of these tuples live, viz
>
>> Seems awkward to put inline so I made
Colin Dunklau writes:
> Hello! I believe I've found a bug in the type conversion process from
> polygon to point.
> In the documentation found here
> http://www.postgresql.org/docs/9.2/interactive/functions-geometry.html,
> Table 9-32 claims that running the point() function on a polygon
> retur
Toby Murray writes:
> On Thu, Jan 31, 2013 at 5:43 PM, Tom Lane wrote:
>> Could we see the full results of heap_page_items(get_raw_page()) for
>> each of the pages where any of these tuples live, viz
> Seems awkward to put inline so I made a text file with these results
> and am attaching it. Ho
Hello! I believe I've found a bug in the type conversion process from
polygon to point.
In the documentation found here
http://www.postgresql.org/docs/9.2/interactive/functions-geometry.html,
Table 9-32 claims that running the point() function on a polygon
returns the "center of polygon". This is
The following bug has been logged on the website:
Bug reference: 7845
Logged by: Morgan
Email address: morgan.h...@altran.com
PostgreSQL version: 9.0.4
Operating system: Windows XP Embedded
Description:
Hello,
We are developing a medical Software with LabVIEW which s
Pius Chan writes:
> Thanks for your prompt response. Yeah, I should have provided you with my
> testing scripts. BTW, during numerous tests, I felt that if there is no long
> holding transaction (the one used for middle-tier service master/slave
> failover), the database server is much quicker
Tom,
Thanks for your prompt response. Yeah, I should have provided you with my
testing scripts. BTW, during numerous tests, I felt that if there is no long
holding transaction (the one used for middle-tier service master/slave
failover), the database server is much quicker to recover the space
Pius Chan writes:
> The ERROR happened again. After several days of investigation and testing, I
> can now reproduce the ERROR in my testing environment. The reason why the
> ERROR used to happen in a certain time period is that our report batch jobs
> run in that period and the batch job can m
=?UTF-8?B?TWFjaWVqIMWBb3B1c3phxYRza2k=?= writes:
> is there a way to find exactly what object/table/column creates this
> circular dependency?
Look into pg_depend for entries referencing the view or the view's
rowtype. (Offhand I'd bet it's the latter.) So the refobjid would
be 'viewname'::reg
On Friday, February 1, 2013, wrote:
> The following bug has been logged on the website:
>
> Bug reference: 7843
> Logged by: Andrey
> Email address: quiver...@gmail.com
> PostgreSQL version: 9.2.2
> Operating system: Windows 7 x64
> Description:
>
> When i try to install post
is there a way to find exactly what object/table/column creates this
circular dependency?
pg_dumb even in verbose mode does not warn/error of this situation. I
managed to find this by testing copy of production db(this should be
reported by pg_dump). also there is nothing fancy about this 'vie
The following bug has been logged on the website:
Bug reference: 7844
Logged by: fduerr
Email address: i...@fduerr.de
PostgreSQL version: 9.2.2
Operating system: Debian
Description:
Up until 9.1
select (xpath('/z/text()', ('' || 'AT&T' || '')::xml))[1];
returned 'AT
The following bug has been logged on the website:
Bug reference: 7843
Logged by: Andrey
Email address: quiver...@gmail.com
PostgreSQL version: 9.2.2
Operating system: Windows 7 x64
Description:
When i try to install postgresql-9.2.2-1-windows-x64.exe, it ask aboute DB
14 matches
Mail list logo
