Re: pg primary key bug? - Mailing list pgsql-sql

<br /><br /> Tom Lane wrote:<br /><blockquote cite="mid10243.1109090250@sss.pgh.pa.us" type="cite"><pre wrap="">pginfo
<aclass="moz-txt-link-rfc2396E" href="mailto:pginfo@t1.unisoftbg.com"><pginfo@t1.unisoftbg.com></a> writes:
</pre><blockquotetype="cite"><pre wrap="">You idea was that we have "vacuum full" + update or select for update in 
 
the same time.
I think it is not the case, because we start vacuum full at 1:00 AM and 
no one is working in this time.   </pre></blockquote><pre wrap="">
Hmm.  AFAICT the duplicate row copies could only be produced by vacuum
full, so that's certainly part of the issue.  But if vacuum full in
isolation were broken, we'd surely know it; so there must be some other
contributing factor involved that your setup is exercising but other
people are (mostly) not doing.

I agree with the plan to use plain vacuum for awhile and see if that
makes the problem go away.  I think it would have to, but maybe I'm
all wet about that. </pre></blockquote> Ok, we can still using vacuum full on some installs (with risk to make problems
tocustomes).<br /> I will to ask if it will be possible to start some querys (I do not know the query) exactly before
runningvacuum full and to save the results in some log file. If it is possible, we will be able to post the results to
thelist in case of  ne problem and to have some start point for reproducing the problem. My idea is some one more
familiarwith pg to send this querys (if it exists) and we will install it in vacuum scripts.<br /><br /><blockquote
cite="mid10243.1109090250@sss.pgh.pa.us"type="cite"><pre wrap="">
 
In the meantime I would suggest seeing if you can distill your
application down into a test case that other people can run to reproduce
the problem.  It doesn't matter if the test doesn't make the bug happen
very often, but we have to see the problem happening before we have much
hope of fixing it.
 </pre><blockquote type="cite"><pre wrap="">Will vacuum full generate this problem if we have locked table in this 
time? (It is possible to have locked table in theory)   </pre></blockquote><pre wrap="">
No, that's hardly likely.  vacuum full deals with locks all the time.
 </pre><blockquote type="cite"><pre wrap="">Can you describe more detailed the idea of  problem with "vacuum full" + 
"update" and can some one make patch if this problem exists in theory 
(if I  understand you right)?   </pre></blockquote><pre wrap="">
I have no idea what the actual failure mechanism might be.
        regards, tom lane </pre></blockquote> regards,<br /> ivan.<br /><blockquote
cite="mid10243.1109090250@sss.pgh.pa.us"type="cite"><pre wrap="">
 
 </pre></blockquote><br />