Re: [PATCHES] [HACKERS] Infrastructure changes for recovery

2008-09-29 Thread Tom Lane
are pretty daunting. We don't really want slaves doing that while they're in catchup mode. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] [HACKERS] Infrastructure changes for recovery

2008-09-29 Thread Tom Lane
the crash, but not too much further because we already know the whole WAL file is available. Or is that the same thing you were saying? The detail about using the end address seems fairly critical, and you didn't mention it... regards, tom lane -- Sent via pgsql-patches

Re: [PATCHES] [HACKERS] Infrastructure changes for recovery

2008-09-29 Thread Tom Lane
Simon Riggs [EMAIL PROTECTED] writes: On Mon, 2008-09-29 at 10:13 -0400, Tom Lane wrote: ... If we crash and restart, we'll have to get to the end of this file before we start letting backends in; which might be further than we actually got before the crash, but not too much further because

Re: [PATCHES] [HACKERS] Infrastructure changes for recovery

2008-09-28 Thread Tom Lane
Simon Riggs [EMAIL PROTECTED] writes: On Thu, 2008-09-25 at 18:28 -0400, Tom Lane wrote: After reading this for awhile, I realized that there is a rather fundamental problem with it: it switches into consistent recovery mode as soon as it's read WAL beyond ControlFile-minRecoveryPoint

Re: [PATCHES] [HACKERS] get_relation_stats_hook()

2008-09-28 Thread Tom Lane
when time to free the tuple */ vardata-freefunc = heap_freetuple; return true; } and if you want to insert stats for expression indexes then there's a separate get_index_stats_hook for that. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches

Re: [PATCHES] [HACKERS] Infrastructure changes for recovery

2008-09-28 Thread Tom Lane
will be unreliable. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] [HACKERS] Infrastructure changes for recovery

2008-09-25 Thread Tom Lane
, but that will all have to be cleaned up before we dare allow any backends to run concurrently with recovery. btree's suppression of relcache invals for metapage updates will be a problem too. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make

Re: [PATCHES] hash index improving v3

2008-09-23 Thread Tom Lane
allocation parameter; it's a switchover threshold between two different behaviors. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] hash index improving v3

2008-09-23 Thread Tom Lane
of shared_buffers then it could still take awhile on installations with lots-o-buffers. The other side of that coin is that it's not clear this is really worth arguing about, much less exposing a separate parameter for. regards, tom lane -- Sent via pgsql-patches mailing

Re: [PATCHES] hash index improving v3

2008-09-22 Thread Tom Lane
Jonah H. Harris [EMAIL PROTECTED] writes: On Mon, Sep 22, 2008 at 11:25 PM, Alex Hunsaker [EMAIL PROTECTED] wrote: On Sun, Sep 14, 2008 at 8:16 PM, Tom Lane [EMAIL PROTECTED] wrote: I'm considering changing hashbuild to switch over at shared_buffers instead of effective_cache_size --- any

Re: [PATCHES] hash index improving v3

2008-09-22 Thread Tom Lane
a need to do that yet. In any case, tying it to maintenance_work_mem is certainly wrong. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] [HACKERS] Infrastructure changes for recovery

2008-09-18 Thread Tom Lane
in a query-answering slave. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] [HACKERS] Infrastructure changes for recovery

2008-09-18 Thread Tom Lane
Simon Riggs [EMAIL PROTECTED] writes: On Thu, 2008-09-18 at 09:06 -0400, Tom Lane wrote: Do we really need a checkpoint there at all? Timelines only change at shutdown checkpoints. Hmm. I *think* that that is just a debugging crosscheck rather than a critical property. But yeah, it would

Re: [PATCHES] [HACKERS] Infrastructure changes for recovery

2008-09-16 Thread Tom Lane
Simon Riggs [EMAIL PROTECTED] wrote: Testing takes a while on this, I probably won't complete it until Friday. So enclosed patch is for eyeballs only at this stage. What's the status on that patch? regards, tom lane -- Sent via pgsql-patches mailing list (pgsql

Re: [PATCHES] hash index improving v3

2008-09-14 Thread Tom Lane
of effective_cache_size --- any thoughts about that? regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] [PgFoundry] Unsigned Data Types [1 of 2]

2008-09-09 Thread Tom Lane
operation is broken. Well, the cause of that one would've been marking an operator as HASHES without providing a hash opclass to back it up. IIRC the test case involved ? That shouldn't even be marked HASHES anyway ... regards, tom lane -- Sent via pgsql-patches mailing

Re: [PATCHES] hash index improving v3

2008-09-08 Thread Tom Lane
. If we accept that patch, I'm okay with including this one too. Still hoping for some performance testing though. (Note that this one isn't going to affect performance, so no need to include it for that purpose.) regards, tom lane -- Sent via pgsql-patches mailing list

Re: [PATCHES] [HACKERS] Infrastructure changes for recovery

2008-09-08 Thread Tom Lane
much duplicated code now? I've kept the distinction between restartpoints and checkpoints in code, to avoid convoluted code. Hmm, I dunno, it seems like that might be a bad choice. Are you sure it's not cleaner to just use the regular checkpoint code? regards, tom lane

Re: [PATCHES] [HACKERS] Infrastructure changes for recovery

2008-09-08 Thread Tom Lane
Simon Riggs [EMAIL PROTECTED] writes: On Mon, 2008-09-08 at 13:34 -0400, Tom Lane wrote: Hmm, I dunno, it seems like that might be a bad choice. Are you sure it's not cleaner to just use the regular checkpoint code? When I tried to write it, it just looked to my eyes like every single line

Re: [PATCHES] [PgFoundry] Unsigned Data Types [1 of 2]

2008-09-07 Thread Tom Lane
Jaime Casanova [EMAIL PROTECTED] writes: contrib_regression=# select * from t1 where f1 35; ERROR: unsupported type: 16486 That obviously isn't supposed to happen. Where's it coming from exactly? regards, tom lane -- Sent via pgsql-patches mailing list (pgsql

Re: [PATCHES] [PgFoundry] Unsigned Data Types [1 of 2]

2008-09-07 Thread Tom Lane
Jaime Casanova [EMAIL PROTECTED] writes: On Sun, Sep 7, 2008 at 2:41 AM, Tom Lane [EMAIL PROTECTED] wrote: That obviously isn't supposed to happen. Where's it coming from exactly? convert_numeric_to_scalar() in src/backend/utils/adt/selfuncs.c the problem seems to be that we are asking

Re: [PATCHES] hash index improving v3

2008-09-06 Thread Tom Lane
catch. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] hash index improving v3

2008-09-06 Thread Tom Lane
flag for bitmap scans. For the convenience of anyone intending to test, here is an updated patch against CVS HEAD that incorporates Alex's fix. regards, tom lane binwQERo3PM5e.bin Description: hash-v5.patch.gz -- Sent via pgsql-patches mailing list (pgsql-patches

Re: [PATCHES] [PgFoundry] Unsigned Data Types [1 of 2]

2008-09-06 Thread Tom Lane
) regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] [HACKERS] TODO item: Implement Boyer-Moore searching (First time hacker)

2008-09-06 Thread Tom Lane
, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] [HACKERS] TODO item: Implement Boyer-Moore searching (First time hacker)

2008-09-06 Thread Tom Lane
, not just len1 or len2. This is (one less than) the maximum number of search loop consultations of the skip table that can happen, so it seems like a plausible number, and better than either length alone. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql

Re: [PATCHES] [PgFoundry] Unsigned Data Types [1 of 2]

2008-09-06 Thread Tom Lane
Jaime Casanova [EMAIL PROTECTED] writes: On Sat, Sep 6, 2008 at 3:57 PM, Tom Lane [EMAIL PROTECTED] wrote: postgres=# select -256::uint1; ERROR: uint1 out of range No, that's just because this is parsed as -(256::uint1) actually, i thought that case is right but the -255::uint1 returning

Re: [PATCHES] [PgFoundry] Unsigned Data Types [1 of 2]

2008-09-06 Thread Tom Lane
/static/sql-syntax-lexical.html#SQL-PRECEDENCE :: binds more tightly than -, and always has. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] [HACKERS] TODO item: Implement Boyer-Moore searching (First time hacker)

2008-09-05 Thread Tom Lane
David Rowley [EMAIL PROTECTED] writes: Tom Lane wrote: Hmm. B-M-H has worst case search speed O(M*N) (where M = length of pattern, N = length of search string); whereas full B-M is O(N). Maybe we should build the second table when M is large? I'll look into this. If it pays off for longer

Re: [PATCHES] hash index improving v3

2008-09-04 Thread Tom Lane
hit the heap a lot, but none of those will be wasted trips. So what we need for testing is a few different key values that hash to the same code. Not sure about an easy way to find such. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches

Re: [PATCHES] [HACKERS] TODO item: Implement Boyer-Moore searching (First time hacker)

2008-09-04 Thread Tom Lane
as well, since it seems to be considering only a single search. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] hash index improving v3

2008-09-04 Thread Tom Lane
Alex Hunsaker [EMAIL PROTECTED] writes: On Thu, Sep 4, 2008 at 7:45 PM, Tom Lane [EMAIL PROTECTED] wrote: So what we need for testing is a few different key values that hash to the same code. Not sure about an easy way to find such. Hrm, well I have not really looked at the hash algorithm

Re: [PATCHES] hash index improving v3

2008-09-04 Thread Tom Lane
Alex Hunsaker [EMAIL PROTECTED] writes: On Thu, Sep 4, 2008 at 7:13 PM, Tom Lane [EMAIL PROTECTED] wrote: * check that the queries actually use the indexes (not sure that the proposed switch settings ensure this, not to mention you didn't create the indexes) Well I was assuming I could just

Re: [PATCHES] WIP Join Removal

2008-09-02 Thread Tom Lane
index_update_stats and index_drop). There might be some situations where we need to force a relcache inval but don't currently do so --- constraint addition/removal for instance I'm not too sure about. But that would represent an easily fixable bug. regards, tom lane -- Sent via

Re: [PATCHES] WIP Join Removal

2008-09-02 Thread Tom Lane
the worry about generating other plans for the inner relation to be off the mark. You're not going to *use* any plan for the inner rel, so who cares what plans it has? regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your

Re: [PATCHES] WIP Join Removal

2008-09-02 Thread Tom Lane
= keeprel-baserestrictinfo; + } Huh? What in the world are you doing to joininfo here? This function should only be manipulating the path list. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your

Re: [PATCHES] WIP Join Removal

2008-09-02 Thread Tom Lane
cheaper startup cost, or present a useful sort order. So just present them as available alternatives and let add_path sort it out. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http

Re: [PATCHES] WIP Join Removal

2008-09-02 Thread Tom Lane
Simon Riggs [EMAIL PROTECTED] writes: On Tue, 2008-09-02 at 12:28 -0400, Tom Lane wrote: I haven't thought this through entirely, but wouldn't a partial index be okay if it's marked predOK? You might be right that the case is unlikely, but if it's only one extra line to support

Re: [PATCHES] [HACKERS] Hint Bits and Write I/O

2008-08-01 Thread Tom Lane
to? regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] pg_dump additional options for performance

2008-07-26 Thread Tom Lane
Simon Riggs [EMAIL PROTECTED] writes: On Fri, 2008-07-25 at 19:16 -0400, Tom Lane wrote: The key problem is that pg_restore is broken: The key capability here is being able to split the dump into multiple pieces. The equivalent capability on restore is *not* required, because once the dump

Re: [PATCHES] pg_dump additional options for performance

2008-07-26 Thread Tom Lane
before the data load steps, those steps would fail. We are relying on the default table privileges until we are done doing everything we need to do to the tables (and perhaps other objects, I'm not sure if there are any other comparable problems). regards, tom lane -- Sent

Re: [HACKERS][PATCHES] odd output in restore mode

2008-07-25 Thread Tom Lane
Simon Riggs [EMAIL PROTECTED] writes: On Fri, 2008-07-25 at 16:31 -0400, Tom Lane wrote: I thought the latest conclusion was that changing the behavior of pg_standby itself wouldn't address the problem anyway, and that what we need is just a docs patch recommending that people use safe copying

Re: [PATCHES] pg_dump additional options for performance

2008-07-25 Thread Tom Lane
. regards, tom lane binBy3Q4pEZad.bin Description: pg_dump_beforeafter.v7.patch.gz -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] pg_dump additional options for performance

2008-07-24 Thread Tom Lane
Simon Riggs [EMAIL PROTECTED] writes: [80k patch] Surely there is a whole lot of unintended noise in this patch? I certainly don't believe that you meant to change keywords.c for instance. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches

Re: [PATCHES] [HACKERS] WITH RECUSIVE patches 0723

2008-07-24 Thread Tom Lane
really can't accept a patch that is so poorly documented as to be unreviewable. Unreviewable also means it'll be unmaintainable going forward. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http

Re: [PATCHES] [HACKERS] WITH RECUSIVE patches 0723

2008-07-23 Thread Tom Lane
know I've not looked at it yet. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] pg_dump lock timeout

2008-07-21 Thread Tom Lane
daveg [EMAIL PROTECTED] writes: On Sun, Jul 20, 2008 at 02:50:50PM -0400, Tom Lane wrote: In most cases our policy has been that pg_dumpall should accept and pass through any pg_dump option for which it's sensible to do so. I did not make that happen but it seems it'd be a reasonable follow

Re: [PATCHES] pg_dump additional options for performance

2008-07-21 Thread Tom Lane
Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: Maybe invert the logic? --omit-pre-data --omit-data --omit-post-data Please, no. Negative logic seems likely to cause endless confusion. I think it might actually be less confusing, because with this approach, each switch has

Re: [PATCHES] pg_dump additional options for performance

2008-07-21 Thread Tom Lane
Stephen Frost [EMAIL PROTECTED] writes: * Tom Lane ([EMAIL PROTECTED]) wrote: As far as the documentation/definition aspect goes, I think it should just say the parts are * stuff needed before you can load the data * the data * stuff needed after loading the data Even that is a lie though

Re: [PATCHES] pg_dump additional options for performance

2008-07-21 Thread Tom Lane
? regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches

Re: [HACKERS] [PATCHES] WITH RECUSIVE patches 0717

2008-07-20 Thread Tom Lane
Tatsuo Ishii [EMAIL PROTECTED] writes: Thus I think we should avoid this kind of ORDER BY. Probably we should avoid LIMIT/OFFSET and FOR UPDATE as well. What of index-optimized SELECT max(...) ? regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches

Re: [PATCHES] pg_dump lock timeout

2008-07-20 Thread Tom Lane
lock-wait-timeout n won't work, although perhaps people used to -X might expect it to. Since we deprecate -X (and don't even document it anymore), I thought that making this work would be much more trouble than it's worth, but perhaps that's open to argument. regards, tom lane

Re: [PATCHES] pg_dump additional options for performance

2008-07-20 Thread Tom Lane
that Simon was using pre-schema and post-schema to name the first and third parts. I'd agree that this is confusing nomenclature: it looks like it's trying to say that the data is the schema, and the schema is not! How about pre-data and post-data? regards, tom lane

Re: [PATCHES] Is autovacuum doing a wraparound-avoiding VACUUM?

2008-07-17 Thread Tom Lane
, this is important for visibility into what's happening. The string isn't getting translated so I don't see any big downside to applying the patch in back branches. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your

Re: [PATCHES] variadic function support

2008-07-15 Thread Tom Lane
that could stand to mention variadic functions. I didn't do anything about the extra pg_proc column, but will start to work on that now. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http

Re: [PATCHES] variadic function support

2008-07-14 Thread Tom Lane
correctly with polymorphic functions. Are you intending to change this right now and resubmit, or is it work for later? regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org

Re: [PATCHES] variadic function support

2008-07-14 Thread Tom Lane
. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] page macros cleanup (ver 04)

2008-07-13 Thread Tom Lane
coding does not.) regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] page macros cleanup (ver 04)

2008-07-13 Thread Tom Lane
+ SizeOfPageHeaderData, but that's easily fixed. On balance it seems like hidden assumptions about alignment are a bigger risk than assumptions about that offset --- anyone want to argue the contrary? regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org

Re: [PATCHES] GIN improvements

2008-07-11 Thread Tom Lane
of fast_insert yet? It looked like a number of people commented on it already. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] [HACKERS] get_relation_stats_hook()

2008-07-10 Thread Tom Lane
Simon Riggs [EMAIL PROTECTED] writes: On Thu, 2008-06-26 at 12:50 -0400, Tom Lane wrote: I think you need to move up a level, and perhaps refactor some of the existing code to make it easier to inject made-up stats. I've looked at ways of refactoring this, but the hooks provided here

Re: [HACKERS] [PATCHES] GIN improvements

2008-07-08 Thread Tom Lane
Teodor Sigaev [EMAIL PROTECTED] writes: I looked this over and it looks good in general. May I think that patch passed review and commit it? I'd still like to take a look. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org

Re: [PATCHES] psql command setting

2008-07-05 Thread Tom Lane
. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] [HACKERS] Solaris ident authentication using unix domain sockets

2008-07-05 Thread Tom Lane
. If the Solaris folk feel that getupeercred() is insecure, they had better explain why their kernel is that broken. This is entirely unrelated to the known shortcomings of the ident IP protocol. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org

Re: [PATCHES] pgbench minor fixes

2008-07-05 Thread Tom Lane
every table in the database just so we get any tables being used for one set of tests. Actually your point is that the -i option wouldn't be used anyway with a custom script ... regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make

Re: [HACKERS] [PATCHES] Explain XML patch v2

2008-07-04 Thread Tom Lane
. Seems to me that anyone who wants this feature will probably also want the existing libxml-based features, so they'll be building with libxml anyway. So I'd not be in favor of expending any extra code on a roll-your-own solution. regards, tom lane -- Sent via pgsql

Re: [PATCHES] Sorting writes during checkpoint

2008-07-04 Thread Tom Lane
readily available from relfilenode, it would *not* be possible for a bufmgr plugin to look it up. bufmgr is much too low-level to be dependent on performing catalog lookups. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes

Re: [PATCHES] pg_dump lock timeout

2008-07-03 Thread Tom Lane
. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] [HACKERS] Solaris ident authentication using unix domain sockets

2008-07-03 Thread Tom Lane
behavioral changes on platforms that work fine now (consider possibility that getpeerucred is there but broken). regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql

Re: [PATCHES] Exposing keywords to clients

2008-07-03 Thread Tom Lane
2701 was claimed too. You need to use the unused_oids script to find unique free OIDs. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] Patch to change psql default banner v6

2008-07-02 Thread Tom Lane
... regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES][UPDATED] A GUC variable to replace PGBE_ACTIVITY_SIZE

2008-07-01 Thread Tom Lane
Heikki Linnakangas [EMAIL PROTECTED] writes: Tom Lane wrote: Huh? How could we be assigning to a slot that is not in use? Before the patch, we loop through the shared PgBackendStatus slots (there is MaxBackends of them), and issue a memcpy for each to copy it to our local slot. After

Re: [PATCHES] Explain XML patch

2008-06-27 Thread Tom Lane
for documentation? As in documentation patches are *required* if your patch adds or changes user-visible behavior? regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql

Re: [PATCHES] Explain XML patch

2008-06-27 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: Anybody mind if I update that to put more emphasis on the need for documentation? As in documentation patches are *required* if your patch adds or changes user-visible behavior? Sure, but I do documentation updates for non-English

Re: [PATCHES] Fix pg_ctl restart bug

2008-06-26 Thread Tom Lane
that people actually do use. As long as you're sure it doesn't do that, I see no downside to an attempted fix, even if it fails. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http

Re: [PATCHES] Fix pg_ctl restart bug

2008-06-25 Thread Tom Lane
, shouldn't this fix be back-patched? regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] [HACKERS] Patch for Prevent pg_dump/pg_restore from being affected by statement_timeout

2008-06-24 Thread Tom Lane
this ought to extend that logic rather than hack around changing the values of global variables. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] [HACKERS] Patch for Prevent pg_dump/pg_restore from being affected by statement_timeout

2008-06-24 Thread Tom Lane
that I see a good argument for making pg_dump deliberately fail, if that's what you're proposing. Maybe I'm just too old-school, but there simply is not any other higher priority for a database than safeguarding your data. regards, tom lane -- Sent via pgsql-patches

Re: [PATCHES] variadic function support

2008-06-24 Thread Tom Lane
Pavel Stehule [EMAIL PROTECTED] writes: Tom Lane wrote: Your point about the syntax is good though. It would be better if the syntax were like create function foo (a text, variadic b int[]) or maybe even better create function foo (a text, variadic b int) I don't see problem with your

Re: [PATCHES] variadic function support

2008-06-23 Thread Tom Lane
consider proper and full support? regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] variadic function support

2008-06-23 Thread Tom Lane
Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: What would you consider proper and full support? I don't know. But this doesn't feel like it. That's a fairly weak argument for rejecting a patch that provides a feature many people have asked for. I thought the patch was pretty

Re: [PATCHES] variadic function support

2008-06-23 Thread Tom Lane
foo (a text, variadic b int) since (a) this makes it much more obvious to the reader what the function might match, and (b) it leaves the door open for marking multiple parameters as variadic, if we can figure out what that means. regards, tom lane -- Sent via pgsql

Re: [PATCHES] Simplify formatting.c

2008-06-21 Thread Tom Lane
basis for functions operating on both text datums and C strings. (Perhaps what I should be asking is whether the performance of upper() and lower() is equally bad. Certainly all three should have comparable code, so maybe they all need refactoring.) regards, tom lane

Re: [PATCHES] Simplify formatting.c

2008-06-21 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: I'd say not. Can't we do some more refactoring and avoid so many useless conversions? Seems like str_initcap is the wrong primitive API --- the work ought to be done by a function that takes a char pointer and a length. That would

Re: [PATCHES] Rewrite sinval messaging to reduce contention

2008-06-19 Thread Tom Lane
results in a lot of unnecessary cache reloads, and every one of those requires taking AccessShareLock on one or more system catalogs in order to suck the data back in. So the reduction in LockMgr traffic is explained by not doing so many cache resets. regards, tom lane

[PATCHES] Rewrite sinval messaging to reduce contention

2008-06-18 Thread Tom Lane
at reducing the amount of LWLock processing. Comments? Does anyone have more realistic test cases for this problem, or want to fiddle with the tuning #defines in sinvaladt.c? regards, tom lane bin7h80XxstUn.bin Description: sinval-rewrite-1.patch.gz -- Sent via pgsql

Re: [PATCHES] Rewrite sinval messaging to reduce contention

2008-06-18 Thread Tom Lane
2388805 89142 LockMgr partition locks 8253142 177715 So I think this patch accomplishes the goal of making sinval not be a cause of contention. Patch version 2 attached. regards, tom lane binW9bQG9JmZj.bin Description: sinval-rewrite-2.patch.gz

Re: [PATCHES] GIN improvements

2008-06-17 Thread Tom Lane
people to look it over you should wait for next month's commit fest. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] Tentative patch for making DROP put dependency info in DETAIL

2008-06-14 Thread Tom Lane
as expected. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] relscan.h split

2008-06-14 Thread Tom Lane
Alvaro Herrera [EMAIL PROTECTED] writes: Tom Lane wrote: Also, it seemed like some of those .c files had no business poking into the scan structs anyway; particularly contrib. Did you check whether the inclusions could be avoided? Not really, unless we were to provide something a routine

Re: [PATCHES] [HACKERS] SSL configure patch

2008-06-14 Thread Tom Lane
. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] Better formatting of functions in pg_dump

2008-06-13 Thread Tom Lane
of newline-before style in this function. I think you might have gone a bit overboard on adding whitespace, but the previous objection is nonsense, sorry. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your

Re: [PATCHES] Better formatting of functions in pg_dump

2008-06-12 Thread Tom Lane
styles? Please be consistent. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] SQL: table function support

2008-06-12 Thread Tom Lane
or not is in the eye of the beholder. I find the TABLE() syntax to be *less* clear. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] relscan.h split

2008-06-12 Thread Tom Lane
? regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] Tentative patch for making DROP put dependency info in DETAIL

2008-06-12 Thread Tom Lane
tremendously clean either, though it would at least have the virtue of improving consistency about where privilege checks etc get done. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http

Re: [PATCHES] Tentative patch for making DROP put dependency info in DETAIL

2008-06-12 Thread Tom Lane
to them. This sounds duplicative, but about all that really is there to duplicate is a foreach loop, which you're going to need anyway if the routines are to handle multiple objects. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org

Re: [PATCHES] Refactoring xlogutils.c

2008-06-11 Thread Tom Lane
Heikki Linnakangas [EMAIL PROTECTED] writes: Tom Lane wrote: The code motion in md.c looks fairly bogus; was that a copy-and-paste error? That's intentional. That check has been moved to smgrcreate(), so that it's done before calling TablespaceCreateDbSpace(). The reason

Re: [PATCHES] Tentative patch for making DROP put dependency info in DETAIL

2008-06-11 Thread Tom Lane
Alvaro Herrera [EMAIL PROTECTED] writes: Tom Lane wrote: ... I wonder if it would be worth refactoring the code so that a multiple-object DROP is implemented via performMultipleDeletions(). This would have more than just cosmetic advantages: it would no longer matter what order you listed

Re: [PATCHES] \timing on/off

2008-06-10 Thread Tom Lane
with formatting of table output. \timing doesn't belong. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches

  1   2   3   4   5   6   7   8   9   10   >