On 12/19/2014 02:53 PM, Noah Misch wrote:
> The test assumed that no two transactions of a given backend will get the same
> timestamp value from now(). That holds so long as ticks of the system time
> are small enough. Not so on at least some Windows configurations.
Most Windows systems with no
On Mon, Jan 5, 2015 at 3:19 PM, Amit Kapila wrote:
> /*
> * errhidestmt --- optionally suppress CONTEXT: field of log entry
> *
> * This should only be used for verbose debugging messages where the
> repeated
> * inclusion of CONTEXT: bloats the log volume too much.
> */
> int
> errhidecontex
On Sun, Jan 4, 2015 at 5:47 AM, Andres Freund wrote:
> On 2015-01-03 16:03:36 +0100, Andres Freund wrote:
>> On 2014-12-31 16:32:19 +0100, Andres Freund wrote:
>> > On 2014-12-05 16:18:02 +0900, Fujii Masao wrote:
>> > > On Fri, Dec 5, 2014 at 9:28 AM, Andres Freund
>> > > wrote:
>> > > > So I t
On Thu, Dec 4, 2014 at 12:08 PM, Fujii Masao wrote:
> On Wed, Dec 3, 2014 at 11:54 PM, Alvaro Herrera
> wrote:
>> Pushed with some extra cosmetic tweaks.
>
> I got the following assertion failure when I executed
> pg_xact_commit_timestamp()
> in the standby server.
>
> =# select pg_xact_commit_t
/*
* errhidestmt --- optionally suppress CONTEXT: field of log entry
*
* This should only be used for verbose debugging messages where the
repeated
* inclusion of CONTEXT: bloats the log volume too much.
*/
int
errhidecontext(bool hide_ctx)
Here in function header, function name should be
er
On Mon, Jan 05, 2015 at 02:25:09PM +0900, Michael Paquier wrote:
> On Fri, Jan 2, 2015 at 1:04 PM, Noah Misch wrote:
> > The first attached patch, for all branches, adds LOG-level messages and an
> > assertion. So cassert builds will fail hard, while others won't. The
> > second
> > patch, for
On Fri, Jan 2, 2015 at 1:04 PM, Noah Misch wrote:
> The first attached patch, for all branches, adds LOG-level messages and an
> assertion. So cassert builds will fail hard, while others won't. The second
> patch, for master only, changes the startup-time message to FATAL. If we
> decide to use
On Mon, Dec 29, 2014 at 8:14 PM, Heikki Linnakangas
wrote:
> On 12/26/2014 09:31 AM, Fujii Masao wrote:
>>
>> Hi,
>>
>> While reviewing FPW compression patch, I found that allocate_recordbuf()
>> always returns TRUE though its source code comment says that FALSE is
>> returned if out of memory. It
On Thu, Jan 1, 2015 at 1:10 AM, Robert Haas wrote:
> On Mon, Dec 29, 2014 at 6:14 AM, Heikki Linnakangas
> wrote:
>> Hmm. There is no way to check beforehand if a palloc() will fail because of
>> OOM. We could check for MaxAllocSize, though.
>
> I think we need a version of palloc that returns NU
On Sun, Jan 04, 2015 at 12:20:09PM -0500, Andrew Dunstan wrote:
>
> I don't wish to seem humorless, but I think this should probably be changed:
>
> root/HEAD/pgsql/src/test/regress/sql/event_trigger.sql:248: RAISE EXCEPTION
> 'I''m sorry Sir, No Rewrite Allowed.';
>
> Quite apart from any othe
Andrew Dunstan wrote:
>
> I don't wish to seem humorless, but I think this should probably be changed:
>
> root/HEAD/pgsql/src/test/regress/sql/event_trigger.sql:248: RAISE EXCEPTION
> 'I''m sorry Sir, No Rewrite Allowed.';
>
> Quite apart from any other reason, the "Sir" does seem a bit sexist
Em domingo, 4 de janeiro de 2015, Andrew Dunstan
escreveu:
>
> I don't wish to seem humorless, but I think this should probably be
> changed:
>
> root/HEAD/pgsql/src/test/regress/sql/event_trigger.sql:248: RAISE
> EXCEPTION 'I''m sorry Sir, No Rewrite Allowed.';
>
> Quite apart from any other re
On 01/03/2015 12:56 AM, Heikki Linnakangas wrote:
> On 01/03/2015 12:28 AM, Josh Berkus wrote:
>> On 01/02/2015 01:57 AM, Heikki Linnakangas wrote:
>>> wal_keep_segments does not affect the calculation of CheckPointSegments.
>>> If you set wal_keep_segments high enough, checkpoint_wal_size will be
On January 4, 2015 9:51:43 PM CET, Andrew Dunstan wrote:
>
>On 12/15/2014 12:04 PM, Andres Freund wrote:
>
>>> I think the safest fix would be to defer catchup interrupt
>processing
>>> while you're in this mode. You don't really want to be processing
>any
>>> remote sinval messages at all, I'd t
On 12/15/2014 12:04 PM, Andres Freund wrote:
I think the safest fix would be to defer catchup interrupt processing
while you're in this mode. You don't really want to be processing any
remote sinval messages at all, I'd think.
Well, we need to do relmap, smgr and similar things. So I think th
On 2015-01-04 12:33:34 -0500, Tom Lane wrote:
> Andres Freund writes:
> > Off list Tom commented that suggestion with:
> >> An easy alternative fix, of course, is to not call isLockedRefname if
> >> we don't have a pstate (or else put the pstate==NULL test inside it).
>
> > I'm not a big fan of t
Andres Freund writes:
> Off list Tom commented that suggestion with:
>> An easy alternative fix, of course, is to not call isLockedRefname if
>> we don't have a pstate (or else put the pstate==NULL test inside it).
> I'm not a big fan of that - won't that essentially cause the wrong
> locklevel t
I don't wish to seem humorless, but I think this should probably be changed:
root/HEAD/pgsql/src/test/regress/sql/event_trigger.sql:248: RAISE
EXCEPTION 'I''m sorry Sir, No Rewrite Allowed.';
Quite apart from any other reason, the "Sir" does seem a bit sexist - we
have no idea of the gender
Hi,
Since at least 61e532820824504aa92ad93c427722d3fa9c1632 from 2009,
addRangeTableEntry() relies pstate being != NULL via its call to
isLockedRefname() even though its documentation says:
* If pstate is NULL, we just build an RTE and return it without adding it
* to an rtable list.
I think we
On Sat, Jan 3, 2015 at 10:16 PM, Peter Geoghegan wrote:
> I looked at the code in more detail, and realized that there were old
> bugs in the exclusion constraint related modifications. I attach a
> delta patch that fixes them. This is a combined patch that is all that
> is needed to apply on top
20 matches
Mail list logo
