On Wed, 2015-04-22 at 20:35 -0700, David G. Johnston wrote:
> But the fact that column "b" has the data type "unknown" is only a
> warning - not an error.
>
I get an error:
postgres=# SELECT ' '::text = 'a';
?column?
--
f
(1 row)
postgres=# SELECT a=b FROM (SELECT ''::text, ' ') x(
On Thu, Apr 23, 2015 at 2:46 PM, Tom Lane wrote:
> Michael Paquier writes:
>> After looking at bug #13128, I have been looking at the code around
>> LWLockAcquire/Release to see if there are similar issues elsewhere.
>> Here are my findings:
>
> IIRC, we automatically release all LWLocks at the s
On Mon, Apr 13, 2015 at 11:57 PM, Heikki Linnakangas wrote:
> On 04/01/2015 07:12 PM, Bruce Momjian wrote:
>>
>> On Fri, Dec 19, 2014 at 10:26:34PM +0200, Heikki Linnakangas wrote:
>>>
>>> On 12/19/2014 02:55 PM, Heikki Linnakangas wrote:
I'm thinking that we should add a step to promoti
Michael Paquier writes:
> After looking at bug #13128, I have been looking at the code around
> LWLockAcquire/Release to see if there are similar issues elsewhere.
> Here are my findings:
IIRC, we automatically release all LWLocks at the start of error recovery,
so I rather doubt that any of this
Hi all,
After looking at bug #13128, I have been looking at the code around
LWLockAcquire/Release to see if there are similar issues elsewhere.
Here are my findings:
1) SimpleLruReadPage() holds a control lock at entry that will be held
at exit as well. However SlruReportIOError() can report an
My apologies if much of this is already assumed knowledge by most
-hackers...I'm trying to learn from observation instead of, largely,
reading code in a foreign language.
On Wed, Apr 22, 2015 at 6:40 PM, Jeff Davis wrote:
> Moving thread to -hackers.
>
> On Wed, Apr 8, 2015 at 11:18 PM, Jeff Dav
Hi Robert,
Thanks for your comments.
> A few random cosmetic problems:
>
> - The hunk in allpaths.c is useless.
> - The first hunk in fdwapi.h contains an extra space before the
> closing parenthesis.
>
OK, it's my oversight.
> And then:
>
> + else if (scan->scanrelid == 0 &&
> +
On 2015/04/23 0:34, Stephen Frost wrote:
* Etsuro Fujita (fujita.ets...@lab.ntt.co.jp) wrote:
postgres=# select * from ft1 for update;
ERROR: could not find junk tableoid1 column
I think this is a bug. Attached is a patch fixing this issue.
Pushed, thanks!
Thank you.
Best regards,
Etsuro
On Fri, Jan 30, 2015 at 01:26:22PM -0800, Josh Berkus wrote:
> Robert, Stephen, etc.:
>
> Apparently you can create a tablespace in the tablespace directory:
>
> josh=# create tablespace tbl location '/home/josh/pg94/data/pg_tblspc/';
> CREATE TABLESPACE
> josh=# create table test_tbl ( test text
Moving thread to -hackers.
On Wed, Apr 8, 2015 at 11:18 PM, Jeff Davis wrote:
> That example was just for illustration. My other example didn't require
> creating a table at all:
>
> SELECT a=b FROM (SELECT ''::text, ' ') x(a,b);
>
> it's fine with me if we want that to fail, but I don't think
On Tue, Apr 21, 2015 at 05:36:41PM -0400, Robert Haas wrote:
> On Mon, Apr 20, 2015 at 5:41 PM, Bruce Momjian wrote:
> > On Mon, Apr 20, 2015 at 05:04:14PM -0400, Robert Haas wrote:
> >> On Mon, Apr 20, 2015 at 4:11 PM, Bruce Momjian wrote:
> >> > Slightly improved patch applied.
> >>
> >> Is it?
On Wed, Apr 22, 2015 at 06:36:23PM -0500, Jim Nasby wrote:
> On 4/22/15 6:12 PM, Bruce Momjian wrote:
> >My point is that for the life of 200M transactions, you would have the
> >overhead of an additional file per table in the file system, and updates
> >of that. I just don't know if the overhead
On Thu, Apr 23, 2015 at 4:31 AM, Petr Jelinek wrote:
> On 19/04/15 01:24, Michael Paquier wrote:
>>
>> On Sat, Apr 18, 2015 at 8:38 PM, Michael Paquier
>> wrote:
>>>
>>> On Fri, Apr 17, 2015 at 10:54 PM, Petr Jelinek wrote:
On 10/04/15 06:46, Michael Paquier wrote:
>
> 13) Some
Hello,
At Thu, 16 Apr 2015 14:43:33 -0700, David Fetter wrote in
<20150416214333.ga...@fetter.org>
> On Wed, Apr 15, 2015 at 09:35:05AM +0900, Kyotaro HORIGUCHI wrote:
> > Hi,
> >
> > Before suppressing the symptom, I doubt the necessity and/or
> > validity of giving foreign tables an ability t
On Wed, Apr 22, 2015 at 3:23 PM, Peter Geoghegan wrote:
> * We need to sort out those issues with the grammar, since that only
> really applies to the inference specification. Maybe the WHERE clause
> that the inference specification accepts can be broken out. No ON
> CONFLICT UPDATE specific issu
On 4/22/15 6:12 PM, Bruce Momjian wrote:
My point is that for the life of 200M transactions, you would have the
overhead of an additional file per table in the file system, and updates
of that. I just don't know if the overhead over the long time period
would be smaller than the VACUUM FREEZE.
On Tue, Apr 21, 2015 at 08:39:37AM +0200, Andres Freund wrote:
> On 2015-04-20 17:13:29 -0400, Bruce Momjian wrote:
> > Didn't you think any of the TODO threads had workable solutions? And
> > don't expect adding an additional file per relation will be zero cost
> > --- added over the lifetime of
On 4/22/15 1:51 PM, Kevin Grittner wrote:
(1) WAL log the insert.
(2) Write the tuple.
(3) Hint and rewrite the tuple.
(4) WAL log the freeze of the tuple.
(5) Rewrite the frozen tuple.
(6) WAL-log the delete.
(7) Rewrite the deleted tuple.
(8) Prune and rewrite the page.
(9) Free line pointers a
On Tue, Apr 21, 2015 at 7:57 AM, Andres Freund wrote:
> I'm not 100% sure Heikki and I am on exactly the same page here :P
>
> I'm looking at git diff $(git merge-base upstream/master HEAD).. where
> HEAD is e1a5822d164db0.
Merged your stuff into my Github branch. Heikki is pushing changes
there
On 4/22/15 2:12 PM, Merlin Moncure wrote:
That being said, I think json types with their associated API, given
that they are core types, will ultimately handle these types of
problems. That way, at least, we can avoid adding syntax and
functionality that will basically do the same thing. This r
On 4/22/15 1:24 PM, Robert Haas wrote:
I keep coming back to the idea of treating any page that is marked as
all-visible as frozen, and deferring freezing until the page is again
modified. The big downside of this is that if the page is set as
all-visible and then immediately thereafter modified
On Wed, Apr 22, 2015 at 06:07:00PM -0300, Alvaro Herrera wrote:
> > Good point, but doesn't vacuum remove the need for pruning as it removes
> > all the old rows?
>
> Sure. The point, I think, is to make autovacuum runs of some sort that
> don't actually vacuum but only do HOT-pruning. Maybe thi
Dean Rasheed wrote, On 2015-03-28 10:01:
> On 28 March 2015 at 05:16, Andrew Gierth wrote:
>>> "Tom" == Tom Lane writes:
>>
>> Tom> I think the concern over backwards compatibility here is probably
>> Tom> overblown; but if we're sufficiently worried about it, a possible
>> Tom> compromise
Bruce Momjian wrote:
> On Wed, Apr 22, 2015 at 04:36:17PM +0100, Greg Stark wrote:
> > On Mon, Apr 20, 2015 at 8:48 PM, Bruce Momjian wrote:
> > > Well, we have to assume there are many misconfigured configurations ---
> > > autovacuum isn't super-easy to configure, so we can't just blame the
> >
On Tue, Apr 14, 2015 at 8:35 PM, Kyotaro HORIGUCHI
wrote:
> Before suppressing the symptom, I doubt the necessity and/or
> validity of giving foreign tables an ability to be a parent. Is
> there any reasonable usage for the ability?
Gee, I don't see why that would be unreasonable or invalid
--
On Wed, Apr 22, 2015 at 3:34 PM, Heikki Linnakangas wrote:
> On 04/22/2015 10:21 PM, Robert Haas wrote:
>> On Wed, Apr 22, 2015 at 3:01 PM, Heikki Linnakangas
>> wrote:
>>> For example, imagine that perform point-in-time recovery to WAL position
>>> 0/1237E568, on timeline 1. That falls within se
On Wed, Apr 22, 2015 at 8:48 AM, Amit Kapila wrote:
> I have implemented this idea (note that I have to expose a new API
> shm_mq_from_handle as TupleQueueFunnel stores shm_mq_handle* and
> we sum_mq* to call shm_mq_detach) and apart this I have fixed other
> problems reported on this thread:
>
>
On Wed, Apr 22, 2015 at 04:36:17PM +0100, Greg Stark wrote:
> On Mon, Apr 20, 2015 at 8:48 PM, Bruce Momjian wrote:
> > Well, we have to assume there are many misconfigured configurations ---
> > autovacuum isn't super-easy to configure, so we can't just blame the
> > user if this makes things wor
On 20/04/15 17:50, Heikki Linnakangas wrote:
On 03/15/2015 09:07 PM, Petr Jelinek wrote:
Slightly updated version of the patch.
Mainly rebased against current master (there were several conflicts) and
fixed some typos, no real functional change.
I also attached initial version of the API sgml
Alvaro Herrera wrote:
> Michael Paquier wrote:
> > Hi all,
> >
> > I just bumped into the following problem in HEAD (1c41e2a):
> > =# create type my_array_float (INPUT = array_in, OUTPUT = array_out,
> > ELEMENT = float4, INTERNALLENGTH = 32);
> > ERROR: XX000: cache lookup failed for type 0
> >
On 04/22/2015 10:21 PM, Robert Haas wrote:
On Wed, Apr 22, 2015 at 3:01 PM, Heikki Linnakangas wrote:
For example, imagine that perform point-in-time recovery to WAL position
0/1237E568, on timeline 1. That falls within segment
00010012. Then we end recovery, and switch to timel
On 19/04/15 01:24, Michael Paquier wrote:
On Sat, Apr 18, 2015 at 8:38 PM, Michael Paquier
wrote:
On Fri, Apr 17, 2015 at 10:54 PM, Petr Jelinek wrote:
On 10/04/15 06:46, Michael Paquier wrote:
13) Some regression tests with pg_tablesample_method would be welcome.
Not sure what you mean by
Michael Paquier wrote:
> Hi all,
>
> I just bumped into the following problem in HEAD (1c41e2a):
> =# create type my_array_float (INPUT = array_in, OUTPUT = array_out,
> ELEMENT = float4, INTERNALLENGTH = 32);
> ERROR: XX000: cache lookup failed for type 0
> LOCATION: format_type_internal, forma
On Wed, Apr 22, 2015 at 3:01 PM, Heikki Linnakangas wrote:
> On 04/22/2015 09:30 PM, Robert Haas wrote:
>> On Wed, Apr 22, 2015 at 2:17 AM, Heikki Linnakangas
>> wrote:
>>>
>>> Note that it's a bit complicated to set up that scenario today. Archiving
>>> is
>>> never enabled in recovery mode, so
On Wed, Apr 22, 2015 at 11:20 AM, Andrew Dunstan wrote:
>
> On 04/22/2015 11:29 AM, Jim Nasby wrote:
>>
>> On 4/20/15 2:04 PM, David G. Johnston wrote:
>>>
>>>
>>> SELECT (src.v).* FROM ( VALUES (ROW(1,2,3)) ) src (v);
>>> ERROR: record type has not been registered
>>>
>>> While it may not be nece
On 04/22/2015 09:30 PM, Robert Haas wrote:
On Wed, Apr 22, 2015 at 2:17 AM, Heikki Linnakangas wrote:
Note that it's a bit complicated to set up that scenario today. Archiving is
never enabled in recovery mode, so you'll need to use a custom cron job or
something to maintain the archive that C
On Tue, Apr 21, 2015 at 8:30 PM, Michael Paquier
wrote:
> This .partial segment renaming is something that we
> should let the archive_command manage with its internal logic.
This strikes me as equivalent to saying "we don't know how to make
this work right, but maybe our users will know". That
Greg Stark wrote:
> And it's a major headache, people are always being surprised that
> their selects cause lots of I/O and slow down dramatically after
> a big update or data load has finished. It's characterized as
> "why is the database writing everything twice" (and saying it's
> actually wri
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
Seeing this when trying to apply the patch:
Patching file src/backend/co
On Wed, Apr 22, 2015 at 2:17 AM, Heikki Linnakangas wrote:
> Note that it's a bit complicated to set up that scenario today. Archiving is
> never enabled in recovery mode, so you'll need to use a custom cron job or
> something to maintain the archive that C uses. The files will not
> automatically
On Wed, Apr 22, 2015 at 2:23 PM, Kevin Grittner wrote:
> Robert Haas wrote:
>> I just tested "pgbench -i -s 40 -n" followed by "VACUUM" or
>> alternatively followed by "VACUUM FREEZE". The VACUUM generated
>> 4641kB of WAL. The VACUUM FREEZE generated 515MB of WAL - that
>> is, 113 times more.
On Wed, Apr 22, 2015 at 12:39 PM, Heikki Linnakangas wrote:
> The thing that made me nervous about that approach is that it made the LSN
> of each page critical information. If you somehow zeroed out the LSN, you
> could no longer tell which pages are frozen and which are not. I'm sure it
> could
Robert Haas wrote:
> I just tested "pgbench -i -s 40 -n" followed by "VACUUM" or
> alternatively followed by "VACUUM FREEZE". The VACUUM generated
> 4641kB of WAL. The VACUUM FREEZE generated 515MB of WAL - that
> is, 113 times more.
Essentially a bulk load. OK, so if you bulk load data and t
On Fri, Mar 13, 2015 at 8:02 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Mar 13, 2015 at 2:31 PM, Tom Lane wrote:
>>> I don't object to the concept, but I think that is a pretty bad place
>>> to put the hook call: add_paths_to_joinrel is typically called multiple
>>> (perhaps *many*) ti
On Tue, Apr 21, 2015 at 05:07:52PM -0400, Peter Eisentraut wrote:
> On 4/21/15 4:45 PM, Jim Nasby wrote:
> > This comment made me wonder... has anyone considered handing the pruning
> > work off to a bgworker, at least for SELECTs? That means the selects
> > themselves wouldn't be burdened by the a
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: tested, failed
Spec compliant: not tested
Documentation:tested, failed
Error in postgresql.conf gives the expected result on pg_ctl reload,
On 4/22/15 11:37 AM, Jim Nasby wrote:
> On 4/21/15 4:07 PM, Peter Eisentraut wrote:
>> On 4/21/15 4:45 PM, Jim Nasby wrote:
>> In order for a background worker to keep up with some of the workloads
>> that have been presented as counterexamples, you'd need multiple
>> background workers operating i
On April 22, 2015 11:14:08 AM Heikki Linnakangas wrote:
> On 04/16/2015 06:51 AM, Alvaro Herrera wrote:
> > Seems reasonable, but why are you sleeping 1s if pg_ctl -w is in use? I
> > thought the -w would wait until promotion has taken effect, so there's
> > no need to sleep additional time.
>
>
On 22 April 2015 at 17:02, Stephen Frost wrote:
> Pushed with those changes, please take a look and test!
>
Excellent, thanks! Will test.
Regards,
Dean
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpre
On 04/22/2015 05:33 PM, Robert Haas wrote:
On Tue, Apr 21, 2015 at 7:24 PM, Jim Nasby wrote:
On 4/21/15 3:21 PM, Robert Haas wrote:
I'm not saying those ideas don't have problems, because they do. But
I think they are worth further exploring. The main reason I gave up
on that is because Heik
On Tue, Apr 21, 2015 at 10:33 PM, Kouhei Kaigai wrote:
> [ new patch ]
A little more nitpicking:
ExecInitForeignScan() and ExecInitCustomScan() could declare
currentRelation inside the if (scanrelid > 0) block instead of in the
outer scope.
I'm not too excited about the addition of GetFdwHandle
On 04/22/2015 11:29 AM, Jim Nasby wrote:
On 4/20/15 2:04 PM, David G. Johnston wrote:
SELECT (src.v).* FROM ( VALUES (ROW(1,2,3)) ) src (v);
ERROR: record type has not been registered
While it may not be necessary to solve both problems I suspect they have
the same underlying root cause - s
On Tue, Apr 21, 2015 at 04:36:53PM -0400, Robert Haas wrote:
> > Keep in mind there's a disconnect between dirtying a page and writing it
> > to storage. A page could remain dirty for a long time in the buffer
> > cache. This writing of sequential pages would occur at checkpoint time
> > only, wh
On Wed, Apr 22, 2015 at 11:09 AM, Kevin Grittner wrote:
> Robert Haas wrote:
>> It's possible that we could use this infrastructure to freeze
>> more aggressively in other circumstances. For example, perhaps
>> VACUUM should freeze any page it intends to mark all-visible.
>> That's not a guarant
Dean,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> On 21 April 2015 at 22:21, Dean Rasheed wrote:
> > On 21 April 2015 at 20:50, Stephen Frost wrote:
> >> Thanks a lot for this. Please take a look at the attached.
> >
> > I've given this a quick read-through, and it looks good to me. The
On Wed, Apr 22, 2015 at 09:18:40AM +0200, Andres Freund wrote:
> Peter, Michael,
>
> On 2015-04-22 16:13:15 +0900, Michael Paquier wrote:
> > All the patches have been committed, finishing the work on this thread.
>
> Many thanks for that effort!
And pg_upgrade thanks you. ;-)
--
Bruce Momj
Keenan,
* kee...@thebrocks.net (kee...@thebrocks.net) wrote:
> I'm looking into connection to postgres using authentication from client
> certificates. [1]
Nice! Glad to hear of more users of that capability. :)
> The documentation states that the common name (aka CN) is read from the
> certifi
On 4/21/15 4:07 PM, Peter Eisentraut wrote:
On 4/21/15 4:45 PM, Jim Nasby wrote:
In order for a background worker to keep up with some of the workloads
that have been presented as counterexamples, you'd need multiple
background workers operating in parallel and preferring to work on
certain parts
On Mon, Apr 20, 2015 at 8:48 PM, Bruce Momjian wrote:
>
>> But if the entire table is very hot, I think that that is just another of way
>> of saying that autovacuum is horribly misconfigured. I think the purpose of
>
> Well, we have to assume there are many misconfigured configurations ---
> aut
Etsuro,
* Etsuro Fujita (fujita.ets...@lab.ntt.co.jp) wrote:
> postgres=# select * from ft1 for update;
> ERROR: could not find junk tableoid1 column
>
> I think this is a bug. Attached is a patch fixing this issue.
Pushed, thanks!
Stephen
signature.asc
Description: Digital signatur
On 4/20/15 2:04 PM, David G. Johnston wrote:
SELECT (src.v).* FROM ( VALUES (ROW(1,2,3)) ) src (v);
ERROR: record type has not been registered
While it may not be necessary to solve both problems I suspect they have
the same underlying root cause - specifically the separation of concerns
betw
Robert Haas wrote:
> It's possible that we could use this infrastructure to freeze
> more aggressively in other circumstances. For example, perhaps
> VACUUM should freeze any page it intends to mark all-visible.
> That's not a guaranteed win, because it might increase WAL
> volume: setting a pag
On Wed, Mar 25, 2015 at 9:51 PM, Kouhei Kaigai wrote:
> The attached patch adds GetForeignJoinPaths call on make_join_rel() only when
> 'joinrel' is actually built and both of child relations are managed by same
> FDW driver, prior to any other built-in join paths.
> I adjusted the hook definition
On Tue, Apr 21, 2015 at 7:24 PM, Jim Nasby wrote:
> On 4/21/15 3:21 PM, Robert Haas wrote:
>> It's possible that we could use this infrastructure to freeze more
>> aggressively in other circumstances. For example, perhaps VACUUM
>> should freeze any page it intends to mark all-visible. That's no
Dean,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> On 21 April 2015 at 22:21, Dean Rasheed wrote:
> > On 21 April 2015 at 20:50, Stephen Frost wrote:
> >> Thanks a lot for this. Please take a look at the attached.
> >
> > I've given this a quick read-through, and it looks good to me. The
On 21 April 2015 at 22:21, Dean Rasheed wrote:
> On 21 April 2015 at 20:50, Stephen Frost wrote:
>> Thanks a lot for this. Please take a look at the attached.
>
> I've given this a quick read-through, and it looks good to me. The
> interaction of permissive and restrictive policies from hooks ma
Ah sorry, didn't realize I top posted. I'll test this new one.
Payal.
On Apr 21, 2015 10:23 PM, "Jan de Visser" wrote:
> On April 21, 2015 09:34:51 PM Jan de Visser wrote:
> > On April 21, 2015 09:01:14 PM Jan de Visser wrote:
> > > On April 21, 2015 07:32:05 PM Payal Singh wrote:
> ... snip ...
At 2015-04-18 12:28:36 +0530, amit.kapil...@gmail.com wrote:
>
> I think you have missed to address the below point:
>
> >> 4) prefetch
Updated patch attached, as well as the diff against the earlier version
just to make it easier to see the exact change I made (which is to copy
the skip logic fr
On Wed, Apr 22, 2015 at 9:30 PM, Pedro Gimeno
wrote:
> Dean Rasheed wrote, On 2015-03-28 10:01:
>> On 28 March 2015 at 05:16, Andrew Gierth wrote:
"Tom" == Tom Lane writes:
>>>
>>> Tom> I think the concern over backwards compatibility here is probably
>>> Tom> overblown; but if we're
On Wed, Apr 22, 2015 at 8:40 PM, Heikki Linnakangas wrote:
> On 04/20/2015 05:21 AM, Michael Paquier wrote:
>>
>> I have just made a run of the TAP tests of pg_rewind on my raspberry
>> PI 1 (hamster), where the tests are very slow, and I noticed that it
>> takes up to 10s to get confirmation from
On 04/20/2015 05:21 AM, Michael Paquier wrote:
I have just made a run of the TAP tests of pg_rewind on my raspberry
PI 1 (hamster), where the tests are very slow, and I noticed that it
takes up to 10s to get confirmation from standby that it has caught up
with the changes from master, and 5s to g
On 21/04/15 22:36, Andres Freund wrote:
On 2015-04-21 16:26:08 -0400, Robert Haas wrote:
On Tue, Apr 21, 2015 at 8:08 AM, Andres Freund wrote:
I've now named the functions:
* pg_replication_origin_create
* pg_replication_origin_drop
* pg_replication_origin_get (map from name to id)
* pg_repli
On 04/16/2015 06:51 AM, Alvaro Herrera wrote:
Seems reasonable, but why are you sleeping 1s if pg_ctl -w is in use? I
thought the -w would wait until promotion has taken effect, so there's
no need to sleep additional time.
-w is not supported with pg_ctl promote. Only start, stop and restart.
Peter, Michael,
On 2015-04-22 16:13:15 +0900, Michael Paquier wrote:
> All the patches have been committed, finishing the work on this thread.
Many thanks for that effort!
Andres
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http:/
On Sun, Apr 12, 2015 at 12:36 PM, Peter Eisentraut wrote:
> On 3/11/15 8:21 PM, Michael Paquier wrote:
>> Attached is a series of patch rebased on current HEAD, there were some
>> conflicts after perl-tidying the refactoring patch for MSVC. Note that
>> this series still uses PGXS in the Makefiles
On 2015/04/22 6:50, Robert Haas wrote:
On Tue, Apr 21, 2015 at 5:45 AM, Etsuro Fujita
wrote:
Since we now allow CHECK constraints to be placed on foreign tables, not
only NOT NULL, I think it'd be better to update docs on considerations
about constraints on foreign tables in fdwhandler.sgml, so
On Wed, Apr 22, 2015 at 3:38 PM, Heikki Linnakangas wrote:
> On 04/22/2015 03:30 AM, Michael Paquier wrote:
>>
>> This is going to change a behavior that people are used to for a
>> couple of releases. I would not mind having this patch do
>> "archive_mode = on during recovery" => archive only seg
On 2015/04/22 0:43, Stephen Frost wrote:
On Tuesday, April 21, 2015, Alvaro Herrera mailto:alvhe...@2ndquadrant.com>> wrote:
Stephen Frost wrote:
> Tom, all,
>
> Looks like preprocess_targetlist() should have been adjusted
with the
> changes to ExecBuildAuxRowMa
78 matches
Mail list logo
