Re: [HACKERS] More stable query plans via more predictable column statistics

On Mon, Apr 4, 2016 at 1:06 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Alex Shulgin <alex.shul...@gmail.com> writes: > > On Sun, Apr 3, 2016 at 10:53 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > >> The reason for checking toowide_cnt is that if it's greater th

Re: [HACKERS] More stable query plans via more predictable column statistics

On Sun, Apr 3, 2016 at 10:53 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Alex Shulgin <alex.shul...@gmail.com> writes: > > This recalled observation can now also explain to me why in the > regression > > you've seen, the short path was not followed: my bet is that sta

Re: [HACKERS] More stable query plans via more predictable column statistics

On Sun, Apr 3, 2016 at 8:24 AM, Alex Shulgin <alex.shul...@gmail.com> wrote: > > On Sun, Apr 3, 2016 at 7:49 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> >> Alex Shulgin <alex.shul...@gmail.com> writes: >> > On Sun, Apr 3, 2016 at 7:18 AM, Tom Lane &l

Re: [HACKERS] More stable query plans via more predictable column statistics

On Sun, Apr 3, 2016, 18:40 Tom Lane <t...@sss.pgh.pa.us> wrote: > Alex Shulgin <alex.shul...@gmail.com> writes: > > > Well, if it's the only value it will be accepted simply because we are > > checking that special case already and don't even bother to l

Re: [HACKERS] Add schema-qualified relnames in constraint error messages.

On Sun, Apr 3, 2016, 18:32 Tom Lane wrote: > Peter Geoghegan writes: > > On Thu, Feb 11, 2016 at 9:50 AM, Robert Haas > wrote: > >> Wow, that's a fabulous idea. I see Oleksandr has tried to implement > >> it, although I haven't

Re: [HACKERS] More stable query plans via more predictable column statistics

On Sun, Apr 3, 2016 at 7:49 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Alex Shulgin <alex.shul...@gmail.com> writes: > > On Sun, Apr 3, 2016 at 7:18 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > >> Well, we have to do *something* with the last (possibly only) valu

Re: [HACKERS] More stable query plans via more predictable column statistics

On Sun, Apr 3, 2016 at 7:18 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Alex Shulgin <alex.shul...@gmail.com> writes: > > On Sun, Apr 3, 2016 at 3:43 AM, Alex Shulgin <alex.shul...@gmail.com> > wrote: > >> I'm not sure yet about the 1% rule for the last v

Re: [HACKERS] More stable query plans via more predictable column statistics

On Sun, Apr 3, 2016 at 3:43 AM, Alex Shulgin <alex.shul...@gmail.com> wrote: > > I'm not sure yet about the 1% rule for the last value, but would also love > to see if we can avoid the arbitrary limit here. What happens with a last > value which is less than 1% popular in the c

Re: [HACKERS] Add schema-qualified relnames in constraint error messages.

On Sat, Apr 2, 2016 at 11:41 PM, Tom Lane wrote: > "Shulgin, Oleksandr" writes: > > On Mon, Mar 14, 2016 at 7:55 PM, Tom Lane wrote: > >> Yeah, I don't much like that either. But I don't think we can avoid > >> some

Re: [HACKERS] More stable query plans via more predictable column statistics

On Sat, Apr 2, 2016 at 8:57 PM, Shulgin, Oleksandr < oleksandr.shul...@zalando.de> wrote: > On Apr 2, 2016 18:38, "Tom Lane" wrote: > >> I did not like the fact that the compute_scalar_stats logic >> would allow absolutely anything into the MCV list once num_hist falls >>

Re: [HACKERS] Sanity checking for ./configure options?

The following review has been posted through the commitfest application: make installcheck-world: not tested Implements feature: tested, passed Spec compliant: not tested Documentation:not tested Looks good to me. It only allows valid number between 1 and 65535,

[HACKERS] POC PATCH: copy from ... exceptions to: (was Re: VLDB Features)

comment about the need for subtransaction around every loaded line still holds. Any example of what would be not properly rolled back by just PG_TRY? Happy hacking! -- Alex From 50f7ab0a503a0d61776add8a138abf2622fc6c35 Mon Sep 17 00:00:00 2001 From: Alex Shulgin a...@commandprompt.com Date: Fri, 19

Re: [HACKERS] Turning recovery.conf into GUCs

Alex Shulgin a...@commandprompt.com writes: Petr Jelinek p...@2ndquadrant.com writes: I had a quick look, the patch does not apply cleanly anymore but it's just release notes so nothing too bad. Yes, there were some ongoing changes that touched some parts of this and I must have missed

Re: [HACKERS] [PATCH] HINT: pg_hba.conf changed since last config reload

Steve Singer st...@ssinger.info writes: On 12/15/2014 11:38 AM, Alex Shulgin wrote: These are all valid concerns IMHO. Attached is the modified version of the original patch by Craig, addressing the handling of the new hint_log error data field and removing the client-side HINT. I'm also

Re: [HACKERS] [PATCH] HINT: pg_hba.conf changed since last config reload

Craig Ringer cr...@2ndquadrant.com writes: On 12/19/2014 11:41 PM, Alex Shulgin wrote: I don't think so. The scenario this patch relies on assumes that the DBA will remember to look in the log if something goes wrong Well, actually, the whole point was that the user who's connecting

Re: [HACKERS] REVIEW: Track TRUNCATE via pgstat

to track insert/update/deletes that happened before first truncate separately. To the point of making a dedicated pgstat testing tool: let's have another TODO item? -- Alex From 0b3161191a3ddb999cd9d0da08e1b6088ce07a84 Mon Sep 17 00:00:00 2001 From: Alex Shulgin a...@commandprompt.com Date: Tue, 9 Dec

Re: [HACKERS] REVIEW: Track TRUNCATE via pgstat

Alvaro Herrera alvhe...@2ndquadrant.com writes: Alex Shulgin wrote: OK, I think I have now all bases covered, though the updated patch is not that pretty. The problem is that we don't know in advance if the (sub)transaction is going to succeed or abort, and in case of aborted truncate we

Re: [HACKERS] REVIEW: Track TRUNCATE via pgstat

cc51823a01a194ef6fcd90bc763fa26498837322 Mon Sep 17 00:00:00 2001 From: Alex Shulgin a...@commandprompt.com Date: Tue, 9 Dec 2014 16:35:14 +0300 Subject: [PATCH] WIP: track TRUNCATEs in pgstat transaction stats. The n_live_tup and n_dead_tup counters need to be set to 0 after a TRUNCATE on the relation. We can't issue

Re: [HACKERS] REVIEW: Track TRUNCATE via pgstat

Alvaro Herrera alvhe...@2ndquadrant.com writes: Another idea would be exposing pgstat_report_stat(true) at SQL level. That would eleminate the need for explicit pg_sleep(=0.5), but we'll still need the wait_for_... call to make sure the collector has picked it up. We already have a stats

Re: [HACKERS] REVIEW: Track TRUNCATE via pgstat

Alvaro Herrera alvhe...@2ndquadrant.com writes: Alex Shulgin wrote: Alvaro Herrera alvhe...@2ndquadrant.com writes: Another idea would be exposing pgstat_report_stat(true) at SQL level. That would eleminate the need for explicit pg_sleep(=0.5), but we'll still need the wait_for_

Re: [HACKERS] [PATCH] add ssl_protocols configuration option

18388300f9ed34fa47c66b8a2da098aeb19a7f71 Mon Sep 17 00:00:00 2001 From: Alex Shulgin a...@commandprompt.com Date: Wed, 19 Nov 2014 19:49:29 +0300 Subject: [PATCH] DRAFT: ssl_protocols GUC --- doc/src/sgml/config.sgml | 29 ++ doc/src/sgml/libpq.sgml | 25 ++ src/backend/libpq

Re: [HACKERS] [PATCH] HINT: pg_hba.conf changed since last config reload

Peter Eisentraut pete...@gmx.net writes: On 10/16/14 11:34 PM, Craig Ringer wrote: psql: FATAL: Peer authentication failed for user fred HINT: See the server error log for additional information. I think this is wrong for many reasons. I have never seen an authentication system that

Re: [HACKERS] Turning recovery.conf into GUCs

Alex Shulgin a...@commandprompt.com writes: Alex Shulgin a...@commandprompt.com writes: Here's an attempt to revive this patch. Here's the patch rebased against current HEAD, that is including the recently committed action_at_recovery_target option. The default for the new GUC is 'pause

Re: [HACKERS] SSL information view

Magnus Hagander mag...@hagander.net writes: You should add it to the next CF for proper tracking, there are already many patches in the queue waiting for reviews :) Absolutely - I just wanted those that were already involved in the thread to get a chance to look at it early :) didn't want

Re: [HACKERS] Small TRUNCATE glitch

to the 2PC pgstat record instead of the bit magic. Attached is v0.2, now with a regression test included. -- Alex From 4c8fae27ecd9c94e7c3da0997f03099045a152d9 Mon Sep 17 00:00:00 2001 From: Alex Shulgin a...@commandprompt.com Date: Tue, 9 Dec 2014 16:35:14 +0300 Subject: [PATCH] WIP: track TRUNCATEs

Re: [HACKERS] Small TRUNCATE glitch

From: Alex Shulgin a...@commandprompt.com Date: Tue, 9 Dec 2014 16:35:14 +0300 Subject: [PATCH] WIP: track TRUNCATEs in pgstat transaction stats. The n_live_tup and n_dead_tup counters need to be set to 0 after a TRUNCATE on the relation. We can't issue a special message to the stats collector

Re: [HACKERS] Small TRUNCATE glitch

Alex Shulgin a...@commandprompt.com writes: Bruce Momjian br...@momjian.us writes: Added to TODO: o Clear table counters on TRUNCATE http://archives.postgresql.org/pgsql-hackers/2008-04/msg00169.php Hello, Attached is a WIP patch for this TODO. This part went

Re: [HACKERS] [COMMITTERS] pgsql: Keep track of transaction commit timestamps

Heikki Linnakangas hlinnakan...@vmware.com writes: On 12/03/2014 04:54 PM, Alvaro Herrera wrote: ir commit timestamp directly as they commit, or an external transaction c Sorry, I'm late to the party, but here's some random comments on this after a quick review: Also this commit breaks

Re: [HACKERS] [COMMITTERS] pgsql: Keep track of transaction commit timestamps

Alvaro Herrera alvhe...@2ndquadrant.com writes: Alex Shulgin wrote: Also this commit breaks initdb of `make check' for me: creating template1 database in /home/ash/build/postgresql/HEAD/src/test/regress/./tmp_check/data/base/1 ... TRAP: FailedAssertion(!(((xmax) = ((TransactionId) 3

Re: [HACKERS] [COMMITTERS] pgsql: Keep track of transaction commit timestamps

Alvaro Herrera alvhe...@2ndquadrant.com writes: Uh, that's odd. Can you please get a stack trace? Do you have unusual settings or a patched build? Is there a way to pause the bootstrap process so I can attach gdb to it? -- Alex -- Sent via pgsql-hackers mailing list

Re: [HACKERS] [COMMITTERS] pgsql: Keep track of transaction commit timestamps

Craig Ringer cr...@2ndquadrant.com writes: On 12/04/2014 10:50 PM, Alex Shulgin wrote: Is there a way to pause the bootstrap process so I can attach gdb to it? With a newer gdb, you can instead tell gdb to follow all forks. I wrote some notes on it recently. http://blog.2ndquadrant.com

Re: [HACKERS] [COMMITTERS] pgsql: Keep track of transaction commit timestamps

Alvaro Herrera alvhe...@2ndquadrant.com writes: Alex Shulgin wrote: DEBUG: inserting column 7 value varchar_transform Breakpoint 1, GetSnapshotData (snapshot=0xdb2d60 CatalogSnapshotData) at /home/ash/src/postgresql/src/backend/storage/ipc/procarray.c:1413 1413 xmax

Re: [HACKERS] [COMMITTERS] pgsql: Keep track of transaction commit timestamps

Alex Shulgin a...@commandprompt.com writes: Figured it out with a pg_usleep in bootstrap.c anyway. Does this look sane? DEBUG: inserting column 6 value 0 DEBUG: inserted - 0 DEBUG: inserting column 7 value varchar_transform TRAP: FailedAssertion(!(((xmax) = ((TransactionId) 3))), File

Re: [HACKERS] [COMMITTERS] pgsql: Keep track of transaction commit timestamps

Alvaro Herrera alvhe...@2ndquadrant.com writes: Alex Shulgin wrote: DEBUG: inserting column 7 value varchar_transform Breakpoint 1, GetSnapshotData (snapshot=0xdb2d60 CatalogSnapshotData) at /home/ash/src/postgresql/src/backend/storage/ipc/procarray.c:1413 1413 xmax

Re: [HACKERS] Turning recovery.conf into GUCs

Michael Paquier michael.paqu...@gmail.com writes: On Tue, Dec 2, 2014 at 1:58 AM, Alex Shulgin a...@commandprompt.com wrote: Here's the patch rebased against current HEAD, that is including the recently committed action_at_recovery_target option. If this patch gets in, it gives a good

Re: [HACKERS] Turning recovery.conf into GUCs

Andres Freund and...@2ndquadrant.com writes: On 2014-12-02 17:25:14 +0300, Alex Shulgin wrote: I'd be in favor of a solution that works the same way as before the patch, without the need for extra trigger files, etc., but that doesn't seem to be nearly possible. Whatever tricks we might

Re: [HACKERS] Turning recovery.conf into GUCs

Alex Shulgin a...@commandprompt.com writes: Here's an attempt to revive this patch. Here's the patch rebased against current HEAD, that is including the recently committed action_at_recovery_target option. The default for the new GUC is 'pause', as in HEAD, and pause_at_recovery_target

Re: [HACKERS] patch : Allow toast tables to be moved to a different tablespace

Julien Tachoires jul...@gmail.com writes: 2011/12/15 Alvaro Herrera alvhe...@commandprompt.com: Uhm, surely you could compare the original toast tablespace to the heap tablespace, and if they differ, handle appropriately when creating the new toast table? =A0Just pass down the toast

Re: [HACKERS] Add shutdown_at_recovery_target option to recovery.conf

Christoph Berg c...@df7cb.de writes: Re: Petr Jelinek 2014-11-25 5474efea.2040...@2ndquadrant.com Patch committed. Before I go and rebase that recovery.conf - GUC patch on top of this... is it final? Thanks! I'm a bit late to the party, but wouldn't recovery_target_action = ...

Re: [HACKERS] [PATCH] add ssl_protocols configuration option

Dag-Erling Smørgrav d...@des.no writes: Alex Shulgin a...@commandprompt.com writes: OK, looks like I've come up with something workable: I've added sslprotocol connection string keyword similar to pre-existing sslcompression, etc. Please see attached v2 of the original patch. I'm having

[HACKERS] Follow up to irc on CREATE INDEX vs. maintenance_work_mem on 9.3

Tom, First of all, thanks for your help on IRC last time with that CREATE INDEX memory consumption problem. As has been pointed out in a stackexchange answer to my question[1], it is indeed the limitation of pre-9.4 versions, but the limit is imposed on memtuples array, rather than total memory

Re: [HACKERS] Follow up to irc on CREATE INDEX vs. maintenance_work_mem on 9.3

Andrew Gierth and...@tao11.riddles.org.uk writes: Alex == Alex Shulgin a...@commandprompt.com writes: Tom Lane t...@sss.pgh.pa.us writes: Must've been my evil twin. Alex Sorry, I must be under false impression that RhodiumToad is Alex *your* nick on #postgresql at freenode. I don't

Re: [HACKERS] [PATCH] add ssl_protocols configuration option

Alex Shulgin a...@commandprompt.com writes: I can do that too, just need a hint where to look at in libpq/psql to add the option. The place to *enforce* the option is src/interfaces/libpq/fe-secure.c (look for SSLv23_method() and SSL_CTX_set_options()). I haven't looked into how to set

Re: Missing OOM checks in libpq (was Re: [HACKERS] Replication connection URI?)

Heikki Linnakangas hlinnakan...@vmware.com writes: On 11/24/2014 06:05 PM, Alex Shulgin wrote: The first patch is not on topic, I just spotted this missing check. *** a/src/interfaces/libpq/fe-connect.c --- b/src/interfaces/libpq/fe-connect.c *** conninfo_array_parse(const char

Re: Missing OOM checks in libpq (was Re: [HACKERS] Replication connection URI?)

Heikki Linnakangas hlinnakan...@vmware.com writes: I think we need to fix all of those, and backpatch. Per attached. Yikes! Looks sane to me. Ok thanks, committed. It didn't apply cleanly to 9.0, 9.1 and 9.2, so the patch for those branches looks a bit different. Great. Are you looking

Re: [HACKERS] Replication connection URI?

Heikki Linnakangas hlinnakan...@vmware.com writes: The second one is a self-contained fix, but the third one which is the actual patch depends on the second one, because it specifies the dbname keyword two times: first to parse the conninfo/URI, then to override any dbname provided by the

Re: [HACKERS] Turning recovery.conf into GUCs

Alex Shulgin a...@commandprompt.com writes: * Why do you include xlog_internal.h in guc.c and not xlog.h? we actually need both but including xlog_internal.h also includes xlog.h i added xlog.h and if someone things is enough only putting xlog_internal.h let me know What's required from

Re: [HACKERS] Turning recovery.conf into GUCs

Josh Berkus j...@agliodbs.com writes: Well, the latest version of this patch fails to start when it sees 'recovery.conf' in PGDATA: FATAL: recovery.conf is not supported anymore as a recovery method DETAIL: Refer to appropriate documentation about migration methods I've missed

[HACKERS] Replication connection URI?

Hackers, It appears that replication connection doesn't support URI but only the traditional conninfo string. src/backend/replication/libpqwalreceiver/libpqwalreceiver.c:99: in libpqrcv_connect(): snprintf(conninfo_repl, sizeof(conninfo_repl), %s dbname=replication

Re: [HACKERS] Replication connection URI?

From: Alex Shulgin a...@commandprompt.com Date: Mon, 24 Nov 2014 16:55:50 +0300 Subject: [PATCH 1/3] Add missing check on OOM in expand_dbname path of conninfo_array_parse(). --- src/interfaces/libpq/fe-connect.c | 8 1 file changed, 8 insertions(+) diff --git a/src/interfaces/libpq/fe

Re: [HACKERS] Turning recovery.conf into GUCs

Jaime Casanova ja...@2ndquadrant.com writes: Either way, from the code it is clear that we only stay in recovery if standby_mode is directly turned on. This makes the whole check for a specially named file unnecessary, IMO: we should just check the value of standby_mode (which is off by

Re: [HACKERS] Turning recovery.conf into GUCs

Josh Berkus j...@agliodbs.com writes: only that you need to start in recovery mode to start replication Right, but my point is that having a trigger file *is not necessary for replication, only for PITR* -- and maybe not necessary even for PITR. That is, in a streaming replication

Re: [HACKERS] Turning recovery.conf into GUCs

Josh Berkus j...@agliodbs.com writes: Before I go into my ideas, though, what does the current patch do regarding non-replication PITR? It removes that $PGDATA/standby.enable trigger file it relies on to start the PITR in the first place. OK, and that's required for replication too? I'm

Re: [HACKERS] Replication connection URI?

Alex Shulgin a...@commandprompt.com writes: Heikki Linnakangas hlinnakan...@vmware.com writes: It appears that replication connection doesn't support URI but only the traditional conninfo string. src/backend/replication/libpqwalreceiver/libpqwalreceiver.c:99: in libpqrcv_connect

Re: [HACKERS] [PATCH] add ssl_protocols configuration option

Dag-Erling Smørgrav d...@des.no writes: Alex Shulgin a...@commandprompt.com writes: I can do that too, just need a hint where to look at in libpq/psql to add the option. The place to *enforce* the option is src/interfaces/libpq/fe-secure.c (look for SSLv23_method() and SSL_CTX_set_options

Re: [HACKERS] Turning recovery.conf into GUCs

de59408e524e3818a7cea98a7c1f049e09eb9f79 Mon Sep 17 00:00:00 2001 From: Alex Shulgin a...@commandprompt.com Date: Fri, 21 Nov 2014 12:22:22 +0300 Subject: [PATCH] DRAFT: rebased recovery_guc_v5.2.patch --- contrib/pg_archivecleanup/pg_archivecleanup.c | 2 +- contrib/pg_standby/pg_standby.c | 2 +- doc/src

Re: [HACKERS] [PATCH] add ssl_protocols configuration option

Dag-Erling Smørgrav d...@des.no writes: Alex Shulgin a...@commandprompt.com writes: * The patch works as advertised, though the only way to verify that connections made with the protocol disabled by the GUC are indeed rejected is to edit fe-secure-openssl.c to only allow specific TLS

Re: [HACKERS] Merging recovery.conf into PostgreSQL.conf -- where did this go?

Andres Freund and...@2ndquadrant.com writes: On 2014-11-19 15:09:10 -0800, Josh Berkus wrote: One patch that got deferred from 9.4 was the merger of recovery.conf and postgresql.conf, due to conflicts with ALTER SYSTEM SET. However, this is still a critical TODO, because recovery.conf is

Re: [HACKERS] [PATCH] add ssl_protocols configuration option

Dag-Erling Smørgrav d...@des.no writes: The attached patches add an ssl_protocols configuration option which control which versions of SSL or TLS the server will use. The syntax is similar to Apache's SSLProtocols directive, except that the list is colon-separated instead of

Re: [HACKERS] Idle transaction cancel/timeout and SSL revisited

Andres Freund and...@2ndquadrant.com writes: On 2014-11-15 00:11:36 +0300, Alex Shulgin wrote: After reading up through archives on the two $subj related TODO items I'm under impression that the patches[1,2] didn't make it mainly because of the risk of breaking SSL internals if we try

Re: [HACKERS] Escaping from blocked send() reprised.

Andres Freund and...@2ndquadrant.com writes: I've invested some more time in this: 0002 now makes sense on its own and doesn't change anything around the interrupt handling. Oh, and it compiles without 0003. In this patch, the endif appears to be misplaced in PostgresMain: + if

[HACKERS] Idle transaction cancel/timeout and SSL revisited

Hello Hackers, After reading up through archives on the two $subj related TODO items I'm under impression that the patches[1,2] didn't make it mainly because of the risk of breaking SSL internals if we try to longjump out of the signal handler in the middle of a blocking SSL read and/or if we try

Re: [HACKERS] Idle transaction cancel/timeout and SSL revisited

Andres Freund and...@2ndquadrant.com writes: On 2014-11-15 00:11:36 +0300, Alex Shulgin wrote: After reading up through archives on the two $subj related TODO items I'm under impression that the patches[1,2] didn't make it mainly because of the risk of breaking SSL internals if we try

Re: [HACKERS] Libxml2 load error on Windows

Dave Page dp...@pgadmin.org writes: On Tue, Jun 19, 2012 at 4:43 AM, Robert Haas robertmh...@gmail.com wrote: Please add this patch here so that it doesn't get lost in the shuffle: https://commitfest.postgresql.org/action/commitfest_view/open Hmm, that raises an interesting question

Re: [HACKERS] Libxml2 load error on Windows

Dave Page dp...@pgadmin.org writes: On Tue, Jun 19, 2012 at 11:04 AM, Alex Shulgin a...@commandprompt.com wrote: In a real bug-tracking system we would create a new bug/ticket and set it's target version to 'candidate for next minor release' or something like that.  This way, if we don't

Re: [HACKERS] libpq URL syntax vs SQLAlchemy

Alex a...@commandprompt.com writes: Peter Eisentraut pete...@gmx.net writes: I have been reviewing how our new libpq URL syntax compares against existing implementations of URL syntaxes in other drivers or higher-level access libraries. In the case of SQLAlchemy, there is an

Re: [HACKERS] Bug tracker tool we need

Robert Haas robertmh...@gmail.com writes: On Tue, Apr 17, 2012 at 1:47 AM, Magnus Hagander mag...@hagander.net wrote: That's probably one reason people aren't jumping on this. Because there is no tracker out there that people actually *like*... I think this is a point worth serious thought.

Re: [HACKERS] Bug tracker tool we need

Jay Levitt jay.lev...@gmail.com writes: (A quick Google shows redmine and especially Trac having spam issues of their own.) Ugh, redmine (or trac for that matters) has nothing to with handling spam. I believe a typical bug tracker doesn't handle spam itself, it lets the mailing system do

Re: [HACKERS] Last gasp

Jay Levitt jay.lev...@gmail.com writes: No meaningful search, eh? Works for me. Redmine searches return partial-word matches, and there's no way to disable that. Searching for test finds latest. To me, that's broken. Well, I believe one can plug in a different search engine, like lucene

Re: [HACKERS] Another review of URI for libpq, v7 submission

Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes: On 22.03.2012 23:42, Alex wrote: Okay, at last here's v9, rebased against current master branch. Some quick comments on this patch: Heikki, thank you for taking a look at this! I see a compiler warning: fe-connect.c: In

Trivial libpq refactoring patch (was: Re: [HACKERS] Another review of URI for libpq, v7 submission)

Alex a...@commandprompt.com writes: Marko Kreen mark...@gmail.com writes: On Thu, Mar 15, 2012 at 11:29:31PM +0200, Alex wrote: https://github.com/a1exsh/postgres/commits/uri The point of the patch is to have one string with all connection options, in standard format, yes? So why does not

Re: [HACKERS] Another review of URI for libpq, v7 submission

Daniel Farina dan...@heroku.com writes: I reviewed this and so far have not found any serious problems, although as is par for the course it contains some of the fiddly bits involved in any string manipulations in C. I made a few edits -- none strictly necessary for correctness -- that the

Re: [HACKERS] WIP: URI connection string support for libpq

Peter Eisentraut pete...@gmx.net writes: I've included a (separate) test shell script based on Greg's cases in one of the updates. What would be preferred place to plug it in? Override installcheck in libpq Makefile? I think that would be the right place. I figured that adding this right

Re: [HACKERS] WIP: URI connection string support for libpq

Greg Smith g...@2ndquadrant.com writes: Thank you for the review, Greg! Given that, there really isn't a useful path forward that helps out all those developers without supporting both prefixes. That's where this left off before, I just wanted to emphasize how clear that need seems now.

Re: [HACKERS] WIP: URI connection string support for libpq

Florian Weimer fwei...@bfk.de writes: * Alex Shulgin: Yeah, this is really appealing, however how do you tell if the part after the last slash is a socket directory name or a dbname? E.g: psql postgres:///path/to/different/socket/dir(default dbname) psql postgres:///path

Re: [HACKERS] Reviewing patch URI connection string support for libpq

Harold Giménez harold.gime...@gmail.com writes: I have interest in the URI connection string support patch[1], so I'm in the process of reviewing it. I have a couple of comments and questions: Hello, thank you for your interest and the review! 1. I see no tests in the patch.

[HACKERS] Review of pg_archivecleanup -x option patch

Hello, This is my first patch review ever, so please bear with me. The patch[1] is in the context diff format and applies cleanly to current git HEAD. Documentation is updated by the patch. The code does implement what's the patch is supposed to do. Do we want that? According to Greg's

Re: [HACKERS] automating CF submissions (was xlog location arithmetic)

Greg Smith g...@2ndquadrant.com writes: One unicorn I would like to have here would give the CF app a database of recent e-mails to pgsql-hackers. I login to the CF app, click on Add recent submission, and anything matching my e-mail address appears with a checkbox next to it. Click on the

Re: [HACKERS] Postgres ReviewFest Patch: URI connection string support for libpq

Nick Roosevelt nro...@gmail.com writes: I am sorry, seems like my new MUA was misconfigured so the two previous attempts to reply to -hackers@ failed. So here goes again. Just reviewed the patch for adding URI connection string support for libpg. Thank you for taking your time on

Re: [HACKERS] automating CF submissions (was xlog location arithmetic)

Andrew Dunstan and...@dunslane.net writes: On 01/19/2012 12:59 PM, Alex Shulgin wrote: Another idea: introduce some simple tag system in mails sent to -hackers to be treated specially, e.g: @fest add-to-current to add new patch to the commit fest currently in progress, or @fest add

Re: [HACKERS] Should we get rid of custom_variable_classes altogether?

On Mon, Oct 3, 2011 at 00:05, Tom Lane t...@sss.pgh.pa.us wrote: So at this point I'd vote for just dropping it and always allowing custom (that is, qualified) GUC names to be set, whether the prefix corresponds to any loaded module or not. Comments, other proposals? While working on E.164