On 06/13/2015 05:02 AM, Thomas Munro wrote:
Since the multixact equivalent of this problem[1] fell through the
cracks on the multixact mega-thread, here is an updated patch that
addresses this problem for both pg_subtrans and pg_multixact/offsets
using the same approach: always step back one mult
Hi
Since the multixact equivalent of this problem[1] fell through the
cracks on the multixact mega-thread, here is an updated patch that
addresses this problem for both pg_subtrans and pg_multixact/offsets
using the same approach: always step back one multixact/xid (rather
than doing so only if ol
If there's anything I can try on my servers to help diagnose the issues,
please let me know. If desired, I can arrange access for debugging.
On Sat, Jun 6, 2015 at 12:51 AM, Thomas Munro wrote:
> On Sat, Jun 6, 2015 at 1:25 PM, Alvaro Herrera
> wrote:
> > Thomas Munro wrote:
> >
> >> My idea w
On Mon, Jun 8, 2015 at 12:29 PM, Thomas Munro
wrote:
> Here's a repro script and a suggested patch.
Argh... I realised immediately after sending this that subtransaction
truncation doesn't even use the oldest XID computed by vacuum, it uses
GetOldestXmin (the "oldest transaction that was running
On Sat, Jun 6, 2015 at 4:51 PM, Thomas Munro
wrote:
> On Sat, Jun 6, 2015 at 1:25 PM, Alvaro Herrera
> wrote:
>> Thomas Munro wrote:
>>
>>> My idea was that if I could get oldestXact == next XID in
>>> TruncateSUBSTRANS, then TransactionIdToPage(oldestXact) for a value of
>>> oldestXact that hap
On Sat, Jun 6, 2015 at 1:25 PM, Alvaro Herrera wrote:
> Thomas Munro wrote:
>
>> My idea was that if I could get oldestXact == next XID in
>> TruncateSUBSTRANS, then TransactionIdToPage(oldestXact) for a value of
>> oldestXact that happens to be immediately after a page boundary (so
>> that xid %
Thomas Munro wrote:
> My idea was that if I could get oldestXact == next XID in
> TruncateSUBSTRANS, then TransactionIdToPage(oldestXact) for a value of
> oldestXact that happens to be immediately after a page boundary (so
> that xid % 2048 == 0) might give page number that is >=
> latest_page_num
On Sat, Jun 6, 2015 at 10:12 AM, Thomas Munro
wrote:
> On Sat, Jun 6, 2015 at 9:45 AM, Dan Langille wrote:
>> I noticed this today on my 9.4.2 server running on FreeBSD 10.1:
>>
>> Jun 5 18:59:40 slocum postgres[986]: [3957-1] LOG: could not truncate
>> directory "pg_subtrans": apparent wrapar
On Sat, Jun 6, 2015 at 9:45 AM, Dan Langille wrote:
> I noticed this today on my 9.4.2 server running on FreeBSD 10.1:
>
> Jun 5 18:59:40 slocum postgres[986]: [3957-1] LOG: could not truncate
> directory "pg_subtrans": apparent wraparound
>
> Looking at a post from 2010, Tom Lane suggest this
I noticed this today on my 9.4.2 server running on FreeBSD 10.1:
Jun 5 18:59:40 slocum postgres[986]: [3957-1] LOG: could not truncate
directory "pg_subtrans": apparent wraparound
Looking at a post from 2010, Tom Lane suggest this information was useful:
[root@slocum:/usr/local/pgsql/data/pg_
10 matches
Mail list logo