On Sat, Dec 12, 2015 at 10:31 PM, Andres Freund wrote:
> On 2015-12-12 12:52:21 +0100, Andres Freund wrote:
>> On 2015-12-12 20:49:52 +0900, Michael Paquier wrote:
>> > Should we consider this bug a 9.5 blocker?
>>
>> I don't think so. But either way, I'm right now working on getting it
>> fixed a
Michael Paquier writes:
> Should we consider this bug a 9.5 blocker? I feel uneasy with the fact
> of releasing a new major version knowing that we know some bugs on it,
> and this one is not cool so I have added it in the list of open items.
> We know the problem and there is a patch, so this is
On 2015-12-12 12:52:21 +0100, Andres Freund wrote:
> On 2015-12-12 20:49:52 +0900, Michael Paquier wrote:
> > Should we consider this bug a 9.5 blocker?
>
> I don't think so. But either way, I'm right now working on getting it
> fixed anyway.
And done. Took a bit longer than predicted - I had to
On 2015-12-11 16:54:45 +0900, Michael Paquier wrote:
> + if (rel->rd_rel->relpersistence ==
> RELPERSISTENCE_PERMANENT ||
> + (rel->rd_rel->relpersistence ==
> RELPERSISTENCE_UNLOGGED &&
> +forkNum == INIT_FORKNUM))
On 2015-12-12 20:49:52 +0900, Michael Paquier wrote:
> Should we consider this bug a 9.5 blocker?
I don't think so. But either way, I'm right now working on getting it
fixed anyway.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http:
On Fri, Dec 11, 2015 at 4:54 PM, Michael Paquier
wrote:
> On Fri, Dec 11, 2015 at 4:27 AM, Andres Freund wrote:
>> On 2015-12-10 18:36:32 +0100, Andres Freund wrote:
>>> On 2015-12-10 12:19:12 -0500, Robert Haas wrote:
>>> > > The real problem there imo isn't that the copy_relation_data() doesn't
On 2015-12-11 15:43:24 +0900, Kyotaro HORIGUCHI wrote:
> What it is doing seems to me reasonable but copying_initfork
> doesn't seems to be necessary. Kicking both of log_newpage() and
> smgrimmedsync() by use_wal, which has the value considering
> INIT_FORKNUM would be more descriptive. (more read
On Fri, Dec 11, 2015 at 4:27 AM, Andres Freund wrote:
> Hi,
>
> On 2015-12-10 18:36:32 +0100, Andres Freund wrote:
>> On 2015-12-10 12:19:12 -0500, Robert Haas wrote:
>> > > The real problem there imo isn't that the copy_relation_data() doesn't
>> > > deal with 0 block tables, but that ATExecSetTa
On Fri, Dec 11, 2015 at 1:32 AM, Andres Freund wrote:
> I've, pushed the fix for the promotion related issue.
Thanks! It is great to see this issue addressed.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.post
Hello,
At Thu, 10 Dec 2015 20:27:01 +0100, Andres Freund wrote in
<20151210192701.gc11...@alap3.anarazel.de>
> > > > A second problem is that the smgrimmedsync() in copy_relation_data()
> > > > isn't called for the init fork of unlogged relations, even if it needs
> > > > to.
>
> Here's a patch
On Fri, Dec 11, 2015 at 1:57 AM, Robert Haas wrote:
> On Mon, Nov 30, 2015 at 9:53 PM, Michael Paquier
> wrote:
>>> I feel quite uncomfortable that it solves the problem from a kind
>>> of nature of unlogged object by arbitrary flagging which is not
>>> fully corresponds to the nature. If we can
Hi,
On 2015-12-10 18:36:32 +0100, Andres Freund wrote:
> On 2015-12-10 12:19:12 -0500, Robert Haas wrote:
> > > The real problem there imo isn't that the copy_relation_data() doesn't
> > > deal with 0 block tables, but that ATExecSetTableSpace() doesn't have a
> > > unlogged table specific codepat
On 2015-12-10 18:36:32 +0100, Andres Freund wrote:
> On 2015-12-10 12:19:12 -0500, Robert Haas wrote:
> > On Thu, Dec 10, 2015 at 11:32 AM, Andres Freund wrote:
> > > I've, pushed the fix for the promotion related issue. I'm afraid that
> > > the ALTER TABLE SET TABLESPACE issue is a bit bigger
>
On 2015-12-10 12:19:12 -0500, Robert Haas wrote:
> On Thu, Dec 10, 2015 at 11:32 AM, Andres Freund wrote:
> > I've, pushed the fix for the promotion related issue. I'm afraid that
> > the ALTER TABLE SET TABLESPACE issue is a bit bigger
> > than it though.
>
> I think that I would have preferred
On Thu, Dec 10, 2015 at 11:32 AM, Andres Freund wrote:
> I've, pushed the fix for the promotion related issue. I'm afraid that
> the ALTER TABLE SET TABLESPACE issue is a bit bigger
> than it though.
I think that I would have preferred to fix this by flushing unlogged
buffers in bulk at the end
On Mon, Nov 30, 2015 at 9:53 PM, Michael Paquier
wrote:
>> I feel quite uncomfortable that it solves the problem from a kind
>> of nature of unlogged object by arbitrary flagging which is not
>> fully corresponds to the nature. If we can deduce the necessity
>> of fsync from some nature, it would
Hi Michael, Robert,
On 2015-12-10 21:10:57 +0900, Michael Paquier wrote:
> On Thu, Dec 10, 2015 at 9:07 PM, Michael Paquier
> wrote:
> >>> Note that in both cases the patches are not complete, we need to fix
> >>> as well copy_relation_data@tablecmds.c so as the INIT_FORKNUM pages
> >>> are logge
On Thu, Dec 10, 2015 at 9:13 PM, Andres Freund wrote:
> On 2015-12-10 21:10:57 +0900, Michael Paquier wrote:
>> In short: should I send patches for all those things or are you on it?
>
> I'm on it. I don't think the new name you gave the function, and the new
> comment, are really an improvement.
On 2015-12-10 21:10:57 +0900, Michael Paquier wrote:
> In short: should I send patches for all those things or are you on it?
I'm on it. I don't think the new name you gave the function, and the new
comment, are really an improvement. We already have 'SyncOneBuffer'
(unusable for our purpose unfor
On Thu, Dec 10, 2015 at 9:07 PM, Michael Paquier
wrote:
> On Thu, Dec 10, 2015 at 8:56 PM, Andres Freund wrote:
>>> So, do we go for something like the patch you attached in
>>> 20151208125716.gs4...@alap3.anarazel.de for master and 9.5, and for
>>> ~9.4 we use the one I wrote in
>>> cab7npqsxerp
On Thu, Dec 10, 2015 at 8:56 PM, Andres Freund wrote:
>> So, do we go for something like the patch you attached in
>> 20151208125716.gs4...@alap3.anarazel.de for master and 9.5, and for
>> ~9.4 we use the one I wrote in
>> cab7npqsxerpzj+bz-mfopzfzp5pabie9jwbucjy6qayertt...@mail.gmail.com?
>
> I'm
> So, do we go for something like the patch you attached in
> 20151208125716.gs4...@alap3.anarazel.de for master and 9.5, and for
> ~9.4 we use the one I wrote in
> cab7npqsxerpzj+bz-mfopzfzp5pabie9jwbucjy6qayertt...@mail.gmail.com?
I'm more thinking of using something like my patch for all branch
On Thu, Dec 10, 2015 at 4:57 PM, Andres Freund wrote:
> On December 10, 2015 5:02:27 AM GMT+01:00, Michael Paquier
> wrote:
>>On Wed, Dec 9, 2015 at 9:07 PM, Andres Freund
>>wrote:
>>> On 2015-12-09 21:03:47 +0900, Michael Paquier wrote:
Oh, OK. I didn't read though your lines correctly. S
On December 10, 2015 5:02:27 AM GMT+01:00, Michael Paquier
wrote:
>On Wed, Dec 9, 2015 at 9:07 PM, Andres Freund
>wrote:
>> On 2015-12-09 21:03:47 +0900, Michael Paquier wrote:
>>> Oh, OK. I didn't read though your lines correctly. So you basically
>>> mean that we would look at the init files t
On Wed, Dec 9, 2015 at 9:07 PM, Andres Freund wrote:
> On 2015-12-09 21:03:47 +0900, Michael Paquier wrote:
>> Oh, OK. I didn't read though your lines correctly. So you basically
>> mean that we would look at the init files that are on disk, and check
>> if they are empty. If they are, we simply u
On 2015-12-09 21:03:47 +0900, Michael Paquier wrote:
> Oh, OK. I didn't read though your lines correctly. So you basically
> mean that we would look at the init files that are on disk, and check
> if they are empty. If they are, we simply use XLogReadBufferExtended
> to fetch the INIT_FORKNUM conte
On Wed, Dec 9, 2015 at 8:04 PM, Andres Freund wrote:
> On 2015-12-09 19:36:11 +0900, Michael Paquier wrote:
>> On Wed, Dec 9, 2015 at 4:41 PM, Andres Freund wrote:
>> > On 2015-12-09 16:30:47 +0900, Michael Paquier wrote:
>> >> > I'm kinda wondering if it wouldn't have been better to go through s
On 2015-12-09 19:36:11 +0900, Michael Paquier wrote:
> On Wed, Dec 9, 2015 at 4:41 PM, Andres Freund wrote:
> > On 2015-12-09 16:30:47 +0900, Michael Paquier wrote:
> >> > I'm kinda wondering if it wouldn't have been better to go through shared
> >> > buffers in ResetUnloggedRelationsInDbspaceDir(
On Wed, Dec 9, 2015 at 4:41 PM, Andres Freund wrote:
> On 2015-12-09 16:30:47 +0900, Michael Paquier wrote:
>> > I'm kinda wondering if it wouldn't have been better to go through shared
>> > buffers in ResetUnloggedRelationsInDbspaceDir() instead of using
>> > copy_file().
>>
>> For deployment wit
On 2015-12-09 16:30:47 +0900, Michael Paquier wrote:
> > I'm kinda wondering if it wouldn't have been better to go through shared
> > buffers in ResetUnloggedRelationsInDbspaceDir() instead of using
> > copy_file().
>
> For deployment with large shared_buffers settings, wouldn't that be
> actually
On Tue, Dec 8, 2015 at 9:57 PM, Andres Freund wrote:
> For me the attached, preliminary, patch, fixes the problem in master;
> previous branches ought to look mostly similar, except the flush moved
> to RestoreBackupBlockContents/RestoreBackupBlock.
> Does anybody have a better idea? Suitable for
On Tue, Dec 8, 2015 at 10:09 PM, Andres Freund wrote:
> On 2015-12-04 21:57:54 +0900, Michael Paquier wrote:
>> On Fri, Dec 4, 2015 at 5:10 PM, Andres Freund wrote:
>> >> Let's go for XLOG_FPI_FLUSH.
>> >
>> > I think the other way is a bit better, because we can add new flags
>> > without changi
Hi,
On 2015-12-04 21:57:54 +0900, Michael Paquier wrote:
> On Fri, Dec 4, 2015 at 5:10 PM, Andres Freund wrote:
> >> Let's go for XLOG_FPI_FLUSH.
> >
> > I think the other way is a bit better, because we can add new flags
> > without changing the WAL format.
>
> Hm. On the contrary, I think that
On 2015-12-03 22:09:43 +0100, Andres Freund wrote:
> On 2015-11-20 16:11:15 +0900, Michael Paquier wrote:
> > + if (bkpb.fork == INIT_FORKNUM)
> > + {
> > + SMgrRelation srel;
> > + srel = smgropen(bkpb.node, InvalidBackendId);
> > +
On Fri, Dec 4, 2015 at 5:10 PM, Andres Freund wrote:
> On 2015-12-04 17:00:13 +0900, Michael Paquier wrote:
>> Andres Freud wrote:
>> >> extern void InitXLogInsert(void);
>> >> diff --git a/src/include/catalog/pg_control.h
>> >> b/src/include/catalog/pg_control.h
>> >> index ad1eb4b..91445f1 100
On 2015-12-04 17:00:13 +0900, Michael Paquier wrote:
> Andres Freud wrote:
> >> @@ -450,14 +450,21 @@ ginbuildempty(PG_FUNCTION_ARGS)
> >> START_CRIT_SECTION();
> >> GinInitMetabuffer(MetaBuffer);
> >> MarkBufferDirty(MetaBuffer);
> >> - log_newpage_buffer(MetaBuffer, false);
Andres Freud wrote:
> On 2015-11-20 16:11:15 +0900, Michael Paquier wrote:
>> diff --git a/src/backend/access/transam/xlog.c
>> b/src/backend/access/transam/xlog.c
>> index cc845d2..4883697 100644
>> --- a/src/backend/access/transam/xlog.c
>> +++ b/src/backend/access/transam/xlog.c
>> @@ -9503,6 +
On 2015-11-27 16:59:20 +0900, Michael Paquier wrote:
> Attached is a patch that fixes the issue for me in master and 9.5.
> Actually in the last patch I forgot a call to smgrwrite to ensure that
> the INIT_FORKNUM is correctly synced to disk when those pages are
> replayed at recovery, letting the
Hi,
On 2015-11-20 16:11:15 +0900, Michael Paquier wrote:
> diff --git a/src/backend/access/transam/xlog.c
> b/src/backend/access/transam/xlog.c
> index cc845d2..4883697 100644
> --- a/src/backend/access/transam/xlog.c
> +++ b/src/backend/access/transam/xlog.c
> @@ -9503,6 +9503,14 @@ xlog_redo(XL
On Tue, Dec 1, 2015 at 3:06 PM, Kyotaro HORIGUCHI
wrote:
> At Tue, 1 Dec 2015 11:53:35 +0900, Michael Paquier
> wrote in
>
>> On Tue, Dec 1, 2015 at 11:11 AM, Kyotaro HORIGUCHI
>> wrote:
>> > Hello, I studied your latest patch.
>>
>> Thanks!
>>
>> > I feel quite uncomfortable that it solves t
Hello,
At Tue, 1 Dec 2015 11:53:35 +0900, Michael Paquier
wrote in
> On Tue, Dec 1, 2015 at 11:11 AM, Kyotaro HORIGUCHI
> wrote:
> > Hello, I studied your latest patch.
>
> Thanks!
>
> > I feel quite uncomfortable that it solves the problem from a kind
> > of nature of unlogged object by ar
On Tue, Dec 1, 2015 at 11:11 AM, Kyotaro HORIGUCHI
wrote:
> Hello, I studied your latest patch.
Thanks!
> I feel quite uncomfortable that it solves the problem from a kind
> of nature of unlogged object by arbitrary flagging which is not
> fully corresponds to the nature. If we can deduce the ne
Hello, I studied your lastest patch.
At Fri, 27 Nov 2015 16:59:20 +0900, Michael Paquier
wrote in
> On Fri, Nov 27, 2015 at 3:42 PM, Michael Paquier wrote:
> > I am still investigating for a correct fix, looking at reinit.c the
> > code in charge of copying the init fork as the main fork for a
On Fri, Nov 27, 2015 at 3:42 PM, Michael Paquier wrote:
> I am still investigating for a correct fix, looking at reinit.c the
> code in charge of copying the init fork as the main fork for a
> relation at the end of recovery looks to be doing its job correctly...
Attached is a patch that fixes the
On Sat, Nov 21, 2015 at 11:30 PM, Michael Paquier
wrote:
> On Fri, Nov 20, 2015 at 4:11 PM, Michael Paquier
> wrote:
>> For master and perhaps 9.5, I would think that a dedicated WAL record
>> type enforcing the fsync is the way to go. This special treatment
>> would go only for btree and spgist
On Fri, Nov 20, 2015 at 4:11 PM, Michael Paquier
wrote:
> For master and perhaps 9.5, I would think that a dedicated WAL record
> type enforcing the fsync is the way to go. This special treatment
> would go only for btree and spgist when they use INIT_FORKNUM and we
> would not impact other relati
On Fri, Nov 20, 2015 at 7:03 AM, Robert Haas wrote:
> On Thu, Nov 19, 2015 at 7:19 AM, Thom Brown wrote:
>> This bug still exists.
>
> Hmm. This probably should have been on the open items list.
I have added an open item for 9.5. That's not a cool bug to release
the next GA even if that's not l
On Thu, Nov 19, 2015 at 7:19 AM, Thom Brown wrote:
> On 27 March 2015 at 04:54, Kyotaro HORIGUCHI
> wrote:
>> Hello,
>>
>> At Thu, 26 Mar 2015 18:50:24 +0100, Andres Freund
>> wrote in <20150326175024.gj...@alap3.anarazel.de>
>>> I think the problem here is that the *primary* makes no such
>>>
On 27 March 2015 at 04:54, Kyotaro HORIGUCHI
wrote:
> Hello,
>
> At Thu, 26 Mar 2015 18:50:24 +0100, Andres Freund
> wrote in <20150326175024.gj...@alap3.anarazel.de>
>> I think the problem here is that the *primary* makes no such
>> assumptions. Init forks are logged via stuff like
>> smg
Michael Paquier wrote:
> On Thu, Mar 26, 2015 at 1:02 AM, Fabrízio de Royes Mello
> wrote:
> > I didn't found any other similar bug introduced by 85b506bb.
> >
> > Attached the original patch provided by Michael with some regression tests.
>
> Thanks for adding a test, this looks fine to me (did
Hello,
At Thu, 26 Mar 2015 18:50:24 +0100, Andres Freund
wrote in <20150326175024.gj...@alap3.anarazel.de>
> I think the problem here is that the *primary* makes no such
> assumptions. Init forks are logged via stuff like
> smgrwrite(index->rd_smgr, INIT_FORKNUM, BTREE_METAPAGE,
..
> i.e.
On 2015-03-26 15:13:41 +0100, Andres Freund wrote:
> On 2015-03-26 13:55:22 +, Thom Brown wrote:
> > I still, however, have a problem with the separate and original issue of:
> >
> > # insert into utest (thing) values ('moomoo');
> > ERROR: index "utest_pkey" contains unexpected zero page at
On 2015-03-26 13:55:22 +, Thom Brown wrote:
> I still, however, have a problem with the separate and original issue of:
>
> # insert into utest (thing) values ('moomoo');
> ERROR: index "utest_pkey" contains unexpected zero page at block 0
> HINT: Please REINDEX it.
>
> I don't see why the
On 26 March 2015 at 00:55, Michael Paquier
wrote:
> On Thu, Mar 26, 2015 at 1:02 AM, Fabrízio de Royes Mello
> wrote:
> > On Wed, Mar 25, 2015 at 12:46 PM, Fabrízio de Royes Mello
> > wrote:
> >>
> >>
> >> On Wed, Mar 25, 2015 at 10:53 AM, Andres Freund >
> >> wrote:
> >> >
> >>
> >> > Did you
On Thu, Mar 26, 2015 at 1:02 AM, Fabrízio de Royes Mello
wrote:
> On Wed, Mar 25, 2015 at 12:46 PM, Fabrízio de Royes Mello
> wrote:
>>
>>
>> On Wed, Mar 25, 2015 at 10:53 AM, Andres Freund
>> wrote:
>> >
>>
>> > Did you check whether a similar bug was made in other places of
>> > 85b506bb? Coul
On Wed, Mar 25, 2015 at 10:53 PM, Andres Freund wrote:
> Hi,
>
> On 2015-03-25 11:38:30 +0900, Michael Paquier wrote:
>> On Tue, Mar 24, 2015 at 8:46 PM, Thom Brown wrote:
>> > The index is unlogged until reindexing...
>> >
>> > [...]
>> > Which is think also raises the question, why are unlogged
On Wed, Mar 25, 2015 at 12:46 PM, Fabrízio de Royes Mello <
fabriziome...@gmail.com> wrote:
>
>
> On Wed, Mar 25, 2015 at 10:53 AM, Andres Freund
wrote:
> >
>
> > Did you check whether a similar bug was made in other places of
> > 85b506bb? Could you additionally add a regression test to this end?
On Wed, Mar 25, 2015 at 10:53 AM, Andres Freund
wrote:
>
> Hi,
>
> On 2015-03-25 11:38:30 +0900, Michael Paquier wrote:
> > On Tue, Mar 24, 2015 at 8:46 PM, Thom Brown wrote:
> > > The index is unlogged until reindexing...
> > >
> > > [...]
> > > Which is think also raises the question, why are un
Hi,
On 2015-03-25 11:38:30 +0900, Michael Paquier wrote:
> On Tue, Mar 24, 2015 at 8:46 PM, Thom Brown wrote:
> > The index is unlogged until reindexing...
> >
> > [...]
> > Which is think also raises the question, why are unlogged indexes made
> > persistent by a reindex?
>
> That's a bug of HEA
On Wednesday, March 25, 2015, Thom Brown wrote:
> On 25 March 2015 at 12:22, Amit Langote > wrote:
>
>> On Wednesday, March 25, 2015, Michael Paquier > > wrote:
>> >
>> > On Tue, Mar 24, 2015 at 8:46 PM, Thom Brown wrote:
>> > > The index is unlogged until reindexing...
>> > >
>> > > [...]
>> >
On 25 March 2015 at 12:22, Amit Langote wrote:
> On Wednesday, March 25, 2015, Michael Paquier
> wrote:
> >
> > On Tue, Mar 24, 2015 at 8:46 PM, Thom Brown wrote:
> > > The index is unlogged until reindexing...
> > >
> > > [...]
> > > Which is think also raises the question, why are unlogged ind
On Wednesday, March 25, 2015, Michael Paquier wrote:
>
> On Tue, Mar 24, 2015 at 8:46 PM, Thom Brown wrote:
> > The index is unlogged until reindexing...
> >
> > [...]
> > Which is think also raises the question, why are unlogged indexes made
> > persistent by a reindex?
>
> That's a bug of HEAD,
On Tue, Mar 24, 2015 at 8:46 PM, Thom Brown wrote:
> The index is unlogged until reindexing...
>
> [...]
> Which is think also raises the question, why are unlogged indexes made
> persistent by a reindex?
That's a bug of HEAD, ~9.4 keeping the index as unlogged even after
REINDEX INDEX. What happe
On Tue, Mar 24, 2015 at 8:37 PM, Andres Freund wrote:
> On March 24, 2015 12:35:28 PM GMT+01:00, Michael Paquier wrote:
> I think Thom's point is that he promoted the node...
>
> Thom, are you sure this want transient?
Well, I got his point :)
I was just thinking that this error message is legit,
On 24 March 2015 at 11:46, Thom Brown wrote:
>
> On 24 March 2015 at 11:37, Andres Freund wrote:
>
>> On March 24, 2015 12:35:28 PM GMT+01:00, Michael Paquier <
>> michael.paqu...@gmail.com> wrote:
>> >On Tue, Mar 24, 2015 at 5:53 PM, Thom Brown wrote:
>> >> I was attempting to set up a data se
On 24 March 2015 at 11:37, Andres Freund wrote:
> On March 24, 2015 12:35:28 PM GMT+01:00, Michael Paquier <
> michael.paqu...@gmail.com> wrote:
> >On Tue, Mar 24, 2015 at 5:53 PM, Thom Brown wrote:
> >> I was attempting to set up a data set to test pg_rewind, when I
> >encountered
> >> an error
On March 24, 2015 12:35:28 PM GMT+01:00, Michael Paquier
wrote:
>On Tue, Mar 24, 2015 at 5:53 PM, Thom Brown wrote:
>> I was attempting to set up a data set to test pg_rewind, when I
>encountered
>> an error. I created a primary and standby, then:
>>
>> [...]
>>
>> # insert into utest (thing) v
On Tue, Mar 24, 2015 at 5:53 PM, Thom Brown wrote:
> I was attempting to set up a data set to test pg_rewind, when I encountered
> an error. I created a primary and standby, then:
>
> [...]
>
> # insert into utest (thing) values ('moomoo');
> ERROR: index "utest_pkey" contains unexpected zero pa
Hi,
I was attempting to set up a data set to test pg_rewind, when I encountered
an error. I created a primary and standby, then:
# create table test (id serial primary key, thing text);
CREATE TABLE
# create unlogged table utest (id serial primary key, thing text);
CREATE TABLE
# insert into t
69 matches
Mail list logo
