Excerpts from Andres Freund's message of lun ene 03 12:03:58 -0300 2011:
> On Monday, January 03, 2011 03:38:56 PM Alvaro Herrera wrote:
> > Is anybody working on this patch?
> I am. Wont be finished in the next two days though (breakin last night...)
Okay ... I will be moving to a new house this
On Monday, January 03, 2011 03:38:56 PM Alvaro Herrera wrote:
> Is anybody working on this patch?
I am. Wont be finished in the next two days though (breakin last night...)
Andres
PS: Alvarro: commandprompt.com doesn't resolv anymore, so I can't send you the
email directly...
--
Sent via pgsq
Alvaro Herrera wrote:
> Is anybody working on this patch?
I'm not, but I sure hope someone is -- we could *really* use this in
the SSI patch. With something providing the equivalent
functionality to Andres's previous patch, and about one day's work
in the SSI patch, SSI could guarantee that a
Is anybody working on this patch?
--
Álvaro Herrera
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgr
Andres Freund wrote:
> I will try to read the thread and make a proposal for a more
> carefull implementation - just not today... I think the results
> would be interesting...
FWIW, the SSI patch that Dan and I are working on can't have a
guarantee that it is immediately safe to retry a transa
On Thursday 16 December 2010 21:41:10 Tom Lane wrote:
> Robert Haas writes:
> > On Thu, Dec 16, 2010 at 3:18 PM, Tom Lane wrote:
> >> I guess you misunderstood what I said. �What I meant was that we cannot
> >> longjmp *out to the outer level*, ie we cannot take control away from
> >> the input s
Excerpts from Tom Lane's message of jue dic 16 17:54:51 -0300 2010:
> Robert Haas writes:
> > On Thu, Dec 16, 2010 at 3:41 PM, Tom Lane wrote:
> >> (But this is all speculation; I don't actually know SSL innards.)
>
> > I would be really surprised if aborting a transaction takes long
> > enough
Robert Haas writes:
> On Thu, Dec 16, 2010 at 3:41 PM, Tom Lane wrote:
>> (But this is all speculation; I don't actually know SSL innards.)
> I would be really surprised if aborting a transaction takes long
> enough to mess up SSL. I mean, there could be a network delay at any
> time, too.
Yea
On Thu, Dec 16, 2010 at 3:41 PM, Tom Lane wrote:
>> I thought the next thing we'd report would be the recovery
>> conflict, not any bizarre can't-abort-the-transaction scenario.
>
> Well, if we discard it because we're too lazy to implement error message
> merging, that's OK. Presumably it'll sti
Robert Haas writes:
> On Thu, Dec 16, 2010 at 3:18 PM, Tom Lane wrote:
>> I guess you misunderstood what I said. What I meant was that we cannot
>> longjmp *out to the outer level*, ie we cannot take control away from
>> the input stack. We could however have a TRY block inside the interrupt
>>
On Thu, Dec 16, 2010 at 3:18 PM, Tom Lane wrote:
> Robert Haas writes:
>> Hmm. It's seeming to me that what we want to do is something like this:
>
>> 1. If an error is thrown while DoingCommandRead, it gets upgraded to
>> FATAL. I don't think we have much choice about this because, per your
>>
Robert Haas writes:
> Hmm. It's seeming to me that what we want to do is something like this:
> 1. If an error is thrown while DoingCommandRead, it gets upgraded to
> FATAL. I don't think we have much choice about this because, per your
> previous comments, we can't longjmp() here without riski
On Thu, Dec 16, 2010 at 1:24 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Dec 16, 2010 at 12:46 PM, Tom Lane wrote:
Another thing I don't quite understand is - at what point does the
protocol allow us to emit an error?
>
>>> Basically, you can send an error in response to a que
Robert Haas writes:
> On Thu, Dec 16, 2010 at 12:46 PM, Tom Lane wrote:
>>> Another thing I don't quite understand is - at what point does the
>>> protocol allow us to emit an error?
>> Basically, you can send an error in response to a query.
> What about some other message that's not a query?
On Thu, Dec 16, 2010 at 12:46 PM, Tom Lane wrote:
> I'm handwaving there --- I think probably the
> first cut should just discard errors after the first, and see how
> well that works in practice.
Seems reasonable.
>> Another thing I don't quite understand is - at what point does the
>> protocol
Robert Haas writes:
> On Thu, Dec 16, 2010 at 11:58 AM, Tom Lane wrote:
>> It's possible we could refactor things so we abort the open transaction
>> while inside the interrupt handler, then queue up an error to be
>> reported whenever we next get a command (as envisioned in part 0003),
>> then j
On Thu, Dec 16, 2010 at 11:58 AM, Tom Lane wrote:
> Greg Smith writes:
>> I count four issues of various sizes left with this patch right now:
>
>> 1) This levels bit
>> 2) Can the approach used be simplified or the code made cleaner?
>> 3) What is the interaction with Hot Standby error handling?
Greg Smith writes:
> I count four issues of various sizes left with this patch right now:
> 1) This levels bit
> 2) Can the approach used be simplified or the code made cleaner?
> 3) What is the interaction with Hot Standby error handling?
> 4) The usual code formatting nitpicking, Kevin mentione
On Wednesday 15 December 2010 20:12:45 Robert Haas wrote:
> On Wed, Dec 15, 2010 at 10:02 AM, Andres Freund wrote:
> >> Is there a way that errstart() and/or errfinish() can know enough
> >> about the state of the communication with the frontend to decide
> >> whether to suppress edata->output_to_
Hi Greg,
On Thursday 16 December 2010 13:32:46 Greg Smith wrote:
> Andres Freund wrote:
> > On Thursday 02 December 2010 22:21:37 Alvaro Herrera wrote:
> >> Excerpts from Andres Freund's message of sáb oct 30 05:49:21 -0300 2010:
> >>> Ill set this up for the next commitfest, I don't think I can d
Andres Freund wrote:
On Thursday 02 December 2010 22:21:37 Alvaro Herrera wrote:
Excerpts from Andres Freund's message of sáb oct 30 05:49:21 -0300 2010:
Ill set this up for the next commitfest, I don't think I can do much
more without further input.
Are you reserving about 20
On Wed, Dec 15, 2010 at 10:02 AM, Andres Freund wrote:
>> Is there a way that errstart() and/or errfinish() can know enough
>> about the state of the communication with the frontend to decide
>> whether to suppress edata->output_to_client? In other words, instead
>> of explicitly passing in a fla
On Wednesday 15 December 2010 15:40:20 Robert Haas wrote:
> On Wed, Dec 15, 2010 at 7:47 AM, Andres Freund wrote:
> > I thought about doing that first. Btw, LOG_NO_CLIENT is just a more
> > abstracted way of what COMERROR did before...
>
> Hmm, but it must not be quite the same, because that didn
On Wed, Dec 15, 2010 at 7:47 AM, Andres Freund wrote:
> I thought about doing that first. Btw, LOG_NO_CLIENT is just a more abstracted
> way of what COMERROR did before...
Hmm, but it must not be quite the same, because that didn't require
the silent_error_while_idle flag.
>> Yeah. I'll try to
On Wednesday 15 December 2010 13:33:30 Robert Haas wrote:
> On Wed, Dec 15, 2010 at 7:13 AM, Andres Freund wrote:
> >> It sort of looks to me like the LOG_NO_CLIENT error flag and the
> >> silent_error_while_idle flag are trying to cooperate to get the effect
> >> of throwing an error without actu
On Wed, Dec 15, 2010 at 7:13 AM, Andres Freund wrote:
>> It sort of looks to me like the LOG_NO_CLIENT error flag and the
>> silent_error_while_idle flag are trying to cooperate to get the effect
>> of throwing an error without actually throwing an error. I'm
>> wondering if it would be at all se
On Wednesday 15 December 2010 02:20:31 Robert Haas wrote:
> On Sat, Oct 30, 2010 at 4:49 AM, Andres Freund wrote:
> >> > Here is a proposed patch which enables cancellation of $subject.
>
> Disclaimer: This isn't my area of expertise, so take the below with a
> grain or seven of salt.
I don't kno
On Sat, Oct 30, 2010 at 4:49 AM, Andres Freund wrote:
>> > Here is a proposed patch which enables cancellation of $subject.
Disclaimer: This isn't my area of expertise, so take the below with a
grain or seven of salt.
It sort of looks to me like the LOG_NO_CLIENT error flag and the
silent_error_
On Thursday 02 December 2010 22:21:37 Alvaro Herrera wrote:
> Excerpts from Andres Freund's message of sáb oct 30 05:49:21 -0300 2010:
> > Ill set this up for the next commitfest, I don't think I can do much
> > more without further input.
>
> Are you reserving about 20 bits for levels, and 12 fo
Excerpts from Andres Freund's message of sáb oct 30 05:49:21 -0300 2010:
> Ill set this up for the next commitfest, I don't think I can do much more
> without further input.
Are you reserving about 20 bits for levels, and 12 for flags? Given the
relatively scarce growth of levels, I think we co
I wrote:
> I applied all three patches with minor offsets, and it builds, but
> several regression tests fail.
Sorry, after sending that I realized I hadn't done a make distclean.
After that it passes. Please ignore the previous post.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-ha
Andres Freund wrote:
> Ok, I implemented that capability
I applied all three patches with minor offsets, and it builds, but
several regression tests fail. I backed out the patches in reverse
order and confirmed that while the regression tests pass without
any of these patches, they fail with
Andres Freund writes:
> On Tuesday 02 November 2010 22:59:15 Kevin Grittner wrote:
>>> Does anybody have any idea why COMMIT is allowed there? Seems
>>> pretty strange to me.
>> So that the "failed transaction" state can be cleared. The
>> transaction as a whole has failed, but you don't want th
On Tuesday 02 November 2010 22:59:15 Kevin Grittner wrote:
> > Does anybody have any idea why COMMIT is allowed there? Seems
> > pretty strange to me.
>
>
> So that the "failed transaction" state can be cleared. The
> transaction as a whole has failed, but you don't want the connection
> to bec
Andres Freund wrote:
> On Tuesday 02 November 2010 18:33:15 Kevin Grittner wrote:
>> Well, on a ROLLBACK I'm not sure it's a problem. On a COMMIT,
>> couldn't you call a function to check for it in CommitTransaction
>> and PrepareTransaction?
> Sure, throwing an error somewhere wouldnt be that
Excerpts from Andres Freund's message of mar nov 02 18:36:19 -0300 2010:
> On Tuesday 02 November 2010 18:33:15 Kevin Grittner wrote:
> > Andres Freund wrote:
> > > * You wont see an error if the next command after the IDLE in
> > > transaction is a COMMIT/ROLLBACK. I don*t see any sensible way
>
On Tuesday 02 November 2010 18:33:15 Kevin Grittner wrote:
> Andres Freund wrote:
> > * You wont see an error if the next command after the IDLE in
> > transaction is a COMMIT/ROLLBACK. I don*t see any sensible way
> > around that.
> Well, on a ROLLBACK I'm not sure it's a problem. On a COMMIT,
>
Andres Freund wrote:
> * You wont see an error if the next command after the IDLE in
> transaction is a COMMIT/ROLLBACK. I don*t see any sensible way
> around that.
Well, on a ROLLBACK I'm not sure it's a problem. On a COMMIT,
couldn't you call a function to check for it in CommitTransaction
Hi,
On Tuesday 19 October 2010 16:18:29 Kevin Grittner wrote:
> Andres Freund wrote:
> > Here is a proposed patch which enables cancellation of $subject.
>
> Cool. Some enhancements we'd like to do to Serializable Snapshot
> Isolation (SSI), should the base patch make it in, would require
> thi
39 matches
Mail list logo
