On Thu, Jun 16, 2011 at 5:34 PM, Robert Haas wrote:
> On Thu, Jun 16, 2011 at 12:12 PM, Simon Riggs wrote:
>> On Thu, Jun 16, 2011 at 3:14 PM, Tom Lane wrote:
>>> Robert Haas writes:
On Thu, Jun 16, 2011 at 7:25 AM, Simon Riggs
wrote:
> With regards to the naming, I think it woul
Robert Haas writes:
> That's a reasonable point, but I still don't really like the name
> "fastpath", because it's not faster, and it's not a path. It's just
> smaller. How about xl_xact_commit_simple or xl_xact_commit_compact or
> something like that?
xl_xact_commit_short ?
"_simple" would
On Thu, Jun 16, 2011 at 12:12 PM, Simon Riggs wrote:
> On Thu, Jun 16, 2011 at 3:14 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> On Thu, Jun 16, 2011 at 7:25 AM, Simon Riggs
>>> wrote:
With regards to the naming, I think it would be better if we kept
XLOG_XACT_COMMIT record exactly
On Thu, Jun 16, 2011 at 3:14 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jun 16, 2011 at 7:25 AM, Simon Riggs
>> wrote:
>>> With regards to the naming, I think it would be better if we kept
>>> XLOG_XACT_COMMIT record exactly as it is now, and make the second
>>> record an entirely new
Excerpts from Leonardo Francalanci's message of jue jun 16 09:00:15 -0400 2011:
> Should I also change the struct name from xl_xact_commit to
> xl_xact_commit_fast_path?
Yes, please.
--
Álvaro Herrera
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Deve
Robert Haas writes:
> On Thu, Jun 16, 2011 at 7:25 AM, Simon Riggs wrote:
>> With regards to the naming, I think it would be better if we kept
>> XLOG_XACT_COMMIT record exactly as it is now, and make the second
>> record an entirely new record called XLOG_XACT_COMMIT_FASTPATH. That
>> way we ret
> The important thing is that we retain backwards compatibility with
> current XLOG_XACT_COMMIT. I'm not worried what we call the other one.
Ok, let me see if I got it right:
#define XLOG_XACT_COMMIT0x00
should become:
#define XLOG_XACT_COMMIT_WITH_INFO 0x00
and I'll add a
On Thu, Jun 16, 2011 at 2:22 PM, Robert Haas wrote:
> On Thu, Jun 16, 2011 at 7:25 AM, Simon Riggs wrote:
>> With regards to the naming, I think it would be better if we kept
>> XLOG_XACT_COMMIT record exactly as it is now, and make the second
>> record an entirely new record called XLOG_XACT_COM
On Thu, Jun 16, 2011 at 9:22 AM, Robert Haas wrote:
> On Thu, Jun 16, 2011 at 7:25 AM, Simon Riggs wrote:
>> With regards to the naming, I think it would be better if we kept
>> XLOG_XACT_COMMIT record exactly as it is now, and make the second
>> record an entirely new record called XLOG_XACT_COM
On Thu, Jun 16, 2011 at 7:25 AM, Simon Riggs wrote:
> With regards to the naming, I think it would be better if we kept
> XLOG_XACT_COMMIT record exactly as it is now, and make the second
> record an entirely new record called XLOG_XACT_COMMIT_FASTPATH. That
> way we retain backwards compatibility
On Thu, Jun 16, 2011 at 2:00 PM, Leonardo Francalanci wrote:
>> With regards to the naming, I think it would be better if we kept
>> XLOG_XACT_COMMIT record exactly as it is now, and make the second
>> record an entirely new record called XLOG_XACT_COMMIT_FASTPATH. That
>> way we retain backwar
On Wed, Jun 15, 2011 at 10:55 AM, Leonardo Francalanci wrote:
>> > On Wed, May 25, 2011 at 3:05 PM, Simon Riggs
> wrote:
>> > Leonardo, can you submit an updated version of this patch today that
>> > incorporates Simon's suggestion?
>
>
> Mmmh, maybe it was simpler than I thought; I must be
>
> With regards to the naming, I think it would be better if we kept
> XLOG_XACT_COMMIT record exactly as it is now, and make the second
> record an entirely new record called XLOG_XACT_COMMIT_FASTPATH. That
> way we retain backwards compatibility.
>
> If you'd like to rework like that please,
> > On Wed, May 25, 2011 at 3:05 PM, Simon Riggs
wrote:
> > Leonardo, can you submit an updated version of this patch today that
> > incorporates Simon's suggestion?
Mmmh, maybe it was simpler than I thought; I must be
missing something... patch attached
How can I test it with "weird" s
> On Tue, Jun 14, 2011 at 2:31 PM, Simon Riggs wrote:
> Well, we certainly have the option to review and commit the patch any
> time up until feature freeze. However, I don't want the CommitFest
> application to be full of entries for patches that are not actually
> being worked on, because it
> We don't need to be in a hurry here. As the reviewer I'm happy to give
> Leonardo some time, obviously no more than the end of the commit fest.
>
> If he doesn't respond at all, I'll do it, but I'd like to give him the
> chance and the experience if possible.
Sorry I couldn't update the pat
On Tue, Jun 14, 2011 at 2:31 PM, Simon Riggs wrote:
> We don't need to be in a hurry here. As the reviewer I'm happy to give
> Leonardo some time, obviously no more than the end of the commit fest.
Well, we certainly have the option to review and commit the patch any
time up until feature freeze.
On Tue, Jun 14, 2011 at 4:21 PM, Robert Haas wrote:
> On Wed, May 25, 2011 at 3:05 PM, Simon Riggs wrote:
>> Yes, that's correct. We can remove them from the normal commit record
>> when nmsgs == 0.
>
> Leonardo, can you submit an updated version of this patch today that
> incorporates Simon's su
On Wed, May 25, 2011 at 3:05 PM, Simon Riggs wrote:
> Yes, that's correct. We can remove them from the normal commit record
> when nmsgs == 0.
Leonardo, can you submit an updated version of this patch today that
incorporates Simon's suggestion? The CommitFest starts tomorrow. If
not, please fee
On Wed, May 25, 2011 at 3:05 PM, Simon Riggs wrote:
> On Wed, May 25, 2011 at 3:41 PM, Simon Riggs wrote:
>> On Wed, May 25, 2011 at 2:43 PM, Leonardo Francalanci
>> wrote:
Da: Simon Riggs
I can't find a clear discussion of what you are trying to do, and how,
just a URL back to
On Wed, May 25, 2011 at 10:41 AM, Simon Riggs wrote:
> OK, thats clear. Thanks.
>
> That formatting sounds quite complex.
>
> I would propose we split this into 2 WAL records: xl_xact_commit and
> xl_xact_commit_with_info
>
> xl_xact_commit doesn't have any flags, counts or arrays.
>
> xl_xact_com
On Wed, May 25, 2011 at 3:41 PM, Simon Riggs wrote:
> On Wed, May 25, 2011 at 2:43 PM, Leonardo Francalanci
> wrote:
>>> Da: Simon Riggs
>>> I can't find a clear discussion of what you are trying to do, and how,
>>> just a URL back to a complex discussion on another topic.
>>
>>
>> While tryi
On Wed, May 25, 2011 at 2:43 PM, Leonardo Francalanci wrote:
>> Da: Simon Riggs
>> I can't find a clear discussion of what you are trying to do, and how,
>> just a URL back to a complex discussion on another topic.
>
>
> While trying to write a patch to allow changing an unlogged table into
> a
Sorry, email sent without body.
Fixed some English mistakes.
commitlog_lessbytes02.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
commitlog_lessbytes02.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> Da: Simon Riggs
> I can't find a clear discussion of what you are trying to do, and how,
> just a URL back to a complex discussion on another topic.
While trying to write a patch to allow changing an unlogged table into
a logged one, I had to add another int field to xl_xact_commit.
Robert H
On Wed, May 18, 2011 at 2:11 PM, Leonardo Francalanci wrote:
> this is a second version: now using
>
> int counts[1]; /* variable-length array of counts */
>
> in xl_xact_commit to keep track of number of
>
> different arrays at the end of the struct.
>
> Waiting for feedbacks...
On Wed, May 18, 2011 at 9:11 AM, Leonardo Francalanci wrote:
> this is a second version: now using
>
> int counts[1]; /* variable-length array of counts */
>
> in xl_xact_commit to keep track of number of
>
> different arrays at the end of the struct.
>
> Waiting for feedbacks...
this is a second version: now using
intcounts[1]; /* variable-length array of counts */
in xl_xact_commit to keep track of number of
different arrays at the end of the struct.
Waiting for feedbacks...
Leonardo
commitlog_lessbytes00.patch
Description: Binary data
--
Se
> int counts[1]; /* variable-length array of counts, xinfo flags define
> length of array and meaning of counts */
Damn, that's much cleaner than what I did. I don't know why
I stuck with the idea that it had to be:
int
array
int
array
...
instead of:
int
int
...
array
array
...
which mak
On Mon, May 16, 2011 at 11:20 AM, Leonardo Francalanci wrote:
>
> following the conversation at
>
> http://postgresql.1045698.n5.nabble.com/switch-UNLOGGED-to-LOGGED-tp4290461p4382333.html
>
>
> I tried to remove some bytes from xl_xact_commit.
>
> The way I did it needs palloc+memcpy. I guess it
Hi,
following the conversation at
http://postgresql.1045698.n5.nabble.com/switch-UNLOGGED-to-LOGGED-tp4290461p4382333.html
I tried to remove some bytes from xl_xact_commit.
The way I did it needs palloc+memcpy. I guess it could be done
reusing the memory for smgrGetPendingDeletes. But I don
32 matches
Mail list logo
