Re: [HACKERS] INSERT...ON DUPLICATE KEY IGNORE

2013-09-02 Thread 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

Re: [HACKERS] [9.4] Make full_page_writes only settable on server start?

2013-09-02 Thread Peter Geoghegan
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

Re: [HACKERS] INSERT...ON DUPLICATE KEY IGNORE

2013-09-02 Thread Peter Geoghegan
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

Re: [HACKERS] INSERT...ON DUPLICATE KEY IGNORE

2013-09-03 Thread Peter Geoghegan
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

Re: [HACKERS] INSERT...ON DUPLICATE KEY IGNORE

2013-09-03 Thread Peter Geoghegan
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

Re: [HACKERS] [9.4] Make full_page_writes only settable on server start?

2013-09-03 Thread Peter Geoghegan
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

Re: [HACKERS] INSERT...ON DUPLICATE KEY IGNORE

2013-09-04 Thread Peter Geoghegan
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

Re: [HACKERS] INSERT...ON DUPLICATE KEY IGNORE

2013-09-04 Thread Peter Geoghegan
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

Re: [HACKERS] INSERT...ON DUPLICATE KEY IGNORE

2013-09-04 Thread Peter Geoghegan
. -- 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

Re: [HACKERS] lcr v5 - introduction of InvalidCommandId

2013-09-05 Thread Peter Geoghegan
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

[HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

2013-09-08 Thread Peter Geoghegan
. 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

Re: [HACKERS] New statistics for WAL buffer dirty writes

2013-09-09 Thread Peter Geoghegan
. -- 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

Re: [HACKERS] New statistics for WAL buffer dirty writes

2013-09-09 Thread Peter Geoghegan
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

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

2013-09-10 Thread Peter Geoghegan
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

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

2013-09-11 Thread Peter Geoghegan
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

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

2013-09-13 Thread Peter Geoghegan
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

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

2013-09-13 Thread Peter Geoghegan
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

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

2013-09-13 Thread Peter Geoghegan
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

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

2013-09-14 Thread Peter Geoghegan
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

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

2013-09-14 Thread Peter Geoghegan
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

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

2013-09-15 Thread 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

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

2013-09-17 Thread Peter Geoghegan
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

Re: [HACKERS] logical changeset generation v6

2013-09-20 Thread Peter Geoghegan
-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

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

2013-09-20 Thread Peter Geoghegan
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

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

2013-09-21 Thread Peter Geoghegan
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

Re: [HACKERS] VMs for Reviewers Available

2013-09-21 Thread Peter Geoghegan
/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

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

2013-09-21 Thread Peter Geoghegan
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

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

2013-09-21 Thread Peter Geoghegan
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

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

2013-09-21 Thread Peter Geoghegan
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

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

2013-09-22 Thread Peter Geoghegan
+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

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

2013-09-22 Thread Peter Geoghegan
. 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

Re: [HACKERS] logical changeset generation v6

2013-09-23 Thread Peter Geoghegan
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

Re: [HACKERS] logical changeset generation v6

2013-09-23 Thread Peter Geoghegan
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

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

2013-09-23 Thread Peter Geoghegan
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

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

2013-09-23 Thread Peter Geoghegan
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

Re: [HACKERS] logical changeset generation v6

2013-09-23 Thread Peter Geoghegan
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

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

2013-09-24 Thread Peter Geoghegan
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

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

2013-09-25 Thread Peter Geoghegan
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

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

2013-09-26 Thread Peter Geoghegan
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

Re: [HACKERS] Wait free LW_SHARED acquisition

2013-09-26 Thread Peter Geoghegan
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

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

2013-09-26 Thread 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

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

2013-09-26 Thread Peter Geoghegan
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

Re: [HACKERS] [PERFORM] Cpu usage 100% on slave. s_lock problem.

2013-09-27 Thread Peter Geoghegan
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

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

2013-09-27 Thread Peter Geoghegan
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

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE - visibility semantics

2013-09-27 Thread 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

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

2013-09-30 Thread Peter Geoghegan
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

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

2013-09-30 Thread Peter Geoghegan
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

Re: [HACKERS] pg_stat_statements: calls under-estimation propagation

2013-10-01 Thread Peter Geoghegan
thoughts about that. On reflection I think it was entirely to do with the testing of the patch. I don't think that the minimum value of pg_stat_statements has any real significance. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] relscan_details.h

2013-10-01 Thread Peter Geoghegan
to happen every once in a while, I'd suggest about every 5 years as the right interval. -- 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

Re: [HACKERS] record identical operator

2013-10-03 Thread Peter Geoghegan
grant Stephen that that's aesthetic. I also agree that an intermediate notion of equality isn't worth 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

Re: [HACKERS] Any reasons to not move pgstattuple to core?

2013-10-03 Thread Peter Geoghegan
? -- 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

Re: [HACKERS] Any reasons to not move pgstattuple to core?

2013-10-03 Thread Peter Geoghegan
that that kind of effort makes a lot of sense. -- 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

Re: [HACKERS] Any reasons to not move pgstattuple to core?

2013-10-04 Thread Peter Geoghegan
server. I was thinking more about different extension tiers, grouping them by quality/usefulness. -- 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

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

2013-10-09 Thread Peter Geoghegan
on Sunday. -- 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

Re: [HACKERS] Auto-tuning work_mem and maintenance_work_mem

2013-10-09 Thread Peter Geoghegan
just increase it as you need to, but you have to know about it in the first place, which is asking too much of many people tasked with semi-routine maintenance tasks like creating indexes. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes

Re: [HACKERS] Auto-tuning work_mem and maintenance_work_mem

2013-10-09 Thread Peter Geoghegan
shared_buffers sizings. After all, 128MB isn't the default in the same way 1MB is presently the default work_mem setting. It is certainly true that shared_buffers size is a poor proxy for an appropriate work_mem size, but does that really matter? -- Peter Geoghegan -- Sent via pgsql-hackers

Re: [HACKERS] Auto-tuning work_mem and maintenance_work_mem

2013-10-09 Thread Peter Geoghegan
. Now, you can attribute some of that to the I/O of temp files on EC2's ephemeral storage, and you'd probably have a point, but that certainly isn't the whole story there. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] Auto-tuning work_mem and maintenance_work_mem

2013-10-09 Thread Peter Geoghegan
people can be forgetful! -- 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

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

2013-10-09 Thread Peter Geoghegan
clients of MVCC snapshots? -- 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

Re: [HACKERS] Auto-tuning work_mem and maintenance_work_mem

2013-10-09 Thread Peter Geoghegan
-level questions like that to get inexperienced users started? The tool could even have a parameter that allows a packager to pass total system memory without bothering the user with that, and without bothering us with having to figure out a way to make that work correctly and portably. -- Peter

Re: [HACKERS] Auto-tuning work_mem and maintenance_work_mem

2013-10-09 Thread Peter Geoghegan
://rhaas.blogspot.com/2012/03/tuning-sharedbuffers-and-walbuffers.html -- 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

Re: [HACKERS] Auto-tuning work_mem and maintenance_work_mem

2013-10-09 Thread Peter Geoghegan
be allowed to be the enemy of the good. -- 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

Re: [HACKERS] Auto-tuning work_mem and maintenance_work_mem

2013-10-09 Thread Peter Geoghegan
Linux distro, installing MySQL will show a ncurses interface where the mysql password is set. We wouldn't need anything as fancy as that. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref

Re: [HACKERS] pg_stat_statements: calls under-estimation propagation

2013-10-10 Thread Peter Geoghegan
originally executed query. Why would you want to, though? There could be many actual plans whose costs are aggregated as one query. Seeing one of them is not necessarily useful at all, and could be misleading. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers

Re: [HACKERS] dynamic shared memory: wherein I am punished for good intentions

2013-10-10 Thread Peter Geoghegan
? Wasn't there already some reason why it was advantageous for FreeBSD to continue to use System V shared memory? -- 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

Re: [HACKERS] Auto-tuning work_mem and maintenance_work_mem

2013-10-10 Thread Peter Geoghegan
, but as you say that's wholly incidental. An equivalent C program would only be slightly more verbose. -- 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

Re: [HACKERS] Auto-tuning work_mem and maintenance_work_mem

2013-10-10 Thread Peter Geoghegan
-dependent code, yes. That's why trying to give the responsibility to a packager is compelling. -- 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

Re: [HACKERS] Auto-tuning work_mem and maintenance_work_mem

2013-10-10 Thread Peter Geoghegan
to re-tune maintenance_wokr_mem when they change the number of autovacuum workers. I'll code that up at some point, then. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

2013-10-11 Thread Peter Geoghegan
exclusively locked a tuple and it hasn't been updated/deleted, why shouldn't it be visible to your snapshot?). The onus is on the executor-level code to notice this should-be-invisibility for non-read-committed, probably immediately after returning from value locking. -- Peter Geoghegan -- Sent

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

2013-10-11 Thread Peter Geoghegan
that are fundamentally in tension with upsert working in the way people expect, and the way it is bound to actually work in numerous other systems. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql

Re: [HACKERS] removing old ports and architectures

2013-10-12 Thread Peter Geoghegan
couple of years, so there is plenty of it out there; I'd be slightly concerned that the proposed restrictions on MIPS would be onerous. Much of this is the kind of hardware that a person might plausibly want to run Postgres on. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

2013-10-13 Thread Peter Geoghegan
On Wed, Oct 9, 2013 at 1:11 PM, Peter Geoghegan p...@heroku.com wrote: Unfortunately, I have a very busy schedule in the month ahead, including travelling to Ireland and Japan, so I don't think I'm going to get the opportunity to work on this too much. I'll try and produce a V4 that formally

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

2013-10-15 Thread Peter Geoghegan
different tables? Or what if the relevant DML will only come in a later statement in the same transaction? -- 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

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

2013-10-15 Thread Peter Geoghegan
On Tue, Oct 15, 2013 at 8:07 AM, Peter Geoghegan p...@heroku.com wrote: Naturally we all want MERGE. It seems self-defeating to insist on something significantly harder that there is significant less demand for, though. I hasten to add: which is not to imply that you're insisting rather than

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

2013-10-15 Thread Peter Geoghegan
that I'm not clear on is how an update can be backed out of if the row is modified by another xact. As I think I've already illustrated, the row locking that takes place has to be kind of opportunistic. I'm sure you could do it, but it would probably be quite invasive. -- Peter Geoghegan -- Sent via

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

2013-10-15 Thread Peter Geoghegan
://www.postgresql.org/message-id/cam3swzthwrktvurf1awaih8qthgnmzafydcnw8qju7pqhk5...@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

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

2013-10-15 Thread Peter Geoghegan
On Tue, Oct 15, 2013 at 11:05 AM, Peter Geoghegan p...@heroku.com wrote: See the original e-mail in the thread for what I imagine idiomatic usage will look like. http://www.postgresql.org/message-id/cam3swzthwrktvurf1awaih8qthgnmzafydcnw8qju7pqhk5...@mail.gmail.com Note also

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

2013-10-15 Thread Peter Geoghegan
with exclusion constraints, which I guess you might have also meant, that's a much more difficult and much less compelling proposition, in my opinion. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

2013-10-15 Thread Peter Geoghegan
of things with it that you can't today. Or you can not use it at all. So that covers semantics, I'd say. As for implementation: I believe that the implementation is by far the most forward thinking (in terms of building infrastructure for a proper MERGE) of any proposal to date. -- Peter Geoghegan

Re: [HACKERS] logical changeset generation v6.2

2013-10-15 Thread Peter Geoghegan
WILL try to machine parse the output of whatever demo plugins we provide; so I think we should try hard to provide at least one such plugin that is designed to make that as easy as possible. I agree that this is important, but I wouldn't like to weigh it too heavily. -- Peter Geoghegan -- Sent

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

2013-10-15 Thread Peter Geoghegan
On Tue, Oct 15, 2013 at 2:25 PM, Andres Freund and...@2ndquadrant.com wrote: On 2013-10-15 10:53:35 -0700, Peter Geoghegan wrote: On Tue, Oct 15, 2013 at 10:29 AM, Andres Freund and...@2ndquadrant.com wrote: I think anything that only works by breaking visibility rules that way

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

2013-10-17 Thread Peter Geoghegan
(with the wCTE upsert pattern) help with that, by naming the constant inserted in the update too? It would be pretty simple to expose that, and far less grotty than naming a unique index in DML. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

2013-10-17 Thread Peter Geoghegan
constraints? MySQL certainly supports all that, for example. -- 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

Re: [HACKERS] removing old ports and architectures

2013-10-18 Thread Peter Geoghegan
a huge amount of extra work. Alpha is completely irrelevant, so I would not like to expend the tiniest effort on supporting it. If there is someone using a very much legacy architecture like this, I doubt that even they will appreciate the ability to upgrade to the latest major version. -- Peter

[HACKERS] autovacuum_work_mem

2013-10-19 Thread Peter Geoghegan
://www.postgresql.org/message-id/CABUevEzVrd36yeFzYBzad0=r09eqRqNoMwX8r=urikg9drf...@mail.gmail.com -- Peter Geoghegan autovacuum_work_mem.v1.2013_10_19.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

2013-10-21 Thread Peter Geoghegan
to encourage people to do frequently. My thoughts exactly. Perhaps it'd be useful to separately invalidate min/max times, without a full reset. But then you've introduced the possibility of the average time (total_time/calls) exceeding the max or being less than the min. -- Peter Geoghegan

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

2013-10-21 Thread Peter Geoghegan
. The standard deviation here would be expressed in units of milliseconds. Now, that could be misleading, in that like a mean average, it might mischaracterize the distribution. But it's still got to be a big improvement. I like the idea of a decay, but can't think of a principled scheme offhand. -- Peter

Re: [HACKERS] Failure while inserting parent tuple to B-tree is not fun

2013-10-22 Thread Peter Geoghegan
. -- 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

Re: [HACKERS] Failure while inserting parent tuple to B-tree is not fun

2013-10-22 Thread Peter Geoghegan
using page level bits (pd_flags), rather than the private state flag bits. Blame it on the lack of coffee, I suppose. -- 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

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

2013-10-23 Thread Peter Geoghegan
to boot, by radically reducing the amount of shared memory required. All of this might be a bit tricky, but I suspect it's well worth it. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

2013-10-23 Thread Peter Geoghegan
inclined to agree. Perhaps more importantly, like the mean, the stddev is the truth, even if it doesn't tell the full story. This data will always need to be interpreted by a reasonably well informed human. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

2013-10-23 Thread Peter Geoghegan
actually implement that. For example, this: https://wiki.postgresql.org/wiki/Aggregate_Histogram requires that a limit be specified ahead of time. Is there a principled way to increase or decrease this kind of limit over time, and have the new buckets contents spill into each other? -- Peter

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

2013-10-23 Thread Peter Geoghegan
memory? If the answer is an array of 32 int64s, one per bucket, -1 from me to this proposal. A huge advantage of pg_stat_statements today is that the overhead is actually fairly modest. I really want to preserve that property. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

2013-10-23 Thread Peter Geoghegan
when someone expresses an interest in seeing totals. -- 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

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

2013-10-23 Thread Peter Geoghegan
what pg_stat_statements can (optionally) track. Having said that, I am still pretty sensitive to bloating pg_stat_statements. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

2013-10-23 Thread Peter Geoghegan
that this is entirely a matter of how much memory we use out of how much is available, and I don't understand it that way. -- 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

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

2013-10-23 Thread Peter Geoghegan
On Wed, Oct 23, 2013 at 4:51 PM, Peter Geoghegan p...@heroku.com wrote: No, I'm not. I'm suggesting storing the query texts externally, in a file. They usually use 1024 bytes of shared memory per entry, regardless of how long the query text is. I should add that I think that that's about

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

2013-10-23 Thread Peter Geoghegan
in the Counters struct needs to be protected by a spinlock, I will be suspicious of the cost. The track_io_timing stuff is still protected, even when it's turned off. So I'm afraid that it isn't that simple. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

2013-10-24 Thread Peter Geoghegan
to burn, up to 40k. I've already hacked up a prototype patch. I've heard enough complaints about that to want to fix it once and for all. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org

Re: [HACKERS] OSX doesn't accept identical source/target for strcpy() anymore

2013-10-28 Thread Peter Geoghegan
Behavior Sanitizer, as described here: http://gcc.gnu.org/gcc-4.9/changes.html -- 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

<    5   6   7   8   9   10   11   12   13   14   >