On Fri, Dec 19, 2014 at 3:53 PM, Noah Misch wrote:
> localhost template1=# select clock_timestamp(), pg_sleep(.1 * (n % 2)) from
> generate_series(0,7) t(n);
> clock_timestamp| pg_sleep
> ---+--
> 2014-12-18 08:34:34.522126+00 |
> 2014-12-18 0
On Tue, Dec 23, 2014 at 5:21 AM, Petr Jelinek wrote:
> Attached is v3 which besides the fixes mentioned above also includes changes
> discussed with Tomas (except the CREATE/DROP TABLESAMPLE METHOD), fixes for
> crash with FETCH FIRST and is rebased against current master.
This patch needs a rebas
On 06/01/15 18:57, Josh Berkus wrote:
On 01/05/2015 05:43 PM, Peter Eisentraut wrote:
I have previously argued for a different approach: Ready recovery.conf
as a configuration file after postgresql.conf, but keep it as a file to
start recovery. That doesn't break any old workflows, it gets yo
Even checking whether the output of the function is in the right order or
not, has its cost. I am suggesting that we can eliminate this cost as well.
For example, PostgreSQL does not check whether a function is really
immutable or not.
>
> Best Wishes,
> Ashutosh Bapat
>
>
I imagine if it could b
On Tue, Jan 6, 2015 at 12:43 PM, Amit Langote wrote:
> On 06-01-2015 PM 04:08, Atri Sharma wrote:
> > On Tue, Jan 6, 2015 at 12:29 PM, Amit Langote <
> langote_amit...@lab.ntt.co.jp
>
>
> I read what Ashutosh says as that a clause like IMMUTABLE does not
> entail a node execution. Reading manual
On Tue, Jan 6, 2015 at 12:47 PM, Pavan Deolasee
wrote:
>
>
> On Tue, Jan 6, 2015 at 12:38 PM, Atri Sharma wrote:
>
>>
>>
> May be what Amit has in mind is that the planner can choose the most
> optimal sorting algorithm using the hint that the dataset is probably
> already sorted. Actually why n
On 06-01-2015 PM 04:08, Atri Sharma wrote:
> On Tue, Jan 6, 2015 at 12:29 PM, Amit Langote > wrote:
>>> Even checking whether the output of the function is in the right order or
>>> not, has its cost. I am suggesting that we can eliminate this cost as
>> well.
>>> For example, PostgreSQL does not c
On Tue, Jan 6, 2015 at 12:38 PM, Atri Sharma wrote:
>
>
> On Tue, Jan 6, 2015 at 12:29 PM, Amit Langote <
> langote_amit...@lab.ntt.co.jp> wrote:
>
>>
>> >
>>
>> Sounds something like ORDERED BY x implying output is "known" ordered by
>> x perhaps enough hint for the planner to make necessary pla
On Tue, Jan 6, 2015 at 2:38 AM, Heikki Linnakangas
wrote:
> Here's an updated version of pg_rewind. The code itself is the same as
> before, and corresponds to the sources in the current pg_rewind github
> repository, as of commit a65e3754faf9ca9718e6b350abc736de586433b7. Based
> mostly on Michael
On Mon, Jan 5, 2015 at 5:53 PM, Peter Geoghegan wrote:
> It's not all that easy to recreate, even with my custom
> instrumentation. With fsync=off, it occurs somewhat infrequently with
> a custom instrumentation Postgres build:
>
> pg@hamster:~/jjanes_upsert$ perl count_upsert.pl 8 10
> [Mon J
On Tue, Jan 6, 2015 at 12:30 PM, Ashutosh Bapat <
ashutosh.ba...@enterprisedb.com> wrote:
>
>
> On Tue, Jan 6, 2015 at 12:23 PM, Atri Sharma wrote:
>
>>
Even checking whether the output of the function is in the right order
> or not, has its cost. I am suggesting that we can elimin
On Tue, Jan 6, 2015 at 12:29 PM, Amit Langote wrote:
> On 06-01-2015 PM 04:00, Ashutosh Bapat wrote:
> > On Tue, Jan 6, 2015 at 12:23 PM, Atri Sharma
> wrote:
> >>> We can eliminate the new node and put onus or having the right order on
> >>> the user like we do with volatile setting of the func
On 06-01-2015 PM 04:00, Ashutosh Bapat wrote:
> On Tue, Jan 6, 2015 at 12:23 PM, Atri Sharma wrote:
>>> We can eliminate the new node and put onus or having the right order on
>>> the user like we do with volatile setting of the function.
>>>
>>>
>>
>> That is exactly what the new node does, since
On Tue, Jan 6, 2015 at 12:23 PM, Atri Sharma wrote:
>
>>>
>>> The overhead of this patch is small. A new path is added for the
>>> preorder keys, and OrderCheck node's additional cost is pretty low, given
>>> that it only compares two rows and stores only a single row (previous row
>>> seen), hen
>
>
>>
>> The overhead of this patch is small. A new path is added for the preorder
>> keys, and OrderCheck node's additional cost is pretty low, given that it
>> only compares two rows and stores only a single row (previous row seen),
>> hence the memory footprint is minuscule.
>>
>>
> We can elim
On Mon, Jan 5, 2015 at 8:42 PM, Atri Sharma wrote:
>
> Hi All,
>
> Please forgive if this is a repost.
>
> Please find attached patch for supporting ORDER BY clause in CREATE
> FUNCTION for SRFs. Specifically:
>
> CREATE OR REPLACE FUNCTION func1(OUT e int, OUT f int) returns setof
> record as '
On 18-12-2014 AM 04:52, Robert Haas wrote:
> On Wed, Dec 17, 2014 at 1:53 PM, Josh Berkus wrote:
>>
>> Sure. But there's a big difference between "we're going to take these
>> steps and that problem will be fixable eventually" and "we're going to
>> retain features of the current partitioning sys
On Tue, Jan 6, 2015 at 12:39 AM, Manuel Kniep wrote:
> Hi,
>
> we are running postges 9.3.5 on gentoo linux kernel 3.16.5, compiled with gcc
> 4.8.3
> Any ideas ?
> #17 0x0062bb9d in SPI_execute_with_args (
src=0x22b880bb0 "\nCREATE TEMPORARY TABLE
> [...]
> #33 0x7f363555ab9
On 01/05/2015 05:43 PM, Peter Eisentraut wrote:
> The wins on the other hand are obscure: You can now use SHOW to inspect
> recovery settings. You can design your own configuration file include
> structures to set them. These are not bad, but is that all?
That's not the only potential win, and i
On Mon, Jan 5, 2015 at 10:39 PM, Alexey Vasiliev wrote:
> Hello. Thanks for help. Yes, new patch look fine!
OK cool. Let's get an opinion from a committer then.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.pos
Hi,
Following is perhaps a typo:
- qualifications of queries which are run against the table the policy
is on,
+ qualifications of queries which are run against the table if the
policy is on,
Attached fixes it if so.
Thanks,
Amit
diff --git a/doc/src/sgml/ref/create_policy.sgml b/doc/src/sg
On Mon, Jan 5, 2015 at 9:57 PM, Robert Haas wrote:
>
> On Sat, Jan 3, 2015 at 7:31 PM, Andres Freund
wrote:
>
> > * Doesn't the restriction in GetSerializableTransactionSnapshotInt()
> > apply for repeatable read just the same?
>
> Yeah. I'm not sure whether we really need that check at all, b
On Fri, Jan 2, 2015 at 06:25:52PM +0100, Andres Freund wrote:
> I can't run tests right now...
>
> What exactly do you want to see with these tests? that's essentially
> what I've already benchmarked + some fprintfs?
I want to test two patches that both allocate an extra 64 bytes but
shift the a
On Mon, Jan 5, 2015 at 10:29 PM, Fujii Masao wrote:
> On Sun, Dec 28, 2014 at 10:57 PM, Michael Paquier wrote:
> The patch 1 cannot be applied to the master successfully because of
> recent change.
Yes, that's caused by ccb161b. Attached are rebased versions.
>> - The real stuff comes with patch
On Thu, Jan 1, 2015 at 11:17 PM, Peter Geoghegan wrote:
> The attached patch fixes Jeff's test case, as far as it goes. But, as
> I mentioned, it's not intended as a real fix. For one thing, I have
> made multiple changes to HeapTupleSatisfies*() routines, but haven't
> fully considered the conseq
I think this is a valuable effort, but I wonder how we are going to
arrive at a consensus. I don't see any committer supporting these
changes. Clearly, there are some advantages to having recovery
parameters be GUCs, but the proposed changes also come with some
disadvantages, and the tradeoffs are
On 06/01/15 01:02, Tom Lane wrote:
Petr Jelinek writes:
Attached is fix for
http://www.postgresql.org/message-id/1420492505.23613.15.ca...@bloodnok.com
It was dumping comment with NULL owner while the function expects
empty string for objects without owner (there is pg_strdup down the
line).
Petr Jelinek writes:
> Attached is fix for
> http://www.postgresql.org/message-id/1420492505.23613.15.ca...@bloodnok.com
> It was dumping comment with NULL owner while the function expects
> empty string for objects without owner (there is pg_strdup down the
> line).
This isn't right either: eve
On 22 December 2014 at 19:14, Robert Haas wrote:
> Here is another new version, with lots of bugs fixed.
An initial blind review, independent of other comments already made on thread.
OK src/backend/access/heap/heapam.c
heapam.c prohibitions on update and delete look fine
OK src/backend/access
Hi,
Attached is fix for
http://www.postgresql.org/message-id/1420492505.23613.15.ca...@bloodnok.com
It was dumping comment with NULL owner while the function expects
empty string for objects without owner (there is pg_strdup down the
line).
--
Petr Jelinek http://www.2ndQuadr
On Tue, Dec 30, 2014 at 04:48:11PM -0800, David Fetter wrote:
> On Wed, Dec 17, 2014 at 08:14:04AM -0500, Andrew Dunstan wrote:
> >
> > Yeah, that's the correct solution. It should not be terribly difficult to
> > create a test for a conninfo string in the dbname parameter. That's what
> > libpq d
On Fri, Jan 2, 2015 at 9:59 PM, Jeff Janes wrote:
> On Mon, Dec 29, 2014 at 2:15 PM, Alvaro Herrera
> wrote:
>
>> Here's a patch that tweaks the grammar to use TypeName in COMMENT,
>> SECURITY LABEL, and DROP for the type and domain cases. The required
>> changes in the code are pretty minimal,
On Sun, Jan 4, 2015 at 8:09 PM, Alvaro Herrera wrote:
> Andrew Dunstan wrote:
>> I don't wish to seem humorless, but I think this should probably be changed:
>>
>> root/HEAD/pgsql/src/test/regress/sql/event_trigger.sql:248: RAISE EXCEPTION
>> 'I''m sorry Sir, No Rewrite Allowed.';
>>
>> Quite apa
Jim Nasby writes:
> Related... I'd like to see a way to inline a function that does something
> like:
> CREATE FUNCTION foo(text) RETURNS int LANGUAGE sql AS $$
> SELECT a FROM b WHERE lower(b.c) = lower($1)
> $$
The reason that's not inlined ATM is that the semantics wouldn't be the
same (ie,
On 1/5/15, 12:20 PM, Atri Sharma wrote:
What would make sense to me is to teach the planner about inlining
SQL functions that include ORDER BY clauses, so that the performance
issue of a double sort could be avoided entirely transparently to
the user.
It sounds good, but inlinin
On 11/19/14 7:36 AM, Magnus Hagander wrote:
> +
> +
> pg_stat_sslpg_stat_ssl
> + One row per connection (regular and replication), showing
> statistics about
> +SSL used on this connection.
> +See for details.
> +
> +
> +
It doesn't really show "s
On 05/01/15 20:44, Robert Haas wrote:
On Sat, Jan 3, 2015 at 12:04 PM, Tom Lane wrote:
Of course, if recovery_min_apply_delay were a proper GUC, we'd just
configure it with a minimum value of zero and be done :-(
Amen. We should *really* convert all of the recovery.conf parameters
to be GUCs
Robert Haas writes:
> On Mon, Jan 5, 2015 at 2:47 PM, Tom Lane wrote:
>> That's a laudable goal, but I would bet that nothing built on the FDW
>> infrastructure will ever get there.
> Why?
> It would be surprising to me if, given that we have gone to some pains
> to create a system that allows
On 24/12/14 20:11, Alex Shulgin wrote:
Alex Shulgin writes:
- the StandbyModeRequested and StandbyMode should be lowercased like
the rest of the GUCs
Yes, except that standby_mode is linked to StandbyModeRequested, not the
other one. I can try see if there's a sane way out of this.
As I s
On Mon, Jan 5, 2015 at 2:47 PM, Tom Lane wrote:
> That's a laudable goal, but I would bet that nothing built on the FDW
> infrastructure will ever get there.
Why?
It would be surprising to me if, given that we have gone to some pains
to create a system that allows cross-system queries, and hopef
Robert Haas writes:
> I was involved in some internal discussions related to this patch, so
> I have some opinions on it. The long-term, high-level goal here is to
> facilitate sharding. If we've got a bunch of PostgreSQL servers
> interlinked via postgres_fdw, it should be possible to perform
>
On Sat, Jan 3, 2015 at 12:04 PM, Tom Lane wrote:
> Of course, if recovery_min_apply_delay were a proper GUC, we'd just
> configure it with a minimum value of zero and be done :-(
Amen. We should *really* convert all of the recovery.conf parameters
to be GUCs.
--
Robert Haas
EnterpriseDB: http:
On 01/05/2015 09:28 PM, Ravi Kiran wrote:
hi,
I am going through the hashjoin algorithm in postgres. I find a function
ExecHashjoin , which is called each time a new tuple is required by the
hash join *Node.*
could someone explain what exactly node mean in postgres.
See src/backend/nodes/. I
hi,
I am going through the hashjoin algorithm in postgres. I find a function
ExecHashjoin , which is called each time a new tuple is required by the
hash join *Node.*
could someone explain what exactly node mean in postgres.
Thanks
Adam, all,
* Adam Brightwell (adam.brightw...@crunchydatasolutions.com) wrote:
> If others are also in agreement on this point then I'll update the patch
> accordingly.
Works for me.
Thanks!
Stephen
signature.asc
Description: Digital signature
On Fri, Jan 2, 2015 at 3:45 PM, Tom Lane wrote:
> In short, you can't force 2PC technology on people who aren't using it
> already; while for those who are using it already, this isn't nearly
> good enough as-is.
I was involved in some internal discussions related to this patch, so
I have some op
On Mon, Jan 5, 2015 at 11:24 PM, Tom Lane wrote:
> David G Johnston writes:
> > Atri Sharma wrote
> >> If order of result rows is not the same as required, an error is raised:
> >>
> >> SELECT * FROM incorrect_order_nulls() ORDER BY e NULLS LAST;
> >> ERROR: Order not same as specified
>
> > Fi
Hello Alvaro,
Here is a v6 with most of your suggestions applied.
On top of evaluateExpr() we need a comment (generally I think pgbench
could do with more comments; not saying your patch should add them, just
expressing an opinion.) Also, intuitively I would say that the return
values of that
On 01/05/2015 09:06 AM, Heikki Linnakangas wrote:
> I wasn't clear on my opinion here. I think I understood what Josh meant,
> but I don't think we should do it. Seems like unnecessary nannying of
> the DBA. Let's just mention in the manual that if you set
> wal_keep_segments higher than [insert fo
David G Johnston writes:
> Atri Sharma wrote
>> If order of result rows is not the same as required, an error is raised:
>>
>> SELECT * FROM incorrect_order_nulls() ORDER BY e NULLS LAST;
>> ERROR: Order not same as specified
> First reaction for the error was unfavorable but (see below) it lik
The patch that implements INSERT ... ON CONFLICT UPDATE has support
and tests for per-column privileges (which are not relevant to the
IGNORE variant, AFAICT). However, RLS support is another thing
entirely. It has not been properly thought out, and unlike per-column
privileges requires careful con
Here's an updated version of pg_rewind. The code itself is the same as
before, and corresponds to the sources in the current pg_rewind github
repository, as of commit a65e3754faf9ca9718e6b350abc736de586433b7. Based
mostly on Michael's comments, I have:
* replaced VMware copyright notices with
On Mon, Jan 5, 2015 at 11:49 AM, Robert Haas wrote:
> On Wed, Dec 24, 2014 at 12:48 PM, Adam Brightwell
> wrote:
> > * BACKUP - allows role to perform backup operations
> > * LOGROTATE - allows role to rotate log files
> > * MONITOR - allows role to view pg_stat_* details
> > * PROCSIGNAL - allo
PGCon 2015 will be on 18-19 June 2015 at University of Ottawa.
* 16-17 (Tue-Wed) tutorials
* 18-19 (Thu-Fri) talks - the main part of the conference
* 20 (Sat) The Unconference (very popular)
PLEASE NOTE: PGCon 2015 is in June.
See http://www.pgcon.org/2015/
We are now accepting proposals for t
On 01/05/2015 12:06 PM, Andres Freund wrote:
On 2015-01-05 11:34:54 +0200, Heikki Linnakangas wrote:
On 01/04/2015 11:44 PM, Josh Berkus wrote:
On 01/03/2015 12:56 AM, Heikki Linnakangas wrote:
On 01/03/2015 12:28 AM, Josh Berkus wrote:
On 01/02/2015 01:57 AM, Heikki Linnakangas wrote:
wal_k
Robert Haas writes:
> On Sat, Jan 3, 2015 at 7:31 PM, Andres Freund wrote:
>> * I wonder if parallel contexts shouldn't be tracked via resowners
> That is a good question. I confess that I'm somewhat fuzzy about
> which things should be tracked via the resowner mechanism vs. which
> things shou
On Thu, Jan 1, 2015 at 3:04 PM, Andres Freund wrote:
>>That's true, but if you don't align the beginnings of the allocations,
>>then it's a lot more complicated for the code to properly align stuff
>>within the allocation. It's got to insert a variable amount of
>>padding based on the alignment i
On 05/01/15 16:17, Petr Jelinek wrote:
On 05/01/15 07:28, Fujii Masao wrote:
On Thu, Dec 4, 2014 at 12:08 PM, Fujii Masao
wrote:
On Wed, Dec 3, 2014 at 11:54 PM, Alvaro Herrera
wrote:
Pushed with some extra cosmetic tweaks.
I got the following assertion failure when I executed
pg_xact_comm
On Wed, Dec 24, 2014 at 12:48 PM, Adam Brightwell
wrote:
> * BACKUP - allows role to perform backup operations
> * LOGROTATE - allows role to rotate log files
> * MONITOR - allows role to view pg_stat_* details
> * PROCSIGNAL - allows role to signal backend processes
How about just "SIGNAL" inste
On 01/03/2015 08:59 PM, Andres Freund wrote:
Hi Heikki,
While writing a test script for
http://archives.postgresql.org/message-id/20141205002854.GE21964%40awork2.anarazel.de
I noticed that this commit broke starting a pg_basebackup -X * without a
recovery.conf present. Which might not be the bes
2015-01-05 17:40 GMT+01:00 Robert Haas :
> On Wed, Dec 31, 2014 at 12:46 PM, Tom Lane wrote:
> > I'd be all right with putting the data structure declarations in a file
> > named something like autovacuum_private.h, especially if it carried an
> > annotation that "if you depend on this, don't be
On Wed, Dec 31, 2014 at 12:46 PM, Tom Lane wrote:
> I'd be all right with putting the data structure declarations in a file
> named something like autovacuum_private.h, especially if it carried an
> annotation that "if you depend on this, don't be surprised if we break
> your code in future".
Wor
On Sat, Jan 3, 2015 at 7:31 PM, Andres Freund wrote:
> A couple remarks:
> * Shouldn't this provide more infrastructure to deal with the fact that
> we might get less parallel workers than we had planned for?
Maybe, but I'm not really sure what that should look like. My working
theory is that
Atri Sharma wrote
> If order of result rows is not the same as required, an error is raised:
>
> SELECT * FROM incorrect_order_nulls() ORDER BY e NULLS LAST;
> ERROR: Order not same as specified
First reaction for the error was unfavorable but (see below) it likely is
the best option and does ad
I'm also just looking at you ERROR() macro, it seems that core code is
quite careful not to use __VA_ARGS__ on compilers where HAVE__VA_ARGS is
not defined. I'd say this needs to be fixed too. Have a look at the trick
used in elog.h for when HAVE__VA_ARGS is not defined.
Hm, I just looked at
Hi,
we are running postges 9.3.5 on gentoo linux kernel 3.16.5, compiled with gcc
4.8.3
getting a segfault from time to time with the below core dump.
The error happens only on our production system and is not reproducible a
second run after
database recovery always succeed without any error
Hello Alvaro,
On top of evaluateExpr() we need a comment (generally I think pgbench
could do with more comments; not saying your patch should add them, just
expressing an opinion.)
Having spent some time in pgbench, I agree that more comments are a good
thing.
Also, intuitively I would say
On Fri, Jan 2, 2015 at 9:04 AM, Amit Kapila wrote:
> While working on parallel seq-scan patch to adapt this framework, I
> noticed few things and have questions regrading the same.
>
> 1.
> Currently parallel worker just attaches to error queue, for tuple queue
> do you expect it to be done in the
* Robert Haas (robertmh...@gmail.com) wrote:
> I think it's right to view this in the same way we view work_mem. We
> plan on the assumption that an amount of memory equal to work_mem will
> be available at execution time, without actually reserving it.
Agreed- this seems like a good approach f
On 05/01/15 07:28, Fujii Masao wrote:
On Thu, Dec 4, 2014 at 12:08 PM, Fujii Masao wrote:
On Wed, Dec 3, 2014 at 11:54 PM, Alvaro Herrera
wrote:
Pushed with some extra cosmetic tweaks.
I got the following assertion failure when I executed pg_xact_commit_timestamp()
in the standby server.
=
Hi All,
Please forgive if this is a repost.
Please find attached patch for supporting ORDER BY clause in CREATE
FUNCTION for SRFs. Specifically:
CREATE OR REPLACE FUNCTION func1(OUT e int, OUT f int) returns setof record
as ' SELECT a,b FROM table1 ORDER BY a; ' language 'sql' ORDER BY e;
This
On Fri, Jan 2, 2015 at 5:36 AM, Amit Kapila wrote:
> On Thu, Jan 1, 2015 at 11:29 PM, Robert Haas wrote:
>> On Thu, Jan 1, 2015 at 12:00 PM, Fabrízio de Royes Mello
>> wrote:
>> > Can we check the number of free bgworkers slots to set the max workers?
>>
>> The real solution here is that this pa
Fabien COELHO wrote:
>
> >I'm also just looking at you ERROR() macro, it seems that core code is
> >quite careful not to use __VA_ARGS__ on compilers where HAVE__VA_ARGS is
> >not defined. I'd say this needs to be fixed too. Have a look at the trick
> >used in elog.h for when HAVE__VA_ARGS is not
David Rowley wrote:
> I'm also just looking at you ERROR() macro, it seems that core code is
> quite careful not to use __VA_ARGS__ on compilers where HAVE__VA_ARGS is
> not defined. I'd say this needs to be fixed too. Have a look at the trick
> used in elog.h for when HAVE__VA_ARGS is not define
Mon, 5 Jan 2015 17:16:43 +0900 от Michael Paquier :
> On Wed, Dec 31, 2014 at 12:22 AM, Alexey Vasiliev wrote:
> > Tue, 30 Dec 2014 21:39:33 +0900 от Michael Paquier
> > :
> > As I understand now = (pg_time_t) time(NULL); return time in seconds, what
> > is why I multiply value to 1000 to compar
On Sun, Dec 28, 2014 at 10:57 PM, Michael Paquier
wrote:
>
>
> On Fri, Dec 26, 2014 at 4:16 PM, Michael Paquier
> wrote:
>> On Fri, Dec 26, 2014 at 3:24 PM, Fujii Masao
>> wrote:
>>> pglz_compress() and pglz_decompress() still use PGLZ_Header, so the
>>> frontend
>>> which uses those functions n
On 2015-01-05 18:49:06 +0900, Fujii Masao wrote:
> On Mon, Jan 5, 2015 at 6:22 PM, Andres Freund wrote:
> > On 2015-01-05 16:22:56 +0900, Fujii Masao wrote:
> >> On Sun, Jan 4, 2015 at 5:47 AM, Andres Freund
> >> wrote:
> >> > On 2015-01-03 16:03:36 +0100, Andres Freund wrote:
> >> > pg_baseback
On Mon, Jan 5, 2015 at 7:56 PM, Marco Nenciarini
wrote:
> I've noticed that I missed to add this to the commitfest.
>
> I've just added it.
>
> It is not meant to end up in a committable state, but at this point I'm
> searching for some code review and more discusison.
>
> I'm also about to send a
On 2015-01-04 21:54:40 +0100, Andres Freund wrote:
> On January 4, 2015 9:51:43 PM CET, Andrew Dunstan wrote:
> >
> >On 12/15/2014 12:04 PM, Andres Freund wrote:
> >
> >>> I think the safest fix would be to defer catchup interrupt
> >processing
> >>> while you're in this mode. You don't really wa
I've noticed that I missed to add this to the commitfest.
I've just added it.
It is not meant to end up in a committable state, but at this point I'm
searching for some code review and more discusison.
I'm also about to send an additional patch to implement an LSN map as an
additional fork for h
I've noticed that I missed to add this to the commitfest.
I've just added it.
It is not meant to end up in a committable state, but at this point I'm
searching for some code review and more discusison.
I'm also about to send an additional patch to implement an LSN map as an
additional fork for h
On 2015-01-05 11:34:54 +0200, Heikki Linnakangas wrote:
> On 01/04/2015 11:44 PM, Josh Berkus wrote:
> >On 01/03/2015 12:56 AM, Heikki Linnakangas wrote:
> >>On 01/03/2015 12:28 AM, Josh Berkus wrote:
> >>>On 01/02/2015 01:57 AM, Heikki Linnakangas wrote:
> wal_keep_segments does not affect the
On Mon, Jan 5, 2015 at 6:22 PM, Andres Freund wrote:
> On 2015-01-05 16:22:56 +0900, Fujii Masao wrote:
>> On Sun, Jan 4, 2015 at 5:47 AM, Andres Freund wrote:
>> > On 2015-01-03 16:03:36 +0100, Andres Freund wrote:
>> > pg_basebackup really
>> > changed heavily since it's introduction. And despa
I'm also just looking at you ERROR() macro, it seems that core code is
quite careful not to use __VA_ARGS__ on compilers where HAVE__VA_ARGS is
not defined. I'd say this needs to be fixed too. Have a look at the trick
used in elog.h for when HAVE__VA_ARGS is not defined.
Here is a v5 with the
On 01/04/2015 11:44 PM, Josh Berkus wrote:
On 01/03/2015 12:56 AM, Heikki Linnakangas wrote:
On 01/03/2015 12:28 AM, Josh Berkus wrote:
On 01/02/2015 01:57 AM, Heikki Linnakangas wrote:
wal_keep_segments does not affect the calculation of CheckPointSegments.
If you set wal_keep_segments high e
On 2015-01-05 16:22:56 +0900, Fujii Masao wrote:
> On Sun, Jan 4, 2015 at 5:47 AM, Andres Freund wrote:
> > On 2015-01-03 16:03:36 +0100, Andres Freund wrote:
> > pg_basebackup really
> > changed heavily since it's introduction. And desparately needs some
> > restructuring.
>
> The patch seems to
I'm also just looking at you ERROR() macro, it seems that core code is
quite careful not to use __VA_ARGS__ on compilers where HAVE__VA_ARGS is
not defined. I'd say this needs to be fixed too. Have a look at the trick
used in elog.h for when HAVE__VA_ARGS is not defined.
Indeed.
The simplest
On Sat, Jan 3, 2015 at 2:24 AM, Bruce Momjian wrote:
> On Fri, Jan 2, 2015 at 02:18:12PM -0300, Claudio Freire wrote:
>> On Fri, Jan 2, 2015 at 2:11 PM, Andres Freund wrote:
>> >> , I now see the compression patch as something that has negatives, so
>> >> has to be set by the user, and only wins
On Sat, Jan 3, 2015 at 1:52 AM, Bruce Momjian wrote:
> On Fri, Jan 2, 2015 at 10:15:57AM -0600, k...@rice.edu wrote:
>> On Fri, Jan 02, 2015 at 01:01:06PM +0100, Andres Freund wrote:
>> > On 2014-12-31 16:09:31 -0500, Bruce Momjian wrote:
>> > > I still don't understand the value of adding WAL co
On 1 January 2015 at 21:23, Fabien COELHO wrote:
>
> I was about to go and look at this, but I had a problem when attempting to
>> compile with MSVC.
>>
>
> Thanks! Here is a v4 which includes your fix.
>
>
I'm also just looking at you ERROR() macro, it seems that core code is
quite careful not
On Wed, Dec 31, 2014 at 12:22 AM, Alexey Vasiliev wrote:
> Tue, 30 Dec 2014 21:39:33 +0900 от Michael Paquier
> :
> As I understand now = (pg_time_t) time(NULL); return time in seconds, what is
> why I multiply value to 1000 to compare with restore_command_retry_interval
> in milliseconds.
This
91 matches
Mail list logo
