Noah Misch wrote:
> On Thu, Jan 24, 2013 at 01:29:10PM -0500, Kevin Grittner wrote:
>> Noah Misch wrote:
>>> For the benefit of the archives, I note that we almost need not truncate an
>>> unlogged materialized view during crash recovery. MVs are refreshed in a
>>
f the all-in-one-file
approach justifies the extra code. If you ever want to view them
all in one file as of some moment in time, there is always:
cat * | less
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
this is here:
http://git.postgresql.org/gitweb?p=users/kgrittn/postgres.git;a=commitdiff;h=9425d7fa551a1433bdbec1de5cfb1bfa9f43da22
As always, any other tips or criticisms (or encouragement!) are
welcome.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chang
h this post:
http://archives.postgresql.org/message-id/28895.1290886...@sss.pgh.pa.us
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
er previous
discussions, I'll try integrating the "IDLE IN TRANSACTION
cancellation" from the current CF to provide feedback from a
practical use case. If Andres's patch works in that context, it
will allow SSI to provide a "guarantee of progress" even in the most
contrived a
ail with just the first, the first and
the second, or all three patches.
If you're not seeing the same thing there, I'll be happy to provide
the details.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.p
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
f updates so that vacuums can make space available for
re-use is more compelling to me, but still pretty iffy, since the
work-arounds aren't that hard to find.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
hardly
be an inconvenience to also run a CHECKPOINT.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Mario Weilguni wrote:
> Is it really up to the database to decide what queries are ok?
> It's the task of the developers to test their applikations.
We're talking about ad hoc queries here, entered directly through
psql or similar.
-Kevin
--
Sent via pgsql-hackers mai
SQL Server it was based on the Sybase code and
therefore worked the same way. I know they've made a lot of changes
in the last five years (including switching to MVCC and adding
snapshot isolation in addition to the already-existing serializable
isolation), so I don't know whether co
yet to be seen, though
> - currently there doesn't seem to be unanimous vote one way or the
> other.
I don't recall seeing any objections to your patch. Do you have a
reference to a post that argues against it?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@p
s, from one stable
branch. (Was it 7.4?) We'd probably want to merge that in as part
of any conversion effort.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Andres Freund wrote:
> On Tuesday 19 October 2010 16:18:29 Kevin Grittner wrote:
>> For SSI purposes, it would be highly desirable to be able to set
>> the SQLSTATE and message generated when the canceled transaction
>> terminates.
> Ok, I implemented that capabil
wrote:
> If possible can you provide glimpses of History.
http://en.wikipedia.org/wiki/Navigational_database
http://en.wikipedia.org/wiki/MARK_IV_%28software%29
I don't want to go back there, myself. YMMV.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgr
> Besides that I dont like the implementation very much, I think its
> generally a good idea...
OK. While browsing around, I'll try to think of an alternative
approach, but this is new territory for me -- I've been learning
about areas in the code at need so far
-Kevin
--
are consumed so quickly.
Currently, a VACUUM FREEZE after a bulk load collapses at least two
of those writes to one. With luck, some pages might still be dirty
in cache, and you can save two of the writes.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chan
Andres Freund wrote:
> On Thursday 02 December 2010 00:48:53 Kevin Grittner wrote:
>> Is there any provision for one backend to cause a *different*
>> backend which is idle in a transaction to terminate cleanly when
>> it attempts to process its next statement?
> You
itFest:
https://commitfest.postgresql.org/action/commitfest_view?id=7
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
flyusa2010 fly wrote:
> clog is for commit log (very unclear for me ...)
It is an important part of tracking tuple visibility.
You might want to start with this page:
http://wiki.postgresql.org/wiki/Hint_Bits
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.
ction if there are no non-read-only
transactions active when it acquires its snapshot, the work needed
within the SSI code is pretty trivial; it's all in adding the
DEFERRABLE word as a non-standard extension to SET TRANSACTION et al,
and finding a heavyweight lock to use.
Thoughts?
-Kevin
Tom Lane wrote:
> "Kevin Grittner" writes:
>> I'm reviving the discussion on the subject topic because I just
>> had an epiphany which makes it seem simple to implement. The
>> concept of this is that if you start a SERIALIZABLE READ ONLY
>> tran
"Kevin Grittner" wrote:
> Andres Freund wrote:
>> On Thursday 02 December 2010 00:48:53 Kevin Grittner wrote:
>>
>>> Is there any provision for one backend to cause a *different*
>>> backend which is idle in a transaction to terminate cleanly when
&g
#x27;re all passing.
Did you have something in particular in mind which I should check?
An example of code you think might break would be ideal, but
anything more concrete than the word "squishy" would be welcome.
Any thoughts on the original question about what to use as a
heavyweigh
ict that any snapshot is no larger than a fairly
small fixed portion plus sizeof(TransactionId) * MaxBackends? So,
for example, if you're configured for 100 connections, you'd be
limited to something under 1kB, maximum?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@pos
Tom Lane wrote:
> "Kevin Grittner" writes:
>> Surely you can predict that any snapshot is no larger than a fairly
>> small fixed portion plus sizeof(TransactionId) * MaxBackends?
>
> No. See subtransactions.
Subtransactions are included in snapshots?
-Ke
Tom Lane wrote:
> "Kevin Grittner" writes:
>> Tom Lane wrote:
>>> No. See subtransactions.
>
>> Subtransactions are included in snapshots?
>
> Sure, see GetSnapshotData(). You could avoid it by setting
> suboverflowed, but that comes at a
Florian Pflug wrote:
> On Dec5, 2010, at 16:11 , Kevin Grittner wrote:
>> The simple way to implement SERIALIZABLE READ ONLY DEFERRABLE
>> under SSI would be to have each non-read-only serializable
>> transaction acquire a heavyweight lock which can coexist with
>> ot
Heikki Linnakangas wrote:
> On 06.12.2010 22:53, Kevin Grittner wrote:
>> What would be the correct way for a process to put itself to
>> sleep, and for another process to later wake it up?
>
> See ProcWaitSignal/ProcSendSignal. Or the new 'latch' code.
Is there
iated with the above
on transaction completion
if (commit
and has written
and has conflict out
to xact committed before deferrable snapshot)
{
flag deferrable as inconsistent
unblock deferrable xact
}
else
if this is termination of last
action read write;
SET
test=# insert into asdf values (2);
INSERT 0 1
test=# commit;
COMMIT
I find that to be a huge POLA violation. I will happily prepare a
patch to fix this if there is agreement that we want it. I really
need READ ONLY *transactions*, not READ ONLY *moments* within
transactions
he
alternative would be to include snapmgr.h in guc.c, which seems less
appealing. Agreed? Other ideas?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ved;
but it passes all regression tests on both `make check` and `make
installcheck-world`. This includes a new regression test that an
attempt to change it after a query fails. I've poked at it with
various ad hoc tests, and it is behaving as expected in those.
I wasn't too confident
ertainly a bit awkward
It would be especially awkward should someone port their DB2
database to PostgreSQL without noticing the semantic difference, and
then find their data missing.
> so maybe we should reconsider.
+1 for choosing terminology without known conflicts with other
significant pr
ake sense to say that the top level transaction is READ WRITE but
the subtransaction is READ ONLY. And I see where I broke support
for that in the patch.
I can fix up the patch if to support it again if you like. (I think
it's just a matter of replacing a few lines that I replaced in the
or
Tom Lane wrote:
> "Kevin Grittner" writes:
> One thing to watch for is allowing subxact exit to restore the
> previous read-write state.
OK.
> BTW it looks like assign_XactIsoLevel emits a rather useless debug
> message in that case, so that code could stand some c
ing cannot be changed from READ ONLY to
READ WRITE.
I'm not clear whether #2 is OK or how to do it only at the start.
I haven't yet looked at the other issues you mentioned.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ndard allows
you to specify a more strict transaction isolation level within a
subtransaction without error, so this way of spelling the feature is
flirting with rather nonstandard behavior.
Is there maybe a better way to check this?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hac
sage and I only
see things that look like errors to me. If I did miss something,
I'll be happy to take another look if you can point me to the right
place.
-Kevin
*** a/src/backend/commands/variable.c
--- b/src/backend/commands/variable.c
***
*** 544,551 show_log_timezone(void)
ource != PGC_S_OVERRIDE)
> {
> check and report all the complaint-worthy cases;
> }
Done. Version 3 attached. I think I've covered all bases now.
-Kevin
*** a/src/backend/commands/variable.c
--- b/src/backend/commands/variable.c
***
**
"Kevin Grittner" wrote:
> Done. Version 3 attached.
My final tweaks didn't make it into that diff. Attached is 3a as a
patch over the version 3 patch.
-Kevin
*** a/src/backend/commands/variable.c
--- b/src/backend/commands/variable.c
*
Tom Lane wrote:
> If the constraint name is not specified, we should certainly use
> the existing index name, not randomly rename it.
+1
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/ma
confident it couldn't break anything.
It's an uphill battle to convince managers that it's safe to apply
minor upgrades with minimal testing. It doesn't take to many slips
for the boulder to roll all the way back to the bottom of that hill.
-Kevin
--
Sent via pgsql-hacke
it might affect something
outside that narrow use case. If that's not possible, then I'm more
comfortable putting it in a release that soon after it hits the
repository.
It's a judgment call, and you're clearly in the best position to
make it. You asked for thoughts, so I shar
Dan Ports wrote:
> On Tue, Dec 07, 2010 at 10:14:24AM -0600, Kevin Grittner wrote:
> The only thing I'm worried about here is how much risk of
> starvation remains. You'd need to wait until there are no running
> r/w transactions accessing overlapping data sets; for so
Dmitriy Igrishin wrote:
> Where is it written ?
http://wiki.postgresql.org/wiki/Guide_to_reporting_problems#Things_Not_To_Do
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
situations where we get a
business analyst to work with clerk of court staff to clean up
orphaned rows, it would be very slick to be able to run some
statement (like CHECK DATA) to see if the cleanup is complete and
successful and to flag that the constraint is now enforced.
So +1 on wha
orary table and doing the sequence Tom
suggests, but to eliminate the above error we had to do:
BEGIN;
ALTER TABLE "old_table" RENAME TO "dead_table";
ALTER TABLE "new_table" RENAME TO "old_table";
COMMIT;
-- Wait for all references to old OID to expi
as set to true. The property I care
about is whether tuples in one backend can be read by an transaction
in a different backend, which I assumed would not be true for
temporary tables. Which of the above would be appropriate for that
use?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-
Robert Haas wrote:
> Kevin Grittner's work is a whole different approach to this
> problem, and while that's obviously not fully debugged and
> committed yet either, it's often easier to design a new tool to
> solve a particular problem than to make an existing tool
g.html#VACUUM-FOR-STATISTICS
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
count(*) from newtable;` with and
without the patch, on a data set too big to fit in RAM.
> *) is there community interest in a full patch that fills in the
> missing details not implemented here?
I'm certainly curious to see real numbers.
-Kevin
--
Sent via pgsql-hackers mailin
How about?:
DML CTEs
DML-based CTEs
RETURNING-based CTEs
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
be on the critical path to a timely release -- at least if
that release will include SSI with the safe retry guarantee. (At
least when I'm planning for a release, I like to know such
things)
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
mmendation would be to rip it out, but a more explicit
comment would have saved me that time.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
*** ** wrote:
> Can you tell me what I doing wrong?
Did you configure --with_ossp_uuid? Did you get any errors or
warnings when you ran ./configure?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
h
*** ** wrote:
> 2010/12/27 Kevin Grittner
>> Did you configure --with_ossp_uuid? Did you get any errors or
>> warnings when you ran ./configure?
> yes. I configure with this flag.
> Configure ends successfull.
Odd. I don't have the required packages ins
; have overlapped.
These two are easy -- we can define a couple more flag bits for
active transactions to check when determining whether a new
rw-conflict has created a dangerous structure which must be rolled
back.
Any comments welcome. Barring surprises, I start coding on this
tom
ge concern
was that there would need to be at least an occasional scan of the
entire table to rebuild the distinct value information. Don't we
already require an occasional scan of the entire table for freezing
transaction IDs? Could this be part of any vacuum of the entire
table?
-Kevin
urrently have some sequential pass of the data, it seemed sane to
piggyback on it when possible. And maybe we should be considering
things like this when we weigh the pros and cons of rejiggering.
This issue of correlated values comes up pretty often
-Kevin
--
Sent via pgsql-hackers maili
tation can cause confusing for someone
trying to get started on hacking. It is an exception to the
otherwise excellent documentation of both the product and the code.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
re in the right order of magnitude -- a 7% error
would be a big improvement in most cases. Let's not lose track of
the fact that these estimates are useful even when they are not
dead-on accurate.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chang
docs have come up dry.
Barring that, any tips or warnings welcome.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
unning
transaction from 2^30 to 2^31. That hardly seems worth the
potential to destabilize a lot of critical code.
Does (2) sound good to anyone else? Other ideas? Does it sound
like I'm totally misunderstanding anything?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@pos
seems to me like it would get into O(N^2)
performance under extreme load, whereas this approach has a couple
performance plateaus at O(1) which will be, I think, the normal
case, and only goes to O(N) performance under extreme load.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@p
e shared
> memory predicate lock area.
Good point. We don't want that, for sure.
> Any chance of upgrading the lock to a relation lock, or killing
> the serializable transaction instead?
Absolutely. Good suggestion. Thanks!
-Kevin
--
Sent via pgsql-hackers mailing list (p
"Kevin Grittner" wrote:
>> Any chance of upgrading the lock to a relation lock, or killing
>> the serializable transaction instead?
>
> Absolutely. Good suggestion. Thanks!
I pushed a TODO SSI comment at the appropriate point with my ideas
on how best to fix
double that?
Beyond a certain point you have transaction ID wrap-around, so at
that point this would be the least of your troubles -- canceling
the old transaction might even be helpful. I thought that was at 2
billion, but Heikki was saying it's at 1 billion in an earlier post.
-Kevin
--
"Kevin Grittner" wrote:
> if a serializable transaction which is not flagged as read only
> remains open long enough for over a billion other transactions to
> commit
Maybe a clarification and example would be useful. We're talking
about going through a billion
Attached is a small patch to avoid putting an opaque structure into
the slru.h file and using it in an external function call where
external callers must always specify NULL.
-Kevin
*** a/src/backend/access/transam/clog.c
--- b/src/backend/access/transam/clog.c
***
*** 445,451
ctions yet, but that's what I do next. I would
love it if someone could review this commit and let me know whether
it looks generally sane.
http://git.postgresql.org/gitweb?p=users/kgrittn/postgres.git;a=commitdiff;h=00a0bc6c47c8173e82e5927d9b75fe570280860f
-Kevin
--
Sent via pgsql-hacke
wanted the searches to have a fast path out for
such cases.
> OldSerXidGetMinConflictCommitSeqNo() calls LWLockRelease twice.
That's because the function calls SimpleLruReadPage_ReadOnly:
"Control lock must NOT be held at entry, but will be held at exit."
That strikes me as
to be sure.
The 99.96% number is your certainty that you have a running server
with up-to-date data if only one machine is sync rep.
It's a matter of whether your shop needs five nines of availability
or the highest probability of not losing data. You get to choose.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ombat zone), but what is?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ncluding docs and incorporating
feedback from previous CFs and Heikki's comments on interim work.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
uld guarantee that an immediate retry of a
transaction rolled back with a serialization failure would not fail
again on conflicts with the same transaction(s). This would be a
very nice guarantee to be able to make.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
the predicate locking was more generally useful.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas wrote:
> Kevin Grittner wrote:
>> Before you decide to taunt me again, I guess I should point out a
>> few things here.
>
> Sorry, that was intended as good-natured humor, not taunting.
Oh, I took it that way. I guess my attempt at humor through an
obliqu
Greg Smith wrote:
> I could see shipping this with the automatic heavy LOCK TABLE in
> there.
How would you handle or document behavior in REPEATABLE READ
isolation? The lock doesn't do much good unless you acquire it
before you get your snapshot, right?
-Kevin
--
Sent via pg
ed around the rest of the code. That's 4346 lines and
1545 lines, respectively.
Now, these numbers are likely to change a little in the next few
days, but not much as a percentage outside the documentation.
Thoughts?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresq
benchmark software might need to be tweaked
to retry transactions which fail with SQLSTATE 40001, or at least
continue on with out counting those in TPS figures, since
applications using this feature will generally have frameworks which
automatically do retries for that SQLSTATE.
-Kevin
--
Sen
sure.)
Does that sound sane, or is something else needed here?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
REPEATABLE READ.
In an off-list exchange with me, David Fetter expressed opposition to
this, as a foot-gun. I'm not sure where anyone else stands on this.
Personally, I don't care a whole lot because it's trivial to add, so
that seems to leave the vote at 1 to 1. Anyone else ca
"Kevin Grittner" wrote:
> In going back through old emails to see what issues might have
> been raised but not yet addressed for the SSI patch, I found the
> subject issue described in a review by Jeff Davis here:
>
> http://archives.postgresql.org/pgsql-hackers/201
raised, I don't
think he's done testing it. (It's hard to test because you don't
hit the problem unless you have a page split or combine right at the
point where the hash table for predicate lock becomes full.) So,
anyway, there could possibly be some wet paint there.
-Kevin
Attached is a rebased roll-up of the 3 and 3a patches from last month.
-Kevin
--- a/src/backend/commands/variable.c
+++ b/src/backend/commands/variable.c
@@ -544,29 +544,72 @@ show_log_timezone(void)
/*
+ * SET TRANSACTION READ ONLY and SET TRANSACTION READ WRITE
+ *
+ * These should be
"Kevin Grittner" wrote:
> "Kevin Grittner" wrote:
>
>> In going back through old emails to see what issues might have
>> been raised but not yet addressed for the SSI patch, I found the
>> subject issue described in a review by Jeff Davis here:
robably be at least some
additional serialization failures. What other interactions or
problems do you see?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
urprising if we've squashed them all just yet. We've tried
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
thereby providing legacy behavior --
anomalies and all.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ple. If we're told that the transactions involved in
some scenario were all run at the SERIALIZABLE isolation level, we
would need to wonder how many *really* were, and how many were (as
David put it) at the NOTREALLYSERIALIZABLEBUTLABELEDASSERIALIZABLE
isolation level?
-Kevin
--
Sent via pg
ly. I'm just trying to be up-front about things so people
can make an informed decision.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
uld have waited that extra few
days before posting the patch
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
gt; serializable transaction isolation level.
Thanks for the report. I'll profile tat and see what can be done about
it.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ooking for
the spot to add that line of code.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Florian Pflug wrote:
> On Jan10, 2011, at 18:50 , Kevin Grittner wrote:
>> I'm trying not to panic here, but I haven't looked at 2PC before
>> yesterday and am just dipping into the code to support it, and
>> time is short. Can anyone give me a pointer to anythin
t I am starting to get concerned about whether this
particular area can be completed by the start of the CF. I might
run a few days over on 2PC support. Unless ... Dan? Could you look
into this while I chase down the issue Anssi raised?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql
h the one exception of the READ ONLY
DEFERRABLE style we invented to support long-running reports and
backups, and all blocking there is at the front -- once it's
running, it's going full speed ahead).
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
s"
Yeah, I was reluctant to reply to that survey because we rely on it
to the extent that it works now, but it would not break anything if
we dropped in a real SERIALIZABLE implementation. I fear that
choosing the "depend on it" answer would imply "don't want changes".
atable read;
Time: 233.946 ms
Time: 236.200 ms
Time: 236.414 ms
I guess the database just hadn't "warmed up" enough for the first
few tests
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
801 - 900 of 4332 matches
Mail list logo
