>What Samrat is proposing here is that WAL is not flushed to the OS before
>it is acked by a synchronous replica so recovery won't go past the
>timeline change made in failover, making it necessary to take a new
>base backup to resync with the new master.
Actually we are proposing that the data
On Monday, April 08, 2013 7:28 PM Rodrigo Barboza wrote:
On Sat, Apr 6, 2013 at 10:39 PM, Rodrigo Barboza
wrote:
Ok! I will try to reproduce in a smaller scenario.
On Sat, Apr 6, 2013 at 9:53 PM, Amit Kapila wrote:
On Saturday, April 06, 2013 12:18 PM Rodrigo Barboza wrote:
>On Sat, Apr 6, 2013
Alexander Korotkov writes:
> On Mon, Apr 8, 2013 at 9:28 AM, Tom Lane wrote:
>> I spent the weekend hacking on this, making a number of bug fixes and a
>> whole lot of cosmetic changes. I think there are large parts of this
>> that are in committable shape now, but I still find the actual graph
On Fri, Apr 5, 2013 at 11:08 PM, Amit Kapila wrote:
> I still have one more doubt, consider the below scenario for cases when we
> Invalidate buffers during moving to freelist v/s just move to freelist
>
>Backend got the buffer from freelist for a request of page-9 (number 9 is
> random, just
On Fri, Apr 5, 2013 at 9:39 PM, Ants Aasma wrote:
> Unless somebody tells me not to waste my time I'll go ahead and come
> up with a workable patch by Monday.
And here you go. I decided to be verbose with the comments as it's
easier to delete a comment to write one. I also left in a huge jumble
o
On 9 April 2013 09:24, Josh Berkus wrote:
> As much as I have a keen interest in this feature, it isn't (AFAIK)
> being considered for 9.3. Given that it's generated a fair amount of
> controversy, could we table it until 9.3 beta? There's still plenty of
> unresolved 9.3 patches in the queue.
Hello,
While walking in the code I see the following code in
src/backend/access/transam/xlogreader.c:177-191
XLogRecord *
XLogReadRecord(XLogReaderState *state, XLogRecPtr RecPtr, char **errormsg)
{
XLogRecord *record;
XLogRecPtr targetPagePtr;
boolrandAcc
On Mon, Apr 8, 2013 at 04:24:31PM -0700, Josh Berkus wrote:
> All,
>
> As much as I have a keen interest in this feature, it isn't (AFAIK)
> being considered for 9.3. Given that it's generated a fair amount of
> controversy, could we table it until 9.3 beta? There's still plenty of
> unresolved
All,
As much as I have a keen interest in this feature, it isn't (AFAIK)
being considered for 9.3. Given that it's generated a fair amount of
controversy, could we table it until 9.3 beta? There's still plenty of
unresolved 9.3 patches in the queue.
--
Josh Berkus
PostgreSQL Experts Inc.
http:
Matthias Nagel wrote:
> I would like to do someting like:
>
> FOREIGN KEY ( container_id, lifetime )
> REFERENCES other_table (id, lifetime )
> USING gist ( container_id WITH =, lifetime WITH <@ )
>
> (Of course, this is PosgreSQL-pseudo-code, but it hopefully make
> clear what I want.)
>
> So, n
On Mon, Apr 8, 2013 at 4:30 PM, Rodrigo Barboza wrote:
>
>
>
>
> On Mon, Apr 8, 2013 at 12:14 PM, Rodrigo Barboza
> wrote:
>
>>
>>
>>
>> On Mon, Apr 8, 2013 at 11:44 AM, Rodrigo Barboza > > wrote:
>>
>>>
>>>
>>>
>>> On Mon, Apr 8, 2013 at 11:27 AM, Rodrigo Barboza <
>>> rodrigombu...@gmail.com> w
On 09/04/13 08:41, Peter Eisentraut wrote:
On 4/5/13 6:14 PM, Tom Lane wrote:
Since gcc 4.8 is going to be on a lot of people's machines pretty soon,
I think we need to do something to prevent it from breaking 8.4.x and
9.0.x. It looks like our choices are (1) teach configure to enable
-fno-agg
On 4/5/13 6:14 PM, Tom Lane wrote:
> Since gcc 4.8 is going to be on a lot of people's machines pretty soon,
> I think we need to do something to prevent it from breaking 8.4.x and
> 9.0.x. It looks like our choices are (1) teach configure to enable
> -fno-aggressive-loop-optimizations if the comp
On Mon, Apr 8, 2013 at 12:14 PM, Rodrigo Barboza wrote:
>
>
>
> On Mon, Apr 8, 2013 at 11:44 AM, Rodrigo Barboza
> wrote:
>
>>
>>
>>
>> On Mon, Apr 8, 2013 at 11:27 AM, Rodrigo Barboza > > wrote:
>>
>>>
>>>
>>> On Mon, Apr 8, 2013 at 11:25 AM, Tom Lane wrote:
>>>
Rodrigo Barboza writes:
>>
On Mon, Apr 8, 2013 at 7:34 PM, Samrat Revagade
wrote:
>
> Hello,
>
> We have been trying to figure out possible solutions to the following problem
> in streaming replication Consider following scenario:
>
> If master receives commit command, it writes and flushes commit WAL records
> to the dis
On Mon, Apr 8, 2013 at 7:38 PM, Andres Freund wrote:
> On 2013-04-08 19:26:33 +0300, Ants Aasma wrote:
>> Not exactly. Sync-rep ensures that commit success is not sent to the
>> client before a synchronous replica acks the commit record. What
>> Samrat is proposing here is that WAL is not flushed
On 2013-04-08 19:26:33 +0300, Ants Aasma wrote:
> On Mon, Apr 8, 2013 at 6:50 PM, Shaun Thomas wrote:
> > On 04/08/2013 05:34 AM, Samrat Revagade wrote:
> >
> >> One solution to avoid this situation is have the master send WAL
> >> records to standby and wait for ACK from standby committing WAL fi
2013/4/5 Robert Haas :
> On Thu, Apr 4, 2013 at 8:26 AM, Kohei KaiGai wrote:
>> OK, I follow the manner of the terminology as we usually call it.
>> The attached patch just replaced things you suggested.
>
> Thanks, I have committed this, after making some changes to the
> comments and documentati
On Mon, Apr 8, 2013 at 6:50 PM, Shaun Thomas wrote:
> On 04/08/2013 05:34 AM, Samrat Revagade wrote:
>
>> One solution to avoid this situation is have the master send WAL
>> records to standby and wait for ACK from standby committing WAL files
>> to disk and only after that commit data page relate
On Apr 6, 2013, at 1:24 PM, Jeff Janes wrote:
> On Sat, Apr 6, 2013 at 1:24 AM, Heikki Linnakangas
> wrote:
>
>>
>> Incidentally, I bumped into another custom backup script just a few weeks
>> back that also excluded backup_label. I don't know what the author was
>> thinking when he wrote that
Samrat Revagade writes:
> We have been trying to figure out possible solutions to the following
> problem in streaming replication Consider following scenario:
> If master receives commit command, it writes and flushes commit WAL records
> to the disk, It also writes and flushes data page related
On 04/08/2013 05:34 AM, Samrat Revagade wrote:
One solution to avoid this situation is have the master send WAL
records to standby and wait for ACK from standby committing WAL files
to disk and only after that commit data page related to this
transaction on master.
Isn't this basically what sy
Hello,
We have been trying to figure out possible solutions to the following
problem in streaming replication Consider following scenario:
If master receives commit command, it writes and flushes commit WAL records
to the disk, It also writes and flushes data page related to this
transaction.
Th
On 7 Apr 2013, at 05:14, Robert Haas wrote:
> On Thu, Apr 4, 2013 at 6:47 PM, Greg Jaskiewicz wrote:
>> Looking around the code Today, one of my helpful tools detected this dead
>> code.
>> As far as I can see, it is actually unused call to strlen() in formatting.c,
>> float8_to_char().
>
>
Joe Conway writes:
> OK, maybe I'll try to take a look in the meantime.
That would be awesome :)
> Did you have any comment on the other pg_dump patch (reviewed by Vibhor)?
This whole extension table filtering and dumping is more in Tom's realm,
so I guess that if you want to have another pair
On Mon, Apr 8, 2013 at 11:44 AM, Rodrigo Barboza wrote:
>
>
>
> On Mon, Apr 8, 2013 at 11:27 AM, Rodrigo Barboza
> wrote:
>
>>
>>
>> On Mon, Apr 8, 2013 at 11:25 AM, Tom Lane wrote:
>>
>>> Rodrigo Barboza writes:
>>> > UPDATE tm32 SET a = a + 1 WHERE a > $i;
>>> > ERROR: unsupported type: 20288
On 04/08/2013 07:42 AM, Dimitri Fontaine wrote:
> Joe Conway writes:
>> Shouldn't that CREATE RULE be implicitly part of the CREATE EXTENSION?
>
> Yes. It's a bug, been reported before, it's on my todo list. I have
> arranged some time to care about it while in beta, I won't be able to
> have at
Tom Lane writes:
> How exactly would you know whether the previous installation was built
> without HAVE_WCSTOMBS/HAVE_TOWLOWER? That's not exposed anywhere
> reliable. And it's not out of the question that somebody upgrading to
> a newer PG version might upgrade his OS too, so I would not think
On Mon, Apr 8, 2013 at 11:27 AM, Rodrigo Barboza wrote:
>
>
> On Mon, Apr 8, 2013 at 11:25 AM, Tom Lane wrote:
>
>> Rodrigo Barboza writes:
>> > UPDATE tm32 SET a = a + 1 WHERE a > $i;
>> > ERROR: unsupported type: 202886
>>
>> I'm betting that's coming from scalargtsel, which doesn't know anyth
Joe Conway writes:
> Shouldn't that CREATE RULE be implicitly part of the CREATE EXTENSION?
Yes. It's a bug, been reported before, it's on my todo list. I have
arranged some time to care about it while in beta, I won't be able to
have at it before then…
Regards,
--
Dimitri Fontaine
http://2ndQu
On Thu, Apr 4, 2013 at 4:10 PM, Merlin Moncure wrote:
> The only reasonable answer for this (a provably used, non-security,
> non-standards violating, non-gross functionality breakage case) is
> *zero*. Our historically cavalier attitude towards compatibility
> breakage has been an immense disse
Dimitri Fontaine writes:
> Tom Lane writes:
>> If there is anybody still using Postgres on machines without wcstombs() or
>> towlower(), and they have non-ASCII data indexed by pg_trgm, they'll need
>> to REINDEX those indexes after pg_upgrade to 9.3, else searches may fail
>> incorrectly. It see
On Mon, Apr 8, 2013 at 11:25 AM, Tom Lane wrote:
> Rodrigo Barboza writes:
> > UPDATE tm32 SET a = a + 1 WHERE a > $i;
> > ERROR: unsupported type: 202886
>
> I'm betting that's coming from scalargtsel, which doesn't know anything
> about your type, but you've nominated it to be the selectivity
Rodrigo Barboza writes:
> UPDATE tm32 SET a = a + 1 WHERE a > $i;
> ERROR: unsupported type: 202886
I'm betting that's coming from scalargtsel, which doesn't know anything
about your type, but you've nominated it to be the selectivity function
for ">" anyway.
/*
* Can't get here
On 8 April 2013 16:09, Tom Lane wrote:
> Brendan Jurd writes:
>> On the specific issue of CARDINALITY, I guess we need to decide
>> whether we are going to pretend that our array/matrix thing is
>> actually nested. I first argued that we should not. But it occurred
>> to me that if we do prete
On 03.04.2013 22:50, Jeff Janes wrote:
On Wed, Apr 3, 2013 at 11:14 AM, Heikki Linnakangas
wrote:
On 03.04.2013 18:58, Jeff Janes wrote:
On Tue, Apr 2, 2013 at 10:08 PM, Jeff Janes wrote:
This commit introduced a problem with wal_keep_segments:
commit dfda6ebaec6763090fb78b458a979b**5
On Mon, Apr 8, 2013 at 9:28 AM, Tom Lane wrote:
> Alexander Korotkov writes:
> > [ trgm-regexp-0.15.patch.gz ]
>
> I spent the weekend hacking on this, making a number of bug fixes and a
> whole lot of cosmetic changes. I think there are large parts of this
> that are in committable shape now,
> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> Alexander Korotkov writes:
> > On Mon, Dec 3, 2012 at 8:31 PM, Tom Lane wrote:
> >> But having said that, I'm wondering (without having read the patch)
> >> why you need anything more than the existing "resjunk" field.
>
> > Actually, I don't know
On 6 April 2013 15:44, Andres Freund wrote:
> > * In xlog_redo, it seemed slightly awkward to call XLogRecGetData twice.
> > Merely a matter of preference but I thought I would mention it.
>
> Youre absolutely right, memcpy should have gotten passed 'data', not
> XLogRecGetData().
Applied, wit
On 6 April 2013 08:40, Heikki Linnakangas wrote:
> AFAICS that could be easily avoided by doing a simple PageGetLSN() like we
> used to, if checksums are not enabled. In XLogCheckBuffer:
>
> /*
>> * XXX We assume page LSN is first data on *every* page that can
>> be passed
>>
40 matches
Mail list logo
