>On further review, I think that we ought to make MarkBufferDirty() the
>caller's job, because sometimes we may need to xlog only if
>XLogIsNeeded(), but the buffer's got to get marked dirty either way.
Incase the place where Xlog is not required, woudn't it fsync the data;
So in that case even Ma
On Thu, Jun 7, 2012 at 6:15 PM, Tom Lane wrote:
> I am pleased to announce that Kevin Grittner has accepted the core
> committee's invitation to become our newest committer. As you all
> know, Kevin's done a good deal of work on the project over the past
> couple of years. We judged that he has
On Fri, Jun 8, 2012 at 7:15 AM, Tom Lane wrote:
> I am pleased to announce that Kevin Grittner has accepted the core
> committee's invitation to become our newest committer.
Wow! Congrats, Kevin!
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
+1 indeed.
Very pleased to see this progression in the development team!
On Fri, Jun 8, 2012 at 1:20 PM, Robert Haas wrote:
> On Fri, Jun 8, 2012 at 9:56 AM, Robert Haas wrote:
>> OK. So what I'm thinking is that we should add a new function that
>> takes a relfilenode and a buffer and steps 4-6 of what's described in
>> transam/README: mark the buffer dirty, xlog it
Simon Riggs wrote:
> On 8 June 2012 18:26, Robert Haas wrote:
>
>> I would be more open to warning people about CREATE GLOBAL TEMP
>> TABLE - frankly, it's pretty wonky that we allow that but treat
>> GLOBAL as a noise word in this first place. But I'm a little
>> disinclined to have the messag
On Thu, Jun 7, 2012 at 3:15 PM, Tom Lane wrote:
> I am pleased to announce that Kevin Grittner has accepted the core
> committee's invitation to become our newest committer.
I have 99 problems, but this ain't one.[0]
[0]: This is a song reference.
--
fdr
--
Sent via pgsql-hackers mailing lis
On 8 June 2012 18:01, Florian Pflug wrote:
>> What would be much better, IMHO, is if the number of retained
>> segments could ratchet down when the system is idle, eventually
>> reaching a state where we keep only one segment beyond the one
>> currently in use.
>
> I'm a bit sceptical about this.
On Jun 7, 2012, at 3:15 PM, Tom Lane wrote:
> Please join me in welcoming him aboard.
Woo, congrats, Kevin!
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Kudos!
Well-earned :)
Cheers,
David.
On Thu, Jun 07, 2012 at 06:15:23PM -0400, Tom Lane wrote:
> I am pleased to announce that Kevin Grittner has accepted the core
> committee's invitation to become our newest committer. As you all
> know, Kevin's done a good deal of work on the project over the
On 8 June 2012 18:26, Robert Haas wrote:
> I would be more open to warning people about CREATE GLOBAL TEMP TABLE
> - frankly, it's pretty wonky that we allow that but treat GLOBAL as a
> noise word in this first place. But I'm a little disinclined to have
> the message speculate about what might
On Sun, Apr 29, 2012 at 4:02 PM, Noah Misch wrote:
> On Tue, Apr 24, 2012 at 11:55:15PM -0400, Noah Misch wrote:
>> Concerning everyone's favorite topic, how to name the new type of table, I
>> liked Tom's proposal[1] to make CREATE TEMP TABLE retain current behavior and
>> have CREATE GLOBAL TEMP
This patch is to provide support for fallback application name for
contrib/pgbench, oid2name, and dblink.
Currently I have done the implementation for pgbench. The implementation is
same as in psql.
Before creating a final patch, I wanted to check whether my direction for
creating a patch is wha
On Fri, Jun 8, 2012 at 9:56 AM, Robert Haas wrote:
> OK. So what I'm thinking is that we should add a new function that
> takes a relfilenode and a buffer and steps 4-6 of what's described in
> transam/README: mark the buffer dirty, xlog it, and set the LSN and
> TLI. We might want to have this
On Fri, Jun 8, 2012 at 1:01 PM, Florian Pflug wrote:
> On Jun8, 2012, at 15:47 , Robert Haas wrote:
>> On Fri, Jun 8, 2012 at 5:02 AM, Simon Riggs wrote:
>>> On 8 June 2012 09:14, Kyotaro HORIGUCHI
>>> wrote:
>>>
The requirement for this patch is as follows.
- What I want to get
On Fri, Jun 8, 2012 at 12:24 PM, Kevin Grittner
wrote:
> I haven't been exactly clear on the risks about which Tom and Robert
> have been concerned; is it a question about whether we change the
> meaning of these settings to something more complicated?:
>
> checkpoint_segments (integer)
> Maxim
On Jun8, 2012, at 15:47 , Robert Haas wrote:
> On Fri, Jun 8, 2012 at 5:02 AM, Simon Riggs wrote:
>> On 8 June 2012 09:14, Kyotaro HORIGUCHI
>> wrote:
>>
>>> The requirement for this patch is as follows.
>>>
>>> - What I want to get is similarity of the behaviors between
>>> master and (hot-)
Robert Haas wrote:
> if the database has checkpointed
I haven't been exactly clear on the risks about which Tom and Robert
have been concerned; is it a question about whether we change the
meaning of these settings to something more complicated?:
checkpoint_segments (integer)
Maximum num
On Thu, Jun 7, 2012 at 9:25 PM, Simon Riggs wrote:
> The only risk of data loss is in the case where someone deletes their
> pg_xlog and who didn't take a backup in all that time, which is hardly
> recommended behaviour. We're at exactly the same risk of data loss if
> someone deletes their pg_clo
On 8 June 2012 15:21, Robert Haas wrote:
> On Fri, Jun 8, 2012 at 9:58 AM, Simon Riggs wrote:
>> On 8 June 2012 14:47, Robert Haas wrote:
>>
ISTM that we should avoid triggering a checkpoint on the master if
checkpoint_segments is less than wal_keep_segments. Such checkpoints
serv
On Fri, Jun 8, 2012 at 9:58 AM, Simon Riggs wrote:
> On 8 June 2012 14:47, Robert Haas wrote:
>
>>> ISTM that we should avoid triggering a checkpoint on the master if
>>> checkpoint_segments is less than wal_keep_segments. Such checkpoints
>>> serve no purpose because we don't actually limit and
On 8 June 2012 14:47, Robert Haas wrote:
>> ISTM that we should avoid triggering a checkpoint on the master if
>> checkpoint_segments is less than wal_keep_segments. Such checkpoints
>> serve no purpose because we don't actually limit and recycle the WAL
>> files and all it does is slow people do
On Fri, Jun 8, 2012 at 9:33 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jun 7, 2012 at 8:06 PM, Tom Lane wrote:
>>> AFAICS, not passing the buffer ID to XLogInsert is not an issue, since
>>> we are logging the whole page in any case. However, failing to perform
>>> MarkBufferDirty with
On Fri, Jun 8, 2012 at 5:02 AM, Simon Riggs wrote:
> On 8 June 2012 09:14, Kyotaro HORIGUCHI
> wrote:
>
>> The requirement for this patch is as follows.
>>
>> - What I want to get is similarity of the behaviors between
>> master and (hot-)standby concerning checkpoint
>> progression. Specifica
Robert Haas writes:
> On Thu, Jun 7, 2012 at 8:06 PM, Tom Lane wrote:
>> AFAICS, not passing the buffer ID to XLogInsert is not an issue, since
>> we are logging the whole page in any case. However, failing to perform
>> MarkBufferDirty within the critical section definitely is an issue.
> Howe
On Fri, Jun 8, 2012 at 7:53 AM, Magnus Hagander wrote:
> On Fri, Jun 8, 2012 at 1:48 PM, Robert Haas wrote:
>> On Wed, Jun 6, 2012 at 6:04 PM, Daniel Farina wrote:
>>> On Wed, Jun 6, 2012 at 1:13 PM, Robert Haas wrote:
On Wed, Jun 6, 2012 at 4:08 PM, Magnus Hagander
wrote:
> How
On Thu, Jun 7, 2012 at 8:06 PM, Tom Lane wrote:
> Robert Haas writes:
>> It seems that in implementing ginbuildempty(), I falsified the first
>> "note" in the header comment for log_newpage():
>
>> * Note: all current callers build pages in private memory and write them
>> * directly to smgr, r
On Fri, Jun 8, 2012 at 1:48 PM, Robert Haas wrote:
> On Wed, Jun 6, 2012 at 6:04 PM, Daniel Farina wrote:
>> On Wed, Jun 6, 2012 at 1:13 PM, Robert Haas wrote:
>>> On Wed, Jun 6, 2012 at 4:08 PM, Magnus Hagander wrote:
However, not throwing errors on the URL syntax should be considered a
>
On Wed, Jun 6, 2012 at 6:04 PM, Daniel Farina wrote:
> On Wed, Jun 6, 2012 at 1:13 PM, Robert Haas wrote:
>> On Wed, Jun 6, 2012 at 4:08 PM, Magnus Hagander wrote:
>>> However, not throwing errors on the URL syntax should be considered a
>>> bug, I think.
>>
>> +1.
>
> +1
>
> Here's a patch that
On 8 June 2012 09:22, Kyotaro HORIGUCHI wrote:
> I have a problem with promoting from hot-standby that exclusive
> checkpointing retards completion of promotion.
Agreed, we have that problem.
> I depend on this and suppose we can omit it if latest checkpoint
> has been taken so as to be able to
2012-06-08 00:15 keltezéssel, Tom Lane írta:
I am pleased to announce that Kevin Grittner has accepted the core
committee's invitation to become our newest committer. As you all
know, Kevin's done a good deal of work on the project over the past
couple of years. We judged that he has the requis
On 8 June 2012 09:14, Kyotaro HORIGUCHI wrote:
> The requirement for this patch is as follows.
>
> - What I want to get is similarity of the behaviors between
> master and (hot-)standby concerning checkpoint
> progression. Specifically, checkpoints for streaming
> replication running at the sp
Le vendredi 8 juin 2012 00:15:23, Tom Lane a écrit :
> I am pleased to announce that Kevin Grittner has accepted the core
> committee's invitation to become our newest committer. As you all
> know, Kevin's done a good deal of work on the project over the past
> couple of years. We judged that he
On 25 April 2012 10:40, Kohei KaiGai wrote:
> I tried to implement a patch according to the idea. It allows extensions
> to register an entry point of the self-managed daemon processes,
> then postmaster start and stop them according to the normal manner.
The patch needs much work yet, but has m
Hello,
I have a problem with promoting from hot-standby that exclusive
checkpointing retards completion of promotion.
This checkpoint is "shutdown checkpoint" as a convention in
realtion to TLI increment according to the comment shown below. I
suppose "shutdown checkpoint" means exclusive checkpo
Hello, I will make this patch start again for this CF.
The requirement for this patch is as follows.
- What I want to get is similarity of the behaviors between
master and (hot-)standby concerning checkpoint
progression. Specifically, checkpoints for streaming
replication running at the spe
Congratulations Kevin!
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
Hi,
On Friday, June 08, 2012 01:42:22 AM Simon Riggs wrote:
> On 7 June 2012 21:08, Andres Freund wrote:
> >> Moved the wakeup to a logical place outside a critical section.
> >
> > Hm. I don't really like the way you implemented that. While it reduces
> > the likelihood quite a bit it will stil
38 matches
Mail list logo
