Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

On Thu, Feb 9, 2017 at 1:44 PM, Tom Lane wrote: > Robert Haas writes: >> On Thu, Feb 9, 2017 at 2:08 PM, Tom Lane wrote: >>> Although this doesn't really settle whether we ought to do 3a (with >>> backwards-compatibility function

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

On Thu, Feb 9, 2017 at 2:08 PM, Tom Lane wrote: > Robert Haas writes: >> On Mon, Feb 6, 2017 at 12:29 PM, Magnus Hagander wrote: Here is what I have, 6 votes clearly stated: 1. Rename nothing: Daniel, 2. Rename

Re: [HACKERS] amcheck (B-Tree integrity checking tool)

On Thu, Feb 9, 2017 at 3:05 AM, Andres Freund wrote: >> +#define CHECK_SUPERUSER() { \ >> + if (!superuser()) \ >> + ereport(ERROR, \ >> + >> (errcode(ERRCODE_INSUFFICIENT_PRIVILEGE), \ >> +

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

On Mon, Feb 6, 2017 at 5:49 PM, Corey Huinker wrote: > I suppressed the endif-balance checking in cases where we're in an > already-failed situation. > In cases where there was a boolean parsing failure, and ON_ERROR_STOP is on, > the error message no longer speak of a

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

Robert Haas writes: > I (still) think this is a bad design. Even if you've got all the > messages just right as things stand today, some new feature that comes > along in the future can change things so that they're not right any > more, and nobody's going to relish

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

On Thu, Feb 9, 2017 at 3:13 PM, Tom Lane wrote: > Robert Haas writes: > > I (still) think this is a bad design. Even if you've got all the > > messages just right as things stand today, some new feature that comes > > along in the future can change

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

On 02/09/2017 12:53 PM, Stephen Frost wrote: > * Josh Berkus (j...@berkus.org) wrote: >> On 02/09/2017 12:42 PM, Stephen Frost wrote: >>> * Josh Berkus (j...@berkus.org) wrote: On 02/09/2017 11:08 AM, Tom Lane wrote: > Agreed, let's just get it done. > > Although this doesn't

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

Corey Huinker writes: > On Thu, Feb 9, 2017 at 3:13 PM, Tom Lane wrote: >> IMO, an erroneous backslash command should have no effect, period. > One way around this is to make the small change: commands with invalid > expressions are ignored in

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

On 02/09/2017 11:08 AM, Tom Lane wrote: > Agreed, let's just get it done. > > Although this doesn't really settle whether we ought to do 3a (with > backwards-compatibility function aliases in core) or 3b (without 'em). > Do people want to re-vote, understanding that those are the remaining >

Re: [HACKERS] PATCH: two slab-like memory allocators

Hi, On 2016-12-13 01:45:13 +0100, Tomas Vondra wrote: > src/backend/utils/mmgr/Makefile | 2 +- > src/backend/utils/mmgr/aset.c | 115 + > src/backend/utils/mmgr/memdebug.c | 131 > ++ > src/include/utils/memdebug.h

Re: [HACKERS] How to debug the wire protocol?

On 2017-02-09 20:17:33 +0100, Rui Pacheco wrote: > I’ve been anxiously waiting for that reply but got nothing. I even mailed the > mailing list manager again with no reply. And when I click on that link I get > a server error: "An internal server error occurred.” The server error has already

Re: [HACKERS] How to debug the wire protocol?

The answers are great, thanks! > On 9 Feb 2017, at 20:26, Andres Freund wrote: > > On 2017-02-09 20:17:33 +0100, Rui Pacheco wrote: >> I’ve been anxiously waiting for that reply but got nothing. I even mailed >> the mailing list manager again with no reply. And when I click

Re: [HACKERS] pageinspect: Hash index support

On Thu, Feb 9, 2017 at 1:11 PM, Ashutosh Sharma wrote: >> I think you should just tighten up the sanity checking in the existing >> function _hash_ovflblkno_to_bitno rather than duplicating the code. I >> don't think it's called often enough for one extra (cheap) test to

Re: [HACKERS] Parallel bitmap heap scan

On Wed, Feb 8, 2017 at 10:59 AM, Robert Haas wrote: > Looks good to me. If nobody has further ideas here, I'll push this > and your previous patch tomorrow. Done. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

On 02/09/2017 12:42 PM, Stephen Frost wrote: > * Josh Berkus (j...@berkus.org) wrote: >> On 02/09/2017 11:08 AM, Tom Lane wrote: >>> Agreed, let's just get it done. >>> >>> Although this doesn't really settle whether we ought to do 3a (with >>> backwards-compatibility function aliases in core) or

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

Andres, * Andres Freund (and...@anarazel.de) wrote: > On 2017-02-09 15:53:47 -0500, Stephen Frost wrote: > > * Josh Berkus (j...@berkus.org) wrote: > > > What I'm voting against is the idea that we'll have aliases in core, but > > > remove them in two releases. Either that's unrealistic, or it's

Re: [HACKERS] amcheck (B-Tree integrity checking tool)

On Thu, Feb 9, 2017 at 12:05 AM, Andres Freund wrote: > reindex_index isn't necessarily comparable, because > RangeVarCallbackForReindexIndex() is, on first blush at least, careful > enough about the locking, and reindex_relation only gets the index list > after building the

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

On Thu, Feb 9, 2017 at 4:24 PM, Tom Lane wrote: > Also, our experience with contrib/tsearch2 suggests that the extension > shouldn't be part of contrib, because we have zero track record of getting > rid of stuff in contrib, no matter how dead it is. Let's nuke tsearch2 to

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Wed, Feb 8, 2017 at 5:36 AM, Thomas Munro wrote: > Thinking a bit harder about this, I suppose there could be a kind of > object called a SharedBufFileManager (insert better name) which you > can store in a DSM segment. The leader backend that initialises a DSM

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

On Thu, Feb 9, 2017 at 4:15 PM, Tom Lane wrote: > Basically, I think you need to start removing complexity (in the sense of > special cases), not adding more. I think Robert was saying the same > thing, though possibly I shouldn't put words in his mouth. Yeah, I was

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

On 2017-02-09 22:15, Tom Lane wrote: Corey Huinker writes: The feature now ( at patch v10) lets you break off with Ctrl-C anywhere. I like it now much more. The main thing I still dislike somewhat about the patch is the verbose output. To be honest I would

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

On 2017-02-09 14:08:14 -0500, Tom Lane wrote: > Robert Haas writes: > > On Mon, Feb 6, 2017 at 12:29 PM, Magnus Hagander > > wrote: > >>> Here is what I have, 6 votes clearly stated: > >>> 1. Rename nothing: Daniel, > >>> 2. Rename directory only:

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

* Josh Berkus (j...@berkus.org) wrote: > On 02/09/2017 11:08 AM, Tom Lane wrote: > > Agreed, let's just get it done. > > > > Although this doesn't really settle whether we ought to do 3a (with > > backwards-compatibility function aliases in core) or 3b (without 'em). > > Do people want to

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

On 2017-02-09 15:53:47 -0500, Stephen Frost wrote: > * Josh Berkus (j...@berkus.org) wrote: > > What I'm voting against is the idea that we'll have aliases in core, but > > remove them in two releases. Either that's unrealistic, or it's just > > prolonging the pain. > > Waiting 10+ years doesn't

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

On 2/9/17 4:03 PM, Josh Berkus wrote: > Counter-argument: moving the directory is going to break many tools > anyway, so why bother with function aliases? +1. -- -David da...@pgmasters.net -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

On 2017-02-09 13:03:41 -0800, Josh Berkus wrote: > Counter-argument: moving the directory is going to break many tools > anyway, so why bother with function aliases? There's not actually that many tools affected by renaming pg_xlog, i.e. there are tools that aren't affected by the rename at all,

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

Stephen Frost writes: > * Josh Berkus (j...@berkus.org) wrote: >> If we clearly mark the old function names as deprecated aliases, client >> tools will gradually move to the new names. > No, they won't. They haven't. Look at pg_shadow- it was clearly marked > as deprecated

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

Robert Haas writes: > On Thu, Feb 9, 2017 at 2:08 PM, Tom Lane wrote: >> Although this doesn't really settle whether we ought to do 3a (with >> backwards-compatibility function aliases in core) or 3b (without 'em). >> Do people want to re-vote,

Re: [HACKERS] Latch reset ordering bug in condition_variable.c

On Thu, Feb 9, 2017 at 6:01 AM, Thomas Munro wrote: > ConditionVariablePrepareToSleep() has a race that can leave you > hanging, introduced by me in the v4 patch. The problem is that that > function resets our latch after adding our process to the wakeup list. >

Re: [HACKERS] amcheck (B-Tree integrity checking tool)

On 2017-02-09 14:48:18 -0500, Robert Haas wrote: > On Thu, Feb 9, 2017 at 3:05 AM, Andres Freund wrote: > >> +#define CHECK_SUPERUSER() { \ > >> + if (!superuser()) \ > >> + ereport(ERROR, \ > >> + > >>

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

* Josh Berkus (j...@berkus.org) wrote: > On 02/09/2017 12:42 PM, Stephen Frost wrote: > > * Josh Berkus (j...@berkus.org) wrote: > >> On 02/09/2017 11:08 AM, Tom Lane wrote: > >>> Agreed, let's just get it done. > >>> > >>> Although this doesn't really settle whether we ought to do 3a (with > >>>

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

* Josh Berkus (j...@berkus.org) wrote: > On 02/09/2017 12:53 PM, Stephen Frost wrote: > > Waiting 10+ years doesn't make the pain go away when it comes to > > removing things like that. > > Sure it does. That's two whole generations of client tools. For > example, at that point, pgAdmin3 won't

Re: [HACKERS] pg_bsd_indent: implement -lps ("leave preprocessor space")

Andres Freund wrote: > On 2017-02-07 23:30:44 -0500, Tom Lane wrote: > > Piotr Stefaniak writes: > > > this is a patch that Andres asked me for. It makes pg_bsd_indent leave > > > preprocessor space alone, as in this example: > > > > > #if 0 > >

Re: [HACKERS] amcheck (B-Tree integrity checking tool)

Hi, On 2016-11-22 10:56:07 -0800, Peter Geoghegan wrote: > Andres said: "Theoretically we should recheck that the oids still > match, theoretically the locking here allows the index->table mapping > to change". I don't know how to act on this feedback, since comparable > index + heap locking code

Re: [HACKERS] One-shot expanded output in psql using \gx

Re: David Fetter 2017-02-08 <20170208151214.ga8...@fetter.org> > Would you be open to saving the next person some work by doing > something similar to how \d is done, namely looking for an 'x' > modifier after g without regard to how far after? As of this writing, > the \d version starts at line

Re: [HACKERS] Proposal : For Auto-Prewarm.

On Thu, Feb 9, 2017 at 12:36 PM, Peter Geoghegan wrote: > On Tue, Feb 7, 2017 at 1:31 AM, Mithun Cy wrote: >> SEGFAULT was the coding mistake I have called the C-language function >> directly without initializing the functioncallinfo. Thanks for >>

[HACKERS] Latch reset ordering bug in condition_variable.c

Hi, ConditionVariablePrepareToSleep() has a race that can leave you hanging, introduced by me in the v4 patch. The problem is that that function resets our latch after adding our process to the wakeup list. With the right timing, the following sequence can happen: 1.

Re: [HACKERS] Parallel Index Scans

On Thu, Feb 9, 2017 at 12:08 PM, Peter Geoghegan wrote: > On Wed, Feb 8, 2017 at 10:33 PM, Amit Kapila wrote: >> I had some offlist discussion with Robert about the above point and we >> feel that keeping only heap pages for parallel computation might not

Re: [HACKERS] Improve OR conditions on joined columns (common star schema problem)

On 2/8/17 5:54 PM, Tom Lane wrote: Although ... actually, that may not be the bottleneck for what you're after. The issue here is not so much discovering a clever plan for a union as realizing that the query could be cast as a union in the first place. Right; their current workaround is to

Re: [HACKERS] amcheck (B-Tree integrity checking tool)

On Thu, Feb 9, 2017 at 4:57 PM, Andres Freund wrote: > On 2017-02-09 13:29:42 -0800, Peter Geoghegan wrote: >> > I'd really like to have something like relation_check(), index_check() >> > which calls the correct functions for the relevan index types (and >> > possibly warns

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Thu, Feb 9, 2017 at 5:09 PM, Thomas Munro wrote: > I agree that the pinned segment case doesn't matter right now, I just > wanted to point it out. I like your $10 wrench analogy, but maybe it > could be argued that adding a dsm_on_destroy() callback mechanism is

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

On Fri, Feb 10, 2017 at 10:16 AM, Stephen Frost wrote: >> As someone mentioned, forcing a user to install an extension makes >> the deprecation visible. Another option would be to have the backend >> spit out a WARNING the first time you access anything that's >> deprecated.

Re: [HACKERS] amcheck (B-Tree integrity checking tool)

On 2017-02-09 13:29:42 -0800, Peter Geoghegan wrote: > > I'd really like to have something like relation_check(), index_check() > > which calls the correct functions for the relevan index types (and > > possibly warns about !nbtree indexes not being checked?). > > I feel that that's something for

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Fri, Feb 10, 2017 at 9:51 AM, Robert Haas wrote: > On Wed, Feb 8, 2017 at 5:36 AM, Thomas Munro > wrote: >> Thinking a bit harder about this, I suppose there could be a kind of >> object called a SharedBufFileManager [... description of

Re: [HACKERS] amcheck (B-Tree integrity checking tool)

On Thu, Feb 9, 2017 at 2:32 PM, Andres Freund wrote: > Except that the proposed names aren't remotely like that... ;). > > And I proposed documenting named parameters, and > check_btree(performing_check_requiring_exclusive_locks => true) is just > about as expressive. I

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Fri, Feb 10, 2017 at 11:31 AM, Robert Haas wrote: > On Thu, Feb 9, 2017 at 5:09 PM, Thomas Munro > wrote: >> I agree that the pinned segment case doesn't matter right now, I just >> wanted to point it out. I like your $10 wrench analogy,

Re: [HACKERS] libpq Alternate Row Processor

On 2/8/17 5:11 PM, Kyle Gearhart wrote: Overall, wall clock improves 24%. User time elapsed is a 430% improvement. About half the time is spent waiting on the IO with the callback. With the regular pqRowProcessor only about 16% of the time is spent waiting on IO. To wit...

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

* Robert Haas (robertmh...@gmail.com) wrote: > On Thu, Feb 9, 2017 at 4:24 PM, Tom Lane wrote: > > Also, our experience with contrib/tsearch2 suggests that the extension > > shouldn't be part of contrib, because we have zero track record of getting > > rid of stuff in contrib,

Re: [HACKERS] amcheck (B-Tree integrity checking tool)

On Thu, Feb 9, 2017 at 2:47 PM, Peter Geoghegan wrote: >> which isn't an issue here, but reinforces my point about the (badly >> documented) assumption that we don't release locks on user relations >> early. > > You are right about the substantive issue, I assume, but I have a hard

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

* Josh Berkus (j...@berkus.org) wrote: > On 02/09/2017 05:19 PM, Michael Paquier wrote: > > On Fri, Feb 10, 2017 at 10:16 AM, Stephen Frost wrote: > >>> As someone mentioned, forcing a user to install an extension makes > >>> the deprecation visible. Another option would be to

Re: [HACKERS] amcheck (B-Tree integrity checking tool)

On 2017-02-09 17:12:58 -0500, Robert Haas wrote: > On Thu, Feb 9, 2017 at 4:57 PM, Andres Freund wrote: > > Meh. I don't think that's a serious problem, nor is without precedent > > (say same toplevel DDL with differing lock levels depending on > > options). Nor do the

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Thu, Feb 9, 2017 at 2:31 PM, Robert Haas wrote: > You might think about plugging that hole by moving the registry of > on-destroy functions into the segment itself and making it a shared > resource. But ASLR breaks that, especially for loadable modules. You > could try

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

On 2017-02-09 20:02:54 -0500, Stephen Frost wrote: > * Andres Freund (and...@anarazel.de) wrote: > > On 2017-02-09 19:19:21 -0500, Stephen Frost wrote: > > > I'd love to nuke pg_shadow and all the other > > > not-really-maintained backwards-compat things from when roles were > > > added too. > >

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

On 2/9/17 6:37 PM, Andres Freund wrote: Anybody who still wants tsearch2 can go get it from an old version, or somebody can maintain a fork on github. Works for me. +1 +1 I'd love to nuke pg_shadow and all the other not-really-maintained backwards-compat things from when roles were added

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

On 2017-02-09 19:19:21 -0500, Stephen Frost wrote: > * Robert Haas (robertmh...@gmail.com) wrote: > > On Thu, Feb 9, 2017 at 4:24 PM, Tom Lane wrote: > > > Also, our experience with contrib/tsearch2 suggests that the extension > > > shouldn't be part of contrib, because we

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

* Andres Freund (and...@anarazel.de) wrote: > On 2017-02-09 19:19:21 -0500, Stephen Frost wrote: > > I'd love to nuke pg_shadow and all the other > > not-really-maintained backwards-compat things from when roles were > > added too. > > Not sure if it's worth the work to rip out and such, but I'm

Re: [HACKERS] WAL consistency check facility

On Thu, Feb 9, 2017 at 5:56 AM, Robert Haas wrote: > On Wed, Feb 8, 2017 at 1:25 AM, Kuntal Ghosh > wrote: >> Thank you Robert for the review. Please find the updated patch in the >> attachment. > > I have committed this patch after fairly

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

Jim, * Jim Nasby (jim.na...@bluetreble.com) wrote: > On 2/9/17 6:37 PM, Andres Freund wrote: > >>I'd love to nuke pg_shadow and all the other > >>not-really-maintained backwards-compat things from when roles were > >>added too. > >Not sure if it's worth the work to rip out and such, but I'm

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

On 02/09/2017 05:19 PM, Michael Paquier wrote: > On Fri, Feb 10, 2017 at 10:16 AM, Stephen Frost wrote: >>> As someone mentioned, forcing a user to install an extension makes >>> the deprecation visible. Another option would be to have the backend >>> spit out a WARNING the

Re: [HACKERS] Provide list of subscriptions and publications in psql's completion

On Tue, Feb 7, 2017 at 6:35 AM, Peter Eisentraut wrote: > On 2/6/17 10:54 AM, Fujii Masao wrote: >> Yes, that's an option. And, if we add dbid to pg_stat_subscription, >> I'm tempted to add all the pg_subscription's columns except subconninfo >> into

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

On Thu, Feb 9, 2017 at 4:43 PM, Erik Rijkers wrote: > On 2017-02-09 22:15, Tom Lane wrote: > >> Corey Huinker writes: >> > > The feature now ( at patch v10) lets you break off with Ctrl-C anywhere. > I like it now much more. > > The main thing I still

Re: [HACKERS] Declarative partitioning - another take

On 2017/02/09 15:22, amul sul wrote: > About 0001-Check-partition-strategy-in-ATExecDropNotNull.patch, > following test is already covered in alter_table.sql @ Line # 1918, > instead of this kindly add test for list_partition: > > 77 +-- cannot drop NOT NULL constraint of a range partition key

Re: [HACKERS] Removal of deprecated views pg_user, pg_group, pg_shadow

Tom, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > The question of removing the pre-role, deprecated, views of pg_user, > > pg_group and pg_shadow has come up again. > > > I figured a new thread was in order, however, to allow others to weigh > > in on

Re: [HACKERS] pg_basebackup -R

On Thu, Feb 9, 2017 at 8:17 PM, Amit Kapila wrote: > +1. Sounds sensible thing to do. Hm. It seems to me that PGPASSFILE still needs to be treated as an exception because it is set to $HOME/.pgpass without any value set in PQconninfoOption->compiled and it depends on

Re: [HACKERS] contrib modules and relkind check

On Thu, Feb 9, 2017 at 7:21 AM, Corey Huinker wrote: > Is this still needing a reviewer? Useful input is always welcome. > Code is quite clear. It does raise two questions: > > 1. should have these tests named in core functions, like maybe: > >

Re: [HACKERS] possibility to specify template database for pg_regress

On Thu, Feb 9, 2017 at 5:13 AM, Pavel Stehule wrote: > here is a patch Thanks. - for (sl = dblist; sl; sl = sl->next) - create_database(sl->str); + if (templatelist != NULL) + { + _stringlist *tl; + + for (sl = dblist, tl

Re: [HACKERS] Removal of deprecated views pg_user, pg_group, pg_shadow

Stephen Frost writes: > The question of removing the pre-role, deprecated, views of pg_user, > pg_group and pg_shadow has come up again. > I figured a new thread was in order, however, to allow others to weigh > in on it. > Note that these views have not been consistently

[HACKERS] Partitioned tables and relfilenode

The new partitioned tables do not contain any data by themselves. Any data inserted into a partitioned table is routed to and stored in one of its partitions. In fact, it is impossible to insert *any* data before a partition (to be precise, a leaf partition) is created. It seems wasteful then

Re: [HACKERS] Improve OR conditions on joined columns (common star schema problem)

On Thu, Feb 9, 2017 at 9:50 PM, Jim Nasby wrote: > WHERE t1 IN ('a','b') OR t2 IN ('c','d') > > into > > WHERE f1 IN (1,2) OR f2 IN (3,4) > > (assuming a,b,c,d maps to 1,2,3,4) > > BTW, there's an important caveat here: users generally do NOT want duplicate > rows from

[HACKERS] Removal of deprecated views pg_user, pg_group, pg_shadow

Greetings, The question of removing the pre-role, deprecated, views of pg_user, pg_group and pg_shadow has come up again. I figured a new thread was in order, however, to allow others to weigh in on it. Note that these views have not been consistently maintained and have ended up including some

Re: [HACKERS] Documentation improvements for partitioning

Hi Corey, On 2017/02/09 6:14, Corey Huinker wrote: > On Fri, Feb 3, 2017 at 4:15 AM, Amit Langote > wrote: > >> Here are some patches to improve the documentation about partitioned >> tables: > > Patch applies. > > Overall this looks really good. It goes a long

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

Hello Corey, Changes in this patch: - invalid boolean expression on \if or \elif is treated as if the script had a bad \command, so it either stops the script (ON_ERROR_STOP, script mode), or just gives the ParseVariableBool error and continues. - All interactive "barks" removed except

Re: [HACKERS] Partitioned tables and relfilenode

On 10 February 2017 at 06:19, Amit Langote wrote: > The new partitioned tables do not contain any data by themselves. Any > data inserted into a partitioned table is routed to and stored in one of > its partitions. In fact, it is impossible to insert *any* data

Re: [HACKERS] contrib modules and relkind check

On 2017/02/10 14:32, Michael Paquier wrote: > On Thu, Feb 9, 2017 at 7:21 AM, Corey Huinker wrote: Thanks Corey and Michael for the reviews! >> 1. should have these tests named in core functions, like maybe: >> >> relation_has_visibility(Relation) >>

Re: [HACKERS] Partitioned tables and relfilenode

On 2017/02/10 15:58, Simon Riggs wrote: > On 10 February 2017 at 06:19, Amit Langote > wrote: >> The new partitioned tables do not contain any data by themselves. Any >> data inserted into a partitioned table is routed to and stored in one of >> its partitions. In

Re: [HACKERS] Patch: Avoid precision error in to_timestamp().

Hi Tom, and others, Thanks for the insightful feedback. You are right, the patch does suffer from overflow (and other possible issues when I think about it). Using rint(), as you suggest, helps in my original example case, but there are still cases when the output is not what you would expect.

Re: [HACKERS] Patch: Avoid precision error in to_timestamp().

Tom, You are of course right that you cannot add precision that was not there to begin with. My patch does nothing for input values that cannot be represented accurately to begin with. However, that was not my main point. The idea with the calculation is this: When you remove the

Re: [HACKERS] ICU integration

On 1/24/17 12:45 PM, Peter Eisentraut wrote: > On 1/9/17 3:45 PM, Peter Geoghegan wrote: >> * I think it's worth looking into ucol_nextSortKeyPart(), and using >> that as an alternative to ucol_getSortKey(). It doesn't seem any >> harder, and when I tested it it was clearly faster. (I think that

Re: [HACKERS] pageinspect: Hash index support

On Wed, Feb 8, 2017 at 11:26 PM, Robert Haas wrote: > On Wed, Feb 8, 2017 at 11:58 AM, Ashutosh Sharma > wrote: >>> And then, instead, you need to add some code to set bit based on the >>> bitmap page, like what you have: >>> >>> +mapbuf =

Re: [HACKERS] pg_basebackup -R

On Wed, Feb 8, 2017 at 11:38 PM, Robert Haas wrote: > I just tried out pg_basebackup -R and got the following recovery.conf file: > > standby_mode = 'on' > primary_conninfo = 'user=rhaas passfile=''/home/rhaas/.pgpass'' > port=5432 sslmode=disable sslcompression=1

Re: [HACKERS] logical decoding of two-phase transactions

> On 31 Jan 2017, at 12:22, Craig Ringer wrote: > > Personally I don't think lack of access to the GID justifies blocking 2PC > logical decoding. It can be added separately. But it'd be nice to have > especially if it's cheap. Agreed. > On 2 Feb 2017, at 00:35, Craig

Re: [HACKERS] One-shot expanded output in psql using \gx

On Thu, Feb 09, 2017 at 11:12:00AM +0100, Christoph Berg wrote: > Re: David Fetter 2017-02-08 <20170208151214.ga8...@fetter.org> > > Would you be open to saving the next person some work by doing > > something similar to how \d is done, namely looking for an 'x' > > modifier after g without regard

Re: [HACKERS] Patch: Avoid precision error in to_timestamp().

=?UTF-8?Q?Erik_Nordstr=C3=B6m?= writes: > Thanks for the insightful feedback. You are right, the patch does suffer > from overflow (and other possible issues when I think about it). Using > rint(), as you suggest, helps in my original example case, but there are > still

[HACKERS] Parameterization of partial path

When looking at try_partial_hashjoin_path and try_partial_nestloop_path functions I'm failing to understand the comment "Parameterized partial paths are not supported.". It's clear to me that GatherPath can't have parameters because repeated execution of parallel plan with adjusted parameters is

Re: [HACKERS] Write Ahead Logging for Hash Indexes

On Thu, Jan 12, 2017 at 10:23 PM, Amit Kapila wrote: > On Fri, Jan 13, 2017 at 1:04 AM, Jesper Pedersen > wrote: >> On 12/27/2016 01:58 AM, Amit Kapila wrote: >>> After recent commit's 7819ba1e and 25216c98, this patch requires a >>> rebase.

Re: [HACKERS] pageinspect: Hash index support

On Thu, Feb 9, 2017 at 8:56 AM, Ashutosh Sharma wrote: >> If you want to verify that the supplied page number is an overflow >> page before returning the bit, I think you should do that calculation >> based on the metapage. There's enough information in hashm_spares to >>

Re: [HACKERS] ICU integration

On Thu, Feb 9, 2017 at 7:58 AM, Peter Eisentraut wrote: > I think I have this sorted out. What I don't understand, however, is > why varstr_abbrev_convert() makes a point of looping until the result of > strxfrm() fits into the output buffer (buf2), when we only

Re: [HACKERS] Parameterization of partial path

On Thu, Feb 9, 2017 at 12:36 PM, Antonin Houska wrote: > When looking at try_partial_hashjoin_path and try_partial_nestloop_path > functions I'm failing to understand the comment "Parameterized partial paths > are not supported.". > > It's clear to me that GatherPath can't have

Re: [HACKERS] pageinspect: Hash index support

> I think you should just tighten up the sanity checking in the existing > function _hash_ovflblkno_to_bitno rather than duplicating the code. I > don't think it's called often enough for one extra (cheap) test to be > an issue. (You should change the elog in that function to an ereport, > too,

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

On Mon, Feb 6, 2017 at 12:29 PM, Magnus Hagander wrote: >> Here is what I have, 6 votes clearly stated: >> 1. Rename nothing: Daniel, >> 2. Rename directory only: Andres >> 3. Rename everything: Stephen, Vladimir, David S, Michael P (with >> aliases for functions, I could

[HACKERS] How to debug the wire protocol?

Hello, I’ve sent a similar email to the general mailing list but got no reply. I’m trying to write my own implementation of the wire protocol. I’m stuck at the Parse message where I send it to the server but always get the following error: “Could not parse statement invalid string in message”

Re: [HACKERS] How to debug the wire protocol?

Hi 2017-02-09 20:01 GMT+01:00 Rui Pacheco : > Hello, > > I’ve sent a similar email to the general mailing list but got no reply. > > I’m trying to write my own implementation of the wire protocol. I’m stuck > at the Parse message where I send it to the server but always

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

Robert Haas writes: > On Mon, Feb 6, 2017 at 12:29 PM, Magnus Hagander wrote: >>> Here is what I have, 6 votes clearly stated: >>> 1. Rename nothing: Daniel, >>> 2. Rename directory only: Andres >>> 3. Rename everything: Stephen, Vladimir, David S,

Re: [HACKERS] How to debug the wire protocol?

Not sure this solves my problem. I’d like to debug how the server is failing to parse my message, not what it looks like on the wire. I am the one forming the message after all. My apologies if I missed something. > On 9 Feb 2017, at 20:05, Pavel Stehule wrote: > >

Re: [HACKERS] How to debug the wire protocol?

Rui Pacheco writes: > I’ve sent a similar email to the general mailing list but got no reply. Uh, multiple people answered you, see https://www.postgresql.org/message-id/flat/22DB2E08-6329-4EF8-B3E5-C0A7728A067B%40gmail.com > Is there a way to see how Postgres parses the

Re: [HACKERS] How to debug the wire protocol?

2017-02-09 20:12 GMT+01:00 Rui Pacheco : > Not sure this solves my problem. I’d like to debug how the server is > failing to parse my message, not what it looks like on the wire. I am the > one forming the message after all. > > My apologies if I missed something. > > ok

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

On 2/9/17 2:14 PM, David G. Johnston wrote: > On Thu, Feb 9, 2017 at 12:08 PM, Tom Lane >wrote: > > Robert Haas > > writes: > > On Mon, Feb 6, 2017 at 12:29 PM, Magnus Hagander

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

On Thu, Feb 9, 2017 at 12:08 PM, Tom Lane wrote: > Robert Haas writes: > > On Mon, Feb 6, 2017 at 12:29 PM, Magnus Hagander > wrote: > >>> Here is what I have, 6 votes clearly stated: > >>> 1. Rename nothing: Daniel, > >>> 2.

Re: [HACKERS] How to debug the wire protocol?

I’ve been anxiously waiting for that reply but got nothing. I even mailed the mailing list manager again with no reply. And when I click on that link I get a server error: "An internal server error occurred.” But thanks, this helps me focus on the problem. > On 9 Feb 2017, at 20:15, Tom Lane