Re: [HACKERS] pg_dump with tables created in schemas created by extensions

2016-08-26 19:37 GMT-03:00 Tom Lane : > =?UTF-8?B?TWFydMOtbiBNYXJxdcOpcw==?= writes: >> Looking at this issue today, I found that we are not setting a >> dependency for an index created inside an extension. > > Surely the index has a dependency on a

Re: [HACKERS] WAL consistency check facility

On Fri, Aug 26, 2016 at 9:26 PM, Simon Riggs wrote: > > I think you should add this as part of the default testing for both > check and installcheck. I can't imagine why we'd have it and not use > it during testing. > The actual consistency checks are done during redo

Re: [HACKERS] OpenSSL 1.1 breaks configure and more

On 08/26/2016 07:04 PM, Heikki Linnakangas wrote: On 08/26/2016 07:44 PM, Tom Lane wrote: Peter Eisentraut writes: On 8/26/16 5:31 AM, Heikki Linnakangas wrote: I think now would be a good time to drop support for OpenSSL versions older than 0.9.8. OpenSSL

Re: [HACKERS] Renaming of pg_xlog and pg_clog

On Fri, Aug 26, 2016 at 8:31 PM, Simon Riggs wrote: > On 26 August 2016 at 04:39, Michael Paquier wrote: >> Hi all, >> >> I am relaunching $subject as 10 development will begin soon. As far as >> I know, there is agreement that we can do

Re: [HACKERS] Renaming of pg_xlog and pg_clog

Hi, On Fri, 2016-08-26 at 21:12 +0900, Michael Paquier wrote: > In short, with the current names, sometimes users think that pg_xlog > and pg_clog are just logs. And so it is fine to delete them to free up > space, corrupting their cluster, because they are just *logs*. ...and we also have

Re: [HACKERS] [Patch] RBTree iteration interface improvement

Hello, Heikki. Thank you for your attention to this patch! > This also seems to change the API so that instead of a single > rb_begin_iterate()+rb_iterate() pair, there is a separate begin and > iterate function for each traversal order. That seems like an unrelated > change. Was there a

Re: [HACKERS] [COMMITTERS] pgsql: Add the "snapshot too old" feature

On Thu, Aug 25, 2016 at 4:51 PM, Alvaro Herrera wrote: > Kevin Grittner wrote: >> On Thu, Aug 25, 2016 at 2:56 PM, Alvaro Herrera >> wrote: >> >> > I'm wondering about the TestForOldSnapshot call in scanPendingInsert(). >> > Why do we apply it

Re: [HACKERS] Showing parallel status in \df+

Pavel Stehule writes: > Using footer for this purpose is little bit strange. What about following > design? > 1. move out source code of PL functions from \df+ > 2. allow not unique filter in \sf and allow to display multiple functions Wasn't that proposed and rejected

Re: [HACKERS] patch proposal

* Venkata B Nagothi (nag1...@gmail.com) wrote: > On Fri, Aug 26, 2016 at 12:30 PM, Stephen Frost wrote: > > * Venkata B Nagothi (nag1...@gmail.com) wrote: > > > This behaviour will be similar to that of recovery_target="immediate" and > > > can be aliased. > > > > I don't

Re: [HACKERS] Odd oid-system-column handling in postgres_fdw

On 04/05/2016 11:15 AM, Etsuro Fujita wrote: On 2016/03/16 16:25, Etsuro Fujita wrote: PG9.5 allows us to add an oid system column to foreign tables, using ALTER FOREIGN TABLE SET WITH OIDS, but currently, that column reads as zeroes in postgres_fdw. That seems to me like a bug. So, I'd like

Re: [HACKERS] WAL consistency check facility

Kuntal Ghosh wrote: > Thanks a lot. > > I just want to mention the situation where I was getting the > speculative token related inconsistency. > > ItemPointer in backup page from master: > LOG: ItemPointer BlockNumber: 1 OffsetNumber:65534 Speculative: true > CONTEXT: xlog redo at 0/127F4A48

[HACKERS] shm_mq_set_sender() crash

Latest from lorikeet: http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=lorikeet=2016-08-26%2008%3A37%3A27 TRAP: FailedAssertion("!(vmq->mq_sender == ((void *)0))", File: "/home/andrew/bf64/root/REL9_6_STABLE/pgsql.build/../pgsql/src/backend/storage/ipc/shm_mq.c", Line: 220) Thoughts?

Re: [HACKERS] pg_xlogdump fails to handle WAL file with multi-page XLP_FIRST_IS_CONTRECORD data

On Wed, Mar 23, 2016 at 7:04 PM, Pavan Deolasee wrote: > > > On Wed, Mar 23, 2016 at 1:13 PM, Michael Paquier > wrote: >> >> >> + /* >> +* Compute targetRecOff. It should typically be greater than short >> +* page-header

[HACKERS] Unsupported feature F867: WITH TIES

Actually we don't support the SQL feature F867 "FETCH FIRST clause: WITH TIES option". On the other side we support the window function "rank()" which acts like the "WITH TIES option". My questions are: Is it hard to implement the "WITH TIES option"? Are there plans for a realization / how do

Re: [HACKERS] pg_dump with tables created in schemas created by extensions

Hi, 2016-08-25 8:10 GMT-03:00 Michael Paquier : > On Thu, Aug 25, 2016 at 10:25 AM, Martín Marqués > wrote: >> 2016-08-24 21:34 GMT-03:00 Michael Paquier : >>> >>> Yes, you are right. If I look at the diffs this

Re: [HACKERS] [sqlsmith] Failed assertion in joinrels.c

On Wed, Aug 17, 2016 at 6:10 PM, Robert Haas wrote: >> If you are making changes in plpgsql_validator(), then shouldn't we >> make changes in plperl_validator() or plpython_validator()? I see >> that you have made changes to function CheckFunctionValidatorAccess() >> which

Re: [HACKERS] Renaming of pg_xlog and pg_clog

On Fri, Aug 26, 2016 at 12:44 PM, Christoph Berg wrote: > Re: Fujii Masao 2016-08-26 cmzgv5u6oemxr-cbjro+w...@mail.gmail.com> > > > I agree on a hard break, unless we get pushback from users, and even > > > then, they can create the symlinks

Re: [HACKERS] increasing the default WAL segment size

On Wed, 24 Aug 2016 21:31:35 -0400 Robert Haas wrote: > Hi, > > I'd like to propose that we increase the default WAL segment size, > which is currently 16MB. It was first set to that value in commit > 47937403676d913c0e740eec6b85113865c6c8ab in October of 1999; prior to

Re: [HACKERS] Renaming of pg_xlog and pg_clog

Re: Fujii Masao 2016-08-26 > > I agree on a hard break, unless we get pushback from users, and even > > then, they can create the symlinks themselves. > > I strongly prefer symlink approach not to break many existing tools >

Re: [HACKERS] OpenSSL 1.1 breaks configure and more

On 07/05/2016 04:46 PM, Andreas Karlsson wrote: @@ -280,8 +287,9 @@ px_find_digest(const char *name, PX_MD **res) digest = px_alloc(sizeof(*digest)); digest->algo = md; - EVP_MD_CTX_init(>ctx); - if (EVP_DigestInit_ex(>ctx, digest->algo, NULL) == 0) +

Re: [HACKERS] Renaming of pg_xlog and pg_clog

On 26 August 2016 at 04:39, Michael Paquier wrote: > Hi all, > > I am relaunching $subject as 10 development will begin soon. As far as > I know, there is agreement that we can do something here. Among the > different proposals I have found: > - pg_clog renamed to

Re: [HACKERS] Simplifying the interface of UpdateMinRecoveryPoint

On 07/13/2016 04:25 PM, Michael Paquier wrote: On Wed, Jul 13, 2016 at 8:27 PM, Amit Kapila wrote: On Wed, Jul 13, 2016 at 9:19 AM, Michael Paquier wrote: Hence why not simplifying its interface and remove the force flag? One point to

Re: [HACKERS] Write Ahead Logging for Hash Indexes

On Thu, Aug 25, 2016 at 6:54 PM, Alvaro Herrera wrote: > Amit Kapila wrote: >> On Wed, Aug 24, 2016 at 11:46 PM, Alvaro Herrera >> wrote: > >> > Can you split the new xlog-related stuff to a new file, say hash_xlog.h, >> > instead of cramming

Re: [HACKERS] Declarative partitioning - another take

On 2016/08/18 5:23, Robert Haas wrote: > On Wed, Aug 17, 2016 at 2:21 AM, Amit Langote > wrote: >> I am slightly tempted to eliminate the pg_partition catalog and associated >> syscache altogether and add a column to pg_class as Robert suggested. >> That way, all

Re: [HACKERS] [Patch] RBTree iteration interface improvement

On 08/22/2016 01:00 PM, Aleksander Alekseev wrote: It seems clear to me that the existing arrangement is hazardous for any RBTree that hasn't got exactly one consumer. I think Aleksander's plan to decouple the iteration state is probably a good one (NB: I've not read the patch, so this is not

Re: [HACKERS] PG_DIAG_SEVERITY and a possible bug in pq_parse_errornotice()

Robert Haas writes: > I don't have strong feelings about this. Technically, this issue > affects 9.5 also, because pqmq.c was introduced in that release. I > don't think we want to add another error field in a released branch. > However, since there's no parallel query in

Re: [HACKERS] Set log_line_prefix and application name in test drivers

Hello Peter, log_line_prefix = '%t [%p]: [%l] %qapp=%a ' which is modeled after the pgfouine recommendation, which is I believe a wide-spread convention, and it also vaguely follows syslog customs. The build farm client has log_line_prefix = '%m [%c:%l] ' which is very similar, but the

Re: [HACKERS] PG_DIAG_SEVERITY and a possible bug in pq_parse_errornotice()

I wrote: > After sleeping on it, I think the right answer is to introduce the new > error-message field (and not worry about 9.5). Will work on a patch > for that, unless I hear objections pretty soon. BTW, while I'm looking at this: what on god's green earth is ThrowErrorData doing copying the

Re: [HACKERS] Renaming of pg_xlog and pg_clog

On 08/26/2016 03:48 AM, Magnus Hagander wrote: Same reason I'm also +1 for Stephens suggestion to put all things that should not be in a base backup into the same directory. That may break things now, but it will simplify things down the road. And doing it at the same time as renaming these

Re: [HACKERS] Renaming of pg_xlog and pg_clog

On 08/25/2016 07:39 PM, Michael Paquier wrote: Hi all, I am relaunching $subject as 10 development will begin soon. As far as I know, there is agreement that we can do something here. Among the different proposals I have found: - pg_clog renamed to pg_commit_status, pg_xact or pg_commit -

Re: [HACKERS] PG_DIAG_SEVERITY and a possible bug in pq_parse_errornotice()

Robert Haas writes: > On Fri, Aug 26, 2016 at 10:35 AM, Tom Lane wrote: >> BTW, while I'm looking at this: what on god's green earth is >> ThrowErrorData doing copying the supplied data into edata->assoc_context? >> Surely it should be putting the data

Re: [HACKERS] PG_DIAG_SEVERITY and a possible bug in pq_parse_errornotice()

I wrote: > After sleeping on it, I think the right answer is to introduce the new > error-message field (and not worry about 9.5). Will work on a patch > for that, unless I hear objections pretty soon. So far as I can find, the attached is all we need to do to introduce a new message field.

Re: [HACKERS] [PATCH] SortSupport for macaddr type

And here's a commitfest link: https://commitfest.postgresql.org/10/743/ Also, a correction to my original message: the unreferenced [1] footnote points back to the thread that included the patch for UUID SortSupport. [1]

Re: [HACKERS] PG_DIAG_SEVERITY and a possible bug in pq_parse_errornotice()

On Fri, Aug 26, 2016 at 11:26 AM, Tom Lane wrote: > Or in short, this has confused edata and newedata. Valid coding would > be > oldcontext = MemoryContextSwitchTo(newedata->assoc_context); > rather than what is there. Oh, right. >>> (Note that in the sole >>>

[HACKERS] old_snapshot_threshold documentation

I doubt the documentation for old_snapshot_threshold is going to be understood by many ordinary users. What is a "snapshot", first of all? Why would a snapshot be old? Why is that a problem? What can I do to avoid it? What are the circumstances in practice where this issue would arise, and

Re: [HACKERS] PG_DIAG_SEVERITY and a possible bug in pq_parse_errornotice()

Robert Haas writes: > On Fri, Aug 26, 2016 at 11:26 AM, Tom Lane wrote: >> I'm not quite sure what to do about this. It feels a tad wrong to use >> ErrorContext as the active context during HandleParallelMessages, but >> what else should we use? Maybe

Re: [HACKERS] Why is a newly created index contains the invalid LSN?

Amit Kapila wrote: On Thu, Aug 25, 2016 at 7:55 PM, Yury Zhuravlev wrote: Hello hackers. I have a small question. While working on an incremental backup I noticed a strange thing. Newly created index is contains the invalid LSN (0/0). Exmaple: ... For some of

Re: [HACKERS] WAL consistency check facility

Hi Kuntal, Thanks for the patch. Current patch has no docs, no tests and no explanatory comments, so makes review quite hard. The good news is you might discover a few bugs with it, so its worth pursuing actively in this CF, though its not near to being committable. I think you should add this

[HACKERS] Renaming some binaries

Hi, I'm bringing this $subject into discussion again. Historically, we are carrying binary names that have been confused newbies. createuser is the worst name so for. Also, names like createdb, initdb, reindexdb, and droplang does not suggest what product it is referring to. Adding a prefix (pg_,

Re: [HACKERS] Renaming of pg_xlog and pg_clog

Magnus Hagander writes: > On Aug 26, 2016 5:54 PM, "Peter Eisentraut" < > peter.eisentr...@2ndquadrant.com> wrote: >> If we're going to do some renaming, then I suggest we do a >> mini-file-system structure under $PGDATA, like >> >> $PGDATA/etc >> $PGDATA/log >> $PGDATA/run

Re: [HACKERS] PG_DIAG_SEVERITY and a possible bug in pq_parse_errornotice()

Tom Lane wrote: > So far as I can find, the attached is all we need to do to introduce a > new message field. (This patch doesn't address the memory-context > questions, but it does fix the localization-driven failure demonstrated > upthread.) > > Any objections? Anyone want to bikeshed the

Re: [HACKERS] PG_DIAG_SEVERITY and a possible bug in pq_parse_errornotice()

Alvaro Herrera writes: > Tom Lane wrote: >> Any objections? Anyone want to bikeshed the field name? I considered >> PG_DIAG_SEVERITY_NONLOCALIZED and PG_DIAG_SEVERITY_ENGLISH before settling >> on PG_DIAG_SEVERITY_ASCII, but I can't say I'm in love with that. > I

Re: [HACKERS] Renaming some binaries

On Fri, Aug 26, 2016 at 01:26:39PM -0300, Euler Taveira wrote: > Hi, > > I'm bringing this $subject into discussion again. Historically, we are > carrying binary names that have been confused newbies. createuser is the > worst name so for. Also, names like createdb, initdb, reindexdb, and >

Re: [HACKERS] Transactions involving multiple postgres foreign servers

On Fri, Aug 26, 2016 at 3:13 PM, Ashutosh Bapat wrote: > > > On Fri, Aug 26, 2016 at 11:37 AM, Masahiko Sawada > wrote: >> >> On Fri, Aug 26, 2016 at 3:03 PM, Ashutosh Bapat >> wrote: >> > >> > >> > On Fri,

Re: [HACKERS] OpenSSL 1.1 breaks configure and more

On 8/26/16 5:31 AM, Heikki Linnakangas wrote: > I think now would be a good time to drop support for OpenSSL versions > older than 0.9.8. OpenSSL don't even support 0.9.8 anymore, although > there are probably distributions out there that still provide patches > for it. But OpenSSL 0.9.7 and

Re: [HACKERS] OpenSSL 1.1 breaks configure and more

Peter Eisentraut writes: > On 8/26/16 5:31 AM, Heikki Linnakangas wrote: >> I think now would be a good time to drop support for OpenSSL versions >> older than 0.9.8. OpenSSL don't even support 0.9.8 anymore, although >> there are probably distributions out

Re: [HACKERS] OpenSSL 1.1 breaks configure and more

On 08/26/2016 07:44 PM, Tom Lane wrote: Peter Eisentraut writes: On 8/26/16 5:31 AM, Heikki Linnakangas wrote: I think now would be a good time to drop support for OpenSSL versions older than 0.9.8. OpenSSL don't even support 0.9.8 anymore, although there are

Re: [HACKERS] OpenSSL 1.1 breaks configure and more

Heikki Linnakangas writes: > Yeah, they want people to move to their own SSL library [1]. > [1] I couldn't find any official statement, but lots of blog posts > saying the same thing. As I recall, the deprecation warning messages said that in so many words. That probably

[HACKERS] [PATCH] SortSupport for macaddr type

Hello, I've attached a patch to add SortSupport for Postgres' macaddr which has the effect of improving the performance of sorting operations for the type. The strategy that I employ is very similar to that for UUID, which is to create abbreviated keys by packing as many bytes from the MAC

Re: [HACKERS] Renaming of pg_xlog and pg_clog

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Euler Taveira writes: > > On 26-08-2016 09:25, Devrim Gündüz wrote: > >> ...and we also have "pg_logical", that includes a "log" keyword already... > > > "clog" and "xlog" is almost "log"; "logical" is not. I don't imagine > > people

Re: [HACKERS] PG_DIAG_SEVERITY and a possible bug in pq_parse_errornotice()

On Fri, Aug 26, 2016 at 10:35 AM, Tom Lane wrote: > I wrote: >> After sleeping on it, I think the right answer is to introduce the new >> error-message field (and not worry about 9.5). Will work on a patch >> for that, unless I hear objections pretty soon. > > BTW, while I'm

Re: [HACKERS] Missing checks when malloc returns NULL...

Hello, Michael. Your patch [1] was marked as "Needs review" so I decided to take a look. It looks good to me. However I found dozens of places in PostgreSQL code that seem to have similar problem you are trying to fix [2]. As far as I understand these are only places left that don't check

Re: [HACKERS] Renaming of pg_xlog and pg_clog

On 26-08-2016 09:25, Devrim Gündüz wrote: > On Fri, 2016-08-26 at 21:12 +0900, Michael Paquier wrote: >> In short, with the current names, sometimes users think that pg_xlog >> and pg_clog are just logs. And so it is fine to delete them to free up >> space, corrupting their cluster, because they

Re: [HACKERS] Renaming of pg_xlog and pg_clog

Euler Taveira writes: > On 26-08-2016 09:25, Devrim Gündüz wrote: >> ...and we also have "pg_logical", that includes a "log" keyword already... > "clog" and "xlog" is almost "log"; "logical" is not. I don't imagine > people confusing "logical" meaning "log". Well, I

Re: [HACKERS] Renaming of pg_xlog and pg_clog

On Aug 26, 2016 5:13 PM, "Joshua D. Drake" wrote: > > On 08/25/2016 07:39 PM, Michael Paquier wrote: >> >> Hi all, >> >> I am relaunching $subject as 10 development will begin soon. As far as >> I know, there is agreement that we can do something here. Among the >>

Re: [HACKERS] GIN logging GIN_SEGMENT_UNMODIFIED actions?

On Tue, May 10, 2016 at 9:57 PM, Alexander Korotkov wrote: > Hi! > > On Mon, May 9, 2016 at 10:46 PM, Andres Freund wrote: >> >> trying to debug something I saw the following in pg_xlogdump output: >> >> rmgr: Gin len (rec/tot): 0/

Re: [HACKERS] Renaming of pg_xlog and pg_clog

On 8/25/16 10:39 PM, Michael Paquier wrote: > I am relaunching $subject as 10 development will begin soon. As far as > I know, there is agreement that we can do something here. Among the > different proposals I have found: > - pg_clog renamed to pg_commit_status, pg_xact or pg_commit > - pg_xlog

Re: [HACKERS] Renaming of pg_xlog and pg_clog

On Aug 26, 2016 5:54 PM, "Peter Eisentraut" < peter.eisentr...@2ndquadrant.com> wrote: > > On 8/25/16 10:39 PM, Michael Paquier wrote: > > I am relaunching $subject as 10 development will begin soon. As far as > > I know, there is agreement that we can do something here. Among the > > different

Re: [HACKERS] Unsupported feature F867: WITH TIES

On 8/26/16 9:06 AM, Jürgen Purtz wrote: > Actually we don't support the SQL feature F867 "FETCH FIRST clause: WITH > TIES option". On the other side we support the window function "rank()" > which acts like the "WITH TIES option". My questions are: Is it hard to > implement the "WITH TIES

Re: [HACKERS] Renaming of pg_xlog and pg_clog

On 26 August 2016 at 18:28, Tom Lane wrote: > Also, I'd just as soon not move/rename things that don't really need it. +1 Let's leave everything exactly as it is now... but put a small README in each directory to explain why files in it shouldn't be deleted to make space.

Re: [HACKERS] Renaming some binaries

On 08/26/2016 07:03 PM, David Fetter wrote: On Fri, Aug 26, 2016 at 01:26:39PM -0300, Euler Taveira wrote: Hi, ... >> initdb: we already have 'pg_ctl init' (since 9.0) and could remove initdb. Opinions? +1 for removing initdb. We can't just remove it because pg_ctl actually calls

Re: [HACKERS] Renaming of pg_xlog and pg_clog

On 2016-08-26 11:53:21 -0400, Peter Eisentraut wrote: > On 8/25/16 10:39 PM, Michael Paquier wrote: > > I am relaunching $subject as 10 development will begin soon. As far as > > I know, there is agreement that we can do something here. Among the > > different proposals I have found: > > - pg_clog

Re: [HACKERS] Why is a newly created index contains the invalid LSN?

On Fri, Aug 26, 2016 at 10:46 AM, Yury Zhuravlev wrote: > Now understand LSN strongly connected with WAL. > However how difficult put last system LSN instead 0? > It's not so important but will allow make use LSN more consistent. There might be performance

Re: [HACKERS] Why is a newly created index contains the invalid LSN?

On 2016-08-26 18:46:42 +0300, Yury Zhuravlev wrote: > Thanks all. > Now understand LSN strongly connected with WAL. > However how difficult put last system LSN instead 0? > It's not so important but will allow make use LSN more consistent. Maybe explain why you're interested in page lsns, that'd

Re: [HACKERS] Renaming some binaries

On 2016-08-26 13:26:39 -0300, Euler Taveira wrote: > I'm bringing this $subject into discussion again. Historically, we are > carrying binary names that have been confused newbies. createuser is the > worst name so for. Also, names like createdb, initdb, reindexdb, and > droplang does not suggest

Re: [HACKERS] Renaming of pg_xlog and pg_clog

On 2016-08-26 17:11:00 -0400, Peter Eisentraut wrote: > On 8/26/16 12:28 PM, Tom Lane wrote: > > Also, I'd just as soon not move/rename things > > that don't really need it. > > I'm just as happy with not changing anything. But if we're going to > rename stuff, let's at least think about

Re: [HACKERS] Renaming of pg_xlog and pg_clog

On 8/26/16 5:20 PM, Andres Freund wrote: > I do think there's an order of magnitude between the impact between > moving some and moving everything. And that's going to impact > cost/benefit calculations. > > Moving e.g. all ephemeral files into a (possibly configurable) directory > is going to

Re: [HACKERS] Renaming of pg_xlog and pg_clog

On 2016-08-26 17:31:14 -0400, Peter Eisentraut wrote: > I agree with all that. But the subject line is specifically about > moving pg_xlog. So if your opinion is that we shouldn't move pg_xlog, > then that is noted. But if we were to move it, we can think about a > good place to move it to. I

Re: [HACKERS] Renaming of pg_xlog and pg_clog

On 8/26/16 11:58 AM, Magnus Hagander wrote: > $PGDATA/etc >> $PGDATA/log >> $PGDATA/run (lock files etc.) >> $PGDATA/tmp >> $PGDATA/var >> >> The names of all the things under "var" could still be refined, but it's >> much less likely that users will confuse data with configuration or >> plain

Re: [HACKERS] Renaming of pg_xlog and pg_clog

On 8/26/16 12:28 PM, Tom Lane wrote: > Also, I'd just as soon not move/rename things > that don't really need it. I'm just as happy with not changing anything. But if we're going to rename stuff, let's at least think about something slightly more comprehensive. Any rename is going to break a

Re: [HACKERS] Renaming of pg_xlog and pg_clog

On 8/26/16 4:02 PM, Joshua D. Drake wrote: > Although... wouldn't run be under var? Traditionally yes, but things are changing in this area, if you consider the top-level file system of a modern Linux distribution. One reason is that "run" is/can be blown away at reboot. This wouldn't be an

Re: [HACKERS] Renaming some binaries

On 8/26/16 12:26 PM, Euler Taveira wrote: > initdb: we already have 'pg_ctl init' (since 9.0) and could remove initdb. I have a concern specifically about pg_ctl. Depending on how your PostgreSQL is packaged, not all of the pg_ctl actions are safe or sensible to run. For example, if you are

Re: [HACKERS] Renaming some binaries

On Fri, Aug 26, 2016 at 04:33:47PM -0300, Euler Taveira wrote: > On 26-08-2016 14:03, David Fetter wrote: > > Would these make sense as pg_ctl options, or are you separating them > > out because they're not instance-wide? If separating them is > > important on those grounds, how about something

Re: [HACKERS] Renaming some binaries

On 26-08-2016 14:03, David Fetter wrote: > Would these make sense as pg_ctl options, or are you separating them > out because they're not instance-wide? If separating them is > important on those grounds, how about something like pg_db or > pg_db_command? > It doesn't make sense because pg_ctl

Re: [HACKERS] Renaming some binaries

On 26 August 2016 at 18:26, Euler Taveira wrote: > I'm bringing this $subject into discussion again. Historically, we are > carrying binary names that have been confused newbies. createuser is the > worst name so for. Also, names like createdb, initdb, reindexdb, and >

Re: [HACKERS] Renaming some binaries

On 2016-08-26 15:03, Andres Freund wrote: On 2016-08-26 22:01:58 +0200, Simon Riggs wrote: On 26 August 2016 at 18:26, Euler Taveira wrote: > I'm bringing this $subject into discussion again. Historically, we are > carrying binary names that have been confused newbies.

Re: [HACKERS] Renaming of pg_xlog and pg_clog

On 08/26/2016 09:28 AM, Tom Lane wrote: Magnus Hagander writes: On Aug 26, 2016 5:54 PM, "Peter Eisentraut" < peter.eisentr...@2ndquadrant.com> wrote: If we're going to do some renaming, then I suggest we do a mini-file-system structure under $PGDATA, like $PGDATA/etc

Re: [HACKERS] Renaming some binaries

On 2016-08-26 22:01:58 +0200, Simon Riggs wrote: > On 26 August 2016 at 18:26, Euler Taveira wrote: > > > I'm bringing this $subject into discussion again. Historically, we are > > carrying binary names that have been confused newbies. createuser is the > > worst name so

Re: [HACKERS] Renaming some binaries

Simon Riggs wrote: > On 26 August 2016 at 18:26, Euler Taveira wrote: > > > I'm bringing this $subject into discussion again. Historically, we are > > carrying binary names that have been confused newbies. createuser is the > > worst name so for. Also, names like createdb,

Re: [HACKERS] pg_dump with tables created in schemas created by extensions

Hi, 2016-08-26 10:53 GMT-03:00 Martín Marqués : > > There's still one issue, which I'll add a test for as well, which is > that if the index was created by the extension, it will be dumped > anyway. I'll have a look at that as well. Looking at this issue today, I found

Re: [HACKERS] pg_dump with tables created in schemas created by extensions

On 08/27/2016 12:37 AM, Tom Lane wrote: =?UTF-8?B?TWFydMOtbiBNYXJxdcOpcw==?= writes: Looking at this issue today, I found that we are not setting a dependency for an index created inside an extension. Surely the index has a dependency on a table, which depends on the

Re: [HACKERS] pg_dump with tables created in schemas created by extensions

=?UTF-8?B?TWFydMOtbiBNYXJxdcOpcw==?= writes: > Looking at this issue today, I found that we are not setting a > dependency for an index created inside an extension. Surely the index has a dependency on a table, which depends on the extension? If you mean that you want an

Re: [HACKERS] pg_dump with tables created in schemas created by extensions

Tomas Vondra writes: > On 08/27/2016 12:37 AM, Tom Lane wrote: >> If you mean that you want an extension to create an index on a table >> that doesn't belong to it, but it's assuming pre-exists, I think >> that's just stupid and we need not support it. > I don't see

Re: [HACKERS] pg_dump with tables created in schemas created by extensions

On 08/26/2016 04:15 PM, Tomas Vondra wrote: On 08/27/2016 12:37 AM, Tom Lane wrote: =?UTF-8?B?TWFydMOtbiBNYXJxdcOpcw==?= writes: Looking at this issue today, I found that we are not setting a dependency for an index created inside an extension. Surely the index has a

Re: [HACKERS] Transactions involving multiple postgres foreign servers

On Fri, Aug 26, 2016 at 11:22 AM, Masahiko Sawada wrote: > On Fri, Aug 26, 2016 at 1:32 PM, Vinayak Pokale > wrote: > > Hi All, > > > > Ashutosh proposed the feature 2PC for FDW for achieving atomic commits > > across multiple foreign servers. > > If

Re: [HACKERS] Transactions involving multiple postgres foreign servers

On Fri, Aug 26, 2016 at 3:03 PM, Ashutosh Bapat wrote: > > > On Fri, Aug 26, 2016 at 11:22 AM, Masahiko Sawada > wrote: >> >> On Fri, Aug 26, 2016 at 1:32 PM, Vinayak Pokale >> wrote: >> > Hi All, >> > >> > Ashutosh

Re: [HACKERS] Transactions involving multiple postgres foreign servers

On Fri, Aug 26, 2016 at 11:37 AM, Masahiko Sawada wrote: > On Fri, Aug 26, 2016 at 3:03 PM, Ashutosh Bapat > wrote: > > > > > > On Fri, Aug 26, 2016 at 11:22 AM, Masahiko Sawada > > > wrote: > >> > >> On Fri, Aug

Re: [HACKERS] WAL consistency check facility

Thanks a lot. I just want to mention the situation where I was getting the speculative token related inconsistency. ItemPointer in backup page from master: LOG: ItemPointer BlockNumber: 1 OffsetNumber:65534 Speculative: true CONTEXT: xlog redo at 0/127F4A48 for Heap/INSERT+INIT: off 1

Re: [HACKERS] patch proposal

On Fri, Aug 26, 2016 at 12:30 PM, Stephen Frost wrote: > * Venkata B Nagothi (nag1...@gmail.com) wrote: > > On Thu, Aug 25, 2016 at 10:59 PM, Stephen Frost > wrote: > > > I'm not a fan of the "recovery_target" option, particularly as it's > only > > > got