Unfortunately we still see it frequently :(
On 9 August 2017 at 14:29, Achilleas Mantzios
wrote:
> On 09/08/2017 15:27, ADSJ (Adam Sjøgren) wrote:
>
>> On 2017-06-21 Adam Sjøgren wrote:
>>
>> Adam Sjøgren wrote:
>>>
Hi,
pls tell me, I am currently running 2nd run in my box, (New attempt 2), and
> its in the "Attempting vacuum" phase.
> What is it supposed to do next?
> I got no errors , it has gotten my machine to its knees.
>
The jar has an endless while loop. Thus please kill the PID when you are
done
It seems to be very hit and miss...
The below is from the machine described in this thread running PostgreSQL
9.4.10:
update 10
update 12
update 14
update 16
update 18
Update all
Vacuum
org.postgresql.util.PSQLException: ERROR: unexpected chunk number 2285
(expected 0)
Hi,
BTW, how do you get that jar to make the test table on a non-default
> tablespace? Or are you just putting the whole test DB on a tablespace?
>
> regards, tom lane
>
I have been putting the whole database on a tablespace. It seemed easier
than modifying the jar.
Hi Everyone,
Still trying to fathom this one. I have added quite a few log lines to a
copy of 9.4.12 and compiled it hoping to find the fault.
Below is from the log (at DEBUG5). Apologies for my name in the log lines,
it was the easiest way to grep them specifically I also apologise that its
a
D’s. Something I had also considered.
Tom - I can provide a jar that I have been using to replicate the issue. Whats
the best transport method to send it over?
Best wishes,
Harry
> On 7 Jun 2017, at 16:27, Tom Lane <t...@sss.pgh.pa.us> wrote:
>
> Harry Ambrose <harry.ambr...@g
Hi,
I too have been experiencing this with a busy PostgreSQL instance.
I have been following the updates to the 9.4 branch hoping a fix will appear,
but sadly no luck yet. I have manually replicated the issue on 9.4.4, 9.4.10
and 9.4.12. My replication steps are:
BEGIN;
CREATE TABLE x (id
Hi,
Maybe you could give some info on :
> - your ext3 mkfs and mount options (journal, barriers, etc)
>
/etc/fstab details below:
LABEL=/var/lib/pgsql/var/lib/pgsql ext3defaults
1 2
LABEL=/tablespace1 /tablespace1ext3defaults
1 2
Hi,
Not sure whether its relevant or not, however upon adding an ANALYSE before
the second vacuum the issue has not presented when testing. I have managed
95 cycles thus far.
BEGIN;
CREATE TABLE x (id BIGSERIAL PRIMARY KEY, payload1 VARCHAR, payload2
VARCHAR, payload3 VARCHAR, payload4 BIGINT,
Hi Tom,
Thanks for attempting to replicate the issue.
Anyway, the bad news is I couldn't reproduce the problem then and I can't
> now. I don't know if it's a timing issue or if there's something critical
> about configuration that I'm not duplicating. Can you explain what sort
> of platform
Hi,
> Their suggestion is to upload to Google Drive. That or use a third party
site, like Dropbox.
I have uploaded the jar to dropbox, link below (please let me know if you
have any issues downloading):
https://www.dropbox.com/s/96vm465i7rwhcf8/toast-corrupter-aio.jar?dl=0
> So I guess you run
further
info.
Best wishes,
Harry
On 7 June 2017 at 17:46, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Harry Ambrose <harry.ambr...@gmail.com> writes:
> > Tom - I can provide a jar that I have been using to replicate the issue.
> Whats the best transport method to send it over?
further
info.
Best wishes,
Harry
On 7 June 2017 at 17:46, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Harry Ambrose <harry.ambr...@gmail.com> writes:
> > Tom - I can provide a jar that I have been using to replicate the issue.
> Whats the best transport method to send it over?
Hi All,
Sorry to open this can of worms again. However, we are still struggling
with this issue across quite a large amount of our estate.
>From doing some further research I stumbled across the following which
seems to sum up what we are seeing quite well...
14 matches
Mail list logo