Today I encountered an interesting situation.
1) A streaming replication primary server and a standby server is
running. At this point max_connections = 100 on both servers.
2) Shutdown both servers.
3) Change max_connections to 1100 on both servers and restart both
servers.
4) The
Hi Tom,
Tom Lane wrote,
Waldemar Brodkorb w...@openadk.org writes:
while doing regular builds via buildroot autobuilders
a compile problem for sparc 32bit v8 was found.
It seems the defines for Linux are other than for Solaris.
Following patch fixes it for buildroot:
The gcc
Tatsuo Ishii is...@postgresql.org writes:
I think this is because pg_control on the standby remembers that the
previous primary server's max_connections = 1100 even if the standby
server fails to start. Shouldn't we update pg_control file only when
standby succeeds to start?
Somebody refresh
Somebody refresh my memory as to why we have this restriction (that is,
slave's max_connections = master's max_connections) in the first place?
Seems like it should not be a necessary requirement, and working towards
getting rid of it would be far better than any other answer.
If you care
On Tue, Aug 11, 2015 at 1:50 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Masahiko Sawada wrote:
This topic may have been already discussed but, why don't we use just
total scanned pages and total pages?
Because those numbers don't extrapolate nicely. If the density of dead
tuples is
On Tue, Aug 11, 2015 at 2:42 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Tatsuo Ishii is...@postgresql.org writes:
I think this is because pg_control on the standby remembers that the
previous primary server's max_connections = 1100 even if the standby
server fails to start. Shouldn't we update
2015-08-10 9:11 GMT+02:00 Heikki Linnakangas hlinn...@iki.fi:
On 07/26/2015 08:34 AM, Pavel Stehule wrote:
Hi
here is complete patch, that introduce context filtering on client side.
The core of this patch is trivial and small - almost all of size are
trivial changes in regress tests -
Alexander Korotkov a.korot...@postgrespro.ru writes:
On Mon, Aug 10, 2015 at 1:12 PM, Petr Jelinek p...@2ndquadrant.com wrote:
I don't understand this, there is already AmRoutine in RelationData, why
the need for additional field for just amsupport?
We need amsupport in
On Mon, Aug 10, 2015 at 6:36 PM, Petr Jelinek p...@2ndquadrant.com wrote:
On 2015-08-10 16:58, Alexander Korotkov wrote:
That should work, thanks! Also we can have SQL-visible functions to get
amsupport and amstrategies and use them in the regression tests.
SQL-visible functions would be
Tom Lane wrote:
There are a couple of other pg_am columns, such as amstorage and
amcanorderbyop, which similarly bear on what's legal to appear in
related catalogs such as pg_opclass. I'd be sort of inclined to
leave those in the catalog as well. I do not see that exposing
a SQL function
On Sun, Aug 9, 2015 at 8:24 AM, Robert Haas robertmh...@gmail.com wrote:
In step 1, AcceptInvalidationMessages() should process all pending
invalidation messages. So if step 2 did AcceptInvalidationMessages()
again it would be a no-op, because no messages should remain at that
point.
On 2015-08-10 18:16, Alvaro Herrera wrote:
Tom Lane wrote:
There are a couple of other pg_am columns, such as amstorage and
amcanorderbyop, which similarly bear on what's legal to appear in
related catalogs such as pg_opclass. I'd be sort of inclined to
leave those in the catalog as well. I
On Mon, Aug 10, 2015 at 5:48 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Alexander Korotkov a.korot...@postgrespro.ru writes:
On Mon, Aug 10, 2015 at 1:12 PM, Petr Jelinek p...@2ndquadrant.com
wrote:
I don't understand this, there is already AmRoutine in RelationData, why
the need for
David Rowley david.row...@2ndquadrant.com writes:
On 10 August 2015 at 07:50, Tom Lane t...@sss.pgh.pa.us wrote:
I've started to work on path-ification of the upper planner (finally),
I was digging around the grouping_planner() last week with the intentions
of making some changes there to
On 2015-08-10 17:47, Tom Lane wrote:
Petr Jelinek p...@2ndquadrant.com writes:
On 2015-08-10 16:58, Alexander Korotkov wrote:
That should work, thanks! Also we can have SQL-visible functions to get
amsupport and amstrategies and use them in the regression tests.
SQL-visible functions would
On 2015-08-10 18:08, Tom Lane wrote:
Alexander Korotkov a.korot...@postgrespro.ru writes:
On Mon, Aug 10, 2015 at 6:47 PM, Tom Lane t...@sss.pgh.pa.us wrote:
There are a couple of other pg_am columns, such as amstorage and
amcanorderbyop, which similarly bear on what's legal to appear in
On Mon, Aug 10, 2015 at 3:23 AM, Heikki Linnakangas hlinn...@iki.fi wrote:
I've marked this as rejected in the commitfest, because others are
working on a more general solution with parallel workers. That's still
work-in-progress, and it's not certain if it's going to make it into
9.6, but if
Hello,
I try to write my first patch. It is too early to tell more about it,
but I am just fiddling around with some prototypes.
Can someone tell me, how I can compare two datum fields, when I do not
know the data type in advance inside an executor function?
For example, x less than y where
Masahiko Sawada wrote:
This topic may have been already discussed but, why don't we use just
total scanned pages and total pages?
Because those numbers don't extrapolate nicely. If the density of dead
tuples is irregular across the table, such absolute numbers might be
completely meaningless:
On 08/10/2015 09:55 AM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 08/09/2015 08:58 PM, Michael Paquier wrote:
Sure. Attached is what I have in mind. Contrary to your version we
keep around temp paths should a run succeed after one that has failed
when running make check
Hello,
When we're in Phase2 or 3, don't we need to report the number of total page
scanned or percentage of how many table pages scanned, as well?
The total heap pages scanned need to be reported with phase 2 or 3. Complete
progress report need to have numbers from each phase when applicable.
On Mon, Aug 10, 2015 at 6:47 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Petr Jelinek p...@2ndquadrant.com writes:
On 2015-08-10 16:58, Alexander Korotkov wrote:
That should work, thanks! Also we can have SQL-visible functions to get
amsupport and amstrategies and use them in the regression
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Tom Lane wrote:
I think that's likely for the best anyway; there are too many catalogs
that think a pg_am OID identifies an index AM. Better to create other
catalogs for other types of AMs.
That means we won't be able to reuse pg_class.relam
Hello Andres,
Thanks for your comments. Some answers and new patches included.
+ /*
+ * Array of buffer ids of all buffers to checkpoint.
+ */
+static int *CheckpointBufferIds = NULL;
Should be at the beginning of the file. There's a bunch more cases of that.
done.
+/* Compare
On 10 August 2015 at 18:02, Josh Berkus j...@agliodbs.com wrote:
There's a lesser version of this item which remains relevant unless we
implement (5). That is, currently the same autovacuum_vaccuum_delay
(AVVD) applies to regular autovacuums as does to anti-wraparound
autovacuums. If the
* extends pgbench expressions with functions
Robert signed up as reviewer for this a long time ago. Ping, do you still
plan to review this?
I seem to recall that I nominated Robert when adding the patch, because
this is an extension of his expression patch. So the sign up is really
just a
Ok ok, I stop resisting... I'll have a look.
Here is a v7 ab version which uses shared memory instead of palloc.
--
Fabien.diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index e900dcc..1cec243 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -2454,6
On 2015-08-10 19:07:12 +0200, Fabien COELHO wrote:
I think that there is no issue with the current shared_buffers limit. I
could allocate and use 4 GB on my laptop without problem. I added a cast to
ensure that unsigned int are used for the size computation.
You can't allocate 4GB with
Hello Andres,
You can't allocate 4GB with palloc(), it has a builtin limit against
allocating more than 1GB.
Argh, too bad, I assumed very naively that palloc was malloc in disguise.
[...]
Well, then everytime the checkpointer is restarted.
Hm...
The point is that it's done at
Hi,
while doing regular builds via buildroot autobuilders
a compile problem for sparc 32bit v8 was found.
It seems the defines for Linux are other than for Solaris.
Following patch fixes it for buildroot:
The gcc predefines for Linux are __sparc_v8__/__sparc_v7__
Signed-off-by: Waldemar
Simon,
Thank you for this summary! I was losing track, myself.
On 08/09/2015 11:03 PM, Simon Riggs wrote:
Freezing is painful for VLDBs and high transaction rate systems. We have
a number of proposals to improve things...
3. Speed up autovacuums when they are triggered to avoid wraparounds
Tom Lane wrote:
I'm not sure how pushing it out to psql makes that better. There is
no way to do further processing on something that psql has printed,
so you've punted on solving that issue just as much if not more.
It's the same spirit as \x : the only thing it achieves is better
I earliest reference I found to this issue is here
http://postgresql.nabble.com/set-search-path-in-dump-output-considered-harm
ful-td1947594.html and refers to the search_path being arbitrarily set in
the file created by pg_dump. This is apparently still the case in 9.4.
I found this issue
On Thu, Oct 30, 2014 at 5:30 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Thu, Oct 30, 2014 at 7:30 PM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp wrote:
+ {
+ {pending_list_cleanup_size, PGC_USERSET,
CLIENT_CONN_STATEMENT,
+
David Fetter wrote:
I'm working up a proposal to add (UN)PIVOT support to the back-end.
I was under the impression that a server-side PIVOT *with dynamic
columns* was just unworkable as an SQL query, because it couldn't
be prepared if it existed.
I am wrong on that? I feel like you
On Fri, Jun 19, 2015 at 07:10:40PM +0300, Marti Raudsepp wrote:
Hi list
Sorry I am just getting this report. Thanks to the people who stalled
for me.
One of my databases failed to upgrade successfully and produced this error in
the copying phase:
error while copying relation
On 08/10/2015 10:31 AM, Simon Riggs wrote:
Freezing is not a necessary pre-condition for either of those things, I
am happy to say. There is confusion here because for ( 1 ) the shrink
was performed after freezing, but when you have access to the epoch
there is no need for exhaustive freezing
On 2015-08-10 16:58, Alexander Korotkov wrote:
On Mon, Aug 10, 2015 at 5:48 PM, Tom Lane t...@sss.pgh.pa.us
mailto:t...@sss.pgh.pa.us wrote:
Alexander Korotkov a.korot...@postgrespro.ru
mailto:a.korot...@postgrespro.ru writes:
On Mon, Aug 10, 2015 at 1:12 PM, Petr Jelinek
On Tue, Aug 11, 2015 at 12:20 AM, Simon Riggs si...@2ndquadrant.com wrote:
On 10 August 2015 at 15:59, Syed, Rahila rahila.s...@nttdata.com wrote:
Hello,
When we're in Phase2 or 3, don't we need to report the number of total
page scanned or percentage of how many table pages scanned, as
On Fri, Nov 21, 2014 at 2:04 AM, Heikki Linnakangas hlinnakan...@vmware.com
wrote:
On 11/20/2014 05:52 AM, Michael Paquier wrote:
On Wed, Nov 19, 2014 at 7:01 AM, Peter Geoghegan p...@heroku.com wrote:
On Tue, Nov 4, 2014 at 7:26 AM, Amit Kapila amit.kapil...@gmail.com
wrote:
1.
Zhaomo,
* Zhaomo Yang (zmp...@gmail.com) wrote:
This thread has a pretty thorough discussion of pros and cons of applying
SELECT policy to other commands. Besides what have been mentioned, I think
there is another potential pro: we can enable references to pseudorelations
OLD and NEW in
Hi,
On 2015-08-08 20:49:03 +0300, Heikki Linnakangas wrote:
I ripped out the flushing part, keeping only the sorting. I refactored the
logic in BufferSync() a bit. There's now a separate function,
nextCheckpointBuffer(), that returns the next buffer ID from the sorted
list. The
On 10 August 2015 at 15:59, Syed, Rahila rahila.s...@nttdata.com wrote:
Hello,
When we're in Phase2 or 3, don't we need to report the number of total
page scanned or percentage of how many table pages scanned, as well?
The total heap pages scanned need to be reported with phase 2 or 3.
Petr Jelinek p...@2ndquadrant.com writes:
On 2015-08-10 16:58, Alexander Korotkov wrote:
That should work, thanks! Also we can have SQL-visible functions to get
amsupport and amstrategies and use them in the regression tests.
SQL-visible functions would be preferable to storing it in pg_am as
Petr Jelinek p...@2ndquadrant.com writes:
On 2015-08-10 17:47, Tom Lane wrote:
I don't see any particularly good reason to remove amsupport and
amstrategies from pg_am. Those are closely tied to the other catalog
infrastructure for indexes (pg_amproc, pg_amop) which I don't think are
Alexander Korotkov a.korot...@postgrespro.ru writes:
On Mon, Aug 10, 2015 at 6:47 PM, Tom Lane t...@sss.pgh.pa.us wrote:
There are a couple of other pg_am columns, such as amstorage and
amcanorderbyop, which similarly bear on what's legal to appear in
related catalogs such as pg_opclass. I'd
Tom Lane wrote:
Petr Jelinek p...@2ndquadrant.com writes:
On 2015-08-10 17:47, Tom Lane wrote:
I don't see any particularly good reason to remove amsupport and
amstrategies from pg_am. Those are closely tied to the other catalog
infrastructure for indexes (pg_amproc, pg_amop) which I
On 10 August 2015 at 16:31, Tom Lane t...@sss.pgh.pa.us wrote:
Pavel Stehule pavel.steh...@gmail.com writes:
On Sun, Aug 09, 2015 at 08:06:11PM -0400, Tom Lane wrote:
So yeah, I do think that getting a syntax error if you don't use
parentheses is the preferable behavior here.
If we
On August 10, 2015 8:24:21 PM GMT+02:00, Fabien COELHO coe...@cri.ensmp.fr
wrote:
Hello Andres,
You can't allocate 4GB with palloc(), it has a builtin limit against
allocating more than 1GB.
Argh, too bad, I assumed very naively that palloc was malloc in
disguise.
It is, but there's some
On 8/9/15 6:23 PM, Tom Lane wrote:
It looks to me like the reason for this is that pg_dump forces the
typacl of a type to be '{=U}' when reading the schema data for a
pre-9.2 type, rather than reading it as NULL (ie default permissions)
which would result in not printing any grant/revoke
Attached patch fixes oversights converting buf_id to Buffer in
PrintBufferDescs() and InvalidateBuffer(). Especially for the latter,
the reason we haven't seen any reports of the issue might be that it
needs certain concurrent conditions to be true.
Along the line, it also changes all direct
On 08/09/2015 07:19 PM, Michael Paquier wrote:
... during my exchange with Michael, I was thinking about the bug
potential of taking the password field and multiplexing it in some way,
which is significant. There is a definite risk of making this too
complicated and we'll need to contrast
* Robert Haas (robertmh...@gmail.com) wrote:
On Sat, Aug 8, 2015 at 1:23 PM, Heikki Linnakangas hlinn...@iki.fi wrote:
On 08/08/2015 04:27 PM, Robert Haas wrote:
I don't see that there's any good reason to allow the same password to
be stored in the catalog encrypted more than one way,
* Robert Haas (robertmh...@gmail.com) wrote:
On Mon, Aug 10, 2015 at 3:23 AM, Heikki Linnakangas hlinn...@iki.fi wrote:
I've marked this as rejected in the commitfest, because others are
working on a more general solution with parallel workers. That's still
work-in-progress, and it's not
On Tue, Aug 4, 2015 at 12:38 PM, Jeff Janes jeff.ja...@gmail.com wrote:
On Tue, Aug 4, 2015 at 1:39 AM, Simon Riggs si...@2ndquadrant.com wrote:
On 4 August 2015 at 06:03, Jeff Janes jeff.ja...@gmail.com wrote:
The attached proof of concept patch greatly improves the bloat for both
the
Having a freeze map would be wholly unnecessary if we don't ever need to
freeze whole tables again. Freezing would still be needed on individual
blocks where an old row has been updated or deleted; a freeze map would not
help there either.
So there is no conflict, but options 2) and 3) are
I wrote:
But now that you mention it, isn't that completely broken? What pg_dump
actually prints given this made-up data is
REVOKE ALL ON TYPE myshell FROM PUBLIC;
REVOKE ALL ON TYPE myshell FROM postgres;
GRANT ALL ON TYPE myshell TO PUBLIC;
which seems like a completely insane
On 2015-08-10 17:36:57 -0400, Tom Lane wrote:
Waldemar Brodkorb w...@openadk.org writes:
while doing regular builds via buildroot autobuilders
a compile problem for sparc 32bit v8 was found.
It seems the defines for Linux are other than for Solaris.
Following patch fixes it for
On 08/10/2015 10:32 AM, Andrew Dunstan wrote:
On 08/10/2015 09:55 AM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 08/09/2015 08:58 PM, Michael Paquier wrote:
Sure. Attached is what I have in mind. Contrary to your version we
keep around temp paths should a run succeed
Andreas Seltenreich seltenre...@gmx.de writes:
Tom Lane writes:
Andreas Seltenreich seltenre...@gmx.de writes:
Tom Lane writes:
Well, I certainly think all of these represent bugs:
3 | ERROR: plan should not reference subplan's variable
2 | ERROR: failed to assign all NestLoopParams to
Waldemar Brodkorb w...@openadk.org writes:
while doing regular builds via buildroot autobuilders
a compile problem for sparc 32bit v8 was found.
It seems the defines for Linux are other than for Solaris.
Following patch fixes it for buildroot:
The gcc predefines for Linux are
Hi,
That's a very nice catch! Did you trigger the error or just found it
when reading the code?
On 2015-08-10 12:12:01 -0700, Qingqing Zhou wrote:
Attached patch fixes oversights converting buf_id to Buffer in
PrintBufferDescs() and InvalidateBuffer(). Especially for the latter,
the reason we
I wrote:
Peter Eisentraut pete...@gmx.net writes:
This was probably just copied from how proacl and lanacl are handled,
which predate typacl by quite a bit. Maybe there was a reason in those
days.
Hm ... I wonder whether those are well-thought-out either.
They're not. Testing with ancient
On Mon, Aug 10, 2015 at 07:10:41PM +0200, Daniel Verite wrote:
David Fetter wrote:
I'm working up a proposal to add (UN)PIVOT support to the back-end.
I was under the impression that a server-side PIVOT *with dynamic
columns* was just unworkable as an SQL query, because it couldn't
On Wed, Aug 5, 2015 at 12:58 AM, Amit Langote
langote_amit...@lab.ntt.co.jp wrote:
I forgot mentioning one thing later yesterday. The way exclRelTlist is
initialized, all the way in the beginning (transformOnConflictClause), is
most probably to blame. It uses expandRelAttrs() for other valid
On 08/10/2015 07:29 PM, Tom Lane wrote:
I wrote:
Peter Eisentraut pete...@gmx.net writes:
This was probably just copied from how proacl and lanacl are handled,
which predate typacl by quite a bit. Maybe there was a reason in those
days.
Hm ... I wonder whether those are well-thought-out
Peter Eisentraut pete...@gmx.net writes:
On 8/9/15 6:23 PM, Tom Lane wrote:
It looks to me like the reason for this is that pg_dump forces the
typacl of a type to be '{=U}' when reading the schema data for a
pre-9.2 type, rather than reading it as NULL (ie default permissions)
which would
On Tue, Aug 11, 2015 at 4:28 AM, Andres Freund wrote:
On August 10, 2015 8:24:21 PM GMT+02:00, Fabien COELHO wrote:
You can't allocate 4GB with palloc(), it has a builtin limit against
allocating more than 1GB.
Argh, too bad, I assumed very naively that palloc was malloc in
disguise.
It is,
On Mon, Aug 10, 2015 at 4:15 PM, Andres Freund and...@anarazel.de wrote:
That's a very nice catch! Did you trigger the error or just found it
when reading the code?
My fellow colleagues hit the issue during some stress: I am not clear
the exact repro but from the failed assertion, the cause
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/10/2015 04:03 PM, David Fetter wrote:
I am wrong on that? I feel like you guys are all telling me that
\pivot should happen on the server, but the point that it would
not be realistic to begin with is not considered.
I think that starting
On Mon, Aug 10, 2015 at 2:02 AM, Simon Riggs si...@2ndquadrant.com wrote:
Almost every patch I review has either zero or insufficient tests.
If we care about robustness, then we must discuss tests. Here are my two
recent experiences:
I agree we could do with x10 as many tests, but that
On 08/10/2015 10:46 AM, Atri Sharma wrote:
* Unique Joins
Still needs to be reviewed. Any volunteers?
Can take this one up, if its within my limits.
Thanks! I've added you as reviewer to that.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
2015-08-10 6:04 GMT+02:00 David Fetter da...@fetter.org:
On Sun, Aug 09, 2015 at 07:29:40PM +0200, Daniel Verite wrote:
Hi,
I want to suggest a client-side \pivot command in psql, implemented
in the attached patch.
\pivot takes the current query in the buffer, execute it and
On Mon, Aug 10, 2015 at 1:04 PM, Heikki Linnakangas hlinn...@iki.fi wrote:
Hello Hackers,
There are a few Needs Review items remaining in the July commitfest.
Reviewers, please take action - you are holding up the commitfest.
In addition to these items, there are a bunch of items in Ready
On 2015-08-10 07:26:29 +0100, Simon Riggs wrote:
On 10 August 2015 at 07:14, Peter Geoghegan p...@heroku.com wrote:
On Sun, Aug 9, 2015 at 11:03 PM, Simon Riggs si...@2ndquadrant.com
wrote:
If 5) fails to bring a workable solution by the Jan 2016 CF then we
commit
2) instead.
Is
2015-08-10 5:37 GMT+02:00 Noah Misch n...@leadboat.com:
On Sun, Aug 09, 2015 at 08:06:11PM -0400, Tom Lane wrote:
Noah Misch n...@leadboat.com writes:
In SQL:2008 and SQL:2011 at least, =, and BETWEEN are all in
the same
boat. They have no precedence relationships to each other; SQL
On 2015-08-08 20:49:03 +0300, Heikki Linnakangas wrote:
* I think we should drop the flush part of this for now. It's not as
clearly beneficial as the sorting part, and adds a great deal more code
complexity. And it's orthogonal to the sorting patch, so we can deal with it
separately.
I don't
On 08/10/2015 11:17 AM, Andres Freund wrote:
On 2015-08-10 07:26:29 +0100, Simon Riggs wrote:
On 10 August 2015 at 07:14, Peter Geoghegan p...@heroku.com wrote:
On Sun, Aug 9, 2015 at 11:03 PM, Simon Riggs si...@2ndquadrant.com
wrote:
If 5) fails to bring a workable solution by the Jan 2016
Hi,
This thread has a pretty thorough discussion of pros and cons of applying
SELECT policy to other commands. Besides what have been mentioned, I think
there is another potential pro: we can enable references to pseudorelations
OLD and NEW in predicates. Now, for UPDATE, the references to the
In case you missed the link to the previous discussion at the bottom,
http://www.postgresql.org/message-id/CAHGQGwEqWD=ynqe+zojbpoxywt3xlk52-v_q9s+xofckjd5...@mail.gmail.com
Thanks for the explanation Robert, that makes total sense. However, it
seems like the utility of PG's statement_timeout is much more limited than
I thought.
In case you're interested, I dug a little further and it seems that
Microsoft's client for SQL Server implements the following timeout
On 10 August 2015 at 07:50, Tom Lane t...@sss.pgh.pa.us wrote:
I've started to work on path-ification of the upper planner (finally),
and since that's going to be a large patch in any case, I've been looking
for pieces that could be bitten off and done separately. One such piece
is the fact
On 8 August 2015 at 17:47, Noah Misch n...@leadboat.com wrote:
We've too often criticized patches for carrying many lines/bytes of test
case
additions. Let's continue to demand debuggable, secure tests that fail
only
when something is wrong, but let's stop pushing for test minimalism. Such
On Sun, Aug 9, 2015 at 11:03 PM, Simon Riggs si...@2ndquadrant.com wrote:
If 5) fails to bring a workable solution by the Jan 2016 CF then we commit
2) instead.
Is there actually a conflict there? I didn't think so.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list
On 10 August 2015 at 07:14, Peter Geoghegan p...@heroku.com wrote:
On Sun, Aug 9, 2015 at 11:03 PM, Simon Riggs si...@2ndquadrant.com
wrote:
If 5) fails to bring a workable solution by the Jan 2016 CF then we
commit
2) instead.
Is there actually a conflict there? I didn't think so.
I
Hello Hackers,
There are a few Needs Review items remaining in the July commitfest.
Reviewers, please take action - you are holding up the commitfest.
In addition to these items, there are a bunch of items in Ready for
Committer state. Committers: please help with those.
* extends pgbench
* Unique Joins
Still needs to be reviewed. Any volunteers?
Can take this one up, if its within my limits.
Freezing is painful for VLDBs and high transaction rate systems. We have a
number of proposals to improve things...
1. Allow parallel cores to be used with vacuumdb (Dilip)
Idea is if we have to get the job done, lets do it as fast as we can using
brute force. Reasonable thinking, but there are
I've marked this as rejected in the commitfest, because others are
working on a more general solution with parallel workers. That's still
work-in-progress, and it's not certain if it's going to make it into
9.6, but if it does it will largely render this obsolete. We can revisit
this patch later
On 07/26/2015 08:34 AM, Pavel Stehule wrote:
Hi
here is complete patch, that introduce context filtering on client side.
The core of this patch is trivial and small - almost all of size are
trivial changes in regress tests - removing useless context.
Documentation, check-world
Looks good to
On Mon, Aug 10, 2015 at 1:04 PM, Heikki Linnakangas hlinn...@iki.fi wrote:
* Parallel Seq scan
Jeff, Haribabu, you're signed up as reviewers. How's it going?
The current state of the patch is that there are few comments by
Jeff and others which I need to take care, however it would have
On 2015/08/10 17:10, Ashutosh Bapat wrote:
On Mon, Aug 10, 2015 at 1:04 PM, Heikki Linnakangas hlinn...@iki.fi
mailto:hlinn...@iki.fi wrote:
* Join pushdown support for foreign tables
Ashutosh, KaiGai, Etsuro: You signed up as reviewers in spring, but
there hasn't been any
On 2015-08-09 23:56, Alexander Korotkov wrote:
Hacker,
some time before I proposed patches implementing CREATE ACCESS METHOD.
http://www.postgresql.org/message-id/capphfdsxwzmojm6dx+tjnpyk27kt4o7ri6x_4oswcbyu1rm...@mail.gmail.com
As I get from comments to my patches and also from Tom's comment
Re: Tom Lane 2015-08-07 928.1438900...@sss.pgh.pa.us
Alvaro Herrera alvhe...@alvh.no-ip.org writes:
Fix BRIN to use SnapshotAny during summarization
This patch added an isolation test that fails unless contrib/pageinspect
has been built and installed. I do not find that acceptable. It
On 08/09/2015 08:58 PM, Michael Paquier wrote:
On Sun, Aug 9, 2015 at 11:19 PM, Andrew Dunstan and...@dunslane.net wrote:
On 08/09/2015 08:41 AM, Michael Paquier wrote:
On Sun, Aug 9, 2015 at 1:40 AM, Andrew Dunstan and...@dunslane.net
wrote:
On 08/08/2015 09:31 AM, Robert Haas wrote:
On
On Mon, Aug 10, 2015 at 1:36 PM, Rahila Syed rahilasye...@gmail.com wrote:
Hello,
Say, 6 bigint counters, 6 float8
counters, and 3 strings up to 80 characters each. So we have a
fixed-size chunk of shared memory per backend, and each backend that
wants to expose progress information can fill in
On 10 August 2015 at 13:55, Robert Haas robertmh...@gmail.com wrote:
On Mon, Aug 10, 2015 at 2:02 AM, Simon Riggs si...@2ndquadrant.com
wrote:
On another review I suggested we add a function to core to allow it to be
used in regression tests. A long debate ensued, deciding that we must be
Andrew Dunstan and...@dunslane.net writes:
On 08/09/2015 08:58 PM, Michael Paquier wrote:
Sure. Attached is what I have in mind. Contrary to your version we
keep around temp paths should a run succeed after one that has failed
when running make check multiple times in a row. Perhaps it does
On 2015-07-30 17:14:16 +0900, Michael Paquier wrote:
So, perhaps the attached is more convincing then? It just changes
--create-slot to leave immediately after creation to address the
complain of this thread. -- Michael
Pushed that. Thanks!
Andres
--
Sent via pgsql-hackers mailing list
On 2015-07-08 15:01:15 +0300, Marko Tiikkaja wrote:
+ if (confirmed_flush_lsn != InvalidTransactionId)
+ values[i++] = LSNGetDatum(confirmed_flush_lsn);
+ else
+ nulls[i++] = true;
+
Hm. That comparison is using the wrong
1 - 100 of 105 matches
Mail list logo
