On 6 May 2011 15:00, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Geoghegan pe...@2ndquadrant.com writes:
On 5 May 2011 21:05, Tom Lane t...@sss.pgh.pa.us wrote:
The major problem I'm aware of for getting rid of periodic wakeups is
the need for child processes to notice when the postmaster has
second per iteration), until
the shmem-attached children that are liable to block us from starting
a new postmaster exit().
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers
, by some margin.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
implementation?
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
for the pipe
by using select()?
Alright, so it's reasonable to assume that all clients of the latch
code are happy to be invariably woken up on Postmaster death?
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
--
Sent via pgsql
While I agree with the need to not box ourselves into a corner on the
latch interface by making sweeping assumptions, isn't the fact that a
socket became readable or writable strictly an implementation detail?
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support
an anonymous pipe in the patch itself.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
issues a
breakpoint, that's exactly where the memory is being
corrupted/improperly dereferenced.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On 9 May 2011 11:19, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
In the child, spawn a thread
How exactly should I go about this? The one place in the code that I
knew to use multiple threads, pgbench, falls back on emulation with
fork() on some platforms.
--
Peter Geoghegan
to be the traditional wisdom. It seems sensible to me
that each process should look out for postmaster death itself though.
Tom described potential race conditions in looking at ps output...do
we really want to double the number of auxiliary processes in a single
release of Postgres?
--
Peter Geoghegan http
that this patch will be split into two separate patches: The
latch patch (complete with currently missing win32 implementation) and
the archiver patch. For now, I'd like to hear thoughts on how I've
implemented the extra latch functionality.
How should I be handling the EXEC_BACKEND case?
--
Peter
to detecting
postmaster death?
Fine by me.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
a second for the archiver to exit. All
processes exit.
Thoughts?
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index e71090f..b1d38f5 100644
should do that, and you don't think that WAL
writing should be throttled, what's the alternative?
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
to the type of
user that your environment has. Which lends itself to the idea that this
should be a Heroku Postgres thing, not a .Org wide thing.
If you look through the -general archives, or on stack overflow you'll
find ample evidence that it is a problem that lots of people have.
--
Peter
On Tue, Jun 11, 2013 at 11:42 PM, Craig Ringer cr...@2ndquadrant.com wrote:
Anyway, point being that PostgreSQL from Macports, Homebrew, and/or
EnterpriseDB's installer might be present ... and even in use.
Perhaps you should direct those users towards http://postgresapp.com
--
Peter
On Fri, Jun 14, 2013 at 7:23 AM, Andres Freund and...@2ndquadrant.com wrote:
3). All the others seem to inflict unneccesary pain for not all that
much gain.
+1. You might want to add a historical note about the name to the
pg_freespace documentation, though.
--
Peter Geoghegan
--
Sent via
I think you'll need to better describe what you mean here.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
LOCATION: _bt_check_unique, nbtinsert.c:398
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
were prevalent at a surprisingly late stage.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
.
That's something largely new.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
shared_buffers could be worth the
overhead, if only for the peace of mind of not relying on something
that is subtly broken.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
,
you'll surely also get a non-zero result with HEAP_LOCK_MASK, because
the latter flag has all the same bits set as the former (plus others,
obviously).
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
On Thu, Jun 27, 2013 at 12:07 AM, Peter Geoghegan p...@heroku.com wrote:
I'm not sure what the resolution of Alvaro's concern was, so I left the
flag reporting the same as the previous patch.
Alvaro's concern was that the new flags added (those added by the
foreign key locks patch) do
a
reasonable case where latency was hurt a bit, but throughput improved.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
that does all
of this for them?
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
quadratic complexity.
That doesn't ensure any such thing. It just makes it less likely.
But we have existing guards that also make that unlikely, so I'm not
sure what we'd be gaining.
+1
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
managed to iron out some
outstanding issues, you might as well look at the github page:
https://github.com/deafbybeheading/pg-quilter
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
for this kind of rhetoric. It helps no one.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
bits.
Alvaro?
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
, and one of the others when
only one of them is set. But I don't have a strong opinion about this,
and since Tom disagrees with me, feel free to exercise your own (Jeff's)
judgement.
I'm inclined to agree with you here, but I suppose it isn't all that important.
--
Peter Geoghegan
--
Sent via
, that's a more subtle problem than the one I'm
proposing to solve, but I still see this as a modest improvement.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
, I'm not a likely
candidate for that task.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
, I suppose that since the number of people that
use windows as an everyday development machine is probably zero, we
could reasonably forgo doing anything on that platform.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
=488d70ab46311386801c10691196ec8d755f2283
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Jul 8, 2013 at 11:33 PM, Andres Freund and...@2ndquadrant.com wrote:
That's for outer joins tho.
Oh, right - I spoke too soon. Looks like I missed the whole discussion
on inner join removal.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
something to do
with the Han unification controversy? I don't know terribly much about
this, so apologies if that's just wrong.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
PostgreSQL's large Japanese user-base about the lack
of UTF-16 support as suggesting that that isn't considered to be a
compelling feature in the CJK realm.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
completely
backwards from the actual work ratio. If all I'm getting out of something
is credit, I'd at least like it to be an appropriate amount of it.
FWIW, I think that's a reasonable request.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
involved - I essentially re-rewrote
AllocSetStats() in weirdly C-like Python.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
.
What settings did you have in mind? Which ones ought to be only be
settable in config files in your estimation?
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
because the
bytes you sent aren't what you think the are when rendered as UTF-8.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
that pgAdmin introduces, for example by using locking and
atomic renames.
+1
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
? I suppose that the cost of the random I/O involved would
probably dominate just as with compress_backup_block = off. That said,
you've used an SSD here, so perhaps not.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
expensive that the additional cost of decompressing
the FPIs looked insignificant in comparison. If that was the case, the
increase in recovery time would be modest.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
--
Peter Geoghegan
insert_on_dup.v1.2013_08_30.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Aug 30, 2013 at 3:40 PM, Josh Berkus j...@agliodbs.com wrote:
Does this work with multiple VALUES rows?
Yes.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
not conflict
with _SHARED but conflicts with _EXCLUSIVE.
I'll ponder it further. There are probably a number of options.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
/postgres/postgres/blob/REL9_3_STABLE/src/backend/access/nbtree/nbtinsert.c#L556
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sat, Aug 31, 2013 at 7:38 PM, Peter Geoghegan p...@heroku.com wrote:
Imo that solution is fairly elegant because it doesn't cause any heap
bloat, and it causes the same amount of index bloat
insert-into-heap-first type of solutions cause.
I don't think that's a reasonable comparison
On Sat, Aug 31, 2013 at 7:53 PM, Peter Geoghegan p...@heroku.com wrote:
With a table with many unique indexes and many reasons to decide
to reject a tuple proposed for insertion by INSERT...ON DUPLICATE KEY
IGNORE, it isn't hard to imagine them all becoming heavily bloated
very quickly
On Sun, Sep 1, 2013 at 11:38 PM, Peter Eisentraut pete...@gmx.net wrote:
../../preproc/ecpg --regression -I./../../include -o insupd.c -I. insupd.pgc
insupd.pgc:22: ERROR: syntax error at or near into
make[3]: *** [insupd.c] Error 3
I'll work on fixing it then. Thanks.
--
Peter Geoghegan
be enough, though.
My preferred solution is to actually provide a variant to lock the
rows implicated in the would-be unique constraint violation. Obviously
that's a harder problem to solve.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
really
want to do it?
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
I had in mind.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
value when the rows were locked). So while I think what I've done here
is probably workable for the ON DUPLICATE KEY IGNORE case, perhaps I'm
being short-sighted in focusing on that. I'm surprised Andres didn't
call me out on this himself, actually.
--
Peter Geoghegan
--
Sent via pgsql-hackers
On Tue, Sep 3, 2013 at 2:11 AM, Peter Geoghegan p...@heroku.com wrote:
and it would be totally unacceptable if that meant that lots of people
blocked on the page lock that an upserter held while it tried to
acquire locks on tuples
By which I mean: it seems shaky that I'd then be assuming
On Tue, Sep 3, 2013 at 9:23 AM, Josh Berkus j...@agliodbs.com wrote:
So it should remain a setting.
Sure. I wasn't suggesting deprecating it or anything.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
don't want to
throw out an old IGNORE value locking mechanism and invent a whole new
one for upserting a little bit down the line.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
that. Actually, I'm pretty surprised
that you haven't been the one insisting that I add a row locking
component from quite early on for exactly these reasons.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
for that
being valid is that CommandIds don't play any role outside of their own
transaction.
Right. It seems like this should probably be noted in the
documentation under 5.4. System Columns -- I just realized that it
isn't.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers
. I was a little puzzled by the problem
there. I'll return to it in a while, or perhaps someone else can
propose a solution.
Thoughts?
--
Peter Geoghegan
insert_on_dup.v2.2013_09_08.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers
.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Sep 9, 2013 at 6:05 PM, Peter Eisentraut pete...@gmx.net wrote:
It is automated.
Oh, yeah. I see that the maintainer-check target does that. I should
probably get into the habit of using targets other than
check/installcheck, as you recently demonstrated.
--
Peter Geoghegan
--
Sent
On Sun, Sep 8, 2013 at 10:21 PM, Peter Geoghegan p...@heroku.com wrote:
This necessitated inventing entirely new LWLock semantics around
weakening (from exclusive to shared) and strengthening (from
shared to exclusive) of locks already held. Of course, as you'd
expect, there are some tricky
the transaction
abort on a duplicate, since that already happens after toasting has
done its work with regular insertion.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
at the end of heap_insert, and the buffer is pinned and locked
very close to the start.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Sep 13, 2013 at 12:14 PM, Stephen Frost sfr...@snowman.net wrote:
It was my first concern regarding this patch.
It was my first concern too.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
to drive discussion? That's how the most important features get
implemented around here.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
it's going to get that from the last place
a heap tuple was inserted from.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
a transaction are, like, a couple of magnitude of a
difference.
Not really. I can see the advantage of having the deadlock be
detectable from a defensive-coding standpoint. But index locking
ordering inconsistencies, and the deadlocks they may cause are not
acceptable generally.
--
Peter Geoghegan
behind the successful but
not-yet-committed inserter.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
an actual representative notion of the expense of releasing and
re-acquiring the locks is too tightly coupled with how this is handled
and how frequently we need to restart. Plus there may well be other
issues in the same vein that we've yet to consider.
--
Peter Geoghegan
--
Sent via pgsql
-fingered it.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Sep 17, 2013 at 9:29 AM, Robert Haas robertmh...@gmail.com wrote:
On Sat, Sep 14, 2013 at 6:27 PM, Peter Geoghegan p...@heroku.com wrote:
Note that today there is no guarantee that the original waiter for a
duplicate-inserting xact to complete will be the first one to get a
second
of pressure to find a magic bullet
Thanks for the encouragement!
[1]
http://www.postgresql.org/message-id/AANLkTineR-rDFWENeddLg=grkt+epmhk2j9x0yqpi...@mail.gmail.com
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
/archives/151-Testing-PostgreSQL-patches-on-Windows-using-Amazon-EC2.html
I'm not sure how current it is - was this before or after we started
shipping our own WinFlex? Magnus?
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
necessarily
guarantee that it's impossible, even if it does (I guess) prevent
undesirable interactions with other buffer locking.
[1] http://www.postgresql.org/message-id/45e845c4.6030...@enterprisedb.com
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
On Fri, Sep 20, 2013 at 5:48 PM, Peter Geoghegan p...@heroku.com wrote:
ProcLockWakeup() only wakes as many waiters from the head of the queue
as can all be granted the lock without any conflicts. So I don't
think there is a race condition in that path.
Right, but what about
On Sat, Sep 21, 2013 at 7:22 PM, Peter Geoghegan p...@heroku.com wrote:
So because this isn't a tuple-level lock - it's really a value-level
lock - LockTuple() is not called by the btree code at all, and so
arbitration of who gets the lock is, as I've said, essentially
undefined.
Addendum
+epmhk2j9x0yqpi...@mail.gmail.com
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
.
Great, thanks. I cannot strongly emphasize enough how I think that's
the way to frame all of this. So much so that I almost managed to
resist answering the above points. :-)
There's other stuff than PG every now and then ;)
Hope you enjoyed the hike.
--
Peter Geoghegan
--
Sent via pgsql
On Mon, Sep 23, 2013 at 1:46 AM, Andres Freund and...@2ndquadrant.com wrote:
pg_receivelogical? Protest now or forever hold your peace.
I was thinking pg_receiveloglog, but that works just as well.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
On Mon, Sep 23, 2013 at 9:54 AM, Andres Freund and...@2ndquadrant.com wrote:
I still find it wierd/inconsistent to have:
* pg_receivexlog
* pg_recvlogical
binaries, even from the same source directory. Why once pg_recv and
once pg_receive?
+1
--
Peter Geoghegan
--
Sent via pgsql-hackers
really like to hear other opinions, though.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
serialization failures at read committed, except when you do
seems kind of weak to me. Especially since none of the usual suspects
say the same thing. That said, it sure would be convenient if it
wasn't true!
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
distinct name. On the
other hand, precisely because it's derivative of
receivelog/pg_receivexlog, it kind of makes sense to group them
together like that. So I don't know.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
understand the problem that way. I think it would be a
bit of a pity to give up the composability, which I liked, but it's
something that we'll have to consider. On the other hand, perhaps we
can get away with it - we simply don't know enough yet.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing
updated/deleted - otherwise we try again).
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
gone very far. I have
sincerely tried to see a way to make them work.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
in BufferAlloc() around the buffer partition lock.
That's unfortunate. I saw someone complain about what sounds like
exactly the same issue on Twitter yesterday:
https://twitter.com/Roguelazer/status/382706273927446528
I tried to engage with him, but was unsuccessful.
--
Peter Geoghegan
+3UKRp2e5s=t...@mail.gmail.com
[2]
http://www.postgresql.org/message-id/cam3swzquuuyycgksvytmcgqacvmkf1ui1uvfjekm15ykwzp...@mail.gmail.com
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
to.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
development that Robert first added
the barriers.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
appreciate, on a certain level that's just the
nature of the beast. This might sound stupid, but: you can say the
same thing about unique constraint violations! I do not believe that
this introduces any anomalies that read committed doesn't already
permit according to the standard.
--
Peter Geoghegan
to comment on this here, but ended up saying some stuff to
Robert about this in the main thread, so I should probably direct you
to that. You were probably right to start a new thread, because I
think we can usefully discuss this topic in parallel, but that's just
what ended up happening.
--
Peter
it just
obviously won't be a problem to begin with.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Sep 30, 2013 at 3:45 PM, Peter Geoghegan p...@heroku.com wrote:
If you think it's a bit odd that we lock every value while the user
essentially has one constraint in mind when writing their DML,
consider:
I should add to that list:
4) Locking all the values at once is necessary
601 - 700 of 3415 matches
Mail list logo
