On Thu, Mar 19, 2015 at 08:43:52PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Thu, Mar 19, 2015 at 06:59:20PM -0300, Alvaro Herrera wrote:
> >> I don't understand why aren't interrupts held until after the commit is
> >> done -- including across the mentioned ereports.
>
> > Uh, I thin
On Thu, Mar 19, 2015 at 07:19:02PM -0400, Tom Lane wrote:
> The core issue here, I think, is that xact.c only holds off interrupts
> during what it considers to be the commit critical section --- which is
> okay from the standpoint of transactional consistency. But the complaint
> has to do with w
Bruce Momjian writes:
> On Thu, Mar 19, 2015 at 04:36:38PM -0400, Robert Haas wrote:
>> So, either way, what happens if the query cancel shows up just an
>> instant after you clear the flag?
> Oh, good point. This version handles that case addressing only the
> log_duration* block.
This is just
On Thu, Mar 19, 2015 at 06:59:20PM -0300, Alvaro Herrera wrote:
> Robert Haas wrote:
> > On Thu, Mar 19, 2015 at 10:23 AM, Bruce Momjian wrote:
>
> > > The issue with CommitTransaction() is that it only _holds_ the signal
> > > --- it doesn't clear it. Now, since there are very few
> > > CHECK_F
On Thu, Mar 19, 2015 at 04:36:38PM -0400, Robert Haas wrote:
> On Thu, Mar 19, 2015 at 10:23 AM, Bruce Momjian wrote:
> > First attached patch is more surgical and clears a possible cancel
> > request before we report the query duration in the logs --- this doesn't
> > affect any after triggers th
Robert Haas wrote:
> On Thu, Mar 19, 2015 at 10:23 AM, Bruce Momjian wrote:
> > The issue with CommitTransaction() is that it only _holds_ the signal
> > --- it doesn't clear it. Now, since there are very few
> > CHECK_FOR_INTERRUPTS() calls in the typical commit process flow, the
> > signal is
On Thu, Mar 19, 2015 at 10:23 AM, Bruce Momjian wrote:
> On Thu, Mar 19, 2015 at 07:54:02AM -0400, Robert Haas wrote:
>> On Wed, Mar 18, 2015 at 10:56 PM, Bruce Momjian wrote:
>> > I have researched this issue originally reported in June of 2014 and
>> > implemented a patch to ignore cancel while
On Thu, Mar 19, 2015 at 07:54:02AM -0400, Robert Haas wrote:
> On Wed, Mar 18, 2015 at 10:56 PM, Bruce Momjian wrote:
> > I have researched this issue originally reported in June of 2014 and
> > implemented a patch to ignore cancel while we are completing a commit.
> > I am not clear if this is th
On Wed, Mar 18, 2015 at 10:56 PM, Bruce Momjian wrote:
> I have researched this issue originally reported in June of 2014 and
> implemented a patch to ignore cancel while we are completing a commit.
> I am not clear if this is the proper place for this code, though a
> disable_timeout() call on th
On Wed, Sep 10, 2014 at 08:10:45PM -0400, Bruce Momjian wrote:
> On Tue, Jun 10, 2014 at 10:30:24AM -0400, Robert Haas wrote:
> > On Tue, Jun 10, 2014 at 10:18 AM, Tom Lane wrote:
> > > Robert Haas writes:
> > >> I don't agree with this analysis. If the connection is closed after
> > >> the clie
On Tue, Jun 10, 2014 at 10:30:24AM -0400, Robert Haas wrote:
> On Tue, Jun 10, 2014 at 10:18 AM, Tom Lane wrote:
> > Robert Haas writes:
> >> I don't agree with this analysis. If the connection is closed after
> >> the client sends a COMMIT and before it gets a response, then the
> >> client mus
Hi,
> Well, the only other principled fix I can see is to add a new reponse
> along the lines of ERRORBUTITCOMMITTED, which does not seem attractive
> either, since all clients will have to be taught to understand it.
+1
I think current specification hard to understand for many users.
It is real
On Tue, Jun 10, 2014 at 10:42 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Jun 10, 2014 at 10:18 AM, Tom Lane wrote:
>>> ... So this whole area is a minefield, and the only
>>> attractive thing we can do is to try to reduce the number of errors that
>>> can get thrown post-commit. We a
Robert Haas writes:
> On Tue, Jun 10, 2014 at 10:18 AM, Tom Lane wrote:
>> ... So this whole area is a minefield, and the only
>> attractive thing we can do is to try to reduce the number of errors that
>> can get thrown post-commit. We already, for example, do not treat
>> post-commit file unl
On Tue, Jun 10, 2014 at 10:18 AM, Tom Lane wrote:
> Robert Haas writes:
>> I don't agree with this analysis. If the connection is closed after
>> the client sends a COMMIT and before it gets a response, then the
>> client must indeed be smart enough to figure out whether or not the
>> commit hap
Robert Haas wrote:
> If the connection is closed after the client sends a COMMIT and
> before it gets a response, then the client must indeed be smart
> enough to figure out whether or not the commit happened. But if
> the server sends a response, the client should be able to rely on
> that resp
Robert Haas writes:
> I don't agree with this analysis. If the connection is closed after
> the client sends a COMMIT and before it gets a response, then the
> client must indeed be smart enough to figure out whether or not the
> commit happened. But if the server sends a response, the client
>
On Sun, Jun 8, 2014 at 2:52 AM, Amit Kapila wrote:
>> I think this cancellation request must not interrupt the internal commited
>> transaction.
>>
>> This is because clients may misunderstand "the transaction has
>> rollbacked".
>
> There can be similar observation if the server goes off (power
>
Hi Amit,
Thank you for your response.
> There can be similar observation if the server goes off (power
> outage or anything like) after committing transaction, client will
> receive connection broken, so he can misunderstand that as well.
> I think for such corner cases, client needs to reconfirm
On Fri, Jun 6, 2014 at 2:11 PM, Naoya Anzai
wrote:
>
> Hi All,
>
> When log_duration is true ( or log_min_duration_statement>=0 ),
> If a transaction has internally been commited receives a SIGINT signal
> then a query cancellation error is output.
>
> For example,
> 1. A query like a TRUNCATE is
Hi All,
When log_duration is true ( or log_min_duration_statement>=0 ),
If a transaction has internally been commited receives a SIGINT signal
then a query cancellation error is output.
For example,
1. A query like a TRUNCATE is removing bigger table files.
2. The session receives SIGINT signal.
21 matches
Mail list logo
