(2018/04/26 15:39), Amit Langote wrote:
On 2018/04/26 15:27, Etsuro Fujita wrote:
Here is a new version I'd like to propose for fixing this issue without
the former patch.
Sorry, didn't notice this before sending my patch, which I also marked v7.
It's a bit different than yours and has comme
On 2018/04/26 15:27, Etsuro Fujita wrote:
> (2018/04/26 12:43), Etsuro Fujita wrote:
>> (2018/04/25 17:29), Amit Langote wrote:
>>> On 2018/04/25 16:42, Kyotaro HORIGUCHI wrote:
At Wed, 25 Apr 2018 11:19:23 +0900, Amit Langote wrote:
> After the refactoring, it appears to me that we only n
Teodor, are you caught up to the point where it'd be okay to run pgindent,
or are there still patches waiting?
There is a gin predicate lock patch from Heikki, I will work on it. But
I have not objection to run pgindent, I believe gin patch will be easy
to change.
--
Teodor Sigaev
On 2018/04/26 12:43, Etsuro Fujita wrote:
> (2018/04/25 17:29), Amit Langote wrote:
>> Hmm, I missed that we do need information from a proper RTE as well. So,
>> I suppose we should be doing this instead of creating the RTE for foreign
>> partition from scratch.
>>
>> + rte = list_nth(estate->
(2018/04/26 12:43), Etsuro Fujita wrote:
(2018/04/25 17:29), Amit Langote wrote:
On 2018/04/25 16:42, Kyotaro HORIGUCHI wrote:
At Wed, 25 Apr 2018 11:19:23 +0900, Amit Langote wrote:
After the refactoring, it appears to me that we only need this much:
+ rte = makeNode(RangeTblEntry);
+ rte->r
On Thu, Apr 26, 2018 at 3:30 AM, Robert Haas wrote:
> On Tue, Apr 10, 2018 at 9:08 PM, Masahiko Sawada
> wrote:
>> Never mind. There was a lot of items especially at the last CommitFest.
>>
>>> In terms of moving forward, I'd still like to hear what
>>> Andres has to say about the comments I mad
On Thu, Apr 26, 2018 at 09:06:09AM +0500, Haroon wrote:
> Apparently the following patch[1] got committed to head only (9.6 at the
> time) and never made it into back branches i.e. 9.5, 9.4 and 9.3. Is it an
> oversight ?
>
> [1]
> http://git.postgresql.org/pg/commitdiff/868628e4fd44d75987d6c099a
Apparently the following patch[1] got committed to head only (9.6 at the
time) and never made it into back branches i.e. 9.5, 9.4 and 9.3. Is it an
oversight ?
[1]
http://git.postgresql.org/pg/commitdiff/868628e4fd44d75987d6c099ac63613cc5417629
Regards,
Haroon
--
Haroonhttp://w
The attached small patch removes the mention that partitioned tables
cannot have foreign keys defined on them.
This has been supported since 3de241db
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
foreign_keys_on_partit
(2018/04/26 2:59), Robert Haas wrote:
On Tue, Apr 24, 2018 at 10:19 PM, Amit Langote
wrote:
I tried to do that. So, attached are two patches.
1. Fix for ExecInitPartitionInfo to use the right RT index to pass to
InitResultRelInfo
2. v5 of the patch to fix the bug of foreign partitions
(2018/04/25 17:29), Amit Langote wrote:
On 2018/04/25 16:42, Kyotaro HORIGUCHI wrote:
At Wed, 25 Apr 2018 11:19:23 +0900, Amit Langote wrote:
After the refactoring, it appears to me that we only need this much:
+rte = makeNode(RangeTblEntry);
+rte->rtekind = RTE_RELATION;
+rte->rel
(2018/04/25 17:51), Etsuro Fujita wrote:
(2018/04/25 4:49), Robert Haas wrote:
I didn't really get beyond the refactoring stage with this today.
This version still seems to work, but I don't really understand the
logic in postgresBeginForeignInsert which decides whether to use the
RTE from the r
The jitflags in the PlannedStmt structure of type "int", but in _out and
_read functions it is treated as of "bool" type.
WRITE_BOOL_FIELD(jitFlags);
READ_BOOL_FIELD(jitFlags);
I am thinking of it is a copy paste mistake as the other members around the
initflags are of "bool" type or is there any
On 23 April 2018 at 08:23, Miles Elam wrote:
> I would like to donate some code to the project, formatting numbers as any
> base from 2 to 64. The FAQ describes contributions to the core code, but
> it's possible contrib is a better target. This is all of course contingent
> on how well received t
On 24 April 2018 at 09:10, Alvaro Herrera wrote:
> I just pushed David patch, with some pretty minor changes. I hope not
> to have broken anything.
Thanks for pushing and thanks Amit for reviewing.
The only thing that stands out in the actual commit is:
+executor to remove (ignore) par
On Wed, Apr 25, 2018 at 6:31 PM, Thomas Munro
wrote:
> Huh. Right. So it's not truly uniform. I wonder if any of these
> algorithms are sensitive to the higher value of the leaf pages than
> the heap pages. It seems quite subtle: even though we can see that
> the individual leaf pages must be
On 13 April 2018 at 05:10, Tom Lane wrote:
> Therefore, I propose the attached patch, which simply sees to it that
> we discard any partial query result at the start of error message
> collection not the end. This makes the behavior very much better,
> at least on Linux.
>
> I think this is a ba
On Wed, Apr 25, 2018 at 06:53:38PM -0700, Noah Misch wrote:
> Right. Done.
Thanks, Noah.
--
Michael
signature.asc
Description: PGP signature
On 24 April 2018 at 04:14, Andres Freund wrote:
> I'm LSF/MM to discuss future behaviour of linux here, but that's how it
> is right now.
Interim LWN.net coverage of that can be found here:
https://lwn.net/Articles/752613/
--
Craig Ringer http://www.2ndQuadrant.com/
Postgr
On Wed, Apr 25, 2018 at 03:42:31PM -0400, Robert Haas wrote:
> The difficulty of finding them all is really the problem. If we had a
> reliable way to list everything that needs to be moved into session
> state, then we could try to come up with a design to do that.
> Otherwise, we're just swattin
On Wed, Apr 25, 2018 at 03:57:49PM +0200, Magnus Hagander wrote:
> On Mon, Apr 23, 2018 at 12:49 AM, Michael Paquier wrote:
> > On Sun, Apr 22, 2018 at 02:55:51PM -0700, Noah Misch wrote:
> > > That change is testing the wrong variable. I plan to repair it as
> > > attached.
> >
> > You are right
On Thu, Apr 26, 2018 at 10:54 AM, Peter Geoghegan wrote:
> On Wed, Apr 25, 2018 at 5:26 AM, Thomas Munro
> wrote:
>> I think pgbench isn't a very interesting workload though. I don't
>> have time right now but it would be fun to dig further and try to
>> construct workloads that generate patholo
On 25 April 2018 at 05:10, Alvaro Herrera wrote:
> Pushed. Thanks!
Thanks!
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
On 25 April 2018 at 06:21, Alvaro Herrera wrote:
> Andres Freund wrote:
>
>> What I wonder, after skimming this change, is where the relevant
>> expression context is reset? That's not really related to this change
>> but the wider thread, I just noticed it while looking at this.
>
> Do you mean
On Wed, Apr 25, 2018 at 2:58 PM, Robert Haas wrote:
> On Wed, Apr 25, 2018 at 10:00 AM, Merlin Moncure wrote:
>> systems. If we get that tor free I'd be all for it but reading
>> Robert's email I'm skeptical there are easy wins here. So +1 for
>> further R&D and -1 for holding things up based o
On Wed, Apr 25, 2018 at 5:26 AM, Thomas Munro
wrote:
> I think pgbench isn't a very interesting workload though. I don't
> have time right now but it would be fun to dig further and try to
> construct workloads that generate pathological searches for buffers (I
> believe that such workloads exist
On Wed, Apr 25, 2018 at 2:09 PM, Alexander Korotkov
wrote:
> Great. Thank you very much for your efforts on this feature!
You're welcome. I also appreciate the efforts of all Postgres Pro
people. I especially appreciate Anastasia's work on this project.
I hope that we see more B-Tree patches fr
>>
+ textprosrc BKI_DEFAULT("${proname}")
BKI_FORCE_NOT_NULL;
>>
>>> That one I kinda like.
>>
>> Agreed, this seems more compelling. However, I think we need more than
>> one compelling example to justify the additional infrastructure.
>
> I'll look for more.
Th
On Wed, Apr 25, 2018 at 11:48 PM, Peter Geoghegan wrote:
> On Wed, Apr 25, 2018 at 1:45 PM, Tom Lane wrote:
> > Teodor, are you caught up to the point where it'd be okay to run
> pgindent,
> > or are there still patches waiting?
>
> I can't speak for Teodor, but fwiw I am not aware of any more p
On Wed, Apr 25, 2018 at 1:45 PM, Tom Lane wrote:
> Teodor, are you caught up to the point where it'd be okay to run pgindent,
> or are there still patches waiting?
I can't speak for Teodor, but fwiw I am not aware of any more patches waiting.
--
Peter Geoghegan
Teodor Sigaev writes:
>> It looks like you pushed v1, which didn't have the tests and other
>> changes you asked for. Attached patch adds those back.
> Oops, I missed, I don't know how... Thank you very much for your quick eye!
Teodor, are you caught up to the point where it'd be okay to run pgi
> On Apr 25, 2018, at 1:31 PM, Tom Lane wrote:
>
> Robert Haas writes:
>> On Wed, Apr 25, 2018 at 3:44 PM, Mark Dilger wrote:
>>> There still seems to be a lot of boilerplate in the .dat files
>>> that could be eliminated. ...
>
>>> {... typname => 'X', ... typinput => 'Xin', typoutput => 'Xo
Mark Dilger writes:
>> On Apr 25, 2018, at 1:00 PM, Robert Haas wrote:
>> -1 for trying to automate this. It varies between fooin and foo_in,
>> and it'll be annoying to have to remember which one happens
>> automatically and which one needs an override.
> That may be a good argument. I was on
On 2018-04-25 14:41:44 -0400, Robert Haas wrote:
> On Mon, Apr 16, 2018 at 2:13 AM, Andrew Gierth
> wrote:
> > The code that detects sequential behavior can not distinguish between
> > pread() and lseek+read, it looks only at the actual offset of the
> > current request compared to the previous on
Robert Haas writes:
> On Wed, Apr 25, 2018 at 3:44 PM, Mark Dilger wrote:
>> There still seems to be a lot of boilerplate in the .dat files
>> that could be eliminated. ...
>> {... typname => 'X', ... typinput => 'Xin', typoutput => 'Xout',
>> typreceive => 'Xrecv', typsend => 'Xsend', ... },
>
"Tels" writes:
> On Wed, April 25, 2018 12:35 pm, Tom Lane wrote:
>> Agreed on pointing to cpan, but that page is pretty confusing if you're
>> looking for a non-bleeding-edge version. I suggest linking to
>> https://cpan.metacpan.org/authors/id/S/SH/SHANCOCK/
>> which presents a handy directory
> On Apr 25, 2018, at 1:00 PM, Robert Haas wrote:
>
> On Wed, Apr 25, 2018 at 3:44 PM, Mark Dilger wrote:
>> There still seems to be a lot of boilerplate in the .dat files
>> that could be eliminated. Tom mentioned upthread that he did
>> not want too much magic in genbki.pl or Catalog.pm, but
John Naylor writes:
> Just after you posted, I sent a patch that tweaks the API of
> Catalog.pm for toast and index oids. If you use that API in your
> patch, you can get rid of the extra bookkeeping you added for those
> oids.
I've adjusted these two patches to play together, and pushed them.
>
On Wed, Apr 25, 2018 at 3:44 PM, Mark Dilger wrote:
> There still seems to be a lot of boilerplate in the .dat files
> that could be eliminated. Tom mentioned upthread that he did
> not want too much magic in genbki.pl or Catalog.pm, but I think
> I can propose putting some magic in the header fi
On Wed, Apr 25, 2018 at 10:00 AM, Merlin Moncure wrote:
> systems. If we get that tor free I'd be all for it but reading
> Robert's email I'm skeptical there are easy wins here. So +1 for
> further R&D and -1 for holding things up based on full
> transparency...no harm in shooting for that, but
On Tue, Apr 24, 2018 at 1:00 PM, Konstantin Knizhnik
wrote:
> My expectation is that there are very few of them which has session-level
> lifetime.
> Unfortunately it is not so easy to locate all such places. Once such
> variables are located, them can be saved in session context and restored on
>
On Tue, Apr 24, 2018 at 6:19 AM, Amit Langote
wrote:
> Given what equalTupleDescs was invented for (commit a152ebeec), reducing
> it down to what can be sensibly used for checking whether tuple conversion
> is needed between a parent and child will, I'm afraid, make it useless for
> its original p
On Wed, Apr 11, 2018 at 6:00 AM, Jeevan Chalke
wrote:
> [ new patch ]
Committed. Apologies for the delay.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Moin,
On Wed, April 25, 2018 12:35 pm, Tom Lane wrote:
> Michael Paquier writes:
>> On Mon, Apr 23, 2018 at 12:40:00PM -0400, Tom Lane wrote:
>>> Alvaro Herrera writes:
I still vote we use 20170521 which is recent enough that we won't have
to change it in a few years.
>
>> That's the v
On Wed, Apr 25, 2018 at 12:06 PM, Teodor Sigaev wrote:
> Oops, I missed, I don't know how... Thank you very much for your quick eye!
Thanks Teodor.
--
Peter Geoghegan
On 4/26/18, Stas Kelvich wrote:
> New version is attached. I've put iterator into Catalog.pm to avoid
> copy-pasting
> it over two scripts. Also instead of greping through *.dat and *.h files
> I've
> used parsers provided in Catalog module. That way should be more
> sustainable
> to format change
It looks like you pushed v1, which didn't have the tests and other
changes you asked for. Attached patch adds those back.
Oops, I missed, I don't know how... Thank you very much for your quick eye!
--
Teodor Sigaev E-mail: teo...@sigaev.ru
Nick Dro writes:
> Hi,
> I have a stock table.
>
> One of the users in the system ran this query: update stock set
> quantity=quantity-5 where stockid=100 (from his client application).
> On the same time I ran from pg-admin this query:
>
> do $$
> begin
> alter table stock disable trigger
On Mon, Apr 16, 2018 at 2:13 AM, Andrew Gierth
wrote:
> The code that detects sequential behavior can not distinguish between
> pread() and lseek+read, it looks only at the actual offset of the
> current request compared to the previous one for the same fp.
>
> Thomas> +1 for adopting pread()/pwr
On Tue, Apr 10, 2018 at 9:08 PM, Masahiko Sawada wrote:
> Never mind. There was a lot of items especially at the last CommitFest.
>
>> In terms of moving forward, I'd still like to hear what
>> Andres has to say about the comments I made on March 1st.
>
> Yeah, agreed.
$ ping -n andres.freund
Req
On Fri, Apr 20, 2018 at 12:14 PM, Konstantin Knizhnik
wrote:
> With the extension lock patch performance in increased to 1146 TPS.
> So it is much better than with vanilla postgres and about 40% better than
> with deadlock patch (1146 vs. 719 TPS).
Cool, that's good to know.
> So definitely elim
John Naylor writes:
> On 4/25/18, Tom Lane wrote:
>> I think we should rewrite
>> both of them to use the Catalog.pm infrastructure.
> If we're going to use Catalog.pm for that, it seems more convenient to
> expose toast and index oids directly rather than in strings formatted
> specifically for
On Fri, Apr 20, 2018 at 6:34 PM, legrand legrand
wrote:
> It would be so helpfull if a planid was included in core Query / plan tree,
> it could be reused here in equal(), in explain commands,
> in pg_stat_activity, in pg_stat_statements ...
+1.
--
Robert Haas
EnterpriseDB: http://www.enterpris
Tom Lane wrote:
> Alvaro Herrera writes:
> > Tom Lane wrote:
> >> Agreed on pointing to cpan, but that page is pretty confusing if you're
> >> looking for a non-bleeding-edge version. I suggest linking to
> >> https://cpan.metacpan.org/authors/id/S/SH/SHANCOCK/
> >> which presents a handy directo
As a general note on this thread, we should try to get this cleared up
as soon as possible, since it involves an on-disk format change.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On 4/25/18, Tom Lane wrote:
> Andrew Dunstan writes:
>> +many for rewriting in perl. Do you want to have a go at that? If not I
>> will.
>
> +1 ... I was mildly astonished that this didn't already have to happen
> as part of the bootstrap data conversion effort. It's certainly not
> hard to imag
Alvaro Herrera writes:
> Tom Lane wrote:
>> Agreed on pointing to cpan, but that page is pretty confusing if you're
>> looking for a non-bleeding-edge version. I suggest linking to
>> https://cpan.metacpan.org/authors/id/S/SH/SHANCOCK/
>> which presents a handy directory listing.
> Works for me.
On Tue, Apr 24, 2018 at 10:19 PM, Amit Langote
wrote:
> I tried to do that. So, attached are two patches.
>
> 1. Fix for ExecInitPartitionInfo to use the right RT index to pass to
>InitResultRelInfo
>
> 2. v5 of the patch to fix the bug of foreign partitions
>
> Thoughts?
Are you splitting t
> On 25 Apr 2018, at 17:55, John Naylor wrote:
>
> On 4/25/18, Stas Kelvich wrote:
>>> On 25 Apr 2018, at 17:18, Tom Lane wrote:
>>> I think we should rewrite
>>> both of them to use the Catalog.pm infrastructure.
>>
>> Okay, seems reasonable. I'll put shared code in Catalog.pm and
>> update
On Wed, Apr 25, 2018 at 9:43 AM, Christophe Pettus wrote:
>
>> On Apr 25, 2018, at 07:00, Merlin Moncure wrote:
>> The limitations headaches that I suffer with pgbouncer project (which
>> I love and use often) are mainly administrative and performance
>> related, not lack of session based server
Tom Lane wrote:
> Michael Paquier writes:
> > On Mon, Apr 23, 2018 at 12:40:00PM -0400, Tom Lane wrote:
> >> Alvaro Herrera writes:
> >>> I further vote that we change the URL in pgindent/README from
> >>> sourceforge to metacpan.org,
> >>> https://metacpan.org/pod/distribution/Perl-Tidy/lib/Per
On Wed, Apr 25, 2018 at 8:06 AM, Teodor Sigaev wrote:
> Leave it in both places. In ideal world, in amcheck test we need to create a
> broken index, but I don't know a correct way to do it :)
There are many ways to create a broken index, but they're hard to make
work with pg_regress. :-)
It look
Michael Paquier writes:
> On Mon, Apr 23, 2018 at 12:40:00PM -0400, Tom Lane wrote:
>> Alvaro Herrera writes:
>>> I still vote we use 20170521 which is recent enough that we won't have
>>> to change it in a few years.
> That's the version available on Debian sid, so from the prospective of
> any
On 04/25/2018 10:55 AM, John Naylor wrote:
> On 4/25/18, Stas Kelvich wrote:
>>> On 25 Apr 2018, at 17:18, Tom Lane wrote:
>>> I think we should rewrite
>>> both of them to use the Catalog.pm infrastructure.
>> Okay, seems reasonable. I'll put shared code in Catalog.pm and
>> update patch.
> I
2) Pls, add to test DELETE as it done in
6db4b49986be3fe59a1f6ba6fabf9852864efc3e
Done. I will leave it to you to decide whether or not the original
create_index.sql test can now be removed.
Leave it in both places. In ideal world, in amcheck test we need to create a
broken index, but I don't k
Thank you, pushed.
Peter Geoghegan wrote:
On Tue, Apr 24, 2018 at 9:06 AM, Teodor Sigaev wrote:
Perfect!
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
On 04/25/2018 04:59 PM, David Fetter wrote:
While we're improving things, there's not really a reason this program
should need to be run from any particular spot. It can detect where it
is and act on that information.
+1
I would appreciate this change, and if Stats does not feel like adding
i
On 04/25/2018 05:57 PM, Sergei Kornilov wrote:
Attached file is empty.
My bad, here is the correct file.
--
Alexander Kuzmenkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 4a
On Wed, Apr 25, 2018 at 09:55:54PM +0700, John Naylor wrote:
> On 4/25/18, Stas Kelvich wrote:
> >> On 25 Apr 2018, at 17:18, Tom Lane wrote:
> >> I think we should rewrite
> >> both of them to use the Catalog.pm infrastructure.
> >
> > Okay, seems reasonable. I'll put shared code in Catalog.pm
Hello
Something was wrong? Attached file is empty.
regards, Sergei
On 4/25/18, Stas Kelvich wrote:
>> On 25 Apr 2018, at 17:18, Tom Lane wrote:
>> I think we should rewrite
>> both of them to use the Catalog.pm infrastructure.
>
> Okay, seems reasonable. I'll put shared code in Catalog.pm and
> update patch.
I don't think you need any new code in Catalog.pm, I
On 04/24/2018 06:09 AM, Kyotaro HORIGUCHI wrote:
It seems that the additional description needs to be meld into
this at the first place? And some caveat may be needed on failure
cases.
That's right. I applied your diff and rewrote these paragraphs, adding
some words about the possible loss of
> On Apr 25, 2018, at 07:00, Merlin Moncure wrote:
> The limitations headaches that I suffer with pgbouncer project (which
> I love and use often) are mainly administrative and performance
> related, not lack of session based server features.
For me, the most common issue I run into with pgboun
> On 25 Apr 2018, at 17:18, Tom Lane wrote:
> I think we should rewrite
> both of them to use the Catalog.pm infrastructure.
Okay, seems reasonable. I'll put shared code in Catalog.pm and
update patch.
--
Stas Kelvich
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Comp
On 25.04.2018 17:00, Merlin Moncure wrote:
On Wed, Apr 25, 2018 at 12:34 AM, Christophe Pettus wrote:
On Apr 24, 2018, at 06:52, Merlin Moncure wrote:
Why does it have to be completely transparent?
The main reason to move it into core is to avoid the limitations that a
non-core pooler has.
> On 25 Apr 2018, at 17:18, Tom Lane wrote:
>
> Andrew Dunstan writes:
>> +many for rewriting in perl. Do you want to have a go at that? If not I
>> will.
>
> +1 ... I was mildly astonished that this didn't already have to happen
> as part of the bootstrap data conversion effort. It's certai
Andrew Dunstan writes:
> +many for rewriting in perl. Do you want to have a go at that? If not I
> will.
+1 ... I was mildly astonished that this didn't already have to happen
as part of the bootstrap data conversion effort. It's certainly not
hard to imagine future extensions to the .dat file f
librelpIldus Kurbangaliev writes:
> apparently gettext can't properly identify strings when 64bit values
> formatted with macros like INT64_FORMAT and UINT64_FORMAT. I did
> some research and found out that gettext can work with PRId64 and
> PRIu64. My suggestion is to use these macro for such str
On Wed, Apr 25, 2018 at 12:34 AM, Christophe Pettus wrote:
>
>> On Apr 24, 2018, at 06:52, Merlin Moncure wrote:
>> Why does it have to be completely transparent?
>
> The main reason to move it into core is to avoid the limitations that a
> non-core pooler has.
The limitations headaches that I
On Mon, Apr 23, 2018 at 12:49 AM, Michael Paquier
wrote:
> On Sun, Apr 22, 2018 at 02:55:51PM -0700, Noah Misch wrote:
> > That change is testing the wrong variable. I plan to repair it as
> > attached.
>
> You are right here. Ditto
>
Ouch indeed. +1 for the fix.
Noah, you are planning to pus
On Tue, Apr 24, 2018 at 5:04 PM, Andrey Borodin wrote:
> Here's what we have about size of shared buffer now [1] (taken from [2]). I
> believe right hill must be big enough to reduce central pit to zero and make
> function monotonic: OS page cache knows less about data blocks and is
> expected
On 04/25/2018 04:45 AM, insaf.k wrote:
> Hello,
>
> I have developed a postgres extension in Linux. I want to compile it
> in MS Windows as well.
>
> The extension extensively make use of POSIX threads and mutexes.
>
> I've done some research regarding compiling in Windows. I am not sure
> in wh
On 04/25/2018 06:22 AM, Stas Kelvich wrote:
> Hi.
>
> BSD sed in macOS doesn't understand word boundary operator "\b". So after
> 372728b0d49 unused_oids doesn’t match all oids in new *.dat files marking
> all of them as unused.
>
> It is possible to write more portable regexps, e.g. change "\b"
> "Andrew" == Andrew Gierth writes:
> "Peter" == Peter Eisentraut writes:
>> On 4/11/18 11:33, Tom Lane wrote:
>>> (Wanders away wondering what Peter has done about toasted parameter
>>> values for procedures in general ...)
Peter> I'm not sure. How can a procedure have a toasted p
> "Peter" == Peter Eisentraut writes:
> On 4/11/18 11:33, Tom Lane wrote:
>> (Wanders away wondering what Peter has done about toasted parameter
>> values for procedures in general ...)
Peter> I'm not sure. How can a procedure have a toasted parameter value?
do $$ declare a text; begin
Hi,
apparently gettext can't properly identify strings when 64bit values
formatted with macros like INT64_FORMAT and UINT64_FORMAT. I did
some research and found out that gettext can work with PRId64 and
PRIu64. My suggestion is to use these macro for such strings.
The problem is here that PRIu64
Hello,
I have developed a postgres extension in Linux. I want to compile it in MS
Windows as well.
The extension extensively make use of POSIX threads and mutexes.
I've done some research regarding compiling in Windows. I am not sure in what
way I should compile the extension. AFAIK, Vi
Hi.
BSD sed in macOS doesn't understand word boundary operator "\b". So after
372728b0d49 unused_oids doesn’t match all oids in new *.dat files marking
all of them as unused.
It is possible to write more portable regexps, e.g. change "\b" to
something like "^.*{*.*", but it seems easier for featu
On Tue, Apr 24, 2018 at 4:49 PM, Etsuro Fujita
wrote:
> (2018/04/17 19:00), Etsuro Fujita wrote:
>>
>> (2018/04/17 18:43), Ashutosh Bapat wrote:
>>>
>>> Here's updated patch-set.
>>
>>
>> Will review.
>
>
> I started reviewing this.
>
> o 0001-Handle-ConvertRowtypeExprs-in-pull_vars_clause.patch:
Hi David,
This new patch is look good for me. So I change the status to need review.
Thanks!
Regards,
Haozhou
On Wed, Apr 11, 2018 at 7:52 PM, David Steele wrote:
> On 4/11/18 2:36 AM, Haozhou Wang wrote:
> >
> > Thanks for your email.
> > Just wondering will I need to re-submit this patch?
>
On 25.04.2018 08:34, Christophe Pettus wrote:
On Apr 24, 2018, at 06:52, Merlin Moncure wrote:
Why does it have to be completely transparent?
Well, we have non-transparent connection pooling now, in the form of pgbouncer,
and the huge fleet of existing application-stack poolers. The main re
(2018/04/25 4:49), Robert Haas wrote:
On Tue, Apr 24, 2018 at 12:21 PM, Robert Haas wrote:
On Mon, Apr 23, 2018 at 11:25 AM, Alvaro Herrera
wrote:
Robert, I think this is your turf, per 3d956d9562aa. Are you looking
into it?
Thanks for the ping. I just had a look over the proposed patch
Thanks Peter,
On Wednesday, April 25, 2018 12:17:05 AM CEST Peter Eisentraut wrote:
> On 4/24/18 07:13, Pavel Raiskup wrote:
> > .. the status quo seems to be bit optimistic with the "distant future",
> > and we should start thinking about dropping plpython2 support, same as
> > upstream (a bit op
Horiguchi-san,
Thanks for taking a look at it.
On 2018/04/25 16:42, Kyotaro HORIGUCHI wrote:
> At Wed, 25 Apr 2018 11:19:23 +0900, Amit Langote wrote:
>> After the refactoring, it appears to me that we only need this much:
>>
>> +rte = makeNode(RangeTblEntry);
>> +rte->rtekind = RTE_RELAT
At Wed, 25 Apr 2018 11:19:23 +0900, Amit Langote
wrote in
<573e60cc-beeb-b534-d89a-7622fae35...@lab.ntt.co.jp>
> Oops, really meant to send the "+1 to the root -> rte refactoring" comment
> and the rest in the same email.
>
> On 2018/04/25 4:49, Robert Haas wrote:
> > I have done some refactori
On Wed, Apr 25, 2018 at 4:11 AM, Michael Paquier
wrote:
> Hi all,
>
> I just found $subject:
> the server was compiled without --with-llvm),
> -JIT will not performed, even if considered to be
> +JIT will not be performed, even if considered to be
> beneficial based on the above
96 matches
Mail list logo
