On Tue, Dec 17, 2013 at 7:48 AM, Andres Freund wrote:
> On 2013-12-16 00:53:10 -0500, Robert Haas wrote:
>> > Yes, I think we could mostly reuse it, we'd probably want to add a field
>> > or two more (application_name, sync_prio?). I have been wondering
>> > whether some of the code in replication
On 2013-12-16 00:53:10 -0500, Robert Haas wrote:
> > Yes, I think we could mostly reuse it, we'd probably want to add a field
> > or two more (application_name, sync_prio?). I have been wondering
> > whether some of the code in replication/logical/logical.c shouldn't be
> > in replication/slot.c or
Robert Haas writes:
> There's that, too. But again, these messages are not can't-happen
> scenarios. The argument is just whether to reuse existing error
> message text (like "could not write file") or invent a new variation
> (like "could not write remapping file").
As long as the message incl
Robert Haas escribió:
> There's that, too. But again, these messages are not can't-happen
> scenarios. The argument is just whether to reuse existing error
> message text (like "could not write file") or invent a new variation
> (like "could not write remapping file"). Andres' argument (which i
On Mon, Dec 16, 2013 at 12:21 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Dec 16, 2013 at 6:01 AM, Andres Freund
>> wrote:
>>> Perhaps we should just introduce a marker that some such strings are not
>>> to be translated if they are of the unexpected kind. That would probably
>>> make
Robert Haas writes:
> On Mon, Dec 16, 2013 at 6:01 AM, Andres Freund wrote:
>> Perhaps we should just introduce a marker that some such strings are not
>> to be translated if they are of the unexpected kind. That would probably
>> make debugging easier too ;)
> Well, we have that: it's called el
On Mon, Dec 16, 2013 at 6:01 AM, Andres Freund wrote:
>> There's no hard and
>> fast rule here, because some cases are distinguished, but my gut
>> feeling is that all of the errors your patch introduces are
>> sufficiently obscure cases that separate messages with separate
>> translations are not
Hi Robert,
On 2013-12-16 00:53:10 -0500, Robert Haas wrote:
> On Wed, Dec 11, 2013 at 7:08 PM, Andres Freund wrote:
> >> I don't think there's much point in including "remapping" in all of
> >> the error messages. It adds burden for translators and users won't
> >> know what a remapping file is
On Wed, Dec 11, 2013 at 7:08 PM, Andres Freund wrote:
>> I don't think there's much point in including "remapping" in all of
>> the error messages. It adds burden for translators and users won't
>> know what a remapping file is anyway.
>
> It helps in locating wich part of the code caused a probl
On Sat, Dec 14, 2013 at 12:12 AM, Andres Freund wrote:
> On 2013-12-13 20:58:24 +1300, David Rowley wrote:
> > On Wed, Dec 11, 2013 at 1:11 PM, Robert Haas
> wrote:
> > This introduced a new compiler warning on the visual studios build:
> > d:\postgres\b\src\backend\utils\cache\relcache.c(3958)
On 2013-12-13 20:58:24 +1300, David Rowley wrote:
> On Wed, Dec 11, 2013 at 1:11 PM, Robert Haas wrote:
> This introduced a new compiler warning on the visual studios build:
> d:\postgres\b\src\backend\utils\cache\relcache.c(3958): warning C4715:
> 'RelationGetIndexAttrBitmap' : not all control
On Wed, Dec 11, 2013 at 1:11 PM, Robert Haas wrote:
>
> Committed #1 (again). Regarding this:
>
>
This introduced a new compiler warning on the visual studios build:
d:\postgres\b\src\backend\utils\cache\relcache.c(3958): warning C4715:
'RelationGetIndexAttrBitmap' : not all control paths retur
Hi,
Lots of sensible comments removed, I plan to make changes to
address them.
On 2013-12-10 22:17:44 -0500, Robert Haas wrote:
> - I think this needs SGML documentation, same kind of thing we have
> for background workers, except probably significantly more. A design
> document with ASCII art i
On Wed, Dec 11, 2013 at 11:25 AM, Andres Freund wrote:
> On 2013-12-10 19:11:03 -0500, Robert Haas wrote:
>> Committed #1 (again). Regarding this:
>>
>> + /* XXX: we could also do this unconditionally, the space is used
>> anyway
>> + if (copy_oid)
>> + HeapTupleSetOid(
On 2013-12-10 19:11:03 -0500, Robert Haas wrote:
> Committed #1 (again). Regarding this:
>
> + /* XXX: we could also do this unconditionally, the space is used
> anyway
> + if (copy_oid)
> + HeapTupleSetOid(key_tuple, HeapTupleGetOid(tp));
>
> I would like to put in a
On 2013-12-10 19:11:03 -0500, Robert Haas wrote:
> Committed #1 (again).
Thanks!
> Regarding this:
>
> + /* XXX: we could also do this unconditionally, the space is used
> anyway
> + if (copy_oid)
> + HeapTupleSetOid(key_tuple, HeapTupleGetOid(tp));
>
> I would like
On Wed, Dec 4, 2013 at 10:55 AM, Andres Freund wrote:
> [ updated logical decoding patches ]
Regarding patch #4, introduce wal decoding via catalog timetravel,
which seems to be the bulk of what's not committed at this point...
- I think this needs SGML documentation, same kind of thing we have
On Wed, Dec 4, 2013 at 10:55 AM, Andres Freund wrote:
> I've primarily sent this, because I don't know of further required
> changes in 0001-0003. I am trying reviewing the other patches in detail
> atm.
Committed #3 also.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise
On Wed, Dec 4, 2013 at 10:55 AM, Andres Freund wrote:
> On 2013-12-03 15:19:26 -0500, Robert Haas wrote:
>> Yeah, you're right. I think the current logic will terminate when all
>> flags are set to false or all attribute numbers have been checked, but
>> it doesn't know that if HOT's been disprov
19 matches
Mail list logo
