Is anybody working on this patch?
--
Álvaro Herrera alvhe...@commandprompt.com
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
Alvaro Herrera alvhe...@commandprompt.com 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,
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
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
Andres Freund and...@anarazel.de 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
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
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 do much
On Wednesday 15 December 2010 20:12:45 Robert Haas wrote:
On Wed, Dec 15, 2010 at 10:02 AM, Andres Freund and...@anarazel.de 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
Greg Smith g...@2ndquadrant.com 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
On Thu, Dec 16, 2010 at 11:58 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Greg Smith g...@2ndquadrant.com 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
Robert Haas robertmh...@gmail.com writes:
On Thu, Dec 16, 2010 at 11:58 AM, Tom Lane t...@sss.pgh.pa.us 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
On Thu, Dec 16, 2010 at 12:46 PM, Tom Lane t...@sss.pgh.pa.us 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
Robert Haas robertmh...@gmail.com writes:
On Thu, Dec 16, 2010 at 12:46 PM, Tom Lane t...@sss.pgh.pa.us 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
On Thu, Dec 16, 2010 at 1:24 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Dec 16, 2010 at 12:46 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Another thing I don't quite understand is - at what point does the
protocol allow us to emit an error?
Basically,
Robert Haas robertmh...@gmail.com 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()
On Thu, Dec 16, 2010 at 3:18 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
Robert Haas robertmh...@gmail.com writes:
On Thu, Dec 16, 2010 at 3:18 PM, Tom Lane t...@sss.pgh.pa.us 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
On Thu, Dec 16, 2010 at 3:41 PM, Tom Lane t...@sss.pgh.pa.us 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.
Robert Haas robertmh...@gmail.com writes:
On Thu, Dec 16, 2010 at 3:41 PM, Tom Lane t...@sss.pgh.pa.us 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
Excerpts from Tom Lane's message of jue dic 16 17:54:51 -0300 2010:
Robert Haas robertmh...@gmail.com writes:
On Thu, Dec 16, 2010 at 3:41 PM, Tom Lane t...@sss.pgh.pa.us wrote:
(But this is all speculation; I don't actually know SSL innards.)
I would be really surprised if aborting a
On Thursday 16 December 2010 21:41:10 Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Dec 16, 2010 at 3:18 PM, Tom Lane t...@sss.pgh.pa.us 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
On Wednesday 15 December 2010 02:20:31 Robert Haas wrote:
On Sat, Oct 30, 2010 at 4:49 AM, Andres Freund and...@anarazel.de 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.
On Wed, Dec 15, 2010 at 7:13 AM, Andres Freund and...@anarazel.de 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
On Wednesday 15 December 2010 13:33:30 Robert Haas wrote:
On Wed, Dec 15, 2010 at 7:13 AM, Andres Freund and...@anarazel.de 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
On Wed, Dec 15, 2010 at 7:47 AM, Andres Freund and...@anarazel.de 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.
On Wednesday 15 December 2010 15:40:20 Robert Haas wrote:
On Wed, Dec 15, 2010 at 7:47 AM, Andres Freund and...@anarazel.de 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,
On Wed, Dec 15, 2010 at 10:02 AM, Andres Freund and...@anarazel.de 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
On Sat, Oct 30, 2010 at 4:49 AM, Andres Freund and...@anarazel.de 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
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
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 for
Andres Freund and...@anarazel.de 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
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
Andres Freund and...@anarazel.de 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
On Tuesday 02 November 2010 18:33:15 Kevin Grittner wrote:
Andres Freund and...@anarazel.de 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
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 and...@anarazel.de wrote:
* You wont see an error if the next command after the IDLE in
transaction is a COMMIT/ROLLBACK. I don*t see any
Andres Freund and...@anarazel.de 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
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 become
Andres Freund and...@anarazel.de 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
Hi,
On Tuesday 19 October 2010 16:18:29 Kevin Grittner wrote:
Andres Freund and...@anarazel.de 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
39 matches
Mail list logo
