server not the client.
>
Ok if you want, I can
* keep the server as is
* give you ssh access to it
Let me know, and I’ll mail you (privately) login details
I am going to move the data, and I have the whole set of daily pg_dumps I need
to set it up elsewhere.
--
Björn Lundin
b.f.lun...@gmail.com
ested of pursuing it,
Otherwise I’ll stop his thread.
That is, I am convinced enough that mixing versions combined with perhaps old
hardware
together did something strange
--
Björn Lundin
b.f.lun...@gmail.com
re
So I learned this - always use same version of client and server
Many thanks to Adrian and Tom
--
Björn Lundin
b.f.lun...@gmail.com
fference. Sorry, pet peeve
> of mine, when people say these two things are not doing the same thing but
> then say they are the same thing.
>
>> I mean, the pg_dump does copy-commands.
>
> It also does a certain amount of setup at the beginning of the file.
I stand corrected
--
Björn Lundin
b.f.lun...@gmail.com
-
ISO, YMD
Both faulty (ibm2) and correct(tp) are populated with the same pg_dump()- files
that r-pi produces every nigth
And for completeness - b info from the pi
bnl=# select version();
version
--
PostgreSQL 9.6.10 on armv7l-unknown-linux-gnueabihf, compiled by gcc (Raspbian
6.3.0-18+rpi1) 6.3.0 20170516, 32-bit
(1 row)
bnl@pibetbot:~ $ uname -a
Linux pibetbot 4.14.79-v7+ #1159 SMP Sun Nov 4 17:50:20 GMT 2018 armv7l
GNU/Linux
--
Björn Lundin
b.f.lun...@gmail.com
machine with basically the
same data,
Enetered the same way, with the same import files, that works
So in a sense many instances, but not really.
I mean, the pg_dump does copy-commands.
I could have inserted that by hand.
--
Björn Lundin
b.f.lun...@gmail.com
> 16 mars 2020 kl. 16:46 skrev Adrian Klaver :
>
> On 3/16/20 3:03 AM, Björn Lundin wrote:
>>>> Yeah, it's hard to think of any explanation other than "the query used a
>>>> corrupt index on startts to produce the ordering". But your \d doesn
> 16 mars 2020 kl. 16:27 skrev Adrian Klaver :
>
> On 3/16/20 1:51 AM, Björn Lundin wrote:
>>> 16 mars 2020 kl. 01:41 skrev Tom Lane >> <mailto:t...@sss.pgh.pa.us>>:
>>>
>>> Adrian Klaver >> <mailto:adrian.kla...@aklaver.com>>
- no index) - but both those are empty.
Then I said I have the same dataset on another another box
Called tp, running ubuntu
With a 10.6 database called bnl
Which works
I’ll reply to the other mail separately
thanks for replying
--
Björn Lundin
b.f.lun...@gmail.com
uot;amarketsi2" btree (eventid)
"amarketsi3" btree (markettype)
"amarketsi4" btree (status)
"amarketsi5" btree (numwinners)
"amarketsi6" btree (ixxluts)
This gets it correctly.
So it points to something on the first machine.
Recreating indexes is a possibility, but (to me) a bit unintuitive since there
are no index on startts
I’ll do that tomorrow.
--
Björn Lundin
b.f.lun...@gmail.com
> 16 mars 2020 kl. 01:41 skrev Tom Lane :
>
> Adrian Klaver writes:
>> On 3/15/20 2:33 PM, Björn Lundin wrote:
>>> I then did ’select * from AMARKETS order by STARTTS’
>
>> Is amarkets in more then one schema?
>
> Yeah, it's hard to think of
> 16 mars 2020 kl. 01:37 skrev Adrian Klaver :
>
> On 3/15/20 2:33 PM, Björn Lundin wrote:
>> Hi!
>> I have an old database that behaves a bit strange.
>> I keeps horse races in UK/IE.
>> I have a program that continuously* adds record into a mar
ier and you can loose much more money much more
>quickly... er... yeah.
I can guarantee you that you can loose on horses in any rate you prefer. :-)
> What this looks like on my end. Feel free to try and make sense
> of it yourself.
Ok - point taken.
--
Björn Lundin
b.f.lun...@gmail.com
i2" btree (eventid)
"amarketsi3" btree (markettype)
"amarketsi4" btree (status)
"amarketsi5" btree (numwinners)
"amarketsi6" btree (ixxluts)
bnl=#
regards
--
Björn Lundin
b.f.lun...@gmail.com
14 matches
Mail list logo
