[HACKERS] pg_dump, pg_dumpall and data durability

2016-10-12 Thread Michael Paquier
Hi all, In my quest of making the backup tools more compliant to data durability, here is a thread for pg_dump and pg_dumpall. Here is in a couple of lines my proposal: - Addition in _archiveHandle of a field to track if the dump generated should be synced or not. - This is effective for all

[HACKERS] Mention to pg_backup in pg_dump.c

2016-10-12 Thread Michael Paquier
Hi all, I just bumped into the following thing in pg_dump.c: /* Set default options based on progname */ if (strcmp(progname, "pg_backup") == 0) format = "c"; As far as I can see this comes from e8f69be0 dated of 2000. Couldn't this be removed? I have never seen traces of

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2016-10-12 Thread Vitaly Burovoy
On 10/12/16, Tom Lane wrote: > Alvaro Herrera writes: >> Tom Lane wrote: >>> Vitaly Burovoy writes: P.S.: I still think it is a good idea to change storage format, >>> I'm not sure which part of "no" you didn't

Re: [HACKERS] Change of extension name to new name

2016-10-12 Thread Tom Lane
Haribabu Kommi writes: > As we are planning to change an extension name from one name to another > name because of additional features that are added into this extension, The usual approach to that is just to increase the version number. Why is it necessary to change

Re: [HACKERS] Re: [COMMITTERS] pgsql: Extend framework from commit 53be0b1ad to report latch waits.

2016-10-12 Thread Michael Paquier
On Thu, Oct 13, 2016 at 8:38 AM, Andres Freund wrote: > On 2016-10-12 11:18:57 -0400, Peter Eisentraut wrote: >> On 10/4/16 11:29 AM, Tom Lane wrote: >> > Robert Haas writes: >> >> Apparently, 'make world' does not build worker_spi. I thought 'make >>

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2016-10-12 Thread Haribabu Kommi
On Thu, Oct 13, 2016 at 7:59 AM, Tom Lane wrote: > Alvaro Herrera writes: > > Tom Lane wrote: > >> Vitaly Burovoy writes: > >>> P.S.: I still think it is a good idea to change storage format, > > >> I'm not sure which part

[HACKERS] Change of extension name to new name

2016-10-12 Thread Haribabu Kommi
Hi All, As we are planning to change an extension name from one name to another name because of additional features that are added into this extension, so the name is not matching, so we decided to change the name, but it is causing problem to the already existing installations with old extension

Re: [HACKERS] parallel.sgml

2016-10-12 Thread Tatsuo Ishii
> On Thu, Oct 13, 2016 at 10:57 AM, Tatsuo Ishii wrote: >>> While reading parallel.sgml, I met with following sentence. >>> >>> If this occurs, the leader will execute the portion of the plan >>> between below the Gather node entirely by itself, >>> almost as if

Re: [HACKERS] Non-empty default log_line_prefix

2016-10-12 Thread Alvaro Herrera
Peter Eisentraut wrote: > On 10/12/16 11:58 AM, Christoph Berg wrote: > > (Yes, the '' default might be fine for syslog, but I don't think > > that's a good argument for sticking with it for default installs. I've > > seen way too many useless log files out there, and at worst we'll have > >

[HACKERS] Parallel Index Scans

2016-10-12 Thread Amit Kapila
As of now, the driving table for parallel query is accessed by parallel sequential scan which limits its usage to a certain degree. Parallelising index scans would further increase the usage of parallel query in many more cases. This patch enables the parallelism for the btree scans. Supporting

Re: [HACKERS] parallel.sgml

2016-10-12 Thread Michael Paquier
On Thu, Oct 13, 2016 at 10:57 AM, Tatsuo Ishii wrote: >> While reading parallel.sgml, I met with following sentence. >> >> If this occurs, the leader will execute the portion of the plan >> between below the Gather node entirely by itself, >> almost as if the

Re: [HACKERS] Non-empty default log_line_prefix

2016-10-12 Thread Peter Eisentraut
On 10/12/16 11:58 AM, Christoph Berg wrote: > (Yes, the '' default might be fine for syslog, but I don't think > that's a good argument for sticking with it for default installs. I've > seen way too many useless log files out there, and at worst we'll have > syslogs with two timestamps.) We'd

Re: [HACKERS] Non-empty default log_line_prefix

2016-10-12 Thread Peter Eisentraut
On 10/12/16 11:40 AM, Tom Lane wrote: > There would be some value in the complexity you're thinking of for > installations that log to multiple targets concurrently, but really, > who does that? I see that a lot. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

2016-10-12 Thread Tomas Vondra
On 10/12/2016 08:55 PM, Robert Haas wrote: > On Wed, Oct 12, 2016 at 3:21 AM, Dilip Kumar wrote: >> I think at higher client count from client count 96 onwards contention >> on CLogControlLock is clearly visible and which is completely solved >> with group lock patch. >> >>

Re: [HACKERS] parallel.sgml

2016-10-12 Thread Tatsuo Ishii
> While reading parallel.sgml, I met with following sentence. > > If this occurs, the leader will execute the portion of the plan > between below the Gather node entirely by itself, > almost as if the Gather node were not present. > > Maybe "the portion of the plan between below"

Re: [HACKERS] Proposal: scan key push down to heap [WIP]

2016-10-12 Thread Dilip Kumar
On Thu, Oct 13, 2016 at 6:05 AM, Robert Haas wrote: > I seriously doubt that this should EVER be supported for anything > other than "var op const", and even then only for very simple > operators. Yes, with existing key push down infrastructure only "var op const", but If

[HACKERS] Typo in foreign.h

2016-10-12 Thread Amit Langote
Attached fixes a minor typo: s/Thes/These/g Thanks, Amit diff --git a/src/include/foreign/foreign.h b/src/include/foreign/foreign.h index 5dc2c90..143566a 100644 --- a/src/include/foreign/foreign.h +++ b/src/include/foreign/foreign.h @@ -23,7 +23,7 @@ /* * Generic option types for

Re: [HACKERS] Proposal: scan key push down to heap [WIP]

2016-10-12 Thread Robert Haas
On Tue, Oct 11, 2016 at 4:57 AM, Dilip Kumar wrote: > This patch will extract the expression from qual and prepare the scan > keys. Currently in POC version I have only supported "var OP const" > type of qual, because these type of quals can be pushed down using > existing

Re: [HACKERS] Is it time to kill support for very old servers?

2016-10-12 Thread Robert Haas
On Tue, Oct 11, 2016 at 11:34 AM, Heikki Linnakangas wrote: > On 10/11/2016 08:23 PM, Tom Lane wrote: >> Not sure where to go from here, but the idea of dropping V2 support >> is seeming attractive again. Or we could just continue the policy >> of benign neglect. > > Let's drop

Re: [HACKERS] another typo in parallel.sgml

2016-10-12 Thread Robert Haas
On Mon, Oct 10, 2016 at 5:40 PM, Tatsuo Ishii wrote: > I think I found a typo in parallel.sgml. I think so, too. Committed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Remove vacuum_defer_cleanup_age

2016-10-12 Thread Robert Haas
On Sun, Oct 9, 2016 at 9:51 PM, Josh Berkus wrote: > Given that hot_standby_feedback is pretty bulletproof now, and a lot of > the work in reducing replay conflicts, I think the utility of > vacuum_defer_cleanup_age is at an end. I really meant so submit a patch > to remove it

Re: [HACKERS] Rename max_parallel_degree?

2016-10-12 Thread Robert Haas
On Wed, Oct 12, 2016 at 8:13 AM, Peter Eisentraut wrote: > On 10/4/16 10:16 AM, Julien Rouhaud wrote: >> Please find attached v9 of the patch, adding the parallel worker class >> and changing max_worker_processes default to 16 and max_parallel_workers >> to 8. I

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2016-10-12 Thread Haribabu Kommi
On Thu, Oct 13, 2016 at 7:31 AM, Vitaly Burovoy wrote: > Haribabu Kommi, why have you read enough about EUI-64? > Your function "macaddr64_trunc" sets 4 lower bytes as 0 whereas > (according to the Wikipedia, but I can look for a standard) 3 bytes > are still define an

Re: [HACKERS] Re: [COMMITTERS] pgsql: Extend framework from commit 53be0b1ad to report latch waits.

2016-10-12 Thread Andres Freund
On 2016-10-12 11:18:57 -0400, Peter Eisentraut wrote: > On 10/4/16 11:29 AM, Tom Lane wrote: > > Robert Haas writes: > >> Apparently, 'make world' does not build worker_spi. I thought 'make > >> world' was supposed to build everything? > > > > You'd have thunk, yeah. It

Re: [HACKERS] munmap() failure due to sloppy handling of hugepage size

2016-10-12 Thread Merlin Moncure
On Wed, Oct 12, 2016 at 5:18 PM, Tom Lane wrote: > Merlin Moncure writes: >> ISTM all this silliness is pretty much unique to linux anyways. >> Instead of reading the filesystem, what about doing test map and test >> unmap? > > And if mmap succeeds and

Re: [HACKERS] pg_dump getBlobs query broken for 7.3 servers

2016-10-12 Thread Robert Haas
On Wed, Oct 12, 2016 at 12:24 PM, Tom Lane wrote: > Robert Haas writes: >> On Wed, Oct 12, 2016 at 11:54 AM, Greg Stark wrote: >>> Fwiw I was considering proposing committing some patches for these old >>> releases to make them easier to

Re: [HACKERS] munmap() failure due to sloppy handling of hugepage size

2016-10-12 Thread Andres Freund
On 2016-10-12 16:33:38 -0400, Tom Lane wrote: > Andres Freund writes: > > On October 12, 2016 1:25:54 PM PDT, Tom Lane wrote: > >> A little bit of research suggests that on Linux the thing to do would > >> be to get the actual default hugepage size by

Re: [HACKERS] munmap() failure due to sloppy handling of hugepage size

2016-10-12 Thread Tom Lane
Merlin Moncure writes: > ISTM all this silliness is pretty much unique to linux anyways. > Instead of reading the filesystem, what about doing test map and test > unmap? And if mmap succeeds and munmap fails, you'll recover how exactly? If this API were less badly designed,

Re: [HACKERS] munmap() failure due to sloppy handling of hugepage size

2016-10-12 Thread Merlin Moncure
On Wed, Oct 12, 2016 at 5:10 PM, Tom Lane wrote: > Alvaro Herrera writes: >> Tom Lane wrote: >>> According to >>> https://www.kernel.org/doc/Documentation/vm/hugetlbpage.txt >>> looking into /proc/meminfo is the longer-standing API and thus is >>>

Re: [HACKERS] logical replication connection information management

2016-10-12 Thread Alvaro Herrera
Peter Eisentraut wrote: > An idea is to make the foreign server concept more general and allow > it to exist independently of a foreign data wrapper. Then create more > specific syntax like > > CREATE SERVER node1 FOR SUBSCRIPTION OPTIONS ( ... ); > > or > > CREATE SUBSCRIPTION SERVER

Re: [HACKERS] munmap() failure due to sloppy handling of hugepage size

2016-10-12 Thread Tom Lane
Alvaro Herrera writes: > Tom Lane wrote: >> According to >> https://www.kernel.org/doc/Documentation/vm/hugetlbpage.txt >> looking into /proc/meminfo is the longer-standing API and thus is >> likely to work on more kernel versions. Also, if you look into >> /sys then

Re: [HACKERS] Add PGDLLEXPORT to PG_FUNCTION_INFO_V1

2016-10-12 Thread Tom Lane
I wrote: > Well, the buildfarm doesn't like that even a little bit. It seems that > the MSVC compiler does not like seeing both "extern Datum foo(...)" and > "extern PGDLLEXPORT Datum foo(...)", so anything that had an extern in > a .h file is failing. There is also quite a bit of

[HACKERS] Add support for SRF and returning composites to pl/tcl

2016-10-12 Thread Jim Nasby
Attached is a patch that adds support for SRFs and returning composites from pl/tcl. This work was sponsored by Flight Aware. -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble!

Re: [HACKERS] munmap() failure due to sloppy handling of hugepage size

2016-10-12 Thread Alvaro Herrera
Tom Lane wrote: > Andres Freund writes: > > On October 12, 2016 1:25:54 PM PDT, Tom Lane wrote: > >> A little bit of research suggests that on Linux the thing to do would > >> be to get the actual default hugepage size by reading /proc/meminfo and > >>

Re: [HACKERS] FTS Configuration option

2016-10-12 Thread Artur Zakirov
Thank you for sharing your thoughts! 2016-10-12 15:08 GMT+03:00 Emre Hasegeli : > However then the stemmer doesn't do a good job on those words, because > the changed characters are important for the language. What I really > needed was something like this: > >> ALTER TEXT

Re: [HACKERS] Add PGDLLEXPORT to PG_FUNCTION_INFO_V1

2016-10-12 Thread Tom Lane
I wrote: > Albe Laurenz writes: >> Tom Lane wrote: >>> I'm okay with adding PGDLLEXPORT to the extern, but we should update >>> that comment to note that it's not necessary with any of our standard >>> Windows build processes. (For that matter, the comment fails to

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2016-10-12 Thread Vitaly Burovoy
On 10/12/16, Tom Lane wrote: > Vitaly Burovoy writes: >> I'm sorry for the offtopic, but does anyone know a reason why a >> condition in mac.c > >>> if ((a < 0) || (a > 255) || (b < 0) || (b > 255) || >>> (c < 0) || (c > 255) || (d < 0) || (d >

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2016-10-12 Thread Tom Lane
Alvaro Herrera writes: > Tom Lane wrote: >> Vitaly Burovoy writes: >>> P.S.: I still think it is a good idea to change storage format, >> I'm not sure which part of "no" you didn't understand, but we're >> not breaking on-disk compatibility of

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2016-10-12 Thread Tom Lane
Vitaly Burovoy writes: > I'm sorry for the offtopic, but does anyone know a reason why a > condition in mac.c >> if ((a < 0) || (a > 255) || (b < 0) || (b > 255) || >> (c < 0) || (c > 255) || (d < 0) || (d > 255) || >> (e < 0) || (e > 255) || (f < 0) || (f > 255)) >

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2016-10-12 Thread Alvaro Herrera
Tom Lane wrote: > Vitaly Burovoy writes: > > P.S.: I still think it is a good idea to change storage format, > > I'm not sure which part of "no" you didn't understand, but we're > not breaking on-disk compatibility of existing macaddr columns. > Breaking the on-the-wire

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2016-10-12 Thread Tom Lane
Vitaly Burovoy writes: > P.S.: I still think it is a good idea to change storage format, I'm not sure which part of "no" you didn't understand, but we're not breaking on-disk compatibility of existing macaddr columns. Breaking the on-the-wire binary I/O representation

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2016-10-12 Thread Vitaly Burovoy
I'm sorry for the offtopic, but does anyone know a reason why a condition in mac.c > if ((a < 0) || (a > 255) || (b < 0) || (b > 255) || > (c < 0) || (c > 255) || (d < 0) || (d > 255) || > (e < 0) || (e > 255) || (f < 0) || (f > 255)) can not be rewritten as: > if (((a | b | c | d | e |

Re: [HACKERS] munmap() failure due to sloppy handling of hugepage size

2016-10-12 Thread Tom Lane
Andres Freund writes: > On October 12, 2016 1:25:54 PM PDT, Tom Lane wrote: >> A little bit of research suggests that on Linux the thing to do would >> be to get the actual default hugepage size by reading /proc/meminfo and >> looking for a line like

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2016-10-12 Thread Vitaly Burovoy
On 10/12/16, Vitaly Burovoy wrote: > On 10/12/16, Alvaro Herrera wrote: >> Julien Rouhaud wrote: >>> On 12/10/2016 14:32, Alvaro Herrera wrote: >>> > Julien Rouhaud wrote: >>> > >>> >> and you can instead make macaddr64 support both format, and

Re: [HACKERS] munmap() failure due to sloppy handling of hugepage size

2016-10-12 Thread Andres Freund
On October 12, 2016 1:25:54 PM PDT, Tom Lane wrote: >If any of you were following the thread at >https://www.postgresql.org/message-id/flat/CAOan6TnQeSGcu_627NXQ2Z%2BWyhUzBjhERBm5RN9D0QFWmk7PoQ%40mail.gmail.com >I spent quite a bit of time following a bogus theory, but the

[HACKERS] munmap() failure due to sloppy handling of hugepage size

2016-10-12 Thread Tom Lane
If any of you were following the thread at https://www.postgresql.org/message-id/flat/CAOan6TnQeSGcu_627NXQ2Z%2BWyhUzBjhERBm5RN9D0QFWmk7PoQ%40mail.gmail.com I spent quite a bit of time following a bogus theory, but the problem turns out to be very simple: on Linux, munmap() is pickier than mmap()

Re: [HACKERS] pg_dump getBlobs query broken for 7.3 servers

2016-10-12 Thread Tom Lane
Robert Haas writes: > On Wed, Oct 12, 2016 at 11:54 AM, Greg Stark wrote: >> Fwiw I was considering proposing committing some patches for these old >> releases to make them easier to build. I would suggest creating a tag >> for a for this stable legacy

Re: [HACKERS] Non-empty default log_line_prefix

2016-10-12 Thread Stephen Frost
* Robert Haas (robertmh...@gmail.com) wrote: > On Wed, Oct 12, 2016 at 11:20 AM, Christoph Berg wrote: > > Re: Jeff Janes 2016-10-12 > >

Re: [HACKERS] Non-empty default log_line_prefix

2016-10-12 Thread Devrim Gündüz
Hi, On Wed, 2016-10-12 at 13:11 -0400, Tom Lane wrote: > > What is the cost of using %m, other than 4 (rather compressible) bytes per > > log entry? > > More log I/O, which is not free ... FWIW, we've been setting log_line_prefix to '< %m > ' for quite a long time in PGDG RPMs, and did not get

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

2016-10-12 Thread Peter Geoghegan
On Wed, Oct 12, 2016 at 11:09 AM, Robert Haas wrote: > I realize that you are primarily targeting utility commands here, and > that is obviously great, because making index builds faster is very > desirable. However, I'd just like to talk for a minute about how this >

Re: [HACKERS] pg_dump getBlobs query broken for 7.3 servers

2016-10-12 Thread Robert Haas
On Wed, Oct 12, 2016 at 11:54 AM, Greg Stark wrote: > On Mon, Oct 10, 2016 at 9:52 PM, Greg Stark wrote: >> >> The code is here: >> >> https://github.com/gsstark/retropg >> >> The build script is called "makeall" and it applies patches from the >>

Re: [HACKERS] Non-empty default log_line_prefix

2016-10-12 Thread Robert Haas
On Wed, Oct 12, 2016 at 11:20 AM, Christoph Berg wrote: > Re: Jeff Janes 2016-10-12 >

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

2016-10-12 Thread Robert Haas
On Wed, Oct 12, 2016 at 3:21 AM, Dilip Kumar wrote: > I think at higher client count from client count 96 onwards contention > on CLogControlLock is clearly visible and which is completely solved > with group lock patch. > > And at lower client count 32,64 contention on

Re: [HACKERS] int2vector and btree indexes

2016-10-12 Thread Tom Lane
Amit Langote writes: > On 2016/10/11 21:40, Tom Lane wrote: >> Hmm ... I kind of wonder why we have int2vectoreq or hashint2vector at >> all, likewise the hash opclass based on them. > Agreed. So how about the attached patch to remove the said infrastructure?

Re: [HACKERS] pg_dump getBlobs query broken for 7.3 servers

2016-10-12 Thread Greg Stark
On Mon, Oct 10, 2016 at 9:52 PM, Greg Stark wrote: > > The code is here: > > https://github.com/gsstark/retropg > > The build script is called "makeall" and it applies patches from the > "old-postgres-fixes" directory though some of the smarts are in the > script because it knows

Re: [HACKERS] Polyphase merge is obsolete

2016-10-12 Thread Heikki Linnakangas
On 10/12/2016 08:27 PM, Tom Lane wrote: Heikki Linnakangas writes: The beauty of the polyphase merge algorithm is that it allows reusing input tapes as output tapes efficiently ... So the whole idea of trying to efficiently reuse input tapes as output tapes is pointless.

Re: [HACKERS] Non-empty default log_line_prefix

2016-10-12 Thread Christoph Berg
Re: Jeff Janes 2016-10-12

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

2016-10-12 Thread Robert Haas
On Fri, Oct 7, 2016 at 5:47 PM, Peter Geoghegan wrote: > Work is still needed on: > > * Cost model. Should probably attempt to guess final index size, and > derive calculation of number of workers from that. Also, I'm concerned > that I haven't given enough thought to the low

[HACKERS] logical replication connection information management

2016-10-12 Thread Peter Eisentraut
I want to discuss the connection information management aspect of the logical replication patch set that is currently being proposed (https://commitfest.postgresql.org/10/701/). To review, the user-visible interfaces center around -- on sending end CREATE PUBLICATION mypub FOR TABLE tbl1,

Re: [HACKERS] Remove "Source Code" column from \df+ ?

2016-10-12 Thread Pavel Stehule
2016-10-12 19:48 GMT+02:00 Peter Eisentraut < peter.eisentr...@2ndquadrant.com>: > On 10/12/16 11:16 AM, Tom Lane wrote: > > I'm not sure that Peter was voting for retaining "internal name", but > > personally I prefer that to deleting prosrc entirely, so +1. > > I'm not sure what the point of

Re: [HACKERS] Remove "Source Code" column from \df+ ?

2016-10-12 Thread Peter Eisentraut
On 10/12/16 11:16 AM, Tom Lane wrote: > I'm not sure that Peter was voting for retaining "internal name", but > personally I prefer that to deleting prosrc entirely, so +1. I'm not sure what the point of showing the internal name would be if we have already declared that the source code of non-C

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2016-10-12 Thread Vitaly Burovoy
On 10/12/16, Alvaro Herrera wrote: > Julien Rouhaud wrote: >> On 12/10/2016 14:32, Alvaro Herrera wrote: >> > Julien Rouhaud wrote: >> > >> >> and you can instead make macaddr64 support both format, and provide a >> >> macaddr::macaddr64 cast >> > >> > Having macaddr64

Re: [HACKERS] Non-empty default log_line_prefix

2016-10-12 Thread Jeff Janes
On Wed, Oct 12, 2016 at 10:11 AM, Tom Lane wrote: > Jeff Janes writes: > > On Sun, Oct 2, 2016 at 1:20 PM, Christoph Berg wrote: > >> Patch attached. (Still using %t, I don't think %m makes sense for the > >> default.) > > > What is

Re: [HACKERS] Polyphase merge is obsolete

2016-10-12 Thread Tom Lane
Heikki Linnakangas writes: > The beauty of the polyphase merge algorithm is that it allows reusing > input tapes as output tapes efficiently ... So the whole idea of trying to > efficiently reuse input tapes as output tapes is pointless. It's been awhile since I looked at that

[HACKERS] Polyphase merge is obsolete

2016-10-12 Thread Heikki Linnakangas
The beauty of the polyphase merge algorithm is that it allows reusing input tapes as output tapes efficiently. So if you have N tape drives, you can keep them all busy throughout the merge. That doesn't matter, when we can easily have as many "tape drives" as we want. In PostgreSQL, a tape

Re: [HACKERS] Non-empty default log_line_prefix

2016-10-12 Thread Tom Lane
Jeff Janes writes: > On Sun, Oct 2, 2016 at 1:20 PM, Christoph Berg wrote: >> Patch attached. (Still using %t, I don't think %m makes sense for the >> default.) > What is the cost of using %m, other than 4 (rather compressible) bytes per > log entry? More

Re: [HACKERS] Remove "Source Code" column from \df+ ?

2016-10-12 Thread Tom Lane
Stephen Frost writes: > * Robert Haas (robertmh...@gmail.com) wrote: >> I'm still not used to the change that I have to use \d+ rather than \d >> to see the view definition. It's the #1 thing I want to see when >> examining a view, and since

Re: [HACKERS] Non-empty default log_line_prefix

2016-10-12 Thread Jeff Janes
On Sun, Oct 2, 2016 at 1:20 PM, Christoph Berg wrote: > Re: Tom Lane 2016-09-29 <18642.1475159...@sss.pgh.pa.us> > > > Possibly the longer version could be added as an example in the > > > documentation. > > > > I suspect that simply having a nonempty default in the first place

Re: [HACKERS] Remove "Source Code" column from \df+ ?

2016-10-12 Thread Stephen Frost
* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > >> I'm OK with just removing all the source codes from the \d family and > >> using the \s family instead. > > > Ok, great, thanks for clarifying

Re: [HACKERS] Add PGDLLEXPORT to PG_FUNCTION_INFO_V1

2016-10-12 Thread Tom Lane
Albe Laurenz writes: > Tom Lane wrote: >> I'm okay with adding PGDLLEXPORT to the extern, but we should update >> that comment to note that it's not necessary with any of our standard >> Windows build processes. (For that matter, the comment fails to explain >> why this

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2016-10-12 Thread Alvaro Herrera
Julien Rouhaud wrote: > On 12/10/2016 14:32, Alvaro Herrera wrote: > > Julien Rouhaud wrote: > > > >> and you can instead make macaddr64 support both format, and provide a > >> macaddr::macaddr64 cast > > > > Having macaddr64 support both formats sounds nice, but how does it work? > > Will we

Re: [HACKERS] Remove "Source Code" column from \df+ ?

2016-10-12 Thread Robert Haas
On Wed, Oct 12, 2016 at 8:16 AM, Tom Lane wrote: > Stephen Frost writes: >> * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: >>> I'm OK with just removing all the source codes from the \d family and >>> using the \s family instead. > >> Ok,

[HACKERS] Re: [COMMITTERS] pgsql: Extend framework from commit 53be0b1ad to report latch waits.

2016-10-12 Thread Robert Haas
On Wed, Oct 12, 2016 at 8:18 AM, Peter Eisentraut wrote: > On 10/4/16 11:29 AM, Tom Lane wrote: >> Robert Haas writes: >>> Apparently, 'make world' does not build worker_spi. I thought 'make >>> world' was supposed to build everything? >>

Re: [HACKERS] Non-empty default log_line_prefix

2016-10-12 Thread Christoph Berg
Re: Peter Eisentraut 2016-10-12 <0caa6d7f-deb6-9a43-2b38-60e63af93...@2ndquadrant.com> > >> > is going to do more to raise peoples' awareness than anything we > >> > could do in the documentation. But perhaps an example along these > >> > lines would be useful for showing proper use of %q. > >

Re: [HACKERS] [COMMITTERS] pgsql: Extend framework from commit 53be0b1ad to report latch waits.

2016-10-12 Thread Tom Lane
Peter Eisentraut writes: > On 10/4/16 11:29 AM, Tom Lane wrote: >> Robert Haas writes: >>> Apparently, 'make world' does not build worker_spi. I thought 'make >>> world' was supposed to build everything? >> You'd have thunk, yeah. It

Re: [HACKERS] Non-empty default log_line_prefix

2016-10-12 Thread Tom Lane
Peter Eisentraut writes: > That still doesn't address what to do about syslog and eventlog users. > We would need either a separate prefix setting for those, or maybe > something like %q that says, skip to here if using syslog. (I don't > know eventlog, so I

Re: [HACKERS] Renaming of pg_xlog and pg_clog

2016-10-12 Thread Stephen Frost
* David Steele (da...@pgmasters.net) wrote: > On 10/4/16 1:48 AM, Michael Paquier wrote: > > > So this is still open for votes. Here are the candidates and who > > voiced for what: > > - pg_transaction: Michael P, Thomas M. => Current 0002 is doing that. > > - pg_xact: David S, Robert > > -

Re: [HACKERS] Renaming of pg_xlog and pg_clog

2016-10-12 Thread Tom Lane
Peter Eisentraut writes: > On 10/4/16 1:48 AM, Michael Paquier wrote: >> So this is still open for votes. Here are the candidates and who >> voiced for what: >> - pg_transaction: Michael P, Thomas M. => Current 0002 is doing that. >> - pg_xact: David S, Robert >>

Re: [HACKERS] Non-empty default log_line_prefix

2016-10-12 Thread Peter Eisentraut
On 10/2/16 4:20 PM, Christoph Berg wrote: >> I suspect that simply having a nonempty default in the first place >> > is going to do more to raise peoples' awareness than anything we >> > could do in the documentation. But perhaps an example along these >> > lines would be useful for showing

[HACKERS] Re: [COMMITTERS] pgsql: Extend framework from commit 53be0b1ad to report latch waits.

2016-10-12 Thread Peter Eisentraut
On 10/4/16 11:29 AM, Tom Lane wrote: > Robert Haas writes: >> Apparently, 'make world' does not build worker_spi. I thought 'make >> world' was supposed to build everything? > > You'd have thunk, yeah. It looks like the issue is that src/Makefile > is selective about

Re: [HACKERS] Remove "Source Code" column from \df+ ?

2016-10-12 Thread Tom Lane
Stephen Frost writes: > * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: >> I'm OK with just removing all the source codes from the \d family and >> using the \s family instead. > Ok, great, thanks for clarifying that. Since we only have '\sf' today, > I think

Re: [HACKERS] Remove "Source Code" column from \df+ ?

2016-10-12 Thread Stephen Frost
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 10/12/16 11:08 AM, Stephen Frost wrote: > > Personally, I like the idea of a '\sv' for views, though we should > > discuss that on a new thread. > > \sv already exists. :-) Whoops, sorry, was looking at a 9.5 psql. :) Neat!

Re: [HACKERS] Remove "Source Code" column from \df+ ?

2016-10-12 Thread Peter Eisentraut
On 10/12/16 11:08 AM, Stephen Frost wrote: > Personally, I like the idea of a '\sv' for views, though we should > discuss that on a new thread. \sv already exists. :-) -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training &

Re: [HACKERS] Rename max_parallel_degree?

2016-10-12 Thread Peter Eisentraut
On 10/4/16 10:16 AM, Julien Rouhaud wrote: > Please find attached v9 of the patch, adding the parallel worker class > and changing max_worker_processes default to 16 and max_parallel_workers > to 8. I also added Amit's explanation for the need of a write barrier > in ForgetBackgroundWorker().

Re: [HACKERS] Remove "Source Code" column from \df+ ?

2016-10-12 Thread Stephen Frost
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 10/11/16 7:51 PM, Tom Lane wrote: > > 1. Do nothing. > > 2. Remove the prosrc column from \df+ altogether. > > 3. Suppress prosrc for PL functions, but continue to show it for > >C and internal functions (and, probably, rename

Re: [HACKERS] Renaming of pg_xlog and pg_clog

2016-10-12 Thread Peter Eisentraut
On 10/4/16 1:48 AM, Michael Paquier wrote: > So this is still open for votes. Here are the candidates and who > voiced for what: > - pg_transaction: Michael P, Thomas M. => Current 0002 is doing that. > - pg_xact: David S, Robert > - pg_trans: Tom > - pg_transaction_status: Peter E. I think this

Re: [HACKERS] Add PGDLLEXPORT to PG_FUNCTION_INFO_V1

2016-10-12 Thread Albe Laurenz
Tom Lane wrote: > I'm okay with adding PGDLLEXPORT to the extern, but we should update > that comment to note that it's not necessary with any of our standard > Windows build processes. (For that matter, the comment fails to explain > why this macro is providing an extern for the base function at

Re: [HACKERS] Remove "Source Code" column from \df+ ?

2016-10-12 Thread Peter Eisentraut
On 10/11/16 7:51 PM, Tom Lane wrote: > 1. Do nothing. > 2. Remove the prosrc column from \df+ altogether. > 3. Suppress prosrc for PL functions, but continue to show it for >C and internal functions (and, probably, rename it to something >other than "Source code" in that case). > 4. #3

Re: [HACKERS] Logical tape pause/resume

2016-10-12 Thread Heikki Linnakangas
On 10/10/2016 10:31 PM, Peter Geoghegan wrote: On Sun, Oct 9, 2016 at 11:52 PM, Heikki Linnakangas wrote: Ok, good. I think we're in agreement on doing this, then, even if we don't agree on the justification :-). Agreed. :-) Attached are new patch versions. Rebased them

Re: [HACKERS] Add PGDLLEXPORT to PG_FUNCTION_INFO_V1

2016-10-12 Thread Tom Lane
Albe Laurenz writes: > Tom Lane wrote: >> Except that we don't. There aren't PGDLLEXPORT markings for any >> functions exported from contrib modules, and we don't use dlltool >> on them either. By your argument, none of contrib would work on >> Windows builds at all,

Re: [HACKERS] ICU integration

2016-10-12 Thread Peter Eisentraut
On 9/30/16 4:32 PM, Thomas Munro wrote: >> Hmm, yeah, that will need more work. To be completely correct, I think, >> > we'd also need to record the version in each expression node, so that >> > check constraints of the form CHECK (x > 'abc') can be handled. > Hmm. That is quite a rabbit hole.

Re: [HACKERS] Add PGDLLEXPORT to PG_FUNCTION_INFO_V1

2016-10-12 Thread Albe Laurenz
Tom Lane wrote: >> PostgreSQL itself seems to use export files that explicitly declare the >> exported symbols, so it gets away without these decorations. > > Except that we don't. There aren't PGDLLEXPORT markings for any > functions exported from contrib modules, and we don't use dlltool > on

Re: [HACKERS] Add PGDLLEXPORT to PG_FUNCTION_INFO_V1

2016-10-12 Thread Tom Lane
Albe Laurenz writes: > Tom Lane wrote: >> The lack of complaints about this suggest that it's not actually necessary >> to do so. So what this makes me wonder is whether we can't drop the >> DLLEXPORT on the finfo function too. I'd rather reduce the number of >>

Re: [HACKERS] Add PGDLLEXPORT to PG_FUNCTION_INFO_V1

2016-10-12 Thread Albe Laurenz
Tom Lane wrote: > Albe Laurenz writes: >> Currently, PG_FUNCTION_INFO_V1 is defined as [...] > >> Is there a good reason why the "funcname" declaration is not decorated >> with PGDLLEXPORT? > > The lack of complaints about this suggest that it's not actually necessary >

Re: [HACKERS] Aggregate Push Down - Performing aggregation on foreign server

2016-10-12 Thread Jeevan Chalke
On Thu, Sep 8, 2016 at 10:41 PM, Ashutosh Bapat < ashutosh.ba...@enterprisedb.com> wrote: > > > I think we should try to measure performance gain because of aggregate > pushdown. The EXPLAIN > doesn't show actual improvement in the execution times. > I did performance testing for aggregate push

Re: [HACKERS] How to inspect tuples during execution of a plan?

2016-10-12 Thread Ernst-Georg Schmid
Hello, > > Either of those would do, if you want to write change the executor. > I used the ExeceutorRun_hook and it seems to work. The drawback is, that I have to provide my own implementation of ExecutePlan() which could make it incompatible over versions of PostgreSQL. I don't know how stable

Re: [HACKERS] Remove "Source Code" column from \df+ ?

2016-10-12 Thread Stephen Frost
* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > As was mentioned, this thread doesn't really need a patch but rather > > some comment from those who have voiced a -1 on removing the PL source > > code column. > > > In another, perhaps vain, attempt to get

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2016-10-12 Thread Julien Rouhaud
On 12/10/2016 14:32, Alvaro Herrera wrote: > Julien Rouhaud wrote: > >> and you can instead make macaddr64 support both format, and provide a >> macaddr::macaddr64 cast > > Having macaddr64 support both formats sounds nice, but how does it work? > Will we have to reserve one additional bit to

Re: [HACKERS] Add PGDLLEXPORT to PG_FUNCTION_INFO_V1

2016-10-12 Thread Tom Lane
Albe Laurenz writes: > Currently, PG_FUNCTION_INFO_V1 is defined as > /* >* Macro to build an info function associated with the given function name. >* Win32 loadable functions usually link with 'dlltool --export-all', but > it >* doesn't hurt to add

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2016-10-12 Thread Tom Lane
Haribabu Kommi writes: > Here I attached a POC patch that adds the support for EUI-64 MAC address > storage with a new datatype macaddr64. Currently this type takes only > EUI-64 datatype, not accepts 48 bit MAC address. Our other data types that have sizes in the names

  1   2   >