On 2018-04-30 22:08:46 -0700, Andres Freund wrote:
> On 2018-04-23 07:58:30 -0700, Andres Freund wrote:
> > On 2018-04-23 13:22:21 +0300, Heikki Linnakangas wrote:
> > > On 13/04/18 13:08, Michael Paquier wrote:
> > > > On Fri, Apr 13, 2018 at 02:15:35PM +0530, amul sul wrote:
> > > > > I have look
On 2018-04-23 07:58:30 -0700, Andres Freund wrote:
> On 2018-04-23 13:22:21 +0300, Heikki Linnakangas wrote:
> > On 13/04/18 13:08, Michael Paquier wrote:
> > > On Fri, Apr 13, 2018 at 02:15:35PM +0530, amul sul wrote:
> > > > I have looked into this and found that the issue is in heap_xlog_delete
As a general note on this thread, we should try to get this cleared up
as soon as possible, since it involves an on-disk format change.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Mon, Apr 23, 2018 at 07:58:30AM -0700, Andres Freund wrote:
> On 2018-04-23 13:22:21 +0300, Heikki Linnakangas wrote:
>> Why does HeapTupleHeaderSetMovedPartitions() leave the offset number
>> unchanged? The old offset number is meaningless without the block number.
>> Also, bits and magic value
On 2018-04-23 13:22:21 +0300, Heikki Linnakangas wrote:
> On 13/04/18 13:08, Michael Paquier wrote:
> > On Fri, Apr 13, 2018 at 02:15:35PM +0530, amul sul wrote:
> > > I have looked into this and found that the issue is in heap_xlog_delete
> > > -- we
> > > have missed to set the correct offset nu
On 13/04/18 13:08, Michael Paquier wrote:
On Fri, Apr 13, 2018 at 02:15:35PM +0530, amul sul wrote:
I have looked into this and found that the issue is in heap_xlog_delete -- we
have missed to set the correct offset number from the target_tid when
XLH_DELETE_IS_PARTITION_MOVE flag is set.
Oh,
On 2018/04/13 19:08, Michael Paquier wrote:
> On Fri, Apr 13, 2018 at 02:15:35PM +0530, amul sul wrote:
>> I have looked into this and found that the issue is in heap_xlog_delete -- we
>> have missed to set the correct offset number from the target_tid when
>> XLH_DELETE_IS_PARTITION_MOVE flag is s
On Fri, Apr 13, 2018 at 02:15:35PM +0530, amul sul wrote:
> I have looked into this and found that the issue is in heap_xlog_delete -- we
> have missed to set the correct offset number from the target_tid when
> XLH_DELETE_IS_PARTITION_MOVE flag is set.
Oh, this looks good to me. So when a row wa
On Fri, Apr 13, 2018 at 9:06 AM, Andres Freund wrote:
> On 2018-04-13 12:29:21 +0900, Amit Langote wrote:
>> On 2018/04/13 7:36, Peter Geoghegan wrote:
>> > On Thu, Apr 12, 2018 at 11:47 AM, Peter Geoghegan wrote:
>> >> In short, it looks like the tests added to update.sql by commit
>> >> 2f17844
Will look into this, thanks.
Regards,
Amul
Sent from a mobile device. Please excuse brevity and tpyos.
On Fri, Apr 13, 2018, 9:06 AM Andres Freund wrote:
> On 2018-04-13 12:29:21 +0900, Amit Lan
On 2018-04-13 12:29:21 +0900, Amit Langote wrote:
> On 2018/04/13 7:36, Peter Geoghegan wrote:
> > On Thu, Apr 12, 2018 at 11:47 AM, Peter Geoghegan wrote:
> >> In short, it looks like the tests added to update.sql by commit
> >> 2f178441 ("Allow UPDATE to move rows between partitions") lead to th
On 2018/04/13 7:36, Peter Geoghegan wrote:
> On Thu, Apr 12, 2018 at 11:47 AM, Peter Geoghegan wrote:
>> In short, it looks like the tests added to update.sql by commit
>> 2f178441 ("Allow UPDATE to move rows between partitions") lead to this
>> failure, since I always hit a problem when update.sq
On Thu, Apr 12, 2018 at 03:36:12PM -0700, Peter Geoghegan wrote:
> Without having looked at it in much detail, this seems rather more
> likely to be the fault of 2f178441. That was recent enough that it's
> easy to believe that I'd be the first to notice it, and actually has
> on-disk changes, in t
On Thu, Apr 12, 2018 at 11:47 AM, Peter Geoghegan wrote:
> In short, it looks like the tests added to update.sql by commit
> 2f178441 ("Allow UPDATE to move rows between partitions") lead to this
> failure, since I always hit a problem when update.sql is reached. I
> haven't gone to the trouble of
Running "make installcheck" with wal_consistency_checking='all' on the
master branch shows the follow failure on a streaming replica:
19696/2018-04-12 11:35:29 PDT FATAL: inconsistent page found, rel
1663/50192/66636, forknum 0, blkno 0
19696/2018-04-12 11:35:29 PDT CONTEXT: WAL redo at 2/6D8411
15 matches
Mail list logo
