On Mon, Jan 5, 2015 at 3:19 PM, Amit Kapila amit.kapil...@gmail.com 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
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
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
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
Andres Freund and...@2ndquadrant.com 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
On 2015-01-04 12:33:34 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com 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
On Sat, Jan 3, 2015 at 10:16 PM, Peter Geoghegan p...@heroku.com 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
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
On January 4, 2015 9:51:43 PM CET, Andrew Dunstan and...@dunslane.net 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,
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
Em domingo, 4 de janeiro de 2015, Andrew Dunstan and...@dunslane.net
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
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 - we
On Mon, Jan 05, 2015 at 02:25:09PM +0900, Michael Paquier wrote:
On Fri, Jan 2, 2015 at 1:04 PM, Noah Misch n...@leadboat.com 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
On Sun, Jan 4, 2015 at 5:47 AM, Andres Freund and...@2ndquadrant.com 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
On Mon, Dec 29, 2014 at 8:14 PM, Heikki Linnakangas
hlinnakan...@vmware.com 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
On Fri, Jan 2, 2015 at 1:04 PM, Noah Misch n...@leadboat.com 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
On Thu, Dec 4, 2014 at 12:08 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, Dec 3, 2014 at 11:54 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Pushed with some extra cosmetic tweaks.
I got the following assertion failure when I executed
pg_xact_commit_timestamp()
in the standby
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 other
On Thu, Jan 1, 2015 at 1:10 AM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Dec 29, 2014 at 6:14 AM, Heikki Linnakangas
hlinnakan...@vmware.com 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
/*
* 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
20 matches
Mail list logo
