d we wouldn't look kindly on complaints about it.
Ideally, PQgetvalue should be redefined to return "const char *".
I don't really see us doing that anytime soon though. It would
result in a lot of compile warnings for perfectly-safe client code.
I'm sure this API would look different if it weren't
Andres Freund <and...@anarazel.de> writes:
> On 2017-06-26 17:38:03 -0400, Tom Lane wrote:
>> Hm. Take that a bit further, and we could drop the connection probes
>> altogether --- just put the whole responsibility on the postmaster to
>> show in the pidfile whether
Andres Freund <and...@anarazel.de> writes:
> On 2017-06-26 17:30:30 -0400, Tom Lane wrote:
>> No, I don't like that at all. Has race conditions against updates
>> coming from the startup process.
> You'd obviously have to take the appropriate locks. I think the i
ould
probably just write the state of the hot_standby GUC to the file, and
pg_ctl would have to infer things from there.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
d slave servers in the when-to-stop-waiting logic?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
till has a problem with long recovery sessions.
We could maybe address that by changing the set of states in pg_control
(or perhaps simpler, adding a "hot standby active" flag there). That
might have wider consequences than we really want to deal with post-beta1
though.
Andres Freund <and...@anarazel.de> writes:
> On 2017-06-26 16:19:16 -0400, Tom Lane wrote:
>> Sure, what do you think an appropriate behavior would be?
> It'd not be unreasonble to check pg_control first, and only after that
> indicates readyness check via the protocol.
a while?
Sure, what do you think an appropriate behavior would be?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Michael Paquier <michael.paqu...@gmail.com> writes:
> On Mon, Jun 26, 2017 at 7:13 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> The attached proposed patch adjusts pg_ctl to check every 100msec,
>> instead of every second, for the postmaster to be done starting o
very
surprised if someone does.
Anyway, pushed this patch with minor editing. Thanks!
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
because "top" is still
showing pretty low CPU load over most of the run, but this is
lots better than 4m30s.
regards, tom lane
diff --git a/src/backend/postmaster/postmaster.c b/src/backend/postmaster/postmaster.c
index 83e99b7..6c79c36 100644
*** a/src/backend/p
Andres Freund <and...@anarazel.de> writes:
> On 2017-06-26 12:32:00 -0400, Tom Lane wrote:
>> ... But I wonder whether it's intentional that the old
>> walreceiver dies in the first place. That FATAL exit looks suspiciously
>> like it wasn't originally-designed
. That FATAL exit looks suspiciously
like it wasn't originally-designed-in behavior.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ailed. The latest one is just hanging.
Well, if it's hung, maybe you could attach to the processes with gdb and
get stack traces manually?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
= ANY (ARRAY[]::integer[])))".
> I think there it is better to avoid constructing an empty array to avoid
> executing ANY expression.
Looks like a good idea, pushed with trivial stylistic adjustments.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgs
o already be ERANGE when we reach the
strtol() call, the code will incorrectly report an error.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
s, I'd like to see those fixed sleeps go away too. Want to work
on a concrete patch?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
wasn't being careful to
reset globalStats and archiverStats to zeroes if they were partially
filled from a corrupted stats file, so this deals with that too.
This seems like a backpatchable bug fix to me; any objections?
regards, tom lane
diff --git a/src/backend
; I do
not think it's been revisited since the first implementation of pg_ctl
in 1999 (cf 5b912b089).
Barring objections I'd like to push this soon.
regards, tom lane
diff --git a/src/bin/pg_ctl/pg_ctl.c b/src/bin/pg_ctl/pg_ctl.c
index 82ac62d..1e6cb69 100644
*** a/src/bin
nder sufficient load.
I wonder if there is an easy way to improve that ... maybe convert
to something involving poll_query_until?
regards, tom lane
diff --git a/src/test/recovery/t/001_stream_rep.pl b/src/test/recovery/t/001_stream_rep.pl
index 266d27c..8d6edd2 100644
*** a
ental
check, converting everything it was testing into Asserts still gets
through check-world. Accordingly, here's a proposed patch that gets
rid of exec_simple_check_node() and simplifies some of the rest of
the logic.
regards, tom lane
diff --git a/src/pl/plpgsql/s
an existing encoding-specific
collation that doesn't happen to match the current DB's encoding.
Now, you'd have to work at it for that to cause problems --- say,
create such a situation in template0 and then copy template0 specifying
that other encoding. But none of that is forbidden.
Peter Eisentraut <peter.eisentr...@2ndquadrant.com> writes:
> On 6/23/17 12:31, Tom Lane wrote:
>> icu_to_uchar() and icu_from_uchar(), and perhaps other places, are
>> touchingly naive about integer overflow hazards in buffer size
>> calculations.
> Here is a patch
basically nothing to do
with complying with the actual federal security standard.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ription worker process that has tried
and failed to apply the update. If our attitude towards this situation is
that it's okay to fork-bomb your server with worker processes continually
respawning and making no progress, well, I don't think that's good enough.
regards, tom lan
this would play with other libc locale
functionality (lc_monetary and so on), but we'd have to deal with
that question anyway.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
not exist
The attached proposed patch makes the behavior for ICU collations the
same, by dint of injecting the is_encoding_supported_by_icu() check
into collation name lookup.
regards, tom lane
diff --git a/src/backend/catalog/namespace.c b/src/backend/catalog/namespace.c
i
d out doesn't make a difference, but it's
> possibly something similar.
Maybe some function invoked in a debug ereport accesses shared memory
or takes locks (eg, for catalog access)?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@pos
ized version.
I'm inclined to add a test to reject non-ASCII in the ICU locale names as
well as the comments. We've had to do that for libc locale names, and
this experience shows that the ICU locale maintainers don't have their
heads screwed on any straighter. But this patch doesn't do that.
ass for each instance.
I find it hard to envision a similar use-case in partitioning though.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
s contrary to project policy,
and the error message violates our message style guidelines.
I don't particularly feel like fixing these things myself, but
somebody needs to; the overflow issues in particular are stop-ship
security hazards.
regards, tom lane
--
Sent via pgs
I don't think (b) would be terribly hard to fix if we had a motivation to,
but I wonder whether there aren't other places that also know this about
TIDs.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes t
y're usually not, then it's a loser. Do
we have any feeling for which case is more common?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
i and (i) equal? What
about (i) and (case when true then i else j end)? In principle,
the system could recognize both those identities, but it seems
silly to expend code on it just for nagware purposes.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-
Robert Haas <robertmh...@gmail.com> writes:
> On Thu, Jun 22, 2017 at 2:11 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> So I'm thinking about adding a regression test case, say in dependency.sql,
>> that looks for unpinned objects with OIDs in the hand-assigne
Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes:
> On 06/22/2017 10:24 AM, Tom Lane wrote:
>> That earlier request is still valid. Also, if you can reproduce the
>> symptom that lorikeet just showed and get a stack trace from the
>> (hypothetical) postmaster core
tedb()
checks those parameters with check_locale() which only knows about
libc-defined locale names.
Is there some way I'm missing, or is this just a not-done-yet feature?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chan
gigabytes.
I believe the reason is that the code paths in varstr_cmp that make
use of icu_to_uchar() have forgotten to free the palloc'd output
of the latter. I have not looked to see where else the users of
that and the reverse function made this mistake.
regards
r idea is just to make setup_collation() insert it first not last,
thereby ensuring that the SQL definition wins over any libc entries.
Comments?
regards, tom lane
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index e073f7b..bd2eaaa 100644
*** a/doc/
at it isn't sounds very much like wishful thinking.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
t feel that it's urgent to do so.
Thoughts?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
to me that we might someday grow additional
options to control the UPDATE, so I'm inclined to reject this patch.
If it were saving a meaningful amount of grammar code, I might think
differently, but it's not really. And it's not like we don't use the
same grammar pattern in lots of other places.
get a stack trace from the
(hypothetical) postmaster core dump, that would be hugely valuable.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Peter Eisentraut <peter.eisentr...@2ndquadrant.com> writes:
> On 6/18/17 10:14, Tom Lane wrote:
>> Doesn't cope with backslash-quoted characters. If we're going to bother
>> to do anything here, I think we ought to make it reversible for all
>> possible characters.
&g
it can't see anything inserted by that query.
Possibly it'd work as you wish with a VOLATILE function.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
a distinct feeling that there's something wrong
with the cygwin port. But I dunno what.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Andres Freund <and...@anarazel.de> writes:
> On 2017-06-21 17:28:32 -0400, Tom Lane wrote:
>> And I think it'd make sense to wait a few
>> months and garner some experience with back-patching from v10 into the
>> older branches, so we have more than guesses about how m
Bruce Momjian <br...@momjian.us> writes:
> On Wed, Jun 21, 2017 at 04:07:30PM -0400, Tom Lane wrote:
>> ... and it's done.
> You are eventually doing all active branches, right?
I don't think we'd entirely decided that we should do that, or when
to do it. I'm not in a huge hu
hout the option. This is not distinguishable from
what you have to do if you consider the startup message as belonging
to a new protocol version 4 instead of 3.
We have done this in the past, but it's painful, subject to bugs,
and generally is a pretty high price to pay for a marginal feature.
re
I wrote:
> Barring objections, I'd like to reindent HEAD with the new version
> of pg_bsd_indent (and correspondingly updated pgindent script)
> tomorrow, say around 1800 UTC.
... and it's done.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsq
Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes:
> On 06/21/2017 11:30 AM, Tom Lane wrote:
>> Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes:
>>> Unfortunately this seems precluded by the use of the non-standard
>>> "err.h". It look
Andres Freund <and...@anarazel.de> writes:
> On 2017-06-20 20:30:34 -0400, Tom Lane wrote:
>> Well, *I* don't care, but I thought we wanted to support Windows-using
>> developers as reasonably first-class citizens.
> The old one didn't have windows support either, righ
missed the call in inheritance_planner. Right.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes:
> Unfortunately this seems precluded by the use of the non-standard
> "err.h". It looks like that will trip us up on mingw also.
Hm, why? Doesn't the -I search path get the right thing?
regard
uld
flush the field altogether. Anybody who doesn't want that should at least
provide the missing comment for create_modifytable_path's partitioned_rels
argument (and yes, the fact that that is missing isn't making me any
more favorably disposed...)
regards, tom lane
Michael Paquier <michael.paqu...@gmail.com> writes:
> On Wed, Jun 21, 2017 at 8:43 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Yeah, I thought it would work fine with Makefile-using Windows toolchains.
>> But people who use MSVC need something else, no?
> Are t
Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes:
> On 06/20/2017 04:17 PM, Tom Lane wrote:
>> There's no Windows support yet, and I won't be writing that,
>> but I hope someone else will.
> What extra support do you think it needs? I have built it on Cygwin
&
were
clearly still necessary at the time, I didn't think hard about
whether any of the other post-planning checks could be got rid of.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas <robertmh...@gmail.com> writes:
> On Tue, Jun 20, 2017 at 3:18 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Robert Haas <robertmh...@gmail.com> writes:
>>> Should we add that to the opr_sanity tests?
>> Yeah, I was wondering a
o mean the latter but Julien's change makes it
about the former.
It could use rewording for clarity, just not this rewording.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Barring objections, I'd like to reindent HEAD with the new version
of pg_bsd_indent (and correspondingly updated pgindent script)
tomorrow, say around 1800 UTC.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
in your PATH; see
README.pg_bsd_indent for details.
There's no Windows support yet, and I won't be writing that,
but I hope someone else will.
BTW, HEAD's version of pgindent doesn't play with this yet, so
don't overwrite your old copy of pg_bsd_indent quite yet.
regards, tom
Robert Haas <robertmh...@gmail.com> writes:
> On Mon, Jun 19, 2017 at 9:57 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Hm, patch looks okay, but while eyeballing it I started to wonder
>> why in the world is pg_get_publication_tables marked prosecdef?
>> If
commits. What version are you testing?
Are you sure you selected serializable mode for both xacts?
(I think it would work like this even if only T2 is marked
serializable, but didn't test.)
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-
library names are converted
to lower case unless double-quoted", which means that formally this isn't
a bug at all, but operating-as-designed-and-documented. Still, I agree
it's an improvement.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@post
se case at all for
if_not_exists = false, I figure we might as well do #1 and take
whatever simplification we can get that way.
I'm willing to do the legwork on this, but before I start, does
anyone have any ideas or objections?
regards, tom lane
--
Sent via pgsql-hackers mail
okay, but while eyeballing it I started to wonder
why in the world is pg_get_publication_tables marked prosecdef?
If that has any consequences at all, they're probably bad.
There are exactly no other built-in functions that have that set.
regards, tom lane
--
Sent via pgsql-hacke
"David G. Johnston" <david.g.johns...@gmail.com> writes:
> On Mon, Jun 19, 2017 at 2:53 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Where are you reading that?
> https://www.postgresql.org/docs/9.6/static/app-psql.html
> First sentence:
> "Fo
nclude
matviews, and that matches the code, which has this as the default
expansion of \d:
/* standard listing of interesting things */
success = listTables("tvmsE", NULL, show_verbose, show_system);
regards, tom lane
--
Sent via pgsq
on or not, but I'm not very sure which side of that argument
I'd come down on. In any case the main point is that different
\d commands are doing different things for no very obvious reason.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Alvaro Herrera <alvhe...@2ndquadrant.com> writes:
> Tom Lane wrote:
>> ... If the trigger is succeeding (ie,
>> detecting a no-op update) often enough that it would be worth that,
>> you've really got an application-stupidity problem to f
e comparison. But that would
eat a lot more cycles than the current implementation, and it seems
dubious that it's worth it. If the trigger is succeeding (ie,
detecting a no-op update) often enough that it would be worth that,
you've really got an application-stupidity problem to fix.
> Is the compressio
t in some quick testing I could not
produce a counterexample proving that that heuristic is helpful;
so for now let's can it.
Thanks, and sorry again for the delay.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to y
Stephen Frost <sfr...@snowman.net> writes:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> On Sat, Jun 17, 2017 at 5:41 PM, Peter Eisentraut
>> <peter.eisentr...@2ndquadrant.com> wrote:
>>> On 6/16/17 10:51, Tom Lane wrote:
>>>> So I'm back t
Robert Haas <robertmh...@gmail.com> writes:
> On Mon, Jun 19, 2017 at 11:59 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> I don't think it's a bug, I think it's an intentional design tradeoff.
>> To suppress an update in this case, the trigger would have to grovel
>&
y'd be so enormous as to make this an interesting
project, but I could be wrong.
Obviously, the answer could be very different when considering a
mostly-hardware implementation. But until those are fairly readily
available, it's hard to believe very many people will be excited.
nly seldom add successes.
Possibly we should adjust the documentation so that it doesn't imply
that this trigger guarantees to suppress every no-op update.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
L, although no doubt nobody's noticed because there would always be
a match. (One call site does defend itself against null pattern, and it
uses two messages like the previous example.)
So we've got at least three things to normalize:
* fprintf(pset.queryFout) vs. psql_error()
* message wordi
ith that correction and some wordsmithing on the comment.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ng to Kuntal's patch up thread? If later, then it is better to
>> mention the link of mail which has a patch that you have verified.
> I am referring to Kuntal's patch upthread. The link for the email
> having the patch is,
> https://www.postgresql.org/message-id/CAGz5QCJPvbBjXA
ll for
the foreseeable future, because of pg_upgrade.
I'd suggest a rule like "if pd_lower is smaller than SizeOfPageHeaderData
then don't trust it, but assume all of the page is valid data".
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql
is to use DROP OPERATOR FAMILY instead.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Peter Eisentraut <peter.eisentr...@2ndquadrant.com> writes:
> On 6/16/17 10:51, Tom Lane wrote:
>> So I'm back to the position that we ought to stick the indent
>> code under src/tools/ in our main repo. Is anyone really
>> seriously against that?
> I think it would
_JP" already exists
Hmph. Could we see the results of "locale -a | grep ja_JP" ?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
question is whether we want to get that deeply invested
in a type that couldn't be considered standard for many years to come.
(Unless somebody wants to write an all-software fallback implementation,
which I sure don't.)
regards, tom lane
--
Sent via pgsql-hackers m
ght to make it reversible for all
possible characters.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
* of code */
+#ifndef false
#define false 0
+#endif
+#ifndef true
#define true 1
+#endif
FILE *input; /* the fid for the input file */
Other than that, I think this is a workable compromise on the
portability questions.
Robert Haas <robertmh...@gmail.com> writes:
> On Fri, Jun 16, 2017 at 10:51 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> So I'm back to the position that we ought to stick the indent
>> code under src/tools/ in our main repo. Is anyone really
>> seriously agai
Piotr Stefaniak <postg...@piotr-stefaniak.me> writes:
> On 2017-06-17 00:02, Tom Lane wrote:
>> What I'm testing with right now has just four differences from your repo:
> There are also the "portability fixes" and they're the main problem.
Fair enough.
>
Piotr Stefaniak <postg...@piotr-stefaniak.me> writes:
> On 2017-06-16 21:56, Tom Lane wrote:
>> Unless Piotr objects, I propose to add another switch to bsdindent
>> that selects this behavior, and then we can drop entab, removing
>> another impediment to getting pginde
Piotr Stefaniak <postg...@piotr-stefaniak.me> writes:
> On 2017-06-16 20:11, Tom Lane wrote:
>> I assume though that Piotr wants an option to preserve that behavior.
>> I'm happy to write up a patch for bsdindent that adds a switch
>> controlling this, but is there any
less Piotr objects, I propose to add another switch to bsdindent
that selects this behavior, and then we can drop entab, removing
another impediment to getting pgindent working.
regards, tom lane
diff -ur /home/postgres/freebsd_indent/indent.c ./indent.c
--- /home/postgres/free
Andres Freund <and...@anarazel.de> writes:
> On 2017-06-16 13:34:01 -0400, Tom Lane wrote:
>> I do intend to apply the diffs to HEAD in multiple steps, just to
>> make them more reviewable. But I think we should probably absorb
>> all the changes we want into v10, not
wrapping.
I assume though that Piotr wants an option to preserve that behavior.
I'm happy to write up a patch for bsdindent that adds a switch
controlling this, but is there any rhyme or reason to the way its
switches are named?
regards, tom lane
--
Sent via pgsql-hackers
I do intend to apply the diffs to HEAD in multiple steps, just to
make them more reviewable. But I think we should probably absorb
all the changes we want into v10, not leave some for later cycles.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers
.
Thoughts?
regards, tom lane
diff -ur pgsql/contrib/amcheck/verify_nbtree.c pgsql-dup/contrib/amcheck/verify_nbtree.c
--- pgsql/contrib/amcheck/verify_nbtree.c 2017-06-16 12:31:36.900504080 -0400
+++ pgsql-dup/contrib/amcheck/verify_nbtree.c 2017-06-16 12:35:21.042052427 -0400
ain repo. Is anyone really
seriously against that?
regards, tom lane
[1]
https://www.postgresql.org/message-id/VI1PR03MB119959F4B65F000CA7CD9F6BF2CC0%40VI1PR03MB1199.eurprd03.prod.outlook.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or
tension
authors have to do to update, but that doesn't have to mean "zero".
Also, it's wise to make sure that any places where code changes
have to be made will result in compile errors if the change isn't
made.
regards, tom lane
--
Sent via pgsql-hackers maili
Michael Paquier <michael.paqu...@gmail.com> writes:
> On Fri, Jun 16, 2017 at 1:01 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> (2) My inclination would be not to back-patch. This change could break
>> configurations that worked before, and the lack of prior complaints
&
1001 - 1100 of 46745 matches
Mail list logo
