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 t
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 al
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 Thu, Dec 26, 2013 at 03:18:23PM -0800, Robert Haas wrote:
> On Thu, Dec 26, 2013 at 11:54 AM, Peter Eisentraut 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
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 whil
> 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_crea
On Thu, Dec 26, 2013 at 5:58 PM, Robert Haas 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 we don't exactly
On Fri, Dec 20, 2013 at 12:39 PM, Heikki Linnakangas
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 already-inserted
> tuple.
>
On Tue, Dec 24, 2013 at 5:33 AM, Peter Eisentraut 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 looks
correct t
On Tue, Dec 24, 2013 at 10:08 AM, Fujii Masao wrote:
> On Tue, Dec 24, 2013 at 2:57 AM, Amit Kapila wrote:
>> On Sun, Dec 22, 2013 at 8:32 PM, Amit Kapila wrote:
>>> On Sun, Dec 22, 2013 at 3:01 PM, Fujii Masao wrote:
I found the bug of ALTER SYSTEM SET patch. The procedure to reproduce
>>
On Tue, Dec 24, 2013 at 6:22 AM, Andres Freund wrote:
> On 2013-12-23 14:15:29 -0500, Robert Haas wrote:
>> On Mon, Dec 23, 2013 at 1:57 PM, Andres Freund
>> wrote:
>> > Well, all of the fundamental changes (combocids, the initial multixact
>> > introduction) have been quite some time ago. I thi
On Thu, Dec 26, 2013 at 11:54 AM, Peter Eisentraut 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 core files
On Dec23, 2013, at 18:39 , Peter Eisentraut 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 ']>'),
>>xmlparse(content '')
>> )::text:
On Dec23, 2013, at 03:45 , Robert Haas wrote:
> On Fri, Dec 20, 2013 at 8:16 PM, Florian Pflug wrote:
>> On Dec20, 2013, at 18:52 , Robert Haas wrote:
>>> On Thu, Dec 19, 2013 at 6:40 PM, Florian Pflug wrote:
Solving this seems a bit messy, unfortunately. First, I think we need to
ha
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 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 t
On 12/17/2013 11:16 AM, Andrew Dunstan wrote:
On 12/17/2013 10:31 AM, Tom Lane wrote:
Andrew Dunstan 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
---
{"sal
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 all
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.
>
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 b/contrib/pgcrypto/crypt-blowf
On Sun, Dec 15, 2013 at 2:27 PM, Josh Berkus 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 us with a d
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
22 matches
Mail list logo
