I see this when I run the regression tests with valgrind (memcheck) on
master's tip:
2014-03-25 22:38:40.850 PDT 31570 LOG: statement: SET enable_seqscan=OFF;
2014-03-25 22:38:40.859 PDT 31570 LOG: statement: SELECT count(*)
FROM test_tsvector WHERE a @@ 'wr|qh';
==31570== Conditional jump or mo
On 03/26/2014 06:59 AM, Robert Haas wrote:
On Tue, Mar 25, 2014 at 11:58 AM, Tom Lane wrote:
Robert Haas writes:
I really think we
should change that rule; it leads to ugly code, and bugs.
No doubt, but are we prepared to believe that we have working "compiler
barriers" other than volatile?
Hello, I could see reparameterize for foreign path to work
effectively thanks to your advice. The key point was setting
use_remote_estimate to false and existence of another child to
get parameterized path in prior stages.
The overall patch was applied on HEAD and compiled cleanly except
for a war
On 03/26/2014 09:21 AM, Peter Geoghegan wrote:
It looks like a "recheck" stack variable isn't every being set within
TS_execute_ternary() (which has a pointer to that variable on the
stack) - ultimately, the checkcondition_gin() callback will set the
flag, but only to 'true' (iff that's appropria
On 03/26/2014 08:39 AM, Michael Paquier wrote:
Hi all,
The behavior of rollback when an error occurs on an handle is
controlled by extending Protocol with "$PROTNUM-[0|1|2]" where:
- 0 = let the application handle rollbacks
- 1 = rollback whole transaction when an error occurs
- 2 = rollback onl
On Wed, Mar 26, 2014 at 3:39 PM, Michael Paquier
wrote:
> Hi all,
>
> The behavior of rollback when an error occurs on an handle is
> controlled by extending Protocol with "$PROTNUM-[0|1|2]"...
My apologies. This message was sent to the wrong mailing list and was
dedicated to odbc.
Once again sorr
Hi Michael,
Isn't it an ODBC issue?
regards,
Hiroshi Inoue
(2014/03/26 15:39), Michael Paquier wrote:
Hi all,
The behavior of rollback when an error occurs on an handle is
controlled by extending Protocol with "$PROTNUM-[0|1|2]" where:
- 0 = let the application handle rollbacks
- 1 = rollback
On 03/25/2014 08:05 PM, Andres Freund wrote:
On 2014-03-25 10:49:54 -0700, Robert Haas wrote:
On Tue, Mar 25, 2014 at 12:30 AM, Heikki Linnakangas
wrote:
I've found WAL_DEBUG quite useful in the past, when working on
scalability, and have indeed wished for it to be
compiled-in-by-default.
I d
On Thu, Mar 13, 2014 at 5:35 PM, Robert Haas wrote:
>
> Well, I'm not sure that's really any big deal, but I'm not wedded to
> the label idea. My principal concern is: I'm opposed to allowing
> unvalidated options into the database. I think it should be a
> requirement that if the validator can'
On Wed, Mar 26, 2014 at 5:08 AM, Heikki Linnakangas
wrote:
> Oh, no, there's no need to do it while holding WALInsertLock. It's quite
> trivial, actually, see attached. So it's not difficult to fix this if we
> want to.
Well is there any reason not to just commit that patch? I mean, it
seems odd
Hi all,
I'm using PostgreSQL 9.1.10 for my HA project and have found this problem.
I did (multiple times) the following sequence in my primary/standby synchronous
replication environment,
1. Update rows in a table (which have primary key constraint column) in active
DB
2. Stop active DB
3. P
On Mon, Mar 24, 2014 at 09:07:07PM -0400, Bruce Momjian wrote:
> > In the "INDEX" case, should the output mention specifically which index
> > is being considered?
>
> Ah, good idea. Updated patch attached. The output is now:
>
> test=> \d+ test
>Table "pub
On 26 March 2014 15:08, Dang Minh Huong wrote:
> Hi all,
>
> I'm using PostgreSQL 9.1.10 for my HA project and have found this problem.
>
> I did (multiple times) the following sequence in my primary/standby
> synchronous replication environment,
>
> 1. Update rows in a table (which have primary k
Bruce Momjian wrote:
> On Mon, Mar 24, 2014 at 09:07:07PM -0400, Bruce Momjian wrote:
> > > In the "INDEX" case, should the output mention specifically which index
> > > is being considered?
> >
> > Ah, good idea. Updated patch attached. The output is now:
> >
> > test=> \d+ test
> >
On Wed, Mar 26, 2014 at 12:20:07PM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > On Mon, Mar 24, 2014 at 09:07:07PM -0400, Bruce Momjian wrote:
> > > > In the "INDEX" case, should the output mention specifically which index
> > > > is being considered?
> > >
> > > Ah, good idea. Updated
Andrew Dunstan writes:
> It occurred to me after having to change I think 9 files to clean up a
> small mess in the jsonb regression tests the other day that we might
> usefully expose the inputdir and outputdir to psql as variables when
> running pg_regress. Then we might be able to do thing l
Bruce Momjian wrote:
> On Wed, Mar 26, 2014 at 12:20:07PM -0300, Alvaro Herrera wrote:
> > Not opposed to this, but it seems a bit strange; REPLICA IDENTITY is a
> > property of the table, not of any individual index. I think we should
> > lose the token in the "Indexes" section.
>
> That is an
On Wed, Mar 26, 2014 at 12:53:32PM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > On Wed, Mar 26, 2014 at 12:20:07PM -0300, Alvaro Herrera wrote:
>
> > > Not opposed to this, but it seems a bit strange; REPLICA IDENTITY is a
> > > property of the table, not of any individual index. I thi
On 03/26/2014 04:51 PM, Robert Haas wrote:
On Wed, Mar 26, 2014 at 5:08 AM, Heikki Linnakangas
wrote:
Oh, no, there's no need to do it while holding WALInsertLock. It's quite
trivial, actually, see attached. So it's not difficult to fix this if we
want to.
Well is there any reason not to just
It seems to me that when flushing logical mappings to disk, each
mapping file leaks the buffer used to pass the mappings to XLogInsert.
Also, it seems consistent to allocate that buffer in the RewriteState
memory context. Patch attached.
Regards,
Ants Aasma
--
Cybertec Schönig & Schönig GmbH
Gröh
On 03/26/2014 11:37 AM, Tom Lane wrote:
Andrew Dunstan writes:
It occurred to me after having to change I think 9 files to clean up a
small mess in the jsonb regression tests the other day that we might
usefully expose the inputdir and outputdir to psql as variables when
running pg_regress. Th
* Ants Aasma (a...@cybertec.at) wrote:
> It seems to me that when flushing logical mappings to disk, each
> mapping file leaks the buffer used to pass the mappings to XLogInsert.
> Also, it seems consistent to allocate that buffer in the RewriteState
> memory context. Patch attached.
Hmm, yeah, it
Andrew Dunstan writes:
> On 03/26/2014 11:37 AM, Tom Lane wrote:
>> At least this one seems rather difficult to fix in this fashion:
>>
>> output/create_function_1.source:83:ERROR: could not find function
>> "nosuchsymbol" in file "@libdir@/regress@DLSUFFIX@"
>>
>> (I'm a bit inclined to think
On 2014-03-26 12:49:41 -0400, Stephen Frost wrote:
> * Ants Aasma (a...@cybertec.at) wrote:
> > It seems to me that when flushing logical mappings to disk, each
> > mapping file leaks the buffer used to pass the mappings to XLogInsert.
> > Also, it seems consistent to allocate that buffer in the Re
* Andres Freund (and...@2ndquadrant.com) wrote:
> On 2014-03-26 12:49:41 -0400, Stephen Frost wrote:
> > * Ants Aasma (a...@cybertec.at) wrote:
> > > It seems to me that when flushing logical mappings to disk, each
> > > mapping file leaks the buffer used to pass the mappings to XLogInsert.
> > > A
On 2014-03-26 13:41:27 -0400, Stephen Frost wrote:
> * Andres Freund (and...@2ndquadrant.com) wrote:
> > On 2014-03-26 12:49:41 -0400, Stephen Frost wrote:
> > > * Ants Aasma (a...@cybertec.at) wrote:
> > > > It seems to me that when flushing logical mappings to disk, each
> > > > mapping file leak
David Rowley writes:
> I've attached an updated invtrans_strictstrict_base patch which has the
> feature removed.
What is the state of play on this patch? Is the latest version what's in
http://www.postgresql.org/message-id/64f96fd9-64d1-40b9-8861-e61820292...@phlo.org
plus this sub-patch? Is e
On Thu, Mar 27, 2014 at 7:33 AM, Tom Lane wrote:
> David Rowley writes:
> > I've attached an updated invtrans_strictstrict_base patch which has the
> > feature removed.
>
> What is the state of play on this patch? Is the latest version what's in
>
> http://www.postgresql.org/message-id/64f96fd9
I wrote:
> Andres Freund writes:
>> If there's a refcounting bug inside python somewhere (which is easy to
>> trigger in python's C interface), it could be excerbated by that change,
>> since it frees/compiles functions more frequently. But I'd very much
>> like more evidence of this...
> I think
On Mon, Mar 24, 2014 at 9:02 PM, Amit Kapila wrote:
> MarkBufferDirty() always increment BufferUsage counter
> (shared_blks_dirtied) for dirty blocks whenever it dirties any
> block, whereas same is not true for MarkBufferDirtyHint().
> Is there any particular reason for not incrementing
> shared_
I found another bug of this category using Valgrind (memcheck). When
the standard regression tests are run against master's git tip, I see
the following:
2014-03-26 12:58:21.246 PDT 28882 LOG: statement: select * from
json_to_record('{"a":1,"b":"foo","c":"bar"}',true)
as x(a int, b te
2014/03/27 0:18、Thom Brown のメッセージ:
>> On 26 March 2014 15:08, Dang Minh Huong wrote:
>> Hi all,
>>
>> I'm using PostgreSQL 9.1.10 for my HA project and have found this problem.
>>
>> I did (multiple times) the following sequence in my primary/standby
>> synchronous replication environment,
>>
On 03/26/2014 05:01 PM, Peter Geoghegan wrote:
I found another bug of this category using Valgrind (memcheck). When
the standard regression tests are run against master's git tip, I see
the following:
2014-03-26 12:58:21.246 PDT 28882 LOG: statement: select * from
json_to_record('{"a":1,"b":"f
On Sun, Mar 2, 2014 at 1:04 AM, Fabrízio de Royes Mello <
fabriziome...@gmail.com> wrote:
>
> On Sat, Mar 1, 2014 at 7:39 PM, Tom Lane wrote:
> >
> > =?ISO-8859-1?Q?Fabr=EDzio_de_Royes_Mello?=
writes:
> > > On Sat, Mar 1, 2014 at 2:11 PM, Tom Lane wrote:
> > >> [ re schema upgrade scenarios ]
>
On Wed, Nov 27, 2013 at 9:10 AM, Noah Misch wrote:
> The threat is that rounding the read size up to the next MAXALIGN would cross
> into an unreadable memory page, resulting in a SIGSEGV. Every palloc chunk
> has MAXALIGN'd size under the hood, so the excess read of "toDelete" cannot
> cause a S
Hi Horiguchi-san,
(2014/03/26 17:14), Kyotaro HORIGUCHI wrote:
> The overall patch was applied on HEAD and compiled cleanly except
> for a warning.
>
>> analyze.c: In function ‘acquire_inherited_sample_rows’:
>> analyze.c:1461: warning: unused variable ‘saved_rel’
I've fixed this in the latest v
I have thought a little further about my proposal to have inner B-Tree
pages store strxfrm() blobs [1]; my earlier conclusion was that this
could not be trusted when equality was indicated [2] due to the
"Hungarian problem" [3]. As I noted earlier, that actually doesn't
really matter, because we ma
On Thu, Mar 27, 2014 at 1:39 AM, Robert Haas wrote:
> On Mon, Mar 24, 2014 at 9:02 PM, Amit Kapila wrote:
>> MarkBufferDirty() always increment BufferUsage counter
>> (shared_blks_dirtied) for dirty blocks whenever it dirties any
>> block, whereas same is not true for MarkBufferDirtyHint().
>> Is
On Tue, 2014-03-18 at 18:37 -0400, Tom Lane wrote:
> After further experimentation, I've found that 2.3 does pass the
> regression
> tests if one installs the separately-available cdecimal module. So my
> complaint reduces to the fact that our "Requirements" documentation
> doesn't mention the nee
Few new warnings have been introduced in windows build.
1>e:\workspace\postgresql\master\postgresql\src\backend\utils\adt\jsonb_util.c(802):
warning C4715: 'JsonbIteratorNext' : not all control paths return a
value
1>e:\workspace\postgresql\master\postgresql\src\backend\utils\adt\jsonb_util.c(104
40 matches
Mail list logo
