On Fri, 2008-11-28 at 12:45 -0500, Tom Lane wrote:
> Simon Riggs writes:
> > On Fri, 2008-11-28 at 11:44 -0500, Tom Lane wrote:
> >> I hadn't been following the discussion closely enough to know what the
> >> problem is.
>
> > When we replay an AccessExclusiveLock on the standby we need to kick
Guillaume Smet wrote:
On Fri, Nov 28, 2008 at 6:45 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
Hm. People have complained of that fact from time to time in normal
usage as well. Should we simply change SIGINT handling to allow it to
cancel an idle transaction?
If this means that we wou
On Fri, Nov 28, 2008 at 6:45 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Hm. People have complained of that fact from time to time in normal
> usage as well. Should we simply change SIGINT handling to allow it to
> cancel an idle transaction?
If this means that we would be able to able to easily r
On Fri, 2008-11-28 at 12:45 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Fri, 2008-11-28 at 11:44 -0500, Tom Lane wrote:
> >> I hadn't been following the discussion closely enough to know what the
> >> problem is.
>
> > When we replay an AccessExclusiveLock on the stan
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Fri, 2008-11-28 at 11:44 -0500, Tom Lane wrote:
>> I hadn't been following the discussion closely enough to know what the
>> problem is.
> When we replay an AccessExclusiveLock on the standby we need to kick off
> any current lock holders, after a conf
On Fri, 2008-11-28 at 11:44 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Fri, 2008-11-28 at 11:14 -0500, Tom Lane wrote:
> >> The sinval queue is an *utterly* inappropriate
> >> mechanism for such a thing.
>
> > To be honest, it did seem quite a neat solution. Any parti
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Fri, 2008-11-28 at 11:14 -0500, Tom Lane wrote:
>> The sinval queue is an *utterly* inappropriate
>> mechanism for such a thing.
> To be honest, it did seem quite a neat solution. Any particular
> direction of thought you'd like me to pursue instead?
I
On Fri, 2008-11-28 at 11:14 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > After some thought, the way I would handle this is by sending a slightly
> > different kind of signal.
>
> > We can send a shared invalidation message which means "end the
> > transaction, whether or
Simon Riggs <[EMAIL PROTECTED]> writes:
> After some thought, the way I would handle this is by sending a slightly
> different kind of signal.
> We can send a shared invalidation message which means "end the
> transaction, whether or not you are currently running a statement".
No, a thousand time
On Thu, 2008-11-27 at 17:14 +, Simon Riggs wrote:
> On Wed, 2008-11-26 at 18:02 +0530, Pavan Deolasee wrote:
>
> > I think whats happening is that
> > ResolveRecoveryConflictWithVirtualXIDs() is failing to abort
> > the open transaction
> >
> >
> > Btw, ISTM that SI
On Wed, 2008-11-26 at 18:02 +0530, Pavan Deolasee wrote:
> I think whats happening is that
> ResolveRecoveryConflictWithVirtualXIDs() is failing to abort
> the open transaction
>
>
> Btw, ISTM that SIGINT works only for statement cancellation. So if the
> transaction is
On Wed, Nov 26, 2008 at 3:52 PM, Pavan Deolasee <[EMAIL PROTECTED]>wrote:
>
>
>
> I think whats happening is that ResolveRecoveryConflictWithVirtualXIDs() is
> failing to abort the open transaction
Btw, ISTM that SIGINT works only for statement cancellation. So if the
transaction is in idle sta
ISTM that the redo conflict resolution is not working as intended. I did the
following test and it throws some surprises.
On standby:
postgres=# BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE ;
BEGIN
postgres=# SELECT * from test;
a | b
-+---
102 |
103 |
(2 rows)
On primary:
postgres=
On Tue, 2008-11-25 at 19:02 +0530, Pavan Deolasee wrote:
> On Tue, Nov 25, 2008 at 6:55 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Huh? The "read only" transaction mode is not hard read-only
> anyway,
> so if that's the only step being taken, it's entirely useless.
>
On Tue, Nov 25, 2008 at 6:55 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
>
>
> Huh? The "read only" transaction mode is not hard read-only anyway,
> so if that's the only step being taken, it's entirely useless.
>
>
I think there are explicit checks for some utility statements (like VACUUM),
but I ha
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> I think we should disallow starting a read-write transaction during
> recovery. The patch attempts to do that by setting transaction mode to
> read-only, but not enough to prevent somebody to explicitly mark the
> transaction as read-write.
Huh? The
The following sequence of commands causes server crash.
postgres=# BEGIN TRANSACTION READ WRITE ;
BEGIN
postgres=# SELECT * FROM pg_class FOR UPDATE;
FATAL: cannot assign TransactionIds during recovery
STATEMENT: SELECT * FROM pg_class FOR UPDATE;
FATAL: cannot assign TransactionIds during reco
On Sun, Nov 23, 2008 at 3:12 AM, Simon Riggs <[EMAIL PROTECTED]> wrote:
>
>
>
> I don't think so, because this section of code is only called if there
> is redo to perform. If no redo, we never get here.
>
>
OK. But why not open up the database for read-only access when there is no
redo action to
On Fri, 2008-11-21 at 14:17 +0530, Pavan Deolasee wrote:
> I wonder if there is corner case
I remain on the lookout for these, so thanks for thinking of this.
> below where there are no WAL records to replay during standby
> recovery. Specifically, that may cause IsRunningXactDataValid() to
>
Pavan Deolasee escribió:
> On Fri, Nov 21, 2008 at 6:59 PM, Simon Riggs <[EMAIL PROTECTED]> wrote:
>
> > The malloc was part of the existing code, explained by comments.
>
> Oh I see. But I don't see any explanations for using malloc instead of
> palloc. Not that the current patch is responsible f
On Sat, 2008-11-22 at 15:14 +0530, Pavan Deolasee wrote:
>
> The malloc was part of the existing code, explained by
> comments.
>
>
> Oh I see. But I don't see any explanations for using malloc instead of
> palloc. Not that the current patch is responsible for t
On Fri, Nov 21, 2008 at 6:59 PM, Simon Riggs <[EMAIL PROTECTED]> wrote:
>
>
> The malloc was part of the existing code, explained by comments.
>
>
Oh I see. But I don't see any explanations for using malloc instead of
palloc. Not that the current patch is responsible for this, I am wondering
why i
On Fri, 2008-11-21 at 15:21 +0530, Pavan Deolasee wrote:
>
> + /*
> +* Release locks, if any.
> +*/
> + RelationReleaseRecoveryLocks(xlrec->slotId);
>
>
> If I am reading the patch correctly, AccessExclusiveLocks acquired by
> a transaction will be released when the
On Fri, 2008-11-21 at 13:22 +0530, Pavan Deolasee wrote:
>
> I think we should avoid the #define's like below which uses a local
> variable. I guess the same #define is used elsewhere in the code as
> well. If the code is rearranged or the variable name is changed, the
> code would break.
I use
+ /*
+* Release locks, if any.
+*/
+ RelationReleaseRecoveryLocks(xlrec->slotId);
If I am reading the patch correctly, AccessExclusiveLocks acquired by a
transaction will be released when the transaction is committed or aborted.
If the transaction errors out with FATAL
I wonder if there is corner case below where there are no WAL records to
replay during standby recovery. Specifically, that may cause
IsRunningXactDataValid() to return false since latestObservedXid remains set
to InvalidTransactionId and that prevents postmaster from serving read-only
clients.
I
I think we should avoid the #define's like below which uses a local
variable. I guess the same #define is used elsewhere in the code as well. If
the code is rearranged or the variable name is changed, the code would
break.
The use of malloc should also be avoided (unless the memory subsystem is no
27 matches
Mail list logo
