Some of the Windows buildfarm members aren't too happy with this.
Indeed.
Windows prettyprinting of double inserts a spurious "0" at the beginning
of the exponent. Makes it look like an octal.
Here is a patch to fix it, which I cannot test on Windows.
--
Fabien.diff --git a/src/bin/pgbenc
A new automaton state is added to quickly step over false branches.
This one took me a little while to understand while reading the patch,
but mostly because of how diff doesn't handle moving things around.
"git diff -w --patience" may help.
Marking as ready for committer.
Here is a reba
Here is a rebase. I made some tests use actual expressions instead of just 0
and 1. No other changes.
Sigh. Better with the attachment. Sorry for the noise.
--
Fabien.diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml
index 3dd492c..c203c41 100644
--- a/doc/src/sgml/re
Here is a v14, after yet another rebase, and some comments added to answer
your new comments.
Attached v15 is a simple rebase after Teodor push of new functions &
operators in pgbench.
--
Fabien.diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml
index 3dd492c..b5139
On 02.01.2018 21:12, Peter Eisentraut wrote:
On 12/29/17 06:28, Konstantin Knizhnik wrote:
Can there be apparent RI
violations?
Right now AS OF is used only in selects, not in update statements. So I
do not understand how integrity constraints can be violated.
I mean, if you join tables c
On 03.01.2018 23:49, legrand legrand wrote:
Maybe that a simple check of the asof_timestamp value like:
asof_timestamp >= now() - time_travel_period
AND
asof_timestamp >= latest_table_ddl
would permit to raise a warning or an error message saying that query result
can not be garanteed with th
On 07.01.2018 01:59, Stephen Frost wrote:
Greetings,
* Konstantin Knizhnik (k.knizh...@postgrespro.ru) wrote:
On 15.12.2017 01:21, Michael Paquier wrote:
On Fri, Dec 15, 2017 at 6:15 AM, Alvaro Herrera wrote:
Konstantin Knizhnik wrote:
If you still thing that additional 16 bytes per relat
This is a simple patch that does what it says on the tin. I ran into
trouble with the pgbench TAP test *even before applying the patch*, but
only because I was doing a VPATH build as a user without 'write'
on the source tree (001_pgbench_with_server.pl tried to make pgbench
create log files ther
Here is a rebase, plus some more changes:
I have improved the error message to tell from where the value was
provided.
I have removed the test to the exact values produced from the expression
test run.
I have added a test which run from the same seed value several times
and checks that the
Hello Teodor,
I just noticed while rebasing stuff that there is some crust in
"pgbench/t/001_pgbench_with_server.pl" coming from this patch:
+=head
+
+} });
+
+=cut
I cannot find any use for these lines which are ignored by perl execution
anyway. It may be some leftovers from debugging
> But performing this query on each access to the table seems to be bad
> idea: in case of nested loop join it can cause significant degrade of
> performance.
this could be a pre-plan / pre-exec check, no more.
> But I am not sure that this check is actually needed.
> If table is changed in some
09/01/2018 23:11, Fabien COELHO пишет:
>
> Hello Ildar,
>
>> Sorry for a long delay. I've added hash() function which is just an
>> alias for murmur2. I've also utilized variable arguments feature from
>> least()/greates() functions to make optional seed parameter, but I
>> consider this as a hack
10/01/2018 16:35, Ildar Musin пишет:
> 09/01/2018 23:11, Fabien COELHO пишет:
>> Hello Ildar,
>>
>>> Sorry for a long delay. I've added hash() function which is just an
>>> alias for murmur2. I've also utilized variable arguments feature from
>>> least()/greates() functions to make optional seed p
On 10.01.2018 16:02, legrand legrand wrote:
But performing this query on each access to the table seems to be bad
idea: in case of nested loop join it can cause significant degrade of
performance.
this could be a pre-plan / pre-exec check, no more.
AS-OF timestamp can be taken from outer tab
On 01/10/2018 06:38 AM, Edmund Horner wrote:
> Hi Vik, thanks so much for the comments and the offer to review!
>
> I kept a low profile after my first message as there was already a
> commitfest in progress, but now I'm working on a V2 patch.
>
> I will include aggregate and window functions as
On 09.01.2018 19:48, Antonin Houska wrote:
Konstantin Knizhnik wrote:
On 14.08.2017 19:33, Konstantin Knizhnik wrote:
On 14.08.2017 12:37, Konstantin Knizhnik wrote:
Hi hackers,
I am trying to compare different ways of optimizing work with huge
append-only tables in PostgreSQL wher
On Thu, Dec 14, 2017 at 2:39 PM, Teodor Sigaev wrote:
> SQL-query seems too huge for release notes and isn't looking for
> materialized view (fixable) and functional indexes with function which
> contains this operator somewhere inside (not fixable by this query). I
> think, just words is enough.
David Rowley wrote:
> Hi Álvaro,
Hi David,
Thanks for the review. Attached is a delta patch that fixes most
things, except your item 14 below.
Before getting into the details of the items you list, in this version I
also fixed a couple of issues noted by Jaime Casanova; namely
a) ALTER INDEX
On 10 January 2018 at 04:24, Jeff Davis wrote:
> On Sat, Jan 6, 2018 at 10:38 AM, Simon Riggs wrote:
>> For this to be useful, it needs to include some details of how to use
>> it when people have NOT used range datatypes in their tables.
>
> Good idea. I added an example that doesn't have range
On Tue, Jan 9, 2018 at 3:36 PM, Peter Eisentraut
wrote:
> I agree a backend status message is the right way to do this.
>
> We could perhaps report transaction_read_only, if we don't want to add a
> new one.
That's not really the same thing, though.
I think that we really need to think about all
On 10 January 2018 at 04:24, Jeff Davis wrote:
> Done.
I think you need to make changes to other parts of the docs also, so
that it is clear what will now be possible
https://www.postgresql.org/docs/devel/static/using-explain.html
https://www.postgresql.org/docs/devel/static/xoper-optimization.
On Tue, Jan 9, 2018 at 5:41 AM, Amit Khandekar wrote:
> This subplan should not be there. It looks like that's because when
> we add up subpaths while preparing Parallel Append path containing mix of
> partial and non-partial child paths, in accumulate_append_subpath(),
> the subpath being added i
On 10 January 2018 at 16:08, Robert Haas wrote:
> I think that we really need to think about allowing clients to tell
> the server which GUCs they'd like reported, instead of having a single
> list to which everyone is bound.
+1
--
Simon Riggshttp://www.2ndQuadrant.com/
Postgre
On 1/8/18 20:28, Peter Eisentraut wrote:
> On 1/8/18 15:27, Andrew Dunstan wrote:
>> This seems like a good idea, and the code change is tiny and clean. I
>> don't know of any third party PLs or other libraries might be pinning
>> the portals already on their own. How would they be affected if they
Teodor Sigaev wrote:
> SQL-query seems too huge for release notes and isn't looking for
> materialized view (fixable) and functional indexes with function which
> contains this operator somewhere inside (not fixable by this query). I
> think, just words is enough.
But the query can be made a litt
On 01/10/2018 01:37 AM, Oleg Bartunov wrote:
>
>
>
> this. Something similar to what we're using for json itself (a
> simple lexer and a recursive descent parser) would be more
> suitable.
>
>
> flex/bison is right tool for jsonpath, which is complex thing.
It's not really
On 10 Jan 2018 20:14, "Andrew Dunstan"
wrote:
On 01/10/2018 01:37 AM, Oleg Bartunov wrote:
>
>
>
> this. Something similar to what we're using for json itself (a
> simple lexer and a recursive descent parser) would be more
> suitable.
>
>
> flex/bison is right tool for jsonp
Robert Haas writes:
> I think that we really need to think about allowing clients to tell
> the server which GUCs they'd like reported, instead of having a single
> list to which everyone is bound.
Interesting idea ...
> As a side benefit, then Craig and Tom can stop arguing about whether
> serv
On 01/10/2018 09:22 AM, Tom Lane wrote:
... but I don't think it fixes that, because you couldn't send this new
request without making an assumption about the server version being
new enough to support it. My entire beef with making server_version_num
be GUC_REPORT is that it would encourage peo
On 1/9/18, 8:55 PM, "Michael Paquier" wrote:
> On Tue, Jan 09, 2018 at 01:46:55PM -0800, Andres Freund wrote:
>> On 2018-01-09 10:23:12 -0500, Robert Haas wrote:
>> > On Mon, Jan 8, 2018 at 11:27 PM, Michael Paquier
>> > wrote:
>> > > On Thu, Dec 28, 2017 at 10:46:18PM +, Bossart, Nathan wrot
"Joshua D. Drake" writes:
> On 01/10/2018 09:22 AM, Tom Lane wrote:
>> ... but I don't think it fixes that, because you couldn't send this new
>> request without making an assumption about the server version being
>> new enough to support it. My entire beef with making server_version_num
>> be GU
On 1/8/18 8:58 PM, Peter Eisentraut wrote:
> On 1/3/18 08:11, Robert Haas wrote:
>> On Tue, Jan 2, 2018 at 11:43 AM, David Steele wrote:
> I think MakeDirectory() is a good wrapper, but isn't
MakeDirectoryPerm() sort of silly?
>>>
>>> There's one place in the backend (storage/ipc/ipc.c) t
On 01/10/2018 09:36 AM, Tom Lane wrote:
It seems to me that is not our problem. Why do we care if some developer
says, "I only work with 9.6"? If I am understanding your complaint.
I don't care at all if J. Random Developer's homegrown code only works
with the PG version he's using. The concer
David,
* David Steele (da...@pgmasters.net) wrote:
> On 1/8/18 8:58 PM, Peter Eisentraut wrote:
> > On 1/3/18 08:11, Robert Haas wrote:
> >> On Tue, Jan 2, 2018 at 11:43 AM, David Steele wrote:
> > I think MakeDirectory() is a good wrapper, but isn't
> MakeDirectoryPerm() sort of silly?
While analyzing a recent crash report[1], I noticed that bufmgr.c's
ckpt_buforder_comparator is coded to assume that no two CkptSortItems
could have equal page IDs; it therefore skips the final comparison
and will never return 0 (equal). I do not think that assumption is
correct. I do not see any
David Steele wrote:
> On 1/8/18 8:58 PM, Peter Eisentraut wrote:
> > Yeah, I didn't like this aspect when this patch was originally
> > submitted. We want to keep the code legible for future new
> > contributors. Having these generic-sounding but specific-in-purpose
> > wrapper functions can be
Hello Ildar,
Patch needs a rebase after Teodor push for a set of pgbench functions.
Done. Congratulations on your patch finally being committed : )
Over 21 months... I hope that pgbench will have hash functions sooner:-)
Should we probably add some infrastructure for optional arguments?
On Tue, Jan 9, 2018 at 10:36 PM, Thomas Munro
wrote:
> This looks good to me.
The addition to README.parallel is basically wrong, because workers
have been allowed to write WAL since the ParallelContext machinery.
See the
XactLastRecEnd handling in parallel.c. Workers can, for example, due
HOT c
Patch needs a rebase after Teodor push for a set of pgbench functions.
Done. Congratulations on your patch finally being committed : )
I forgot: please provide a doc & some coverage tests as well!
--
Fabien.
Hello hackers,
I'd like to follow up to my previous proposition of tracking (some) best
and worst plans for different queries in the pg_stat_statements extension.
Based on the comments and suggestions made towards my last endeavour,
I've taken the path of computing the interquartile distance
> committed
I'm afraid it causes regressions for pgjdbc.
Here's CI log: https://travis-ci.org/pgjdbc/pgjdbc/jobs/327327402
The errors are:
testMetaData[typeName = REF_CURSOR, cursorType =
2,012](org.postgresql.test.jdbc2.RefCursorTest) Time elapsed: 0.032 sec
<<< ERROR! org.postgresql.util.PSQL
On 8 January 2018 at 23:13, Shubham Barai wrote:
>
>
> On 8 January 2018 at 22:44, Shubham Barai
> wrote:
>
>>
>>
>> On 5 January 2018 at 03:18, Alexander Korotkov > > wrote:
>>
>>> On Thu, Jan 4, 2018 at 7:07 PM, Andrey Borodin
>>> wrote:
>>>
29 нояб. 2017 г., в 22:50, Shubham Barai
I think I found what happened here.
One WAL record can be split between WAL files.
In XLogReadRecord, if last WAL record is incomplete, it try to get next WAL:
/* Copy the first fragment of the record from the first page. */
memcpy(state->readRecordBuf,
On 1/10/18 13:53, Vladimir Sitnikov wrote:
>> committed
>
> I'm afraid it causes regressions for pgjdbc.
> Here's CI log: https://travis-ci.org/pgjdbc/pgjdbc/jobs/327327402
>
> The errors are:
> testMetaData[typeName = REF_CURSOR, cursorType =
> 2,012](org.postgresql.test.jdbc2.RefCursorTest) Ti
Hi,
On 2018-01-10 13:06:50 -0500, Tom Lane wrote:
> So I think we should get rid of that micro-optimization, which is
> probably useless anyway from a performance standpoint, and do the
> comparison honestly. Any objections?
No, absolutely none. You're going to change it?
Greetings,
Andres Fre
On Sat, Dec 30, 2017 at 4:20 AM, Michael Paquier
wrote:
> On Sat, Dec 30, 2017 at 04:30:07AM +0300, Sergey Burladyan wrote:
> > We use this scripts:
> > https://github.com/avito-tech/dba-utils/tree/master/pg_archive
> >
> > But I can reproduce problem with simple cp & mv:
> > archive_command:
> >
On 01/10/2018 11:08 AM, Robert Haas wrote:
> I think that we really need to think about allowing clients to tell
> the server which GUCs they'd like reported, instead of having a single
> list to which everyone is bound.
+1
That already sounded like a good idea back in
https://www.postgresql.org
Kyotaro HORIGUCHI writes:
> [ 0002-Lock-parent-on-ALTER-TABLE-NO-INHERIT.patch ]
I don't especially like any of the patches proposed on this thread.
The one with rechecking inheritance seems expensive, duplicative,
and complicated. The approach of taking a lock on the parent will
create deadlock
Andres Freund writes:
> On 2018-01-10 13:06:50 -0500, Tom Lane wrote:
>> So I think we should get rid of that micro-optimization, which is
>> probably useless anyway from a performance standpoint, and do the
>> comparison honestly. Any objections?
> No, absolutely none. You're going to change it
On Wed, Jan 10, 2018 at 12:36 PM, Tom Lane wrote:
> I don't care at all if J. Random Developer's homegrown code only works
> with the PG version he's using. The concern I have is that unwanted
> server version dependencies will sneak into widely used code, like
> psql, or libpq, or jdbc. Or anot
Robert Haas writes:
> Your argument here sounds suspiciously like "If we add a new feature
> and people use it in a stupid way then it may cause their stuff not to
> work".
I think you're attacking a straw man ...
> Everything that worked before adding an option like _pq_.report
> continues to w
> On Jan 10, 2018, at 21:45, Robert Haas wrote:
>
> The documentation for max_parallel_workers_maintenance cribs from the
> documentation for max_parallel_workers_per_gather in saying that we'll
> use fewer workers than expected "which may be inefficient".
Can we actually call it max_parallel
On 01/10/2018 03:11 PM, Robert Haas wrote:
> it will only work on versions that support that option, but that is
> true of any new feature. Furthermore, they will easily be able to
> tell based on the reported server version whether or not their request
> for different behavior was accepted by th
On Wed, Jan 10, 2018 at 3:22 PM, Tom Lane wrote:
> My point is specifically that that reasoning fails for features that you
> might try to use to determine what the server version is, or that you
> might try to use before finding out what the server version is.
OK, I didn't understand that your o
On Wed, Jan 10, 2018 at 3:32 PM, Chapman Flack wrote:
> Is there a notion like that in the pq protocol now? If not, and
> a protocol bump becomes necessary to meet some need, would it be
> worth adding such a notion at the same time, to simplify future
> evolution?
For the fourth time in this thr
Robert Haas writes:
> But if we add this feature and somebody wants to use it for
> server_version_num, it's really pretty simple. In the startup packet,
> you say _pq_.report=server_version_num. Then, you call
> PQparameterStatus(conn, "server_version_num"). If you don't get a
> value, you try
> Sorry, truncate is not compatible with AS OF. It is performed at file
> level and deletes old old version.
> So if you want to use time travel, you should not use truncate.
As time travel doesn't support truncate, I would prefer it to be checked.
If no check is performed, ASOF queries (with tim
On Wed, Jan 10, 2018 at 3:55 PM, Tom Lane wrote:
> Robert Haas writes:
>> But if we add this feature and somebody wants to use it for
>> server_version_num, it's really pretty simple. In the startup packet,
>> you say _pq_.report=server_version_num. Then, you call
>> PQparameterStatus(conn, "se
On 1/10/18 12:37, David Steele wrote:
> How about MakeDirectoryDefaultPerm()? That's what I'll go with if I
> don't hear any other ideas. The single call to MakeDirectoryPerm() will
> be reverted to mkdir() and I'll remove the function.
Works for me.
--
Peter Eisentraut http://www
On Wed, Jan 10, 2018 at 3:29 PM, Evgeniy Shishkin wrote:
>> On Jan 10, 2018, at 21:45, Robert Haas wrote:
>> The documentation for max_parallel_workers_maintenance cribs from the
>> documentation for max_parallel_workers_per_gather in saying that we'll
>> use fewer workers than expected "which ma
On Wed, Jan 10, 2018 at 10:45 AM, Robert Haas wrote:
> The addition to README.parallel is basically wrong, because workers
> have been allowed to write WAL since the ParallelContext machinery.
> See the
> XactLastRecEnd handling in parallel.c. Workers can, for example, due
> HOT cleanups during S
On Wed, Jan 10, 2018 at 1:31 PM, Robert Haas wrote:
>> Can we actually call it max_parallel_maintenance_workers instead?
>> I mean we don't have work_mem_maintenance.
>
> Good point.
WFM.
--
Peter Geoghegan
I wrote:
> Evidently, they consider that negative beg_index indicates
> the last place where the target substring can *begin*, whereas
> our code thinks it is the last place where the target can *end*.
> After a bit of fooling around with it, I produced code that agrees
> with Oracle as far as I c
On Wed, Jan 10, 2018 at 5:05 PM, Peter Geoghegan wrote:
> How about I remove the comment, but have tuplesort_begin_common()
> force each Tuplesortstate to have workMem that is at least 64KB
> (minimum legal work_mem value) in all cases? We can just formalize the
> existing assumption that workMem
Robert Haas wrote:
> + * To support parallel sort operations involving coordinated callers to
> + * tuplesort.c routines across multiple workers, it is necessary to
> + * concatenate each worker BufFile/tapeset into one single leader-wise
> + * logical tapeset. Workers should have produced one fi
Antonin Houska writes:
> After having read the thread on your patch I think that the reason you were
> asked to evaluate performance was that your patch can possibly make syslogger
> a bottleneck. In contrast, my patch does not prevent user from disabling the
> syslogger if it (the syslogger) seem
On Wed, Jan 10, 2018 at 2:21 PM, Robert Haas wrote:
>> I share your general feelings on all of this, but I really don't know
>> what to do about it. Which of these alternatives is the least worst,
>> all things considered?
>
> Let's get the patch committed without any explicit way of forcing the
>
On Wed, Jan 10, 2018 at 2:36 PM, Alvaro Herrera wrote:
> I think "one at a time" is not the right way to interpret the affix.
> Rather, a "partitionwise join" is a join done "in the manner of
> partitions", that is, the characteristics of the partitions are
> considered when the join is done.
>
>
> I spent some more time comparing this version's behavior with
> rextester's Oracle instance, and couldn't find any other
> discrepancies, so I pushed it.
Great!
I agree with your commit message:
> Back-patch to all supported branches. Although this patch only touches
> documentation, we shoul
On Thu, Jan 11, 2018 at 11:42 AM, Peter Geoghegan wrote:
> "Peter Geoghegan, Rushabh Lathia" seems right. Thomas did write a very
> small amount of the actual code, but I think it was more of a review
> thing (he is already credited as a reviewer).
+1
--
Thomas Munro
http://www.enterprisedb.com
On Wed, Jan 10, 2018 at 05:26:43PM +, Bossart, Nathan wrote:
> Right. I don't have a terribly strong opinion either way. I think the
> counter-argument is that logging skipped relations might provide
> valuable feedback to users. If I ran a database-wide VACUUM and a
> relation was skipped d
On 11 January 2018 at 03:28, Vik Fearing wrote:
> On 01/10/2018 06:38 AM, Edmund Horner wrote:
>> Regarding support for older versions, psql fails silently if a tab
>> completion query fails.
>
> No it doesn't, see below.
>
>> We could just let it do this, which is what
>> happens with, for exampl
Andres Freund writes:
> You might not love me for this suggestion, but I'd like to see the
> renaming here split from the rest of the patch. There's a lot of diff
> that's just more or less automatic changes, making it hard to see the
> actual meaningful changes.
Yeah, I'm beginning to wonder if
On Sun, 31 Dec 2017 11:57:02 -0500
Tom Lane wrote:
> Yugo Nagata writes:
> > Attached is a patch to implement a feature to get the current function
> > name by GET DIAGNOSTICS in PL/pgSQL function.
>
> While this is certainly not a very large patch, it's still code that
> we'd have to maintain
On Thu, Jan 11, 2018 at 8:14 AM, Michael Paquier
wrote:
> On Wed, Jan 10, 2018 at 05:26:43PM +, Bossart, Nathan wrote:
>> Right. I don't have a terribly strong opinion either way. I think the
>> counter-argument is that logging skipped relations might provide
>> valuable feedback to users.
On 1/8/18 23:47, Michael Paquier wrote:
>> @@ -1505,7 +1515,7 @@ sub wait_for_catchup
>>. $target_lsn . " on "
>>. $self->name . "\n";
>> my $query =
>> -qq[SELECT '$target_lsn' <= ${mode}_lsn FROM pg_catalog.pg_stat_replication
>> WHERE application_name = '$standby_name';];
>
On Wed, Jan 10, 2018 at 09:45:56PM -0500, Peter Eisentraut wrote:
> On 1/8/18 23:47, Michael Paquier wrote:
> Should we just remove it? Apparently, it was never functional to begin
> with. Otherwise, we'd have to write a second query to return the value
> to print. wait_for_slot_catchup has the
On Sun, Dec 10, 2017 at 11:46:08AM -0800, Noah Misch wrote:
> On Sun, Dec 10, 2017 at 12:36:13PM +, Christian Ullrich wrote:
> > * Noah Misch wrote:
> > > On Wed, Nov 29, 2017 at 11:45:35PM -0500, Tom Lane wrote:
> > >> Oh, OK. In that case, we need to get some representatives of these
> > >>
Thanks for making those changes.
On 11 January 2018 at 04:00, Amit Khandekar wrote:
> Yes, I understand that there won't be any update scan plans. But, with
> the modifications done in ExecInitModifyTable(), I wanted to run that
> code with this scenario where there are no partitions, to make sur
On 11 January 2018 at 10:44, David Rowley wrote:
>>> 18. Why two RESET SESSION AUTHORIZATIONs?
>>>
>>> reset session authorization;
>>> drop trigger trig_d_1_15 ON part_d_1_15;
>>> drop function func_d_1_15();
>>> -- Policy expression contains SubPlan
>>> reset session authorization;
>>
>> The sec
On Thu, Jan 11, 2018 at 3:35 AM, Peter Geoghegan wrote:
> On Wed, Jan 10, 2018 at 1:31 PM, Robert Haas
> wrote:
> >> Can we actually call it max_parallel_maintenance_workers instead?
> >> I mean we don't have work_mem_maintenance.
> >
> > Good point.
>
> WFM.
>
>
This is good point. I agree with
On 11 January 2018 at 04:37, Alvaro Herrera wrote:
> In prior incarnations of the patch, I had an if-test to prevent
> attaching invalid indexes, but I decided to remove it at some point --
> mainly thinking of attaching a partition for which a CREATE INDEX
> CONCURRENTLY was running which already
I see there are some tests in src/test/regress:
sql/numeric.sql
expected/numeric.out
They pass. I see "numeric ... ok" in a make check.
I do not doubt they are being run, because if I edit numeric.sql
and fudge some digits, say around
-- cases that used to error out
select 0.12 ^ (-25);
select
On Tue, Nov 7, 2017 at 4:10 PM, Thomas Munro
wrote:
> Hi hackers,
>
> I have often wanted $SUBJECT and was happy to find that Fujii-san had
> posted a patch five years ago[1]. The reception then seemed positive.
> So here is a refurbished and (hopefully) improved version of his patch
> with a ne
* From: Noah Misch [mailto:n...@leadboat.com]
> > > Ready to go, waiting for animal assignment. For now, I can
> confirm that it works, that is, the buildfarm --test run is
> successful.
> Did the animal assignment come through? I don't see such an animal
> reporting.
No, not yet. Sorry, I lost
Hi all,
While reviewing another patch related to the use of pg_strcasecmp in the
backend, I have noticed this bit in ruleutils.c:
/*
* Some GUC variable names are 'LIST' type and hence must not
* be quoted.
*/
if (pg_strcasecmp(configitem, "DateStyle") == 0
|| pg_st
Hello. Thank you for the comment.
(And sorry for the absense.)
At Fri, 22 Dec 2017 15:04:20 +0300, Sergei Kornilov wrote in
<337571513944...@web55j.yandex.ru>
> Hello
> I think limit wal in replication slots is useful in some cases. But first
> time i was confused with proposed terminology
>
Chapman Flack writes:
> I see there are some tests in src/test/regress:
> [ that don't work for me ]
> Is there some special GUC setting in effect during the make check
> that would be different in my ordinary session? What else could
> be different? This is making me question my sanity.
Hm, it w
(2018/01/09 23:46), Robert Haas wrote:
On Mon, Jan 8, 2018 at 10:37 PM, Etsuro Fujita
wrote:
Attached is a patch for that.
Committed.
Thank you!
Best regards,
Etsuro Fujita
Thank you for the discussion.
# I didn't noticed that the license has been changed.
At Sat, 30 Dec 2017 14:35:27 -0500, Andrew Dunstan
wrote in
<4ab7546e-dd48-c985-2b26-e98d58920...@2ndquadrant.com>
>
>
> On 12/30/2017 10:45 AM, Tom Lane wrote:
> > Andrew Dunstan writes:
> >> As for out-dat
(2017/12/27 20:55), Etsuro Fujita wrote:
> Attached is an updated version of the patch.
I revised code/comments a little bit. PFA new version.
Best regards,
Etsuro Fujita
*** a/contrib/postgres_fdw/deparse.c
--- b/contrib/postgres_fdw/deparse.c
***
*** 132,138 static void depars
91 matches
Mail list logo
