Re: [HACKERS] [BUGS] BUG #5412: test case produced, possible race condition.

2010-04-14 Thread Kevin Grittner
Tom Lane wrote: > On second thought, since there's no need for a particularly > high-quality RNG here, we could just embed some brain-dead > one-liner implementation, which should behave the same everywhere. Sounds good to me. -Kevin -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Very ineffective plan with merge join

2010-04-15 Thread Kevin Grittner
Oleg Bartunov wrote: > Sorry for odd names, they were generated by popular accounting > engine in Russia. How much of that can you trim out and still see the problem? -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription

Re: [HACKERS] Very ineffective plan with merge join

2010-04-15 Thread Kevin Grittner
rt of _accrged7200 (in the slower plan) taking in 3.5 million rows and putting out 1 row? There's something there I'm not understanding. -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: [HACKERS] shared_buffers documentation

2010-04-19 Thread Kevin Grittner
e RAID controller flushed them from BBU cache, causing an overall reduction in disk writes. I have little doubt that *without* a good BBU cached controller a larger setting is better, but it's not universally true that bigger is better on this one. -Kevin -- Sent via pgsql-hackers mailing list

Re: [HACKERS] shared_buffers documentation

2010-04-19 Thread Kevin Grittner
do for production usage afterward. This has become part of my bag of tricks for bulk loads, but we still use a larger number after the load. Also, I haven't heard of any independent confirmation -- it could be a quirk of our hardware and configuration? Has anyone else benchmarked t

Re: [HACKERS] [DOCS] Streaming replication document improvements

2010-04-20 Thread Kevin Grittner
gular supply > of connections is maxed out. +1 -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: [HACKERS] [DOCS] Streaming replication document improvements

2010-04-20 Thread Kevin Grittner
g walsender > to non-superuser across the board, and would prefer not to > experiment with it at this stage of the release cycle. +1 -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: [HACKERS] should I post the patch as committed?

2010-04-20 Thread Kevin Grittner
Robert Haas wrote: > is it helpful to attach the patch-as-committed to the -hackers > email, or is it just duplicative of what's already available > elsewhere? I'm fine with using git.postgresql.org to see what was committed. -Kevin -- Sent via pgsql-hackers mailing

Re: recovery_connections cannot start (was Re: [HACKERS] master in standby mode croaks)

2010-04-23 Thread Kevin Grittner
ng WAL contents to the transport mechanism. -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: recovery_connections cannot start (was Re: [HACKERS] master in standby mode croaks)

2010-04-23 Thread Kevin Grittner
7;t alert me to the problem sooner. For that I apologize. -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: recovery_connections cannot start (was Re: [HACKERS] master in standby mode croaks)

2010-04-23 Thread Kevin Grittner
tand that things slow down when you request > additional information in the WAL, and also clear that Hot Standby > requires slightly more info on top of that. It's also clear that > this has nothing at all to do with the delivery mechanism. Are we going to support running warm

Re: [HACKERS] Discarding the resulting rows

2010-04-26 Thread Kevin Grittner
to create an artificial "worst case" scenario for bounding purposes. Oh, and most serious database servers have 256MB or more of battery backed cache on the RAID controller; don't forget to deal with that somehow. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-h

Re: [HACKERS] Discarding the resulting rows

2010-04-26 Thread Kevin Grittner
Robert Haas wrote: > On Mon, Apr 26, 2010 at 3:36 PM, Kevin Grittner > wrote: >> "Murali M. Krishna" wrote: >> >>> Basically, I would like to discard the result rows after doing >>> all the work required to execute the query. >> >>

Re: [HACKERS] Differential backup

2010-04-27 Thread Kevin Grittner
his. Why? I must be missing something, because my feeling is that if you can't trust your OS to cover something like this, how can you trust any application *running* under that OS to do it? > Is this route worthwhile? I'm not seeing it, but I could be missing something. Can

Re: [HACKERS] Differential backup

2010-04-27 Thread Kevin Grittner
the middle. http://archives.postgresql.org/pgsql-admin/2009-07/msg00071.php I don't know how rare or common that 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

Re: [HACKERS] Differential backup

2010-04-27 Thread Kevin Grittner
with SR connections. Otherwise I'd do the same. It's pretty much mandated that we keep those copies. It'd be ideal if SR could reconstruct the WAL file segments on the receiving end, to avoid sending the data twice. Dare I dream? :-) -Kevin -- Sent via pgsql-hackers mailing list (pgs

Re: [HACKERS] Error handling for ShmemInitStruct and ShmemInitHash

2010-04-28 Thread Kevin Grittner
x27;em. +1 It would be low priority if the return value was currently being consistently checked for NULL; but since that's not the case we have to do something, and what you suggest sounds best, long term. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) T

Re: [HACKERS] Differential backup

2010-04-28 Thread Kevin Grittner
Hannu Krosing wrote: > I see the main value when doing pg_dump based backups Ah, now that makes more sense. -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: [HACKERS] Differential backup

2010-04-28 Thread Kevin Grittner
ntual purge) use cases. One of the nicest things about PostgreSQL is the availability of several easy and viable backup strategies, so that you can tailor one to fit your environment. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] explicit (void *) casts

2010-04-28 Thread Kevin Grittner
I'm wondering the reason that I see (void *) casts for function call parameters which are pointers to specific structures. Do some compilers generate warnings if these are omitted? It's hard to believe that the generated code would differ without them. -Kevin -- Sent via pgs

Re: [HACKERS] explicit (void *) casts

2010-04-28 Thread Kevin Grittner
Tom Lane wrote: > Any particular place where you think it's unnecessary? How about the 2nd (tag pointer) parameter for hash_search? -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpr

Re: pg_start_backup and pg_stop_backup Re: [HACKERS] Re: [COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct

2010-04-28 Thread Kevin Grittner
rchive than > waiting for traditional WAL file archiving... I'm interested in that, too. > I don't personally care about streaming replication replaying WAL > as it comes, or running queries in recovery... I'm with you that far, but I wouldn't want the sender to wai

Re: [HACKERS] Re: [COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct

2010-04-29 Thread Kevin Grittner
explicitly sets it to "auto", then it's up to them to understand the implications. IMO, If someone sets it to "on", they should get a highly visible failure if it can't run in that mode. -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: [HACKERS] Re: [COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct

2010-04-29 Thread Kevin Grittner
pay a performance penalty or take the risks of exercising complex new code paths because others need 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

Re: [HACKERS] s/recovery_connections/allow_standby_queries/, or something like that?

2010-04-29 Thread Kevin Grittner
e'd be sure to get many posts from confused users on this if we don't rename it. > The best idea I can come up with on the spur of the moment is > "allow_standby_queries", but I'm not sure that can't be improved > on. That seems clear and self-explanatory to

Re: [HACKERS] Re: [COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct

2010-04-29 Thread Kevin Grittner
Simon Riggs wrote: > I've asked for evidence that recovery is any slower as a result of > HS. Can you quantify the impact on the number of bytes written to WAL when switching from the archiving level to the hot standby level? -Kevin -- Sent via pgsql-hackers mailing list (pg

Re: [HACKERS] Re: [COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct

2010-04-29 Thread Kevin Grittner
Simon Riggs wrote: > 9.0 without HS enabled is fairly untested on the standby, so it's > not clear to me turning it off makes you any safer. I think you've just made the strongest possible case for not defaulting it on during beta testing. -Kevin -- Sent via pgsql-hack

Re: [HACKERS] Re: [COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct

2010-04-29 Thread Kevin Grittner
tra WAL would be very valuable, and it would be reassuring to know that it worked with a large number of clients without exposing any dire race conditions. -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: [HACKERS] missing file in git repo

2010-04-30 Thread Kevin Grittner
nce we grabbed our copy. Some of the fixes mentioned sound like they might possibly be related. -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: pg_start_backup and pg_stop_backup Re: [HACKERS] Re: [COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct

2010-04-30 Thread Kevin Grittner
Heikki Linnakangas wrote: > Yeah, min_wal_segments or something would make sense. Surely it would confuse people to see they have fewer than min_wal_segments WAL segments. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscript

Re: pg_start_backup and pg_stop_backup Re: [HACKERS] Re: [COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct

2010-04-30 Thread Kevin Grittner
Heikki Linnakangas wrote: > Kevin Grittner wrote: >> Surely it would confuse people to see they have fewer than >> min_wal_segments WAL segments. > > they wouldn't see that, that's the point of the setting. I was thinking, in particular, about beginners pokin

Re: pg_start_backup and pg_stop_backup Re: [HACKERS] Re: [COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct

2010-05-03 Thread Kevin Grittner
Simon Riggs wrote: > On Fri, 2010-04-30 at 13:41 -0500, Kevin Grittner wrote: >> Surely it would confuse people to see they have fewer than >> min_wal_segments WAL segments. > > That does sound like a reasonable argument, though it also applies > to wal_keep_segmen

Re: [HACKERS] Reg: SQL Query for Postgres 8.4.3

2010-05-04 Thread Kevin Grittner
row) SELECT substring(B'0001' from 4); substring --- 10001 (1 row) We have maintained nonstandard behavior in the past for compatibility reasons, so it's a fair question; however, I'm inclined toward the standard on this one. -Kevin -

Re: [HACKERS] Reg: SQL Query for Postgres 8.4.3

2010-05-04 Thread Kevin Grittner
Robert Haas wrote: > But I don't have strong feelings about it. Nor do I. Perhaps this question should be floated on -general? -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpr

Re: [HACKERS] Reg: SQL Query for Postgres 8.4.3

2010-05-04 Thread Kevin Grittner
w, you should be keeping up with the minor releases anyway. -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: [HACKERS] GUCs that need restart

2010-05-04 Thread Kevin Grittner
able, but it would be nice if..." basis. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] On a somewhat disappointing correspondence (was: max_standby_delay considered harmful)

2010-05-05 Thread Kevin Grittner
nstable software. Today you oppose > my promise to fix that. Why is it, we all wonder, is it that you > oppose everything I say and do? Robert strikes me as a top-notch project manager, and his comments struck me as totally in line with someone wearing that hat. -Kevin -- Sent via pgsq

Re: [HACKERS] SQLSTATE for Hot Standby cancellation

2010-05-06 Thread Kevin Grittner
really wrong with the transaction, you can probably just reschedule it" SQLSTATE values for the product. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] no universally correct setting for fsync

2010-05-07 Thread Kevin Grittner
hardware, and your | utility company (or your battery backup), you can consider | disabling fsync. Isn't this a little too rosy a picture to paint? -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresq

Re: [HACKERS] no universally correct setting for fsync

2010-05-07 Thread Kevin Grittner
sy, leading people to believe it's no big deal to turn it off. -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: [HACKERS] max_standby_delay considered harmful

2010-05-09 Thread Kevin Grittner
age which would conflict badly with a positive setting. Hopefully we can document this area better than we've historically done with, for example, fsync -- which has similar trade-offs, only with more dire consequences for bad user choices. -Kevin -- Sent via pgsql-hackers mailing list (pgs

Re: [HACKERS] max_standby_delay considered harmful

2010-05-10 Thread Kevin Grittner
at we're stuck with it. I know that's true of SQL code constructs, but postgresql.conf files? How about redirect_stderr, max_fsm_*, sort_mem, etc.? This argument seems tenuous. > Suggesting we will fix it later in beta is not a solution. I'm with you there, 100% -Kevin -- S

Re: [HACKERS] no universally correct setting for fsync

2010-05-10 Thread Kevin Grittner
the sectors making it or none of them making it for every single page. Does such an environment exist? -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: [HACKERS] no universally correct setting for fsync

2010-05-10 Thread Kevin Grittner
hat covers bulk loads to an empty or just-backed-up database and entirely redundant databases. Saying it should never be turned off would tend to make one wonder why we have the setting at all. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to yo

Re: [HACKERS] no universally correct setting for fsync

2010-05-10 Thread Kevin Grittner
r43m12.914s > sys 1m56.499s > -- activate fsync > time pg_restore -U postgres -d foodb -j 32 foo.psql > real177m0.121s > user42m54.581s > sys 2m0.452s Wow. In a situation where you save seven minutes (4%), it's hardly worth turning off. -Kevin --

Re: [HACKERS] Partitioning/inherited tables vs FKs

2010-05-11 Thread Kevin Grittner
patched code rolls back T2 with this message: T2> DELETE FROM a WHERE i = 1; ERROR: could not serialize access due to read/write dependencies among transactions HINT: The transaction might succeed if retried. Thanks for the example; I will it to the others. -Kevin -- Sent via p

Re: [HACKERS] SHARE locks vs. DELETE in SERIALIZABLE mode (Was: Partitioning/inherited tables vs FKs)

2010-05-11 Thread Kevin Grittner
PERFORM By the way, when adding these, I'm taking off the "FOR SHARE" or "FOR UPDATE" clauses; they're not needed with true serializable transactions. Otherwise, examples used as presented. -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: [HACKERS] Query execution plan from 8.3 -> 8.4

2010-05-12 Thread Kevin Grittner
age for ideas on other information (like hardware and the postgresql.conf file) which might help people better understand the problem: http://wiki.postgresql.org/wiki/SlowQueryQuestions -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your su

Re: [HACKERS] hot update doesn't work?

2010-05-12 Thread Kevin Grittner
to see the old row after this, and other transactions shouldn't see it either. I suspect that somewhere in the subtransaction or referential integrity areas there may be some issues with that, but it would be a clever optimization if it could be pulled off. -Kevin -- Sent via pgsql-hackers

Re: [HACKERS] primary/secondary/master/slave/standby

2010-05-12 Thread Kevin Grittner
so, that should be considered in our choice of terminology. -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: [HACKERS] Row-level Locks & SERIALIZABLE transactions, postgres vs. Oracle

2010-05-13 Thread Kevin Grittner
quot;Just Work" with the patch applied. There's a Wiki page and a public git repository related to this work, for anyone who is interested and not busy with release work. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscrip

Re: [HACKERS] Row-level Locks & SERIALIZABLE transactions, postgres vs. Oracle

2010-05-14 Thread Kevin Grittner
ll out the FOR UPDATE and FOR SHARE clauses, any redundant updates or denormalizations added just for concurrency issues, and all explicit locking -- and compare that under SERIALIZABLE to the original performance. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To

Re: [HACKERS] Row-level Locks & SERIALIZABLE transactions, postgres vs. Oracle

2010-05-14 Thread Kevin Grittner
Florian Pflug wrote: > On May 14, 2010, at 12:56 , Kevin Grittner wrote: >> I think that SIREAD locks will generally be cheaper than SELECT >> FOR UPDATE, since the former don't require any disk I/O and the >> latter do. > I can see how a single SIREAD lock can po

Re: [HACKERS] List traffic

2010-05-14 Thread Kevin Grittner
he burden of responding to the posts for those brave few who wade through them all. Personally, I'm not convince that merging current lists will solve more problems than it will create. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to you

Re: [HACKERS] Row-level Locks & SERIALIZABLE transactions, postgres vs. Oracle

2010-05-14 Thread Kevin Grittner
with possible backtracking through the log after that, which simplifies management of certain concurrency issues. Do they perhaps use an in-RAM lock table, pointing to the "base" location of the row for these SELECT FOR UPDATE locks? (Just guessing; I've never used Oracle, myself.) -

Re: [HACKERS] List traffic

2010-05-14 Thread Kevin Grittner
whether we could decrease inappropriate traffic on the -bugs list if we had a "feature request" list, for end users not prepared to discuss things at the level appropriate for -hackers, but who think that PostgreSQL should support some feature they don't see. -Kevin -- Sent via

Re: [HACKERS] List traffic

2010-05-14 Thread Kevin Grittner
good fit. Perhaps if the description of -general was changed to suggest it *was* a catch-all for posts which don't fit the other lists, things would improve. -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: [HACKERS] List traffic

2010-05-14 Thread Kevin Grittner
nably happen on -general. I think that's exactly backwards -- we shouldn't have any traffic on -general for issues which could reasonably happen in another list. You can always configure your email to combine lists into a common folder upon receipt. -Kevin -- Sent via pgsql-hackers

Re: [HACKERS] Parameter oddness; was HS/SR Assert server crash

2010-05-14 Thread Kevin Grittner
ut there were good reasons not to try to infer one setting from the other. -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: [HACKERS] Row-level Locks & SERIALIZABLE transactions, postgres vs. Oracle

2010-05-15 Thread Kevin Grittner
milar to PostgreSQL. Anything in particular you wanted me to notice about it besides that? (Of course another MySQL engine which doesn't provide very strong integrity guarantees isn't exciting to me as a technology in itself.) -Kevin -- Sent via pgsql-hackers mailing l

[HACKERS] ERROR: GIN indexes do not support whole-index scans

2010-05-20 Thread Kevin Flanagan
uery('french', 'rien du tout') AND lower(source_text) LIKE '%rien du tout%' AND target_lang_code='en' Why would adding "target_lang_code='en'" cause this error? Environment: PostgreSQL 8.4 on Windows (installed with one-click installer), default text search config used. Thanks in advance for any information. Kevin.

Re: [HACKERS] ERROR: GIN indexes do not support whole-index scans

2010-05-21 Thread Kevin Flanagan
I change the "='code'" terms to use LIKE, it works ... so it obviously can be done without adding another index. Still, those two columns both needed an index anyway, and everything then works just fine, so I shan't worry about that :) Thank you very much. Kevin. -Ori

Re: [HACKERS] Exposing the Xact commit order to the user

2010-05-24 Thread Kevin Grittner
ializable transactions are used; if they aren't there are no guarantees of transactional integrity no matter how you track commit sequence, unless it can be based on S2PL-type blocking locks. I'll have to leave that to someone else to sort out. -Kevin -- Sent via pgsql-hackers mail

Re: [HACKERS] [COMMITTERS] pgsql: Add new replication mode synchronous_commit = 'write'.

2012-04-13 Thread Kevin Grittner
Robert Haas wrote: > In my view, remote_write seems a lot more clear than write +1 I sure didn't understand it to mean remote_write when I read the subject line. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscripti

[HACKERS] extension allocating shared memory

2012-04-17 Thread Kevin Grittner
uot; I guess I could start a little daemon to run alongside PostgreSQL and talk to it through a pipe or TCP on localhost, but it seems cleaner to have it run within PostgreSQL if feasible. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to you

Re: [HACKERS] extension allocating shared memory

2012-04-17 Thread Kevin Grittner
Alvaro Herrera wrote: > Excerpts from Kevin Grittner's message: >> What is the best way for an extension to allocate shared memory >> and to access it from every backend? > RequestAddinShmemSpace Perfect! That's exactly what I wanted. I see that the pg_

Re: [HACKERS] Bug tracker tool we need

2012-04-18 Thread Kevin Grittner
it, while pretending to the moral high ground. Better to leave that aside and stick to remarks with actual meaning and content. In other words, declaring something to be anti-pattern is, IMO, an anti-pattern. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Regression tests for preload extension

2012-04-25 Thread Kevin Grittner
27;t see how to set shared_preload_libraries for the server startup. The existing contrib extensions which preload either seem to do something ad hoc or skip regression tests entirely, so I suspect that is my choice; but I figured I should ask. -Kevin -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Temporary tables under hot standby

2012-04-26 Thread Kevin Grittner
eally missing here is a > high-performance, log-based logical replication solution with good > core support. The GSoC xReader project is intended to be a major step toward that, by providing a way to translate the WAL stream to a series of notifications of logical events to clients which regi

Re: [HACKERS] default_transaction_isolation = serializable causes crash under Hot Standby

2012-04-27 Thread Kevin Grittner
? We didn't want to allow SERIALIZABLE to be set while still allowing read-only anomalies like this (assuming T3 was on the HS): http://wiki.postgresql.org/wiki/SSI#Deposit_Report -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: [HACKERS] default_transaction_isolation = serializable causes crash under Hot Standby

2012-04-27 Thread Kevin Grittner
#x27;s suggestion might be the least of the various evils. -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: [HACKERS] default_transaction_isolation = serializable causes crash under Hot Standby

2012-04-27 Thread Kevin Grittner
. I know I've fallen down on a couple other things which I meant to look at lately, but this one should be small enough to fit in between the brickbats the non-PostgreSQL world has been throwing at me lately. I'll take a shot at it sometime today, although it may be late. -Kevin --

Re: [HACKERS] smart shutdown at end of transaction (was: Default mode for shutdown)

2012-04-27 Thread Kevin Grittner
o do that. maybe?: --escalate-after=seconds -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Re: xReader, double-effort (was: Temporary tables under hot standby)

2012-04-27 Thread Kevin Grittner
e server. I think we need to know that much before we can get very far in discussion. -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: [HACKERS] Re: xReader, double-effort (was: Temporary tables under hot standby)

2012-04-27 Thread Kevin Grittner
the particulars of tasks and the dates may need adjustment based on the new work which is expected to appear before you start, but what's there now would be a helpful reference. -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: [HACKERS] xReader, double-effort

2012-04-27 Thread Kevin Grittner
nly switched over to working on *producing* it when he heard that no such thing was currently available. I think there's a lot of room to coordinate these efforts so that there *isn't* a waste of effort as long as communication is open enough. -Kevin -- Sent via pgsql-hacke

Re: [HACKERS] Re: xReader, double-effort (was: Temporary tables under hot standby)

2012-04-27 Thread Kevin Grittner
e clients, although that seems a lot more muddy to me at this point. If we can share enough code, there may be room for both approaches with minimal code duplication. -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: [HACKERS] default_transaction_isolation = serializable causes crash under Hot Standby

2012-04-27 Thread Kevin Grittner
> "Kevin Grittner" wrote: > Tom Lane wrote: > >> Yeah, it would definitely be nicer if BEGIN; SET TRANSACTION LEVEL >> would work too. Maybe the place to put the check is where we >> establish the transaction snapshot. > > That makes sense,

Re: [HACKERS] Re: xReader, double-effort (was: Temporary tables under hot standby)

2012-04-28 Thread Kevin Grittner
dless of whether the incoming stream is sync or async. What reliability problem do you see with this approach? -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: [HACKERS] default_transaction_isolation = serializable causes crash under Hot Standby

2012-04-29 Thread Kevin Grittner
Simon Riggs wrote: > Kevin Grittner wrote: > >> But if you set it in the postgresql.conf file, it's not pretty: >> >> kevin@kevin-desktop:~$ psql -p 5433 test >> psql: FATAL: can not create a serializable snapshot during >> recovery >> >> I

Re: [HACKERS] Re: xReader, double-effort (was: Temporary tables under hot standby)

2012-04-29 Thread Kevin Grittner
Tom Lane wrote: > "Kevin Grittner" writes: >> Well, the xReader approach (Aakash's GSoC project) is to serve as >> a proxy for a WAL stream going to a hot standby, to interpret each >> incoming WAL record by "cheating" and querying the HS before

Re: [HACKERS] default_transaction_isolation = serializable causes crash under Hot Standby

2012-04-29 Thread Kevin Grittner
27;s the best way > forwards. I guess I don't see much alternative. Did you want to code that (I seem to remember you saying that in an earlier post) or would you like me to do it? -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes t

Re: [HACKERS] Re: xReader, double-effort (was: Temporary tables under hot standby)

2012-04-29 Thread Kevin Grittner
you referring to this discussion or some effort at 2Q that hasn't yet been shared with the community? -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: [HACKERS] default_transaction_isolation = serializable causes crash under Hot Standby

2012-04-29 Thread Kevin Grittner
> Simon Riggs wrote: > On Sun, Apr 29, 2012 at 5:54 PM, Kevin Grittner > wrote: >> Simon Riggs wrote: >> >>> The only way default_transaction_isolation = serializable would >>> be acceptable when hot_standby = on is if we silently downgrade >>>

Re: [HACKERS] default_transaction_isolation = serializable causes crash under Hot Standby

2012-04-30 Thread Kevin Grittner
all resulting errors at the point where they are promoted to FATAL (before HS is really functional)? -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: [HACKERS] precision and scale functions for numeric

2012-04-30 Thread Kevin Grittner
::numeric % 1; ?column? -- 0.01 (1 row) -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: [HACKERS] Future In-Core Replication

2012-04-30 Thread Kevin Grittner
e in the database. In my experience a declarative definition of data distribution has always been sufficient, and certainly cleaner to deal with than imperative coding would be. YMMV. -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: [HACKERS] Patch: add conversion from pg_wchar to multibyte

2012-04-30 Thread Kevin Grittner
p five coolest things about PostgreSQL and should be promoted heavily. -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: [HACKERS] proposal: additional error fields

2012-05-01 Thread Kevin Grittner
Perhaps a better solution would be to allow some filtering of error SQLSTATE values to determine what action is taken? Changes would be more localized, and it would provide greater flexibility. The comments earlier in the thread about this helping translation don't make sense to me. In wh

Re: [HACKERS] Problem with multi-job pg_restore

2012-05-01 Thread Kevin Grittner
s probably dumping all that new data you just restored to ... somewhere. You'll need to review the crontab job (or maybe ps output) to figure out where. -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: [HACKERS] proposal: additional error fields

2012-05-01 Thread Kevin Grittner
l monitoring software. I don't see anything for the community here other than to discuss places where we might want to use a different SQLSTATE than we currently do. Or possibly hooks in the logging process, so monitors don't need to scan text. -Kevin -- Sent via pgsql-ha

Re: [HACKERS] proposal: additional error fields

2012-05-02 Thread Kevin Grittner
at start with '5', 'P', and 'X'. That "F0" class looks suspicious; are those really defined by standard or did we encroach on standard naming space with PostgreSQL-specific values? We also have PostgreSQL-specific values in standard classes where we use 

Re: [HACKERS] proposal: additional error fields

2012-05-02 Thread Kevin Grittner
Tom Lane wrote: > "Kevin Grittner" writes: >> That "F0" class looks suspicious; are those really defined by >> standard or did we encroach on standard naming space with >> PostgreSQL-specific values? > > I think we screwed up on that :-(. So we o

Re: [HACKERS] "unexpected EOF" messages

2012-05-03 Thread Kevin Grittner
expect to see '08006' (connection_failure). FWIW, there are also specific exceptions for rejecting a connection attempt, and for attempting to send something when no connection exists. We don't need to invent new mechanisms for categorizing messages; we just need to start consist

Re: [HACKERS] "unexpected EOF" messages

2012-05-03 Thread Kevin Grittner
be inclined toward something to identify distinct conditions within a SQLSTATE, rather than some overarching independent mechanism. -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: [HACKERS] "unexpected EOF" messages

2012-05-03 Thread Kevin Grittner
before successfully sending that result to the client? I notice there's a SQLSTATE 08007 (transaction_resolution_unknown), but I don't know whether that makes sense on the server side, or just on the client side. -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: [HACKERS] "unexpected EOF" messages

2012-05-03 Thread Kevin Grittner
lost_during_transaction 2DP02 connection_lost_during_commit_notification I'm less sure what makes sense if the connection fails while idle (not in transaction). If you don't like "Class 08 * Connection Exception" for that, I'm not quite sure where it belongs. -Kevin -- Sent via pgsql-hacke

Re: [HACKERS] Re: xReader, double-effort (was: Temporary tables under hot standby)

2012-05-03 Thread Kevin Grittner
f md5sum values on both sides so we can resend any corrupted data (or tell people to rescan). -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: [HACKERS] Gsoc2012 idea, tablesample

2012-05-10 Thread Kevin Grittner
be good to have multiple plans compete on costs, if possible. It would not surprise me at all if the typical break-even point between the two techniques was somewhere on the order of a 1% sample size, but one would hope we could get there on the basis of estimated costs rather than using arbitrary rules

Re: [HACKERS] Can pg_trgm handle non-alphanumeric characters?

2012-05-10 Thread Kevin Grittner
=# select similarity('smith8john', 'jon smith'); similarity 0.3125 (1 row) So making the proposed change unconditionally could indeed hurt current users of the technique. On the other hand, if there was fine-grained control of this, it might make trigrams

<    9   10   11   12   13   14   15   16   17   18   >