c update)
which allows doing that when pg_dumping from PG10+.
I also wonder if it should be mentioned in release notes. If the
attached patch would make it into PG10 it would be no brainer to mention
it as feature under pg_dump section, but exporting snapshots alone I am
not sure about.
--
Petr J
uld not be surprised if there is race condition in shutdown somewhere
before that's done.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.
On 23/03/17 15:17, Stephen Frost wrote:
> Petr,
>
> * Petr Jelinek (petr.jeli...@2ndquadrant.com) wrote:
>> On 23/03/17 14:47, Petr Jelinek wrote:
>>> I am looking into buildfarm failures.
>>>
>>> Looks like the clang issue (mylodon, longfin) is be
On 23/03/17 14:47, Petr Jelinek wrote:
> I am looking into buildfarm failures.
>
> Looks like the clang issue (mylodon, longfin) is because we are missing
> extern in include/replication/worker_internal.h for ApplyCacheContext.
>
> Still analyzing the rest.
>
Ah missing
I am looking into buildfarm failures.
Looks like the clang issue (mylodon, longfin) is because we are missing
extern in include/replication/worker_internal.h for ApplyCacheContext.
Still analyzing the rest.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development
error
>>> recovery, or to use a PG_TRY block.
>>
>> To be honest, I have thought about using PG_ENSURE_ERROR_CLEANUP()
>> when seeing the thread. If other ERROR messages are generated in the
>> future that the current fix would be unreliable.
>
> What about the
On 14/12/16 15:35, Peter Eisentraut wrote:
> On 12/12/16 8:28 PM, Petr Jelinek wrote:
>> On 13/12/16 02:00, Andres Freund wrote:
>>> On 2016-12-13 01:57:01 +0100, Petr Jelinek wrote:
>>>> I mentioned that as possible solution upthread, I am only worried that
>>
On 13/12/16 02:00, Andres Freund wrote:
> On 2016-12-13 01:57:01 +0100, Petr Jelinek wrote:
>> I mentioned that as possible solution upthread, I am only worried that
>> the failure scenario is basically infinite loop.
>
> I don't see the problem with that. If you're
On 13/12/16 02:08, Tom Lane wrote:
> Andres Freund writes:
>> On 2016-12-13 01:57:01 +0100, Petr Jelinek wrote:
>>> I mentioned that as possible solution upthread, I am only worried that
>>> the failure scenario is basically infinite loop.
>
>> I don't se
On 13/12/16 01:49, Andres Freund wrote:
> On 2016-12-13 01:42:48 +0100, Petr Jelinek wrote:
>> On 13/12/16 01:40, Tom Lane wrote:
>>> Petr Jelinek writes:
>>>> On 13/12/16 00:39, Tom Lane wrote:
>>>>> Hm, buildfarm says this didn't fix it. Where
On 13/12/16 01:40, Tom Lane wrote:
> Petr Jelinek writes:
>> On 13/12/16 00:39, Tom Lane wrote:
>>> Hm, buildfarm says this didn't fix it. Where exactly does the dropping
>>> of the slot happen ... is it not complete by the time the backend exits?
>
>>
On 13/12/16 00:39, Tom Lane wrote:
> I wrote:
>> Petr Jelinek writes:
>>> Attached is the fixed test using the loop from test_extensions (and yes
>>> I would have missed the pg_stat_clear_snapshot() call without the hint,
>>> thanks :) ).
>
>> Pushed
bust enough for slower machines.
Attached is the fixed test using the loop from test_extensions (and yes
I would have missed the pg_stat_clear_snapshot() call without the hint,
thanks :) ).
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Trainin
e, namelen) pgwin32_connect(s, name, namelen)
>
> which breaks the use of "connect" as a struct member name (same with send).
> The easiest fix seems to rename the struct members.
>
Hi,
Yes, that seems to be the case.
Something as simple as attached should do.
--
Petr Jel
On 2015-10-04 05:47, Tom Lane wrote:
Andres Freund writes:
Add CASCADE support for CREATE EXTENSION.
Buildfarm results suggest this was not tested with python 3.
Attached patch fixes it on my machine.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development
ler code, I think. Before I apply it I'd like to
have comments from Dmitry and Petr, just to make sure I haven't
inadvertently slipped my moorings.
I think it's ok like this, except that the "cannot get delete from
scalar" error message should probably be "c
is called (for each row).
Or you could change the long long int to int64.
But in general I wouldn't be too much against ripping it off, it's only
a bit of CPU when reading the stats...
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Sup
17 matches
Mail list logo
