On Thu, Jan 31, 2013 at 11:21 PM, Toby Murray wrote:
> Also, the node change happened on January 28th. To be precise, the
> timestamp of the node is 2013-01-28 02:38:29. So it is looking like
> something may have gone wrong, possibly in a single minutely update,
> on January 28th. I'll do a little
On Thu, Jan 31, 2013 at 10:57 PM, Toby Murray wrote:
> On Thu, Jan 31, 2013 at 5:43 PM, Tom Lane wrote:
>> Toby Murray writes:
>>> I just had some interaction with RhodiumToad on IRC about a duplicated
>>> primary key problem I ran into today. After some poking around he
>>> suggested that I sen
On Thu, Jan 31, 2013 at 5:43 PM, Tom Lane wrote:
> Toby Murray writes:
>> I just had some interaction with RhodiumToad on IRC about a duplicated
>> primary key problem I ran into today. After some poking around he
>> suggested that I send this to -bugs since it seems like an interesting
>> error.
Hi Tom,
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 make the TOAST area
Toby Murray writes:
> I just had some interaction with RhodiumToad on IRC about a duplicated
> primary key problem I ran into today. After some poking around he
> suggested that I send this to -bugs since it seems like an interesting
> error.
I poked around in the PK index file (thanks for sendin
dig...@126.com wrote:
> The following bug has been logged on the website:
>
> Bug reference: 7840
> Logged by: digoal
> Email address: dig...@126.com
> PostgreSQL version: Unsupported/Unknown
> Operating system: CentOS 5.7 x64
I have pushed patches for these two problems, ple
dig...@126.com wrote:
> digoal=# select * from heap_page_items(get_raw_page('test', 0));
> lp | lp_off | lp_flags | lp_len | t_xmin | t_xmax | t_field3 | t_ctid |
> t_infomask2 | t_infomask | t_hoff | t_bits | t_oid
> ++--++++--++--
lopuszan...@oleofarm.com writes:
> 1. after using pg_dump to dump WHOLE database to file, 1 of views 'turned'
> into a table.
> so there is no 'create or replace VIEW ...' with definition, but
> instead:
> its scripted as 'create TABLE ..' and definition.(in file that
> pg_dump cr
The following bug has been logged on the website:
Bug reference: 7841
Logged by: Joanna Biernat-Gerono
Email address: biern...@interia.pl
PostgreSQL version: 9.2.2
Operating system: Windows 7
Description:
Sample code that provides to access violation (I am using the l
The following bug has been logged on the website:
Bug reference: 7842
Logged by: Maciej Łopuszański
Email address: lopuszan...@oleofarm.com
PostgreSQL version: 9.1.7
Operating system: ubuntu 12.04
Description:
hello,
1. after using pg_dump to dump WHOLE database to fi
The following bug has been logged on the website:
Bug reference: 7840
Logged by: digoal
Email address: dig...@126.com
PostgreSQL version: Unsupported/Unknown
Operating system: CentOS 5.7 x64
Description:
I think there is a bug in PostgreSQL 9.3 devel version about sel
I just had some interaction with RhodiumToad on IRC about a duplicated
primary key problem I ran into today. After some poking around he
suggested that I send this to -bugs since it seems like an interesting
error.
The short version is that I have a table ("ways") which has a primary
key ("id") th
12 matches
Mail list logo
