Hi all,
I have been looking at the possibility to support wait events for
system processes, and here are the things that I think need to be
done:
- System processes do not have PGPROC entries in PROC_HDR. I think
that we should add an array for system processes, putting in it
walwriterLatch, check
On Fri, Sep 30, 2016 at 5:23 PM, Jeevan Chalke <
jeevan.cha...@enterprisedb.com> wrote:
> In the attached patch I have fixed all other review comments you have
> posted. All the comments were excellent and helped me a lot to improve
> in various areas.
>
Hi,
I have tested and created few extra
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 modes
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 pg_backup
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 understand,
I just paid attention to the words "likelihood" (mixed up with
"li
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 the name?
> I just thought o
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
>> >> world' was supposed to build everything?
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 of "no" you didn't understand, but we're
> >> not breaking on-disk compa
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
> 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 Gather node were no
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
> > syslog
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 p
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 Gather node were not prese
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 have
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 Development
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.
>>
>> And at lower client cou
> 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" shou
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 we extend that I think we
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 validation.
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 framework.
>
> Purpose
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 it.
I agree. The
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 (pgsql-hackers@postgresql.org)
To mak
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 to 9.6, but it got
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 also added Amit's explanation for
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 OUI (organizationally uniqu
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 looks like the issue is
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 munmap fails, you'll recover how exactly?
>
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 build. I would suggest creating a tag
>>> for a for this s
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 reading /proc/meminfo and
> >> looking for a
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, we'd not be having th
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
>>> likely to work on more kernel versions. Also, if
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
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 you are going to see multiple
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 phase-of-the-mo
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! http://BlueTreble
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
> >> looking for a line like "Hugepagesize:
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 SEARCH CONFIGURATION tu
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 explain
>>> why this macro is p
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 > 255) ||
>>> (e < 0) || (e > 255) || (f < 0)
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 existing macaddr columns.
>> Breaking the on-the-wir
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))
> can not be rewritten as:
>>
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 binary I/O representation
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 seems like a
nonstarter as w
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 |
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 "Hugepagesize: 2048 kB".
> We had that,
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 provide a
>>> >> macaddr::macaddr64 cast
>>> >
>>> >
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 problem
>turns out to
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()
a
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 version and limiting the commits to just:
>>
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Oct 12, 2016 at 11:20 AM, Christoph Berg wrote:
> > Re: Jeff Janes 2016-10-12
> >
> >> Do you think the pushback will come from people who just accept the
> >> defaults?
> >
> > I'm concerned about readability. "2016-10-12 20:14:30.449 CEST"
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
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
> relates to parallel query. W
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
>> "old-postgres-fixes" directory though some of the
On Wed, Oct 12, 2016 at 11:20 AM, Christoph Berg wrote:
> Re: Jeff Janes 2016-10-12
>
>> Do you think the pushback will come from people who just accept the
>> defaults?
>
> I'm concerned about readability. "2016-10-12 20:14:30.449 CEST" is a
> lot of digits. My eyes can parse "20:14:30" as a ti
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 CLogControlLock is not
> s
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?
Looks good, pushed.
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 about how to run
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.
It's been awhile sinc
Re: Jeff Janes 2016-10-12
> Do you think the pushback will come from people who just accept the
> defaults?
I'm concerned about readability. "2016-10-12 20:14:30.449 CEST" is a
lot of digits. My eyes can parse "20:14:30" as a timestamp, but
"20:14:30.449" looks more like an IP address. (Admitted
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 end, where with defau
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, t
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 sho
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 f
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 support both formats sounds
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 the cost of using %m, other than 4 (rather compressible) bytes
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 code, but I'm qui
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 dri
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 log I/O, which is not free ... and that
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 2fe1b4dd651917aad2accac7ba8adb44d9f54930 I
>> have to r
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
> > is going to do
* 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 that. Since we only
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 macro is providing an exte
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 hav
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, great, thanks for clarifying that. Since we
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?
>>
>> You'd have thunk, yeah. It looks like the issue is th
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.
> > Pa
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 looks like the issue is that src/Makefile
>> is selective ab
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 don't know if a common setting for sys
* 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
> > - pg_tra
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
>> - pg_trans: Tom
>> - pg_transactio
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 proper
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 recursing into certain subd
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 the prevailing option h
* 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!
Thank
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 & Servic
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().
Thi
* 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 it
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 w
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
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 plus
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 over current head, f
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, but we have a ton of buildfa
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. I
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 t
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
>> Microsoft-isms in the code, not i
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
> to do so. So what this m
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 d
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
* 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 to a consensus, here's
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 sel
1 - 100 of 115 matches
Mail list logo
