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

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

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

er than we actually got before 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,

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

-distance-based 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

omeplace else). I'm not totally sure about that. But I am sure that doing nothing 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] get_relation_stats_hook()

tatsTuple = statstup; /* define function to use 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 la

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

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 soo

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

the SLRU-related modules about their StartUp calls being executed without any concurrent access. This isn't really a problem that needs to be dealt with in this patch, I think, but that will all have to be cleaned up before we dare allow any backends to run concurrently with recovery. btre

Re: [PATCHES] hash index improving v3

large fraction 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 pg

Re: [PATCHES] hash index improving v3

here is that this isn't a memory 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

ch of a use case for hash indexes at all, I don't feel 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] hash index improving v3

"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 hashbu

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

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 crit

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

s a statement that's certainly not going to be true 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

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-patch

Re: [PATCHES] hash index improving v3

alue. I'm considering changing hashbuild to switch over at shared_buffers instead 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]

ig in and figure out why the hashjoin 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 ...

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

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

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

27;s not cleaner to just use the regular checkpoint code? 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

patch > will > be committed. 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

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

"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

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

"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 --

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

//www.postgresql.org/docs/8.3/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] [PgFoundry] Unsigned Data Types [1 of 2]

"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::u

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

, choose its size based on len1 - len2, 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

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

n this up to some extent, but it would be better if the code looked more like the project style in the first place. 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]

because this is parsed as -(256::uint1) 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

uot;. > And here is the fix, we just forget to set the recheck 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.p

Re: [PATCHES] hash index improving v3

didn't seem to be happening in his tests. Nice 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] [HACKERS] TODO item: Implement Boyer-Moore searching (First time hacker)

way, it's not material for this patch, since it'd involve pretty fundamental redesign of the LIKE code. 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)

"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?

Re: [PATCHES] hash index improving v3

"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 cre

Re: [PATCHES] hash index improving v3

"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, w

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

stic about big a skip table to make may need some adjustment 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

ans it'll 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

Re: [PATCHES] hash index improving v3

suggested are surely not large enough 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

wrong with doing that, further down the road. So my thinking right now is that we should just test this patch as-is. If it doesn't show really horrid performance when there are lots of hash key collisions, we should forget the store-both-things idea and just go with this.

Re: [PATCHES] hash index improving v3

ybe declare a new entry point column in pg_am that lets the AM modify the tupledesc constructed by this function before it gets used to create the index. But that is irrelevant to performance testing, so I'm not going to do it right now. regards, tom lane -- S

Re: [PATCHES] hash index improving v3

This seems like a good idea, but I think we should do it as a separate, cosmetic-cleanup patch. It'll touch a lot of parts of access/hash/ that the current patch doesn't need to change, and thus complicate reviewing. regards, tom lane -- Sent via pgsql-pat

Re: [PATCHES] hash index improving v3

so that result is exactly what hash proponents would hope for. Whether it's real or not is another question, but it could be. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.pos

Re: [PATCHES] WIP Join Removal

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

Re: [PATCHES] WIP Join Removal

...) The reason is that it's not an all-or-nothing choice: some of the paths might offer 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 mai

Re: [PATCHES] WIP Join Removal

here you're calling this. In any case I'm unconvinced that join removal could ever not be a win, so that test seems unnecessary anyhow. > + { > + elog(LOG, "join removed"); > + joinrel->pathlist = keeprel->pathlist; > +

Re: [PATCHES] WIP Join Removal

timal. I also find all 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@postgr

Re: [PATCHES] WIP Join Removal

that works for index addition and removal (cf 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 fix

Re: [PATCHES] pg_dump additional options for performance

ious that we *necessarily* care about > parallelizing loading data. The thing that happens every day is > backups. Maybe so, but I would say that routine backups shouldn't be designed to eat 100% of your disk bandwidth anyway --- they'd be more like background tasks.

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

tail --- where did the other 8 bits go 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: [HACKERS][PATCHES] odd output in restore mode

n't want this patch as it is. > Instead, we want a documentation patch that describes the problem, > mentioning that GNU cp is safe, or you can use the copy+rename trick. Right, after which we remove the presently hacked-in delay. I've updated the commitfest page accordingly.

Re: [PATCHES] pg_dump additional options for performance

a -d target_db whole.dump which (given a parallelizing pg_restore) would do all the time-consuming steps in a fully parallelized fashion. 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

Stephen Frost <[EMAIL PROTECTED]> writes: > * Tom Lane ([EMAIL PROTECTED]) wrote: >> This argument is nonsense. The typical usage of this capability, IMHO, >> will be >> >> pg_dump -Fc >whole.dump >> pg_restore --schema-before-data whole.dump >be

Re: [PATCHES] pg_dump additional options for performance

e tables (and perhaps other objects, I'm not sure if there are any other comparable problems). 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

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* req

Re: [PATCHES] pg_dump additional options for performance

to gain implementation simplicity and robustness? BTW, another incomplete item is that pg_dumpall should probably be taught to accept and pass down --schema-before-data and --schema-after-data switches. 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: [HACKERS][PATCHES] odd output in restore mode

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 pa

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

lf wouldn't address the problem anyway, and that what we need is just a docs patch recommending that people use safe copying methods in their scripts that copy to the archive area? regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)

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

chapter 43 in the SGML docs.) We 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)

Re: [PATCHES] pg_dump additional options for performance

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

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

reading the code. I 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 additional options for performance

e mistakes along the way? 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

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

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

same kind of issue as with your stats-hooks patch. 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)

atch first. Right, my point exactly. Those necessarily-incompatible changes might or might not ever get applied --- if they are, we can do cosmetic cleanups afterwards. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make change

Re: [PATCHES] pg_dump additional options for performance

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, bec

Re: [PATCHES] pg_dump lock timeout

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 b

Re: [PATCHES] pg_dump additional options for performance

. > (I don't like those names either, just thinking about capabilities) Maybe invert the logic? --omit-pre-data --omit-data --omit-post-data Not wedded to these either, just tossing out an idea... regards, tom lane -- Sent via pgsq

Re: [PATCHES] pg_dump additional options for performance

s 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 -- 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

that's open to argument. 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

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

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

ot; or something like that? Otherwise, +1. >> You're not proposing it for 8.3 right? > I think I am. It's an important diagnostic for your other fix. I agree, this is important for visibility into what's happening. The string isn't getting translated so I d

Re: [PATCHES] variadic function support

t there may be a few other places 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 m

Re: [PATCHES] variadic function support

e in use as a user identifier. Does anyone think this issue is a showstopper? 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

"Pavel Stehule" <[EMAIL PROTECTED]> writes: > 2008/7/14 Tom Lane <[EMAIL PROTECTED]>: >> Are you intending to change this right now and resubmit, or is it >> work for later? > I prefer separate it to other patch. It seems a fairly important part of the fea

Re: [PATCHES] variadic function support

rgtypes altogether, and that seems mad. 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

s specified, so it would work 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

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

o that. There's at least one place that thinks that PageGetContents is the same as page + 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?

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

result, but the current 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] variadic function support

argument on to the second one? This is closely akin to the problem faced by C "..." functions, and the solutions are pretty ugly (sprintf vs vsprintf for instance). Can we do any better? At least in the polymorphic case, I'm not sure we can :-(. regards, tom lane

Re: [PATCHES] Relation forks & FSM rewrite patches

kely to cause trouble. A bigger problem is it would mess up a lot of your loops. BTW, don't put a comma at end of enum ForkNumber, I think some compilers will barf on that. Last, don't forget to update the sgml docs chapter on database physical storage. 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] VACUUM Improvements - WIP Patch

nce heap_page_prune has been refactored into a "scan" followed by an "apply", it'd be possible to decide before the "apply" step whether this is the case or not. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@p

Re: [PATCHES] GIN improvements

Do you need more review 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()

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

Re: [HACKERS] [PATCHES] GIN improvements

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-pa

Re: [PATCHES] pgbench minor fixes

m scripts? > I don't think we can justify vacuuming 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 la

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

ockets on any > platform. Indeed. 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 --

Re: [PATCHES] psql command setting

x27;t really toggles. 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] Sorting writes during checkpoint

f the information weren't 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-p

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

bxml? > You can create XML without libxml. 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.

Re: [PATCHES] Exposing keywords to clients

d by another function in the meanwhile. Modified > it to 2701. > DATA(insert OID = 2701 ( pg_get_keywordsPGNSP PGUID 12 10 400 f f t t s > 0 2249 2701 was claimed too. You need to use the unused_oids script to find unique free OIDs. regards, tom lane --

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

ike it could cause unexpected 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:

Re: [PATCHES] pg_dump lock timeout

default would break that, and will certainly not be accepted. 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

d server versions ... 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

"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

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

x out > max_connections. Huh? How could we be assigning to a slot that is not in use? 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] Explain XML patch

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

Re: [PATCHES] Explain XML patch

emphasis on the need 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 subs

Re: [PATCHES] Fix pg_ctl restart bug

tion worse would be if the patch affected some other code path 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

Re: [PATCHES] Fix pg_ctl restart bug

he contributed patch in 2004. So, 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] variadic function support

"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 >&

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

errupt" in > the context of pg_dump. I'm not sure 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.

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

intended to add a feature like 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.post

Re: [PATCHES] variadic function support

on foo (a text, variadic b int[]) or maybe even better create function 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.

  1   2   3   4   5   6   7   8   9   10   >