Tom Lane wrote:
So these two geometry values do not overlap in the original database,
but they do overlap in the clone, apparently because the output
representation of geometry doesn't result in an exact reconstruction
of the value. Somebody better complain over in the postgis lists.
Thanks f
Well, the answer is that Jeff's instinct was right: the dump and reload
isn't reproducing the original data exactly. It's not our fault though,
it's a postgis bug. Observe:
gisttest2=# select ST_expand(setsrid(makepoint(-122.50367,37.74189),4326),
0.4);
On Tue, 2010-08-31 at 14:13 -0400, Tom Lane wrote:
> Jeff Davis writes:
> > On Mon, 2010-08-30 at 20:06 -0400, Tom Lane wrote:
> >> You need extra_float_digits cranked up. Which pg_dump knows about.
>
> > I can't reproduce the problem with float4/8, but I still see a problem
> > with floating-po
Jeff Davis writes:
> On Mon, 2010-08-30 at 20:06 -0400, Tom Lane wrote:
>> You need extra_float_digits cranked up. Which pg_dump knows about.
> I can't reproduce the problem with float4/8, but I still see a problem
> with floating-point timestamps:
Hmmm ... timestamp_out pays no attention to ex
On Mon, 2010-08-30 at 20:06 -0400, Tom Lane wrote:
> Jeff Davis writes:
> > On Mon, 2010-08-30 at 19:40 -0400, Tom Lane wrote:
> >> That's really *not* supposed to happen, assuming that both machines have
> >> IEEE float arithmetic and competently written float I/O code.
>
> > On my machine I see
Tom Lane wrote:
Alex Zepeda writes:
I'd be happy to provide someone with a copy of the dump...
but it's ~70MB bzip'd.
I'd be willing to take a look ... but if my WAG is right, the insertion
order would be critical information to reproduce the problem. Is it
possible to tell what order the ro
Alex Zepeda writes:
> I'd be happy to provide someone with a copy of the dump...
> but it's ~70MB bzip'd.
I'd be willing to take a look ... but if my WAG is right, the insertion
order would be critical information to reproduce the problem. Is it
possible to tell what order the rows were inserted
Tom Lane wrote:
Alex Zepeda writes:
If I try to manually add the constraint on the table I get:
blockface=# alter table bus_positions add constraint "exclude_time_buffer" EXCLUDE USING gist
(vehicle WITH =, buffer_time WITH &&, bbox_dup WITH &&);
NOTICE: ALTER TABLE / ADD EXCLUDE will create
Alex Zepeda writes:
> If I try to manually add the constraint on the table I get:
> blockface=# alter table bus_positions add constraint "exclude_time_buffer"
> EXCLUDE USING gist (vehicle WITH =, buffer_time WITH &&, bbox_dup WITH &&);
> NOTICE: ALTER TABLE / ADD EXCLUDE will create implicit in
On Mon, 2010-08-30 at 19:40 -0400, Tom Lane wrote:
> That's really *not* supposed to happen, assuming that both machines have
> IEEE float arithmetic and competently written float I/O code.
On my machine I see:
=> select float4in(float4out((1::numeric + 1e-7::numeric)::float4)) =
(1::numeric
Jeff Davis writes:
> On Mon, 2010-08-30 at 19:40 -0400, Tom Lane wrote:
>> That's really *not* supposed to happen, assuming that both machines have
>> IEEE float arithmetic and competently written float I/O code.
> On my machine I see:
> => select float4in(float4out((1::numeric + 1e-7::numeric):
Jeff Davis wrote:
Are you using any floating point values, or floating-point timestamps
(that's a compile-time option)?
I'm using whatever the default compile time options are.
It's worth noting that if I delete the row, and then attempt to insert
a row with the same data on the original data
Jeff Davis writes:
> On Mon, 2010-08-30 at 14:05 -0700, Alex Zepeda wrote:
>> I dumped a table with an exclude constraint with pg_dump, and loaded it
>> into another instance of postgres where it promptly failed to create the
>> constraint. The complaint was... key conflicts with key. IOW,
>>
Alex Zepeda writes:
> I dumped a table with an exclude constraint with pg_dump, and loaded it
> into another instance of postgres where it promptly failed to create the
> constraint. The complaint was... key conflicts with key. IOW,
> duplicate data.
> This should not happen, correct? If it
On Mon, 2010-08-30 at 14:05 -0700, Alex Zepeda wrote:
> Short version:
>
> I dumped a table with an exclude constraint with pg_dump, and loaded it
> into another instance of postgres where it promptly failed to create the
> constraint. The complaint was... key conflicts with key. IOW,
> dupli
I'm relatively unsure where and how to proceed.
Short version:
I dumped a table with an exclude constraint with pg_dump, and loaded it
into another instance of postgres where it promptly failed to create the
constraint. The complaint was... key conflicts with key. IOW,
duplicate data.
Thi
16 matches
Mail list logo
