BTW, there are a a couple of spec files floating around which perhaps we
should consider getting into the source repo (in some cleaned up form).
Noah published one, Andres shared a couple more with me, and I think I
have two more. They can't be made to work in normal circumstances,
because they de
Noah Misch wrote:
> On Tue, Dec 03, 2013 at 07:26:38PM +0100, Andres Freund wrote:
> > On 2013-12-03 13:14:38 -0500, Noah Misch wrote:
> > > On Tue, Dec 03, 2013 at 04:37:58PM +0100, Andres Freund wrote:
> > > > I currently don't see fixing the errorneous freezing of lockers (not the
> > > > update
On 2013-12-13 17:08:46 -0300, Alvaro Herrera wrote:
> Andres Freund wrote:
> > Afaics this will cause HEAP_KEYS_UPDATED to be reset, is that
> > problematic? I don't really remember what it's needed for TBH...
>
> So we do reset HEAP_KEYS_UPDATED, and in general that bit seems critical
> for sever
Andres Freund wrote:
> On 2013-12-12 18:24:34 -0300, Alvaro Herrera wrote:
> > + else if (TransactionIdIsValid(update_xid) && !has_lockers)
> > + {
> > + /*
> > +* If there's a single member and it's an update, pass it back
> > alone
> > +* without creating a
On 2013-12-13 13:39:20 -0300, Alvaro Herrera wrote:
> Here's cache code with LRU superpowers (ahem.)
Heh.
> I settled on 256 as number of entries because it's in the same ballpark
> as MaxHeapTuplesPerPage which seems a reasonable guideline to follow.
Sounds ok.
> I considered the idea of avoid
Andres Freund wrote:
> On 2013-12-12 18:24:34 -0300, Alvaro Herrera wrote:
> > + /*
> > +* It's an update; should we keep it? If the
> > transaction is known
> > +* aborted then it's okay to ignore it, otherwise not.
> > (Note this
> > +
On 2013-12-12 18:24:34 -0300, Alvaro Herrera wrote:
> + /*
> + * It's an update; should we keep it? If the
> transaction is known
> + * aborted then it's okay to ignore it, otherwise not.
> (Note this
> + * is ju
Andres Freund writes:
> Unfortunately I find that too ugly. Adding a flag in the procarray
> because of an Assert() in a lowlevel routine? That's overkill.
If this flag doesn't need to be visible to other backends, it absolutely
does not belong in the procarray.
regards,
Hi,
On 2013-12-12 18:39:43 -0300, Alvaro Herrera wrote:
> Alvaro Herrera wrote:
> > One last thing (I hope). It's not real easy to disable this check,
> > because it actually lives in GetNewMultiXactId. It would uglify the API
> > a lot if we were to pass a flag down two layers of routines; and
Alvaro Herrera wrote:
> One last thing (I hope). It's not real easy to disable this check,
> because it actually lives in GetNewMultiXactId. It would uglify the API
> a lot if we were to pass a flag down two layers of routines; and moving
> it to higher-level routines doesn't seem all that appro
Andres Freund wrote:
> On 2013-12-11 22:08:41 -0300, Alvaro Herrera wrote:
> > Andres Freund wrote:
> > > I worry that this MultiXactIdSetOldestMember() will be problematic in
> > > longrunning vacuums like a anti-wraparound vacuum of a huge
> > > table. There's no real need to set MultiXactIdSetO
Andres Freund wrote:
> On 2013-12-11 22:08:41 -0300, Alvaro Herrera wrote:
> > Andres Freund wrote:
> > > I worry that all these multixact accesses will create huge performance
> > > problems due to the inefficiency of the multixactid cache. If you scan a
> > > huge table there very well might be
On 2013-12-11 22:08:41 -0300, Alvaro Herrera wrote:
> Andres Freund wrote:
> > On 2013-12-11 14:00:05 -0300, Alvaro Herrera wrote:
> > > Andres Freund wrote:
> > > > On 2013-12-09 19:14:58 -0300, Alvaro Herrera wrote:
> > > > > ! if (ISUPDATE_from_mxstatus(members[i].status) &&
> > > >
Andres Freund wrote:
> On 2013-12-11 14:00:05 -0300, Alvaro Herrera wrote:
> > Andres Freund wrote:
> > > On 2013-12-09 19:14:58 -0300, Alvaro Herrera wrote:
> > > > Andres mentioned the idea of sharing some code between
> > > > heap_prepare_freeze_tuple and heap_tuple_needs_freeze, but I haven't
On 2013-12-11 14:00:05 -0300, Alvaro Herrera wrote:
> Andres Freund wrote:
> > On 2013-12-09 19:14:58 -0300, Alvaro Herrera wrote:
> > I don't so much have a problem with exporting CreateMultiXactId(), just
> > with exporting it under its current name. It's already quirky to have
> > both MultiXact
On 2013-12-09 19:14:58 -0300, Alvaro Herrera wrote:
> Here's a revamped version of this patch. One thing I didn't do here is
> revert the exporting of CreateMultiXactId, but I don't see any way to
> avoid that.
I don't so much have a problem with exporting CreateMultiXactId(), just
with exporting
Here's a revamped version of this patch. One thing I didn't do here is
revert the exporting of CreateMultiXactId, but I don't see any way to
avoid that.
Andres mentioned the idea of sharing some code between
heap_prepare_freeze_tuple and heap_tuple_needs_freeze, but I haven't
explored that.
--
Hi,
On 2013-12-05 10:42:35 -0300, Alvaro Herrera wrote:
> I intend to apply these two to 9.3 and master, and
> then apply your freeze fix on top (which I'm cleaning up a bit -- will
> resend later.)
I sure hope it get's cleaned up - it's an evening's hack, with a good
glass of wine ontop. Do you
Andres Freund wrote:
> On 2013-12-03 19:55:40 -0300, Alvaro Herrera wrote:
> > I added a new isolation spec to test this specific case, and noticed
> > something that seems curious to me when that test is run in REPEATABLE
> > READ mode: when the UPDATE is aborted, the concurrent FOR UPDATE gets a
On Wed, Dec 4, 2013 at 8:43 PM, Tom Lane wrote:
> Magnus Hagander writes:
> > On Tue, Dec 3, 2013 at 7:20 PM, Tom Lane wrote:
> >> I assume what would happen is the slave would PANIC upon seeing a WAL
> >> record code it didn't recognize.
>
> > I wonder if we should for the future have the STAR
Magnus Hagander writes:
> On Tue, Dec 3, 2013 at 7:20 PM, Tom Lane wrote:
>> I assume what would happen is the slave would PANIC upon seeing a WAL
>> record code it didn't recognize.
> I wonder if we should for the future have the START_REPLICATION command (or
> the IDENTIFY_SYSTEM would probabl
On Tue, Dec 3, 2013 at 7:20 PM, Tom Lane wrote:
> Magnus Hagander writes:
> > On Tue, Dec 3, 2013 at 7:11 PM, Tom Lane wrote:
> >> Maybe we should just bite the bullet and change the WAL format for
> >> heap_freeze (inventing an all-new record type, not repurposing the old
> >> one, and allowin
On 2013-12-03 19:55:40 -0300, Alvaro Herrera wrote:
> I added a new isolation spec to test this specific case, and noticed
> something that seems curious to me when that test is run in REPEATABLE
> READ mode: when the UPDATE is aborted, the concurrent FOR UPDATE gets a
> "can't serialize due to con
Alvaro Herrera wrote:
> Attached is a patch to fix it.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
*** a/src/backend/utils/time/tqual.c
--- b/src/backend/utils/time/tqual.c
***
*** 789,801 HeapTupleSatis
On 2013-12-03 15:46:09 -0500, Tom Lane wrote:
> Noah Misch writes:
> > I'd rather have an readily-verifiable fix that changes WAL format than a
> > tricky fix that avoids doing so. So, modulo not having seen the change, +1.
>
> Yeah, same here.
I am afraid it won't be *that* simple. We still nee
Noah Misch wrote:
> On Tue, Dec 03, 2013 at 04:08:23PM +0100, Andres Freund wrote:
> > > (For clarity, the other problem demonstrated by the test spec is also a
> > > 9.3.2
> > > regression.)
> >
> > Yea, I just don't see why yet... Looking now.
>
> Sorry, my original report was rather terse.
Alvaro Herrera writes:
> Tom Lane wrote:
>> After some discussion, the core committee has concluded that we should go
>> ahead with the already-wrapped releases. 9.2.6 and below are good anyway,
>> and despite this issue 9.3.2 is an improvement over 9.3.1. We'll plan to
>> do a 9.3.3 as soon as
Tom Lane wrote:
> After some discussion, the core committee has concluded that we should go
> ahead with the already-wrapped releases. 9.2.6 and below are good anyway,
> and despite this issue 9.3.2 is an improvement over 9.3.1. We'll plan to
> do a 9.3.3 as soon as the multixact situation can b
Noah Misch writes:
> On Tue, Dec 03, 2013 at 07:26:38PM +0100, Andres Freund wrote:
>> On 2013-12-03 13:14:38 -0500, Noah Misch wrote:
>>> On Tue, Dec 03, 2013 at 04:37:58PM +0100, Andres Freund wrote:
I currently don't see fixing the errorneous freezing of lockers (not the
updater thoug
Andres Freund wrote:
> On 2013-12-03 13:49:49 -0500, Noah Misch wrote:
> > On Tue, Dec 03, 2013 at 07:26:38PM +0100, Andres Freund wrote:
> > > On 2013-12-03 13:14:38 -0500, Noah Misch wrote:
> > > > Not fixing it at all is the real no-go. We'd take both of those
> > > > undesirables
> > > > befo
On 2013-12-03 15:40:44 -0300, Alvaro Herrera wrote:
> Andres Freund wrote:
>
> > I wondered about that myself. How would you suggest the format to look
> > like?
> > ISTM per tuple we'd need:
> >
> > * OffsetNumber off
> > * uint16 infomask
> > * TransactionId xmin
> > * TransactionId xmax
> >
>
On 2013-12-03 13:49:49 -0500, Noah Misch wrote:
> On Tue, Dec 03, 2013 at 07:26:38PM +0100, Andres Freund wrote:
> > On 2013-12-03 13:14:38 -0500, Noah Misch wrote:
> > > Not fixing it at all is the real no-go. We'd take both of those
> > > undesirables
> > > before just tolerating the lost locks
On Tue, Dec 03, 2013 at 07:26:38PM +0100, Andres Freund wrote:
> On 2013-12-03 13:14:38 -0500, Noah Misch wrote:
> > On Tue, Dec 03, 2013 at 04:37:58PM +0100, Andres Freund wrote:
> > > I currently don't see fixing the errorneous freezing of lockers (not the
> > > updater though) without changing t
Andres Freund wrote:
> I wondered about that myself. How would you suggest the format to look
> like?
> ISTM per tuple we'd need:
>
> * OffsetNumber off
> * uint16 infomask
> * TransactionId xmin
> * TransactionId xmax
>
> I don't see why we'd need infomask2, but so far being overly skimpy in
>
On 2013-12-03 13:11:13 -0500, Tom Lane wrote:
> Andres Freund writes:
> > Any idea how to cheat our way out of that one given the current way
> > heap_freeze_tuple() works (running on both primary and standby)? My only
> > idea was to MultiXactIdWait() if !InRecovery but that's extremly grotty.
>
Noah Misch wrote:
> > On 2013-12-03 10:29:54 -0500, Noah Misch wrote:
> > > Sorry, my original report was rather terse. I speak of the scenario
> > > exercised
> > > by the second permutation in that isolationtester spec. The multixact is
> > > later than VACUUM's cutoff_multi, so 9.3.1 does no
On 2013-12-03 13:14:38 -0500, Noah Misch wrote:
> On Tue, Dec 03, 2013 at 04:37:58PM +0100, Andres Freund wrote:
> > On 2013-12-03 10:29:54 -0500, Noah Misch wrote:
> > > Sorry, my original report was rather terse. I speak of the scenario
> > > exercised
> > > by the second permutation in that is
On Tue, Dec 3, 2013 at 7:20 PM, Tom Lane wrote:
> Magnus Hagander writes:
> > On Tue, Dec 3, 2013 at 7:11 PM, Tom Lane wrote:
> >> Maybe we should just bite the bullet and change the WAL format for
> >> heap_freeze (inventing an all-new record type, not repurposing the old
> >> one, and allowin
Magnus Hagander writes:
> On Tue, Dec 3, 2013 at 7:11 PM, Tom Lane wrote:
>> Maybe we should just bite the bullet and change the WAL format for
>> heap_freeze (inventing an all-new record type, not repurposing the old
>> one, and allowing WAL replay to continue to accept the old one). The
>> imp
Tom Lane wrote:
> Andres Freund writes:
> > Any idea how to cheat our way out of that one given the current way
> > heap_freeze_tuple() works (running on both primary and standby)? My only
> > idea was to MultiXactIdWait() if !InRecovery but that's extremly grotty.
> > We can't even realistically
On Tue, Dec 3, 2013 at 7:11 PM, Tom Lane wrote:
> Andres Freund writes:
> > Any idea how to cheat our way out of that one given the current way
> > heap_freeze_tuple() works (running on both primary and standby)? My only
> > idea was to MultiXactIdWait() if !InRecovery but that's extremly grotty
On Tue, Dec 03, 2013 at 04:37:58PM +0100, Andres Freund wrote:
> On 2013-12-03 10:29:54 -0500, Noah Misch wrote:
> > Sorry, my original report was rather terse. I speak of the scenario
> > exercised
> > by the second permutation in that isolationtester spec. The multixact is
> > later than VACUU
Andres Freund writes:
> Any idea how to cheat our way out of that one given the current way
> heap_freeze_tuple() works (running on both primary and standby)? My only
> idea was to MultiXactIdWait() if !InRecovery but that's extremly grotty.
> We can't even realistically create a new multixact wit
On 2013-12-03 12:22:33 -0500, Tom Lane wrote:
> Andres Freund writes:
> >> On 2013-12-03 09:48:23 -0500, Tom Lane wrote:
> >>> Is this bad enough that we need to re-wrap the release?
>
> > After looking, I think I am revising my opinion. The broken locking
> > behaviour (outside of freeze, which
Andres Freund writes:
>> On 2013-12-03 09:48:23 -0500, Tom Lane wrote:
>>> Is this bad enough that we need to re-wrap the release?
> After looking, I think I am revising my opinion. The broken locking
> behaviour (outside of freeze, which I don't see how we can fix in time),
> is actually bad.
>
Hi Alvaro, Noah,
On 2013-12-03 15:57:10 +0100, Andres Freund wrote:
> On 2013-12-03 09:48:23 -0500, Tom Lane wrote:
> > Andres Freund writes:
> > > On 2013-12-03 00:47:07 -0500, Noah Misch wrote:
> > >> The test spec additionally
> > >> covers a (probably-related) assertion failure, new in 9.3.2
Hi,
On 2013-12-03 10:29:54 -0500, Noah Misch wrote:
> On Tue, Dec 03, 2013 at 04:08:23PM +0100, Andres Freund wrote:
> > On 2013-12-03 09:16:18 -0500, Noah Misch wrote:
> > > On Tue, Dec 03, 2013 at 11:56:07AM +0100, Andres Freund wrote:
> > > > On 2013-12-03 00:47:07 -0500, Noah Misch wrote:
> >
On 2013-12-03 10:29:54 -0500, Noah Misch wrote:
> Sorry, my original report was rather terse. I speak of the scenario exercised
> by the second permutation in that isolationtester spec. The multixact is
> later than VACUUM's cutoff_multi, so 9.3.1 does not freeze it at all. 9.3.2
> does freeze i
On Tue, Dec 03, 2013 at 04:08:23PM +0100, Andres Freund wrote:
> On 2013-12-03 09:16:18 -0500, Noah Misch wrote:
> > On Tue, Dec 03, 2013 at 11:56:07AM +0100, Andres Freund wrote:
> > > On 2013-12-03 00:47:07 -0500, Noah Misch wrote:
> > > > On Sat, Nov 30, 2013 at 01:06:09AM +, Alvaro Herrera
On 2013-12-03 09:16:18 -0500, Noah Misch wrote:
> > > The test spec additionally
> > > covers a (probably-related) assertion failure, new in 9.3.2.
> >
> > Too bad it's too late to do anthing about it for 9.3.2. :(. At least the
> > last seems actually unrelated, I am not sure why it's 9.3.2
> > o
On 2013-12-03 09:16:18 -0500, Noah Misch wrote:
> On Tue, Dec 03, 2013 at 11:56:07AM +0100, Andres Freund wrote:
> > On 2013-12-03 00:47:07 -0500, Noah Misch wrote:
> > > On Sat, Nov 30, 2013 at 01:06:09AM +, Alvaro Herrera wrote:
> > Any idea how to cheat our way out of that one given the curr
On 2013-12-03 09:48:23 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-12-03 00:47:07 -0500, Noah Misch wrote:
> >> The test spec additionally
> >> covers a (probably-related) assertion failure, new in 9.3.2.
>
> > Too bad it's too late to do anthing about it for 9.3.2. :(. At least th
Andres Freund writes:
> On 2013-12-03 00:47:07 -0500, Noah Misch wrote:
>> The test spec additionally
>> covers a (probably-related) assertion failure, new in 9.3.2.
> Too bad it's too late to do anthing about it for 9.3.2. :(. At least the
> last seems actually unrelated, I am not sure why it's
On Tue, Dec 03, 2013 at 11:56:07AM +0100, Andres Freund wrote:
> On 2013-12-03 00:47:07 -0500, Noah Misch wrote:
> > On Sat, Nov 30, 2013 at 01:06:09AM +, Alvaro Herrera wrote:
> > > Fix a couple of bugs in MultiXactId freezing
> > >
> > > Both heap_freeze_tuple() and heap_tuple_needs_freeze()
On 2013-12-03 00:47:07 -0500, Noah Misch wrote:
> On Sat, Nov 30, 2013 at 01:06:09AM +, Alvaro Herrera wrote:
> > Fix a couple of bugs in MultiXactId freezing
> >
> > Both heap_freeze_tuple() and heap_tuple_needs_freeze() neglected to look
> > into a multixact to check the members against cuto
On Sat, Nov 30, 2013 at 01:06:09AM +, Alvaro Herrera wrote:
> Fix a couple of bugs in MultiXactId freezing
>
> Both heap_freeze_tuple() and heap_tuple_needs_freeze() neglected to look
> into a multixact to check the members against cutoff_xid.
> ! /*
> !
56 matches
Mail list logo
