In the following thread I discovered that my new regression tests worked
perfectly on windows, but when they were run on linux they failed.
http://www.postgresql.org/message-id/CAApHDvo_YCiPYGDz07MpX9o6EGg=3mmyJTb0ysPTwoTg3c=t...@mail.gmail.com
After looking at pg_regress to see which options it
On Sun, Dec 15, 2013 at 2:27 PM, Josh Berkus j...@agliodbs.com wrote:
On 12/14/2013 05:00 PM, Tom Lane wrote:
This consideration also makes me question whether we should apply the
method for NUMERIC. Although in principle numeric addition/subtraction
is exact, such a sequence could leave
http://www.viva64.com/en/b/0227/ reported that on-stack memset()s
might be optimized away by compilers. Fix it.
* Replace memset() with px_memset()
* Add px_memset to copy_crlf()
* ADd px_memset to pgp-s2k.c
--
marko
diff --git a/contrib/pgcrypto/crypt-blowfish.c
On Tue, Dec 24, 2013 at 07:25:01PM +0100, Vik Fearing wrote:
I was recently annoyed that I had to do
CREATE TABLESPACE x LOCATION y;
ALTER TABLESPACE x SET (random_page_cost = z);
The attached patch is a quick n' dirty extension to allow the SET
directly on the CREATE statement.
CREATE
On 12/26/2013 06:10 PM, David Fetter wrote:
On Tue, Dec 24, 2013 at 07:25:01PM +0100, Vik Fearing wrote:
I was recently annoyed that I had to do
CREATE TABLESPACE x LOCATION y;
ALTER TABLESPACE x SET (random_page_cost = z);
The attached patch is a quick n' dirty extension to allow the SET
On 12/17/2013 11:16 AM, Andrew Dunstan wrote:
On 12/17/2013 10:31 AM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On Wed, Dec 11, 2013 at 02:30:04PM +,
em...@andersonloyola.com.br wrote:
postgres=# SELECT to_json(a) FROM (VALUES(1000::money)) a(salario);
to_json
On 12/25/13, 7:01 AM, Andreas Joseph Krogh wrote:
http://wiki.postgresql.org/wiki/BDR_Project
Is implementing main BDR features into core Postgres a probable
objective to version 9.4?
No.
No BDR feature has been proposed for core PostgreSQL so far. Also, this
feature builds on top of the
On 12/12/13, 8:45 PM, Tom Lane wrote:
Memo to hackers: I think the SIGSTOP stuff is rather obsolete now that
most systems dump core files with process IDs embedded in the names.
Which systems are those?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
On Dec23, 2013, at 03:45 , Robert Haas robertmh...@gmail.com wrote:
On Fri, Dec 20, 2013 at 8:16 PM, Florian Pflug f...@phlo.org wrote:
On Dec20, 2013, at 18:52 , Robert Haas robertmh...@gmail.com wrote:
On Thu, Dec 19, 2013 at 6:40 PM, Florian Pflug f...@phlo.org wrote:
Solving this seems a
On Dec23, 2013, at 18:39 , Peter Eisentraut pete...@gmx.net wrote:
On 12/19/13, 6:40 PM, Florian Pflug wrote:
The following example fails for XMLOPTION set to DOCUMENT as well as for
XMLOPTION set to CONTENT.
select xmlconcat(
xmlparse(document '!DOCTYPE test [!ELEMENT test
On Thu, Dec 26, 2013 at 11:54 AM, Peter Eisentraut pete...@gmx.net wrote:
On 12/12/13, 8:45 PM, Tom Lane wrote:
Memo to hackers: I think the SIGSTOP stuff is rather obsolete now that
most systems dump core files with process IDs embedded in the names.
Which systems are those?
MacOS X dumps
On Tue, Dec 24, 2013 at 6:22 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-12-23 14:15:29 -0500, Robert Haas wrote:
On Mon, Dec 23, 2013 at 1:57 PM, Andres Freund and...@2ndquadrant.com
wrote:
Well, all of the fundamental changes (combocids, the initial multixact
introduction)
On Tue, Dec 24, 2013 at 10:08 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Tue, Dec 24, 2013 at 2:57 AM, Amit Kapila amit.kapil...@gmail.com wrote:
On Sun, Dec 22, 2013 at 8:32 PM, Amit Kapila amit.kapil...@gmail.com wrote:
On Sun, Dec 22, 2013 at 3:01 PM, Fujii Masao masao.fu...@gmail.com
On Tue, Dec 24, 2013 at 5:33 AM, Peter Eisentraut pete...@gmx.net wrote:
On 12/24/13, 1:33 AM, Etsuro Fujita wrote:
This is a small patch to fix a typo in src/backend/utils/mmgr/README.
I don't think that change is correct.
Why not? It looks like a correct fix to me. The second version
On Fri, Dec 20, 2013 at 12:39 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Hmm. If I understand the problem correctly, it's that as soon as another
backend sees the tuple you've inserted and calls XactLockTableWait(), it
will not stop waiting even if we later decide to kill the
On Thu, Dec 26, 2013 at 5:58 PM, Robert Haas robertmh...@gmail.com wrote:
While mulling this over further, I had an idea about this: suppose we
marked the tuple in some fashion that indicates that it's a promise
tuple. I imagine an infomask bit, although the concept makes me wince
a bit since
I wrote:
Robert Haas wrote:
I'd be wary of showing a desired value unless it's highly likely to
be accurate.
The desired value is accurately estimated based on (a) the total
number of exact/lossy pages stored in the TIDBitmap and (b) the
following equation in tbm_create(), except
Hi,
Can a posting item / ItemPointer belonging to posting list/tree of
some entry stored in a GIN index be lossy? If yes, under what
circumstances would such a lossy ItemPointer be included for the
entry?
I got an impression that there may be some lossy ItemPointers stored
in a GIN index while
On Thu, Dec 26, 2013 at 03:18:23PM -0800, Robert Haas wrote:
On Thu, Dec 26, 2013 at 11:54 AM, Peter Eisentraut pete...@gmx.net wrote:
On 12/12/13, 8:45 PM, Tom Lane wrote:
Memo to hackers: I think the SIGSTOP stuff is rather obsolete now that
most systems dump core files with process IDs
On 2013-12-12 20:45:17 -0500, Tom Lane wrote:
Memo to hackers: I think the SIGSTOP stuff is rather obsolete now that
most systems dump core files with process IDs embedded in the names.
What would be more useful today is an option to send SIGABRT, or some
other signal that would force core
On 2013-12-26 21:11:27 -0800, Peter Geoghegan wrote:
I'm generally opposed to making value locks of any stripe be held for
more than an instant (so we should not hold them indefinitely pending
another conflicting xact finishing). It's not just that it's
convenient to my implementation; I also
Hi,
On 2013-12-26 14:26:15 -0500, Peter Eisentraut wrote:
On 12/25/13, 7:01 AM, Andreas Joseph Krogh wrote:
http://wiki.postgresql.org/wiki/BDR_Project
Is implementing main BDR features into core Postgres a probable
objective to version 9.4?
Not fully. We hope to integrate some of the
22 matches
Mail list logo
