06.10.2016, 16:52, Heikki Linnakangas kirjoitti:
I propose the attached patch. It gives up on trying to deal with
multiple key lengths (as noted earlier, OpenSSL just always passed
keylength=1024, so that was useless). Instead of using the callback, it
just sets fixed DH parameters with SSL_CTX_s
On 12 October 2016 at 14:30, Haribabu Kommi wrote:
> As we are moving to PostgreSQL 10, so are there any plans of backward
> compatiblity
> breakage, so the existing macaddr datatype itself can be changed to support
> both
> 48 and 64 bit MAC addresses. If not, I will try update the POC patch wit
Currently, if child table has a non-inherited constraint and a constraint
with the same name is added to the parent, it will fail with an error as
illustrated below:
create table parent (a int);
CREATE TABLE
create table child (constraint check_a check (a > 0) no inherit) inherits
(parent);
CREATE
On 12/10/2016 09:32, Craig Ringer wrote:
> On 12 October 2016 at 14:30, Haribabu Kommi wrote:
>
>> As we are moving to PostgreSQL 10, so are there any plans of backward
>> compatiblity
>> breakage, so the existing macaddr datatype itself can be changed to support
>> both
>> 48 and 64 bit MAC addr
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 PGDLLIMPORT in case they don't.
*/
#define PG_FUNCTION_INF
On 10/11/2016 08:52 AM, Amit Langote wrote:
Attached fixes what seems like a copy-pasto in pg_cast.h.
Applied, thanks.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2016/10/12 18:10, Heikki Linnakangas wrote:
> On 10/11/2016 08:52 AM, Amit Langote wrote:
>> Attached fixes what seems like a copy-pasto in pg_cast.h.
>
> Applied, thanks.
Thanks, Heikki!
Regards,
Amit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
Thanks Jeevan for taking care of the comments.
On Fri, Sep 30, 2016 at 5:23 PM, Jeevan Chalke
wrote:
> Hi Ashutosh,
>
> On Mon, Sep 26, 2016 at 2:28 PM, Ashutosh Bapat
> wrote:
>>
>> Thanks Jeevan for working on the comments.
>>
>> Ok. Yes, we should also handle bare conditions in
>> classifyCon
On Mon, Oct 10, 2016 at 2:17 AM, Tomas Vondra
wrote:
> after testing each combination (every ~9 hours). Inspired by Robert's wait
> event post a few days ago, I've added wait event sampling so that we can
> perform similar analysis. (Neat idea!)
I have done wait event test on for head vs group lo
Hello.
First patch fixes:
```
pg_filedump.c: In function ‘FormatItem’:
pg_filedump.c:994:18: error: ‘SizeOfIptrData’ undeclared (first use in
this function)
if (numBytes < SizeOfIptrData)
```
After 8023b582 there is no more SizeOfIptrData macro.
Second patch fixes Makef
Hi all. I thought I'd share some experience from Npgsql regarding
batching/pipelining - hope this isn't off-topic.
Npgsql has supported batching for quite a while, similar to what this patch
proposes - with a single Sync message is sent at the end.
It has recently come to my attention that this i
> => ALTER TEXT SEARCH CONFIGURATION multi_conf
> ALTER MAPPING FOR asciiword, asciihword, hword_asciipart,
> word, hword, hword_part
> WITH german_ispell (JOIN), english_ispell, simple;
I have something like this in my mind since I dealt with FTS for a
Turkish real estate listing appl
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 select the representation?
That would make the type be 65
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 measure the sizes in
bytes
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 PGDLLIMPORT in case they don'
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
* 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
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
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
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
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:
>> 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
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
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 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
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
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/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
* 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 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
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
* 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
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
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
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
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
* 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:
> 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
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
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
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
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
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
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
* 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
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
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
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
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
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
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
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 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
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
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
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
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 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
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
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 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
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 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: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
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
* 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"
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:
>>
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
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
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
>>> >
>>> >
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,
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 |
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
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:
> 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:
>>
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
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)
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
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
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:
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
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
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
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
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 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
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 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 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 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 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 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 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 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 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
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 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
> 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 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
1 - 100 of 115 matches
Mail list logo
