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
updater though)
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
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 several
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 avoiding
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 new Multi.
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 millions of
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
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
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 moving
Andres Freund and...@2ndquadrant.com 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.
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 just an
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-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 MultiXactIdCreate
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
explored
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)
!
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.
--
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
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
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
On Tue, Dec 3, 2013 at 7:20 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Tue, Dec 3, 2013 at 7:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Maybe we should just bite the bullet and change the WAL format for
heap_freeze (inventing an all-new record
Magnus Hagander mag...@hagander.net writes:
On Tue, Dec 3, 2013 at 7:20 PM, Tom Lane t...@sss.pgh.pa.us 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
On Wed, Dec 4, 2013 at 8:43 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Tue, Dec 3, 2013 at 7:20 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I assume what would happen is the slave would PANIC upon seeing a WAL
record code it didn't recognize.
I
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 cutoff_xid.
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() neglected
Andres Freund and...@2ndquadrant.com 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
On 2013-12-03 09:48:23 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com 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. :(.
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 current way
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
only. Alvaro,
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 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 it
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 Sat,
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 and...@2ndquadrant.com writes:
On 2013-12-03 00:47:07 -0500, Noah Misch wrote:
The test spec additionally
covers a (probably-related) assertion failure, new
Andres Freund and...@2ndquadrant.com 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
On 2013-12-03 12:22:33 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com 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
Andres Freund and...@2ndquadrant.com 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
On Tue, Dec 3, 2013 at 7:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andres Freund and...@2ndquadrant.com 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
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 VACUUM's
Tom Lane wrote:
Andres Freund and...@2ndquadrant.com 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
Magnus Hagander mag...@hagander.net writes:
On Tue, Dec 3, 2013 at 7:11 PM, Tom Lane t...@sss.pgh.pa.us 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
On Tue, Dec 3, 2013 at 7:20 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Tue, Dec 3, 2013 at 7:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Maybe we should just bite the bullet and change the WAL format for
heap_freeze (inventing an all-new record
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
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
On 2013-12-03 13:11:13 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com 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
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
that place
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 the wal
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 in 9.3.
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
I don't see why
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
before just
Noah Misch n...@leadboat.com 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
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 be
Alvaro Herrera alvhe...@2ndquadrant.com 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
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. I speak of the
On 2013-12-03 15:46:09 -0500, Tom Lane wrote:
Noah Misch n...@leadboat.com 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.
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
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
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
