;
if (MyWalSnd)
SetLatch(&MyWalSnd->latch);
~~~
Regards,
Marco
--
Marco Nenciarini - 2ndQuadrant Italy
PostgreSQL Training, Services and Support
marco.nenciar...@2ndquadrant.it | www.2ndQuadrant.it
signature.asc
Description: OpenPGP digital signature
On 08/07/16 13:10, Michael Paquier wrote:
> On Fri, Jul 8, 2016 at 6:40 PM, Marco Nenciarini
> wrote:
>> The resulting backup is working perfectly, because Postgres has no use
>> for pg_stop_backup LSN, but this can confuse any tool that uses the stop
>> LSN to figure
On 07/07/16 08:38, Michael Paquier wrote:
> On Thu, Jul 7, 2016 at 12:57 AM, Marco Nenciarini
> wrote:
>> After further analysis, the issue is that we retrieve the starttli from
>> the ControlFile structure, but it was using ThisTimeLineID when writing
>> the backup labe
On 06/07/16 17:41, Marco Nenciarini wrote:
> On 06/07/16 17:37, Marco Nenciarini wrote:
>> Hi,
>>
>> On 06/07/16 17:07, francesco.cano...@2ndquadrant.it wrote:
>>> The following bug has been logged on the website:
>>>
>>> Bug reference:
On 06/07/16 17:37, Marco Nenciarini wrote:
> Hi,
>
> On 06/07/16 17:07, francesco.cano...@2ndquadrant.it wrote:
>> The following bug has been logged on the website:
>>
>> Bug reference: 14230
>> Logged by: Francesco Canovai
>> Email address
e commands on the
> master.
>
> An incorrect backup label doesn't prevent PostgreSQL from starting up, but
> it affects the tools using that information.
>
>
The issue here is that the do_pg_stop_backup function uses the
ThisTimeLineID variable that is not valid on standb
On 27/06/15 01:13, Jim Nasby wrote:
> On 6/26/15 8:50 AM, Marco Nenciarini wrote:
>>> >In the heap_xlog_freeze we need to subtract one to the value of
>>> cutoff_xid
>>> >before passing it to ResolveRecoveryConflictWithSnapshot.
>>> >
>>> &
eclared identifier 'tblspc_mapfbuf'
pfree(tblspc_mapfbuf.data);
^
xlog.c:10193:17: error: use of undeclared identifier 'labelfbuf'
*labelfile = labelfbuf.data;
^
xlog.c:10194:8: error: use of undeclared identifier 'tblspc_mapfbuf'
if (tblspc_mapfbuf.len > 0)
^
Hi Magnus,
thanks for working on this topic.
What it does is very similar to what Barman's pgespresso extension does and I'd
like to see it implemented soon in the core.
I've added myself as reviewer for the patch on commitfest site.
Regards,
Marco
--
Marco Nenciarini - 2n
On 11/12/15 19:18, Marco Nenciarini wrote:
> On 11/12/15 18:48, Alvaro Herrera wrote:
>> Hi,
>>
>> A customer of ours hit some very slow code while running the
>> @>(polygon, polygon) operator with some big polygons. I'm not familiar
>> with this
T polygon 'poligon literal with 522 points' @> polygon 'poligon box'
I'm checking if we can share the full query.
Regards,
Marco
--
Marco Nenciarini - 2ndQuadrant Italy
PostgreSQL Training, Services and Support
marco.nenciar...@2ndquadrant.it | www.2ndQuadrant.it
signature.asc
Description: OpenPGP digital signature
Hi Robert,
On 17/11/15 20:10, Robert Haas wrote:
> On Tue, Nov 10, 2015 at 1:35 AM, Craig Ringer wrote:
>> On 10 November 2015 at 01:47, Marco Nenciarini
>> wrote:
>>
>>> I've attached a little patch that removes the errors when connected to 9.3.
>>
>
On 10/11/15 07:35, Craig Ringer wrote:
> On 10 November 2015 at 01:47, Marco Nenciarini
> wrote:
>
>> I've attached a little patch that removes the errors when connected to 9.3.
>
> Looks good to me. No point confusing users.
>
> The other callers of RunIden
f the connection is not database specific, and
this check is not needed on 9.3.
I've attached a little patch that removes the errors when connected to 9.3.
Regards,
Marco
--
Marco Nenciarini - 2ndQuadrant Italy
PostgreSQL Training, Services and Support
marco.nenciar...@2ndquadran
Il 26/06/15 15:43, marco.nenciar...@2ndquadrant.it ha scritto:
> The following bug has been logged on the website:
>
> Bug reference: 13473
> Logged by: Marco Nenciarini
> Email address: marco.nenciar...@2ndquadrant.it
> PostgreSQL version: 9.4.4
> Op
nt: 4302
Matching files size: 4432709876 (4.1GiB, 21.6%)
Matching LSN size: 4388993884 (4.1GiB, 21.4%)
== Heavily updated database, interval one week
First backup size: 3203198962 (3.0GiB)
Second backup size: 3222409202 (3.0GiB)
Matching files count: 1801
Matching LSN count: 1273
Matching files size
Hi Fujii,
Il 03/03/15 11:48, Fujii Masao ha scritto:
> On Tue, Mar 3, 2015 at 12:36 AM, Marco Nenciarini
> wrote:
>> Il 02/03/15 14:21, Fujii Masao ha scritto:
>>> On Thu, Feb 12, 2015 at 10:50 PM, Marco Nenciarini
>>> wrote:
>>>> Hi,
>>>&
Il 02/03/15 14:21, Fujii Masao ha scritto:
> On Thu, Feb 12, 2015 at 10:50 PM, Marco Nenciarini
> wrote:
>> Hi,
>>
>> I've attached an updated version of the patch.
>
> basebackup.c:1565: warning: format '%lld' expects type 'long long
> int
Il 02/02/15 21:48, Robert Haas ha scritto:
> On Sat, Jan 31, 2015 at 8:28 AM, Marco Nenciarini
> wrote:
>> Il 30/01/15 03:54, Michael Paquier ha scritto:
>>> On Fri, Jan 30, 2015 at 2:49 AM, Tom Lane wrote:
>>>> There is at least one other bug in that functi
ock number correctly.
Il 29/01/15 18:57, Robert Haas ha scritto:
> On Thu, Jan 29, 2015 at 9:47 AM, Marco Nenciarini
> wrote:
>> The current implementation of copydir function is incompatible with LSN
>> based incremental backups. The problem is that new files are created,
>> b
you look at https://commitfest.postgresql.org/4/94/ all the
attachments are marked as "Patch: no", but many of them are
clearly a patch.
Regards,
Marco
--
Marco Nenciarini - 2ndQuadrant Italy
PostgreSQL Training, Services and Support
marco.nenciar...@2ndquadrant.it | www.2ndQuadrant.it
Il 02/02/15 22:28, Magnus Hagander ha scritto:
> On Mon, Feb 2, 2015 at 10:06 PM, Robert Haas <mailto:robertmh...@gmail.com>> wrote:
>
> On Sat, Jan 31, 2015 at 6:47 PM, Marco Nenciarini
> <mailto:marco.nenciar...@2ndquadrant.it>> wrote:
> >
Il 31/01/15 17:22, Erik Rijkers ha scritto:
> On Sat, January 31, 2015 15:14, Marco Nenciarini wrote:
>
>> 0001-public-parse_filename_for_nontemp_relation.patch
>> 0002-copydir-LSN-v2.patch
>> 0003-File-based-incremental-backup-v8.patch
>
> Hi,
>
> It loo
Il 29/01/15 18:57, Robert Haas ha scritto:
> On Thu, Jan 29, 2015 at 9:47 AM, Marco Nenciarini
> wrote:
>> The current implementation of copydir function is incompatible with LSN
>> based incremental backups. The problem is that new files are created,
>> but their block
new version of the patch fixing the missing closedir on
readdir error.
Regards,
Marco
--
Marco Nenciarini - 2ndQuadrant Italy
PostgreSQL Training, Services and Support
marco.nenciar...@2ndquadrant.it | www.2ndQuadrant.it
From d2bfb6878aed404fdba1447d3f813edb4442ff47 Mon Sep 17 00:00:00 2001
From:
Il 29/01/15 18:37, Robert Haas ha scritto:
> On Thu, Jan 29, 2015 at 11:00 AM, Marco Nenciarini
> wrote:
>> reading pgcheckdir.c code I noticed that the function comment
>> was outdated. The code now can return values from 0 to 4 while the
>> comment explains only values
Hi,
reading pgcheckdir.c code I noticed that the function comment
was outdated. The code now can return values from 0 to 4 while the
comment explains only values 0,1,2.
Patch attached.
Regards,
Marco
--
Marco Nenciarini - 2ndQuadrant Italy
PostgreSQL Training, Services and Support
d the LSN comparison to the only MAIN fork, because:
* LSN fork doesn't uses LSN
* VM fork update LSN only when the visibility bit is set
* INIT forks doesn't use LSN. It's only one page anyway.
Regards,
Marco
--
Marco Nenciarini - 2ndQuadrant Italy
PostgreSQL Training,
Il 27/01/15 10:25, Giuseppe Broccolo ha scritto:> Hi Marco,
>
> On 16/01/15 16:55, Marco Nenciarini wrote:
>> On 14/01/15 17:22, Gabriele Bartolini wrote:
>> >
>> > My opinion, Marco, is that for version 5 of this patch, you:
>> >
>> > 1) update t
, ...]
It also supports relocation of tablespace with -T option.
The -T option is mandatory if there was any tablespace defined in the
PostgreSQL instance when the incremental_backup was taken.
Regards,
Marco
--
Marco Nenciarini - 2ndQuadrant Italy
PostgreSQL Training, Services and Suppor
t has to send it. One it found a single newer page it
immediately stop scanning and start sending the file. The IO impact
should not be that big due to the filesystem cache, but I agree with you
that it has to be measured.
Regards,
Marco
--
Marco Nenciarini - 2ndQuadrant Italy
PostgreSQL Tra
I'm now working to the client tool to rebuild a full backup starting
from a file based incremental backup.
Regards,
Marco
--
Marco Nenciarini - 2ndQuadrant Italy
PostgreSQL Training, Services and Support
marco.nenciar...@2ndquadrant.it | www.2ndQuadrant.it
From 50ff0872d3901a30b6742900170052e
Il 08/01/15 20:18, Jim Nasby ha scritto:
> On 1/7/15, 3:50 AM, Marco Nenciarini wrote:
>> The current implementation tracks only heap LSN. It currently does not
>> track any kind of indexes, but this can be easily added later.
>
> Would it make sense to do this at a buffer
e #2 approach.
54ad016e.9020...@2ndquadrant.it
Regards,
Marco
--
Marco Nenciarini - 2ndQuadrant Italy
PostgreSQL Training, Services and Support
marco.nenciar...@2ndquadrant.it | www.2ndQuadrant.it
signature.asc
Description: OpenPGP digital signature
ease advice on the best way to implement it.
Conclusions
This code is incomplete, and the xlog reply part must be
improved/fixed, but I think its a good start to have this feature.
I will appreciate any review, advice or critic.
Regards,
Marco
--
Marco Nenciarini - 2ndQuadrant Italy
Pos
additional fork for heap files.
Regards,
Marco
--
Marco Nenciarini - 2ndQuadrant Italy
PostgreSQL Training, Services and Support
marco.nenciar...@2ndquadrant.it | www.2ndQuadrant.it
signature.asc
Description: OpenPGP digital signature
additional fork for heap files.
Regards,
Marco
--
Marco Nenciarini - 2ndQuadrant Italy
PostgreSQL Training, Services and Support
marco.nenciar...@2ndquadrant.it | www.2ndQuadrant.it
signature.asc
Description: OpenPGP digital signature
a restartpoint happened on
standby between the start and the end of the backup.
you could simulate it issuing a checkpoint on master, a checkpoint on
standby (to force a restartpoint), then copying the pg_control from the
standby.
This way I've been able to reproduce it.
Regards,
Marco
Il 01/12/14 14:16, Craig Ringer ha scritto:
>
> +#ifndef FRONTEND
> +#include
> +#endif
> +
I think this is a leftover, as you don't use elog afterwards.
Regards,
Marco
--
Marco Nenciarini - 2ndQuadrant Italy
PostgreSQL Training, Services and Support
marco.nenciar...@
how to implement it in an
acceptable way.
== Disclaimer
The code here is an intermediate step, it does not contain any
documentation beside the code comments and will be subject to deep and
radical changes. However I believe it can be a base to allow PostgreSQL
to have its file-based incremental back
Il 06/10/14 17:50, Robert Haas ha scritto:
> On Mon, Oct 6, 2014 at 11:33 AM, Marco Nenciarini
> wrote:
>>> 2. Take a differential backup. In the backup label file, note the LSN
>>> of the fullback to which the differential backup is relative, and the
>>> newes
Il 06/10/14 17:55, Robert Haas ha scritto:
> On Mon, Oct 6, 2014 at 11:51 AM, Marco Nenciarini
> wrote:
>> I agree that a full backup does not need to include a profile.
>>
>> I've added the option to require the profile even for a full backup, as
>> it can
Il 06/10/14 16:51, Robert Haas ha scritto:
> On Mon, Oct 6, 2014 at 8:59 AM, Marco Nenciarini
> wrote:
>> Il 04/10/14 08:35, Michael Paquier ha scritto:
>>> On Sat, Oct 4, 2014 at 12:31 AM, Marco Nenciarini
>>> wrote:
>>>> Compared to first version, w
Il 03/10/14 22:47, Robert Haas ha scritto:
> On Fri, Oct 3, 2014 at 12:08 PM, Marco Nenciarini
> wrote:
>> Il 03/10/14 17:53, Heikki Linnakangas ha scritto:
>>> If we're going to need a profile file - and I'm not convinced of that -
>>> is there any reaso
Il 04/10/14 08:35, Michael Paquier ha scritto:
> On Sat, Oct 4, 2014 at 12:31 AM, Marco Nenciarini
> wrote:
>> Compared to first version, we switched from a timestamp+checksum based
>> approach to one based on LSN.
> Cool.
>
>> This patch adds an option to pg
Il 03/10/14 23:12, Andres Freund ha scritto:
> On 2014-10-03 17:31:45 +0200, Marco Nenciarini wrote:
>> I've updated the wiki page
>> https://wiki.postgresql.org/wiki/Incremental_backup following the result
>> of discussion on hackers.
>>
>> Compared to first
o scan all files twice, in the
> worst case.
>
It's true. To solve this you have to keep a central maxLSN directory,
but I think it introduces more issues than it solves.
Regards,
Marco
--
Marco Nenciarini - 2ndQuadrant Italy
PostgreSQL Training, Services and Support
marco.nenciar...@2ndquadrant.it | www.2ndQuadrant.it
signature.asc
Description: OpenPGP digital signature
r I'd appreciate comments
on correctness of relnode files detection and LSN extraction code.
Regards,
Marco
--
Marco Nenciarini - 2ndQuadrant Italy
PostgreSQL Training, Services and Support
marco.nenciar...@2ndquadrant.it | www.2ndQuadrant.it
backup_profile_v2.patch.gz
Description: GNU Zip compr
0060
BACKUP METHOD: streamed
BACKUP FROM: master
START TIME: 2014-08-14 18:54:01 CEST
LABEL: pg_basebackup base backup
END LABEL
I've attached the current patch based on master.
Any comment will be appreciated.
Regards,
Marco
--
Marco Nenciarini - 2ndQuadrant Italy
PostgreSQL Trai
Il 12/08/14 15:25, Claudio Freire ha scritto:
> On Tue, Aug 12, 2014 at 6:41 AM, Marco Nenciarini
> wrote:
>> To declared two files identical they must have same size,
>> same mtime and same *checksum*.
>
> Still not safe. Checksum collisions do happen, especially in bi
As I already stated, timestamps will be only used to early detect
changed files. To declared two files identical they must have same size,
same mtime and same *checksum*.
Regards,
Marco
--
Marco Nenciarini - 2ndQuadrant Italy
PostgreSQL Training, Services and Support
marco.nenciar
Postgres.
With the current full backup procedure they are backed up, so I think
that having them backed up with a rsync-like algorithm is what an user
would expect for an incremental backup.
Regards,
Marco
--
Marco Nenciarini - 2ndQuadrant Italy
PostgreSQL Training, Services and Support
marco.nenciar
nt it as a DWH oriented feature.
Regards,
Marco
--
Marco Nenciarini - 2ndQuadrant Italy
PostgreSQL Training, Services and Support
marco.nenciar...@2ndquadrant.it | www.2ndQuadrant.it
signature.asc
Description: OpenPGP digital signature
Il 25/07/14 20:44, Robert Haas ha scritto:
> On Fri, Jul 25, 2014 at 2:21 PM, Claudio Freire
> wrote:
>> On Fri, Jul 25, 2014 at 10:14 AM, Marco Nenciarini
>> wrote:
>>> 1. Proposal
>>> =
>>> Our proposal is to i
Il 25/07/14 20:21, Claudio Freire ha scritto:
> On Fri, Jul 25, 2014 at 10:14 AM, Marco Nenciarini
> wrote:
>> 1. Proposal
>> =
>> Our proposal is to introduce the concept of a backup profile. The backup
>> profile consists of
Il 25/07/14 16:15, Michael Paquier ha scritto:
> On Fri, Jul 25, 2014 at 10:14 PM, Marco Nenciarini
> wrote:
>> 0. Introduction:
>> =
>> This is a proposal for adding incremental backup support to streaming
>> protocol and hence to pg_
ebackup
We are willing to get consensus over our design here before to start
implementing it.
Regards,
Marco
--
Marco Nenciarini - 2ndQuadrant Italy
PostgreSQL Training, Services and Support
marco.nenciar...@2ndquadrant.it | www.2ndQuadrant.it
signature.asc
Description: OpenPGP digital signature
Thanks for your review.
Please find the attached refreshed patch (v2) which fixes the loose ends
you found.
Regards,
Marco
--
Marco Nenciarini - 2ndQuadrant Italy
PostgreSQL Training, Services and Support
marco.nenciar...@2ndquadrant.it | www.2ndQuadrant.it
Array-ELEMENT-foreign-key-v2
Hi,
please find attached the refreshed v1 patch.
Regards,
Marco
--
Marco Nenciarini - 2ndQuadrant Italy
PostgreSQL Training, Services and Support
marco.nenciar...@2ndquadrant.it | www.2ndQuadrant.it
Array-ELEMENT-foreign-key-v1-refreshed.patch.bz2
Description: application/bzip
--
Sent
adrant.
Thank you.
Cheers,
Marco
--
Marco Nenciarini - 2ndQuadrant Italy
PostgreSQL Training, Services and Support
marco.nenciar...@2ndquadrant.it | www.2ndQuadrant.it
Array-ELEMENT-foreign-key-v1.patch.bz2
Description: application/bzip
--
Sent via pgsql-hackers mailing list (pgsql-hackers
those into a helper function,
> array_replace_internal(). Thoughts?
It looks reasonable.
There was a typo in array_replace which was caught by regression tests.
I've fixed the typo and changed a comment in array_replace_internal.
Patch v3 attached.
Regards,
Marco
--
Marco Nenciarini - 2ndQuadrant Ita
y Array" patch as " Returned with Feedback"
as per your request. We will start working again on this patch in the
next commitfest as anticipated by Gabriele, hoping that the array
functions will be committed by then.
Thank you.
Cheers,
Marco
--
Marco Nenciarini - 2ndQuadrant Italy
patch includes changes to the documentation.
Cheers,
Marco
[1] http://archives.postgresql.org/message-id/4FD8F422.40709%402ndQuadrant.it
--
Marco Nenciarini - 2ndQuadrant Italy
PostgreSQL Training, Services and Support
marco.nenciar...@2ndquadrant.it | www.2ndQuadrant.it
array-functions.patch.
with the review.
Thank you,
Marco
--
Marco Nenciarini - 2ndQuadrant Italy
PostgreSQL Training, Services and Support
marco.nenciar...@2ndquadrant.it | www.2ndQuadrant.it
pg_backup_start_time-and-pg_is_in_backup-v4.1.patch.bz2
Description: application/bzip
--
Sent via pgsql-hackers mailing list
Il giorno lun, 19/03/2012 alle 18.41 +0100, Marco Nenciarini ha scritto:
>
> Attached is v5, which should address all the remaining issues.
Please find attached v6 of the EACH Foreign Key patch. From v5 only
cosmetic changes to the documentation were made.
Regards,
Marco
--
Marco Nenc
Il giorno mar, 20/03/2012 alle 11.16 +, Peter Geoghegan ha scritto:
> On 20 March 2012 10:53, Marco Nenciarini
> wrote:
> > alert.c: In function ‘dbms_alert_defered_signal’:
> > alert.c:839:33: error: dereferencing pointer to incomplete type
> > make: *** [alert.o] E
Il giorno mar, 20/03/2012 alle 16.46 +0500, Asif Naeem ha scritto:
> It seems that compiler is complain about "Relation" structure, can you
> please try adding the following in trigtest.c i.e.
>
> #include "utils/rel.h"
>
It does the trick.
Regards,
Marco
Il giorno mar, 20/03/2012 alle 11.16 +, Peter Geoghegan ha scritto:
> On 20 March 2012 10:53, Marco Nenciarini
> wrote:
> > alert.c: In function ‘dbms_alert_defered_signal’:
> > alert.c:839:33: error: dereferencing pointer to incomplete type
> > make: *** [alert.o] E
the example at
http://www.postgresql.org/docs/devel/static/trigger-example.html
and the result is exactly the same.
trigtest.c: In function ‘trigf’:
trigtest.c:44:36: error: dereferencing pointer to incomplete type
make: *** [trigtest.o] Error 1
Regards,
Marco
--
Marco Nenciarini - 2ndQua
bmit an update
> correcting the above; I'm sure your committer will appreciate it.
Attached is v5, which should address all the remaining issues.
Regards,
Marco
--
Marco Nenciarini - 2ndQuadrant Italy
PostgreSQL Training, Services and Support
marco.nenciar...@2ndquadrant.it | www.2ndQuadra
;
We are working on it and I hope we can send the v4 version during the
upcoming weekend.
Regards,
Marco
--
Marco Nenciarini - 2ndQuadrant Italy
PostgreSQL Training, Services and Support
marco.nenciar...@2ndquadrant.it | www.2ndQuadrant.it
--
Sent via pgsql-hackers mailing list
d above, we have
some ideas on multi-dimensional element removal, but not for this patch
for the aforementioned reasons.
* Support of EACH CASCADE/SET NULL in ConvertTriggerToFK(): we decided
to leave it.
Regards,
Marco
--
Marco Nenciarini - 2ndQuadrant Italy
PostgreSQL Training, Services
RESTRICT |-|-|
--- - -
We will resubmit the patch for the 2012-01 commit fest.
Thank you,
Marco
--
Marco Nenciarini - System manager @ Devise.IT
marco.nenciar...@devise.it | http://www.devise.it
foreign-key-array-v2.patch.gz
Description:
RESTRICT |-|-|
--- - -
We will resubmit the patch for the 2012-01 commit fest.
Thank you,
Marco
--
Marco Nenciarini - 2ndQuadrant Italy
PostgreSQL Training, Services and Support
marco.nenciar...@2ndquadrant.it | www.2ndQuadrant.it
for
g which has a case
mismatch error with its end tag.
Attached you can find the patch, if you want to apply it.
Regards,
Marco
--
Marco Nenciarini - 2ndQuadrant Italy
PostgreSQL Training, Services and Support
marco.nenciar...@2ndquadrant.it | www.2ndQuadrant.it
>From d22539bdb7cabcb6bfbf0ce1b80a59fbb
75 matches
Mail list logo