x27;s focus on the
technical concerns I wrote about in the first part of the email rather
than wrangling about business interests. I'm not blind to the fact
that we work for different companies and I realize that can create
some tension, but if we want to *have* a PostgreSQL community we'v
ion and grouping at
> foreign server side. But still it is very useful and flexible mechanism,
> allowing to implement many wonderful things.
That is true. And everybody is entitled to an opinion on each new
proposed hook, as to whether that hook is general or not. We have
both accepted
e done,
perhaps you should just go ahead.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
be able to run the whole regression test suite with
a given --temp-config. I'm in agreement with this change but if it
doesn't play well with that need, I suppose I'll be writing that
pg_regress.c patch sooner rather than later.
--
Robert Haas
EnterpriseDB: http://www.enterprised
t should probably keep doing the same things it's always
done. If you want to supply a BC date, why not do this:
rhaas=# select to_date('0001-06-01 BC', '-MM-DD BC');
to_date
---
0001-06-01 BC
(1 row)
--
Robert Haas
EnterpriseDB: http://www.enterpri
On Sat, Feb 27, 2016 at 6:19 PM, Michael Paquier
wrote:
> On Sat, Feb 27, 2016 at 1:08 AM, Robert Haas wrote:
>> On Fri, Feb 26, 2016 at 6:16 PM, Michael Paquier
>> wrote:
>>> On Fri, Feb 26, 2016 at 4:18 PM, Kyotaro HORIGUCHI
>>> wrote:
>>>> I mar
On Sat, Feb 27, 2016 at 8:36 PM, Andrew Dunstan wrote:
> "doesn't meet your need" is probably a better way of putting it. The
> facility's use has grown beyond what I originally envisaged, so I think we
> will need that patch.
>
> Would you like me to apply w
On Sat, Feb 27, 2016 at 7:05 PM, Noah Misch wrote:
> On Fri, Feb 26, 2016 at 04:16:58PM +0530, Robert Haas wrote:
>> Committed these patches after revising the comment you wrote and
>> adding documentation.
>
> I've modified buildfarm member mandrill to use force
sses
+* up are probably much slower than the simple memory writes
we did while
+* holding the lock.
+*/
This comment was true in the place that you cut-and-pasted it from,
but it's not true here, since we potentially need to read from disk.
--
Robert Haas
EnterpriseDB:
#x27;ll abstain from the question of whether this patch is too late in
coming (but the answer is probably "yes") and instead volunteer to
review it.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-
e thing, but I don't know why it deserves scorn.
> or in this way:
>
> xlrec.xact_time = xactUseGTM ? xactStopTimestamp + GTMdeltaTimestamp
> : xactStopTimestamp;
>
> is very very bad idea.
I don't know why that is such a bad idea. It's a heck of a lo
On Tue, Mar 1, 2016 at 10:37 AM, Bruce Momjian wrote:
> On Tue, Mar 1, 2016 at 10:19:45AM -0500, Robert Haas wrote:
>> > Two reasons:
>> > 1. There is no ideal implementation of DTM which will fit all possible
>> > needs
>> > and be efficient for all clu
hem OIDs, but where will those OIDs come from? What
guarantees that they aren't in use, or won't be used later while your
temporary object still exists? I think making this work would make
parallel query look like a minor feature.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
unction.
Actually, this function just doesn't seem to fit into this section at
all. It's really quite different from the others listed there. How
about something like the attached instead?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
gejlp
e
> end-of-life of 9.5 series at least.
Yeah, I'm rather doubtful about anything happening with cmake any time soon.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To ma
On Wed, Feb 17, 2016 at 3:22 AM, Fabien COELHO wrote:
> Indeed. My gcc 4.8.4 with --Wall does not show the warning, too bad.
>
> Attached is the fixed patch for the array method.
Committed with a few tweaks, including running pgindent over some of it.
--
Robert Haas
Enterpris
On Mon, Feb 29, 2016 at 4:07 AM, Kouhei Kaigai wrote:
> RegisterExtensibleNodeMethods() initializes its hash table
> with keysize=NAMEDATALEN, instead of EXTNODENAME_MAX_LEN.
>
> The attached patch fixes it.
Oops.
Thanks, committed.
--
Robert Haas
EnterpriseDB: http://www.enterpri
events will be a list of the individual LWLocks, which I
suppose then will each need a brief description.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Feb 26, 2016 at 12:33 AM, Kyotaro HORIGUCHI
wrote:
> I divided the last patch into one typo-fix patch and one
> improvement patch. This is the former one.
Committed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-h
ter 'é'. With the patch it does.
OK, but I am a little concerned about this code:
/* Find something that matches */
if (result && PQresultStatus(result) == PGRES_TUPLES_OK)
{
const char *item;
while (list_index < PQntuples(result) &&
r the
lock levels we choose here. Just changing it without analyzing why a
certain level is sufficient for safety and no higher than necessary
seems poor. And the reasoning should be documented for future
readers.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreS
of what's in that view, and
it wasn't reliable in my testing. I did however throw together a
little contrib module for testing, which I attach here. I'm not sure
we want to commit this, and at the least someone would need to write
documentation. But it's certainly handy for
long list of things to do later ;-). There might be other
> pain points I haven't recognized yet.
Yikes. The read-only test is an 0.5% hit which isn't great, but the
read-write test is about 5% which I think is clearly not OK. What's
your plan for doing something about th
er to restructure this a bit so that the
decision about whether to add the hash path is based on whether there
are any other paths in the rel when we reach the bottom of the
function. create_grouping_paths() has a similar issue.
In general, and I'm sure this is not a huge su
this and Amit's clog control log patch(es)? Maybe
the combination of the two helps substantially more than either one alone.
Or maybe not, but seems worth checking.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
that pgbench.c is not pgindent'ed. Since you
> are modifying this file anyway probably you cold solve this issue too?
> As a separate patch perhaps.
That's not really this patch's job.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
g logic in pgstat_report_tabstat() to time out
-- and send a message
SELECT pg_sleep(1.0);
pg_sleep
--
(1 row)
That function was renamed in commit
93c701edc6c6f065cd25f77f63ab31aff085d6ac, but apparently Tom forgot to
grep for other uses of that identifier name.
--
Robert Haas
Enterpr
On Thu, Mar 3, 2016 at 2:19 PM, Tom Lane wrote:
> Robert Haas writes:
>> Thanks for working on this. Some review comments:
>
>> - I think all of the new path creation functions should bubble up
>> parallel_degree from their subpath.
>
> Ah, thanks, I didn't ha
On Fri, Mar 4, 2016 at 12:46 AM, Tom Lane wrote:
> Robert Haas writes:
>> A couple of my colleagues have been looking into this. It's not
>> entirely clear to me what's going on here yet, but it looks like the
>> stats get there if you wait long enough. Rahila Sy
On Fri, Mar 4, 2016 at 10:33 AM, Tom Lane wrote:
> Robert Haas writes:
>> Sure. If you have an idea what the right thing to do is, please go
>> ahead.
>
> Yeah, I'll modify the patch and commit sometime later today.
OK, if you're basing that on the patch I sent
ion
> updates? If we've gotten those, we must have gotten the earlier ones.
I'm not sure if that's actually true with parallel mode. I'm pretty
sure the earlier workers will have terminated before the later ones
start, but is that enough to guarantee that the stats collec
On Fri, Mar 4, 2016 at 11:17 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Mar 4, 2016 at 11:03 AM, Tom Lane wrote:
>>> Well, that would make the function more complicated, but maybe it's a
>>> better answer. On the other hand, we know that the stat
on it. And we're not going to cut any releases in between,
> so what's the benefit of not having it there?
Agreed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
r than
I am also tempted to change the API to be a bit more friendly,
although I am not sure exactly how. This was a quick and dirty hack
so that I could test, but the hardest thing about making it not a
quick and dirty hack is probably deciding on a good UI.
--
Robert Haas
EnterpriseDB: htt
of
10 is a little unsettling but I think we can live with it.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
adds these options.
>
> Yeah, I agree that we don't need to go out of our way to make the query
> succinct here. Explicitness is easier and safer too, so why not?
+1. So, committed Ashutosh's version.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise P
attached instead?
>
> Right. Mentioning the function in the description of relevant function looks
> better and avoids some duplication.
Cool, committed that way.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
vious
> string_length and string_length for string_length_cars. Also
> text_length is renamed in the attached patch.
I committed this and back-patched this but (1) I avoided changing the
other functions for now and (2) I gave both the byte length and the
character length new names to avoid
On Fri, Mar 4, 2016 at 12:02 PM, Alvaro Herrera
wrote:
> Robert Haas wrote:
>> On Wed, Mar 2, 2016 at 8:07 PM, Kyotaro HORIGUCHI
>> wrote:
>> > Hello, thank you for the comments.
>> >> I think we should leave string_length as it is and use a new variable
>
On Fri, Mar 4, 2016 at 12:08 PM, Robert Haas wrote:
> On Fri, Mar 4, 2016 at 12:02 PM, Alvaro Herrera
> wrote:
>> Robert Haas wrote:
>>> On Wed, Mar 2, 2016 at 8:07 PM, Kyotaro HORIGUCHI
>>> wrote:
>>> > Hello, thank you for the comments.
>>>
;>
>> IMO this patch may need to backpatch supported branches as it is
>> a bug fix. Committer can decide.
>
> +1 for the backpatch. The current error message should the rolename be
> undefined in this context is misleading for users.
Back-patched to 9.5. I don't thin
ion has to treat the raw descriptor
> carefully not to give an adverse effect to the storage manager.)
>
> How about this tiny enhancement?
Why not FileDescriptor(), FileFlags(), FileMode() as separate
functions like FilePathName()?
--
Robert Haas
EnterpriseDB: http://www.enterprised
t;
>> > WaitForParallelWorkersToFinish(pei->pcxt);
>> >
>> >
>> >
>> > /* Next, accumulate buffer usage. */
>> >
>> > - for (i = 0; i < pei->pcxt->nworkers; ++i)
>> >
>> > + for (i = 0; i < pei->pcxt->nworkers_lau
d. Otherwise, we need an
explicit sort. Anyway, it seems like the two stages should be costed
and decided on their own merits - there's no reason to chain the two
decisions together.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
; For the good, because cardinality estimations will be more accurate in these
> cases, so yes I would expect it to be back-patchable.
-1. I think the cost of changing existing query plans in back
branches is too high. The people who get a better plan never thank
us, but t
hen
> snapshot->subxcnt.
>
> I tried hard to come up with individual test but somehow I was unable to
> create testcase.
>
> PFA patch to fix the issue.
Thanks, that looks right to me. Committed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Pos
hat means
> “function called by function”, sometimes it isn't. So I’ve also changed it to
> actual call nesting.
After some study, this looks good to me, so committed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing
to execute a bulk modification
directly on the remote server". It shouldn't actually begin the
execution phase.
+ End the table update and release resources. It is normally not important
And I think this one should say "Clean up following a bulk
modification on the remote serv
On Fri, Mar 4, 2016 at 2:39 PM, Thomas Munro
wrote:
> Here is a patch to fix a typo in a comment in timestamp.c.
That looks like a typo, all right. Committed.
(It's "commit small patches day" for me today, in case anybody hasn't
caught on to that already...)
--
Robert
FROM
pg_catalog.pg_roles ");
+ "FROM
pg_catalog.pg_roles "
+ "WHERE rolname
!~ '^pg_'");
if (PQntuples(res) != 1)
pg_fatal("cou
l.org/message-id/56500356.4070...@bluetreble.com
+ if (blkno == nblocks - 1 &&
vacrelstats->num_dead_tuples == 0 && nindexes != 0
+ && vacrelstats->num_index_scans == 0)
+ total_index_pages = 0;
I'm not sure what this is trying to do
in this area are attempting to do. Meanwhile, there's also
Bruce, who is neither doing nor planning to do any work in this area,
nor advising either EnterpriseDB or the PostgreSQL community to
undertake any particular project, but who *is* making it sound like
there is a super sekret plan that nob
is to start with a good algorithm, write reliable code to
implement it, and then optimize.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ically, and in no particular order, we plan to
continue contributing performance and scalability enhancements,
improvements to parallel query, and FDW-related improvements, just as
we have for 9.6. We may also try to contribute other stuff that we
think will be cool and benefit PostgreSQL.
Server in some places
where PostgreSQL doesn't have them, and it's not hard to imagine that
somebody else might find those useful, at least. Whether they'd be
useful enough that the PostgreSQL community would accept them if
EnterpriseDB were to approve open-sourci
None of that means I would support any particular hook proposal, of
course.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
hat as an OID is reasonable. We're not going to be able
to pass variable-sized arrays through this mechanism, ever, because
our shared memory segment doesn't work like that. And it seems to me
that nearly every command somebody might want to report progress on
will touch, basically, one
relation extension lock wait queue is, instead of adding
more stuff to PGPROC?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgr
On Fri, Mar 4, 2016 at 2:37 PM, Andres Freund wrote:
> On 2016-02-12 15:56:45 +0100, Andres Freund wrote:
>> Hi,
>>
>>
>> On 2016-02-10 23:26:20 -0500, Robert Haas wrote:
>> > I think the part about whacking around the FDW API is a little more
>> > p
test case that
illustrates this problem? Ideally, one that doesn't involve
installing PostGIS?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ime believing that starting
over will be better. Somebody can do that if they like and I'm not
gonna get in the way, but if it's got problems that could have been
avoided by basing that same work on the FDW stuff we've already got, I
do plan to point that out.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
2 398304189836620
>
> I think, here we can not see any regression, (If I take median then it may
> looks low with patch so posting all 3 reading).
If the median looks low, how is that not a regression?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterp
develop, but it's a huge project unto
itself. My priority for 9.6 is to have a user-visible feature that
takes the infrastructure that we already have as far as it reasonably
can go. Building new infrastructure will have to wait for a future
release.
--
Robert Haas
EnterpriseDB: http://
On Mon, Mar 7, 2016 at 11:09 AM, Tom Lane wrote:
> Robert Haas writes:
>> The currently-committed code generates paths where nested loops and
>> hash joins get pushed beneath the Gather node, but does not generate
>> paths where merge joins have been pushed beneath the Gat
On Sun, Mar 6, 2016 at 11:24 PM, Kyotaro HORIGUCHI
wrote:
> At Fri, 4 Mar 2016 12:30:17 -0500, Robert Haas wrote
> in
>> >>> I committed this and back-patched this but (1) I avoided changing the
>> >>> other functions for now and (2) I gave both the byte le
---
> Update on public.foo (cost=100.00..101.05 rows=1 width=14)
>-> Foreign Update on public.foo (cost=100.00..101.05 rows=1 width=14)
> Remote SQL: UPDATE public.foo SET a = (a + 1) WHERE ((a = 1))
> (3 rows)
>
> The optimized plan requires just a single UPDATE query to do th
e attached cleanup patch.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
diff --git a/src/backend/access/heap/heapam.c b/src/backend/access/heap/heapam.c
index 8a64321..34ba385 100644
--- a/src/backend/access/heap/heapam.c
+++ b/src/backend/access/h
rdinate and consume from worker processes?
1 worker is often a very big speedup vs. 0 workers, and the work can
easily be evenly distributed between the worker and the leader.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers
's an updated patch with an API that I think is much more
reasonable to expose to users, and documentation! It assumes that the
patch I posted a few hours ago to remove PD_ALL_FROZEN will be
accepted; if that falls apart for some reason, I'll update this. I
plan to push this RSN i
or the second? I probably need more caffeine here, so please
tell me what I'm missing.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
rom heavyweight locks to
lightweight locks is going to work. It would mean, for example, that
we lose the ability to service interrupts while extending a relation;
not to mention that we lose scalability if many relations are being
extended at once.
--
Robert Haas
EnterpriseDB: http://www.ente
understand about file moves but it doesn't do a terribly
> good job with that history-wise (try git log or git blame on
> recently-moved files such as pgbench). And I've never heard even
> a claim that it understands splits.
But we've split very long source files in the
On Tue, Mar 8, 2016 at 8:30 AM, Robert Haas wrote:
> On Tue, Mar 8, 2016 at 7:26 AM, Masahiko Sawada wrote:
>> Regarding pg_visibility module, I'd like to share some bugs and
>> propose to add a relation type condition to each functions.
>
> OK, thanks.
I left out
re work in parallel.
> The setrefs.c parts of the patch remain completely broken. I've not
> had time to look at this again yet, sorry.
I hope you get time soon.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Mar 7, 2016 at 4:32 AM, Kouhei Kaigai wrote:
>> Why not FileDescriptor(), FileFlags(), FileMode() as separate
>> functions like FilePathName()?
>>
> Here is no deep reason. The attached patch adds three individual
> functions.
This seems unobjectionable to me, s
us about that IMHO.
This patch has been worked on by so many people and reviewed by so
many people that I can't keep track of who should be credited when it
gets committed. Could someone provide a list of author(s) and
reviewer(s)?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
Th
would be a set of read-only tests based on the
> database "regression" generated by make check, itself run with
> pg_regress.
I'm not sure anything in the main regression suite actually goes
parallel right now, which is probably the first thing to fix.
Unless, of course, you use f
be add a helper function
checkIntegerEquality(PgBenchValue *, int64).
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ally like the way you updated the
documentation. "eager freezing" doesn't seem like a great term to me,
and I think your changes were a little too localized. Here's a draft
alternative where I used the term "aggressive vacuum" to describe
freezing all of t
On Tue, Mar 8, 2016 at 11:48 AM, Fabien COELHO wrote:
> If this is a blocker I'll do them, but I'm convince it is not what should be
> done.
Well, I think it's a blocker. Exiting within deeply-nested code
instead of propagating the error upward does not strike me as a good
XID must be one that was
> in progress while VACUUM was running, and hence will be after the xmin
> horizon we computed earlier. This requires the existence of a read
> barrier somewhere between computing xmin horizon and inspecting the
> visibility map, but I find it hard to believ
committed the first and last of those. I think the other one
needs some work yet; the error message doesn't seem like it is quite
our usual style, and if we're going to do something here we should
probably also insert a check to throw a better error when there is no
relfilenode.
--
x it.
The test case failed for me, possibly because of Tom's upper planner
pathification, but the substantive part of the fix looks right to me,
so committed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list
recheck one single row, and there's only one order in which you can
return one row.
- if (bms_equal(em->em_relids, rel->relids))
+ if (bms_is_subset(em->em_relids, rel->relids))
Why do we need this?
--
Robert Haas
EnterpriseDB: http://www.enterpri
On Fri, Jan 15, 2016 at 6:20 AM, Etsuro Fujita
wrote:
> Attached patch makes minor modification to the GetForeignPlan
> documentation. This adds the description about outer_plan, the new
> parameter added in 9.5.
Good catch. Committed and back-patched to 9.5.
--
Robert Haas
Ent
to propose to add
> *fdw_recheck_quals* to both lists, then. Updated patch attached.
OK, sure. Committed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to you
ew it, but I doubt I'll find time before the end
> of the month.
Tom, can you pick this up?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
adds multiple blocks at a time to
its own function instead of including it all in line.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
uld be good to work on figuring out how
to fix that. I feel that some of the replies on this thread were
rather hostile considering that the goal -- good connectors for the
database server -- is extremely important.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQ
and then, in medias res, bomb out because of the idle timeout.
Then again, maybe you had some compelling reason for doing it this
way, in which case we should document that in the comments.
- It would be nice if you reviewed someone else's patch in turn.
I'm attaching a lightly-e
false on
> non-WIN32, if this gets backpatched). I got this warning from GCC6
> and it went away with this patch.
Peter, are you going to commit this?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgs
.). I think this should probably do the same.
I also think that we should probably store the end time someplace
instead of recomputing it in multiple places (this patch adds two such
places).
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via
yle.
Please fix the whitespace damage git diff --check complains about, and
check for other places where you haven't followed project style.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@p
On Mon, Mar 7, 2016 at 10:18 PM, Andres Freund wrote:
>> Instead of "durable" I think that "persistent" makes more sense.
>
> I find durable a lot more descriptive. persistent could refer to
> retrying the rename or something.
Yeah, I like durable, too.
ink we should drop the "else" and unindent the next two lines.
That's the style I have seen elsewhere. Plus less indentation equals
more happiness.
I'm pretty meh about the whole idea of this function, though,
actually, and I don't see a single clear +1 vote for this
fun
no place for that to come from except other people who
would like their own patches reviewed in turn, other than the limited
bandwidth of committers and of course the absolutely stunning efforts
of Michael Paquier to review everything in sight. But that's not
going to be enough: we really
appen -
>
> Many of "needs review" state patches already have reviewer(s). Do you
> mean we want more reviewers in addition to them for such patches?
Well, what we mostly need is more *reviews*. Whether those are from
the reviewers already signed up or new reviewers is, IMHO, a se
your best to review it, and you don't see
any remaining problems, you should mark it Ready for Committer.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
t one, which
will be first. And then, if there's one that has the pathkeys you
want, also consider that.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
t overzealous type checks ...
This.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
1 - 100 of 21742 matches
Mail list logo
