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 only statement that failed
Using such an extension i
On Sun, Mar 9, 2014 at 5:28 PM, Wang, Jing wrote:
> Enclosed is the patch to implement the requirement that issue log message to
> suggest VACUUM FULL if a table is nearly empty.
>
> The requirement comes from the Postgresql TODO list.
>
> If the relpage of the table > RELPAGES_VALUES_THRESHOLD(de
On Tue, Mar 25, 2014 at 9:32 AM, 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_
On Tue, Mar 25, 2014 at 11:58 AM, Tom Lane wrote:
> Robert Haas writes:
>> Well, it's possible that the issue could be related to compiler
>> reordering, since it's still the rule that SpinLockAcquire/Release
>> must be memory barriers but need not be compiler barriers, and
>> FastPathStrongRelat
On Tue, Mar 25, 2014 at 5:39 PM, MauMau wrote:
> OK, I removed the second (existing) definition of st.
This patch version looks fine, I have verified the issue, regression tests
passed.
I had attached the latest version of patch in CF app and marked it as
"Ready For Committer".
With Regards,
A
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 like this, quite
independent of
Andres Freund writes:
> On 2014-03-25 15:08:16 -0400, Tom Lane wrote:
>> It's 100% reproducible on prairiedog, which is a Mac Cube running Tiger,
>> and using the version of python that came with Tiger (2.3.5 :-(). It
>> seems not impossible that we're looking at a long-since-fixed python
>> bug,
On 2014-03-25 15:08:16 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-03-24 00:54:31 -0400, Tom Lane wrote:
> >> Some bisection tests say that it started failing after commit
> >> 17dee323e7ff67863582f279e415a8228e0b99cd. No idea why, atm.
>
> > I can't really see why that'd would ca
On Tue, Mar 25, 2014 at 8:16 PM, Костя Кузнецов wrote:
> Hello.
>
> I submit a proposal. But Heikki Linnakangas write comments that i dont
> have a plan of implementation.
>
> My project is knn for spgist.
>
> Can I ask you a few questions?
>
> 1. I research a commit gist knn implementation. in g
Hello. I submit a proposal. But Heikki Linnakangas write comments that i dont have a plan of implementation. My project is knn for spgist. Can I ask you a few questions? 1. I research a commit gist knn implementation. in gist implementation in role of queue is ised rtree(with distance comparator) ,
Andres Freund writes:
> On 2014-03-24 00:54:31 -0400, Tom Lane wrote:
>> Some bisection tests say that it started failing after commit
>> 17dee323e7ff67863582f279e415a8228e0b99cd. No idea why, atm.
> I can't really see why that'd would cause any such failure either. One
> thing that I'd try is i
Robert Haas writes:
> On Tue, Mar 25, 2014 at 10:09 AM, Tom Lane wrote:
>> Since this machine has only been running the buildfarm for a week,
>> I rather imagine we will see more of these. Thoughts?
>>
>> (This is a PPC machine, but only a single processor, so it's hard
>> to see how memory ord
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 don't know whethe
Hi,
Robert pointed this out to me, thanks.
On 2014-03-24 00:54:31 -0400, Tom Lane wrote:
> I wrote:
> > Well ... [2.3] passes in C locale, anyway. 9.1 appears to have a problem if
> > using UTF8 encoding:
> > http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prairiedog&dt=2014-03-19%2017%3A
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 don't know whether I'm the only one, though.
>>
>> You are not. I would rather
Hi,
I found a typo causing is_init set to be to true when it should be
false...
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
>From 7f81d553204f06ca46099e80ae4aaa798b75b57f Mon Sep 17 00:00:
On Tue, Mar 25, 2014 at 10:09 AM, Tom Lane wrote:
> Buildfarm member prairiedog crashed on today's HEAD with this:
>
> TRAP: FailedAssertion("!(FastPathStrongRelationLocks->count[fasthashcode] >
> 0)", File: "lock.c", Line: 1240)
>
> I have the core file, and gdb says:
>
> #0 0x90047dac in kill
On Mon, Mar 24, 2014 at 8:59 PM, Fujii Masao wrote:
> On Sat, Mar 22, 2014 at 9:33 AM, Tatsuo Ishii wrote:
>>> That's because the parameter is checked at the beginning of recovery
>>> (i.e. at standby start) before XLOG_PARAMETER_CHANGE is received and
>>> applied on the standby. Please see Chec
Buildfarm member prairiedog crashed on today's HEAD with this:
TRAP: FailedAssertion("!(FastPathStrongRelationLocks->count[fasthashcode] >
0)", File: "lock.c", Line: 1240)
I have the core file, and gdb says:
#0 0x90047dac in kill ()
#1 0x9012d7b4 in abort ()
#2 0x003b1c38 in ExceptionalCondi
Hi,
2014-03-25 1:08 GMT+01:00 Robert Haas :
>
>
> As far as I know, this mailing list isn't the right place to discuss
> anything related to MADlib.
>
>
As MADlib projects were mentionned on the GSoC thread (see here:
http://postgresql.1045698.n5.nabble.com/GSoC-2014-mentors-students-and-admins-t
From: "Amit Kapila"
If you think that above scenario is not possible, then you just need to
modify comment:
"! * Remove old symlink in recovery"
Hm, my scenario seems impossible. I reverted the comment.
One more minor point about patch:
+ struct stat st;
if (InRecovery)
{
struct stat
Heikki Linnakangas wrote:
> On 03/25/2014 02:13 AM, Alvaro Herrera wrote:
> >You are not. I would rather have it fixed than removed, if possible. I
> >don't really care too much about getting a performance hit to palloc the
> >records, really; being able to actually read what's happening is much
2014-03-18 18:47 GMT+04:00 Robert Haas
>
>
> > If the fetch() is specified by the developer, then using it, algorithm
> can
> > retrieve the data directly to output areas at this stage, without
> reference
> > to the heap.
>
> This seems to be the crux of your proposal, but it seems vague: what
>
On 03/25/2014 02:13 AM, Alvaro Herrera wrote:
Robert Haas wrote:
On Mon, Mar 24, 2014 at 7:14 AM, Tom Lane wrote:
3. Remove the feature altogether, so that enabling wal_debug doesn't
cause all insertions to be logged anymore (no changes to the logging
during replay). It's a lot less interest
24 matches
Mail list logo
