On 2013-08-27 11:32:30 -0400, Alvaro Herrera wrote:
> Andres Freund wrote:
> > The git tree is at:
> > git://git.postgresql.org/git/users/andresfreund/postgres.git branch
> > xlog-decoding-rebasing-cf4
> > http://git.postgresql.org/gitweb/?p=users/andresfreund/postgres.git;a=shortlog;h=refs/heads/
Andres Freund wrote:
> The git tree is at:
> git://git.postgresql.org/git/users/andresfreund/postgres.git branch
> xlog-decoding-rebasing-cf4
> http://git.postgresql.org/gitweb/?p=users/andresfreund/postgres.git;a=shortlog;h=refs/heads/xlog-decoding-rebasing-cf4
I gave this recently rebased branc
On 2013-07-22 13:50:08 -0400, Robert Haas wrote:
> On Fri, Jun 14, 2013 at 6:51 PM, Andres Freund wrote:
> > The git tree is at:
> > git://git.postgresql.org/git/users/andresfreund/postgres.git branch
> > xlog-decoding-rebasing-cf4
> > http://git.postgresql.org/gitweb/?p=users/andresfreund/postgr
On Fri, Jun 14, 2013 at 6:51 PM, Andres Freund wrote:
> The git tree is at:
> git://git.postgresql.org/git/users/andresfreund/postgres.git branch
> xlog-decoding-rebasing-cf4
> http://git.postgresql.org/gitweb/?p=users/andresfreund/postgres.git;a=shortlog;h=refs/heads/xlog-decoding-rebasing-cf4
>
On Tue, Jul 16, 2013 at 9:00 AM, Robert Haas wrote:
> On Sun, Jul 7, 2013 at 4:34 PM, Andres Freund wrote:
>> On 2013-07-07 15:43:17 -0400, Tom Lane wrote:
>>> Andres Freund writes:
>>> > 3b) Add catcache 'filter' that ensures the cache stays unique and use
>>> > that for the mapping
>>>
>>>
On Sun, Jul 7, 2013 at 4:34 PM, Andres Freund wrote:
> On 2013-07-07 15:43:17 -0400, Tom Lane wrote:
>> Andres Freund writes:
>> > 3b) Add catcache 'filter' that ensures the cache stays unique and use
>> > that for the mapping
>>
>> > I slightly prefer 3b) because it's smaller, what's your op
Andres Freund wrote:
> Any chance there still was an old replication slot around?
It is quite likely that there was.
--
Kevin Grittner
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On 2013-07-10 15:14:58 -0700, Kevin Grittner wrote:
> Andres Freund wrote:
> > Kevin Grittner wrote:
>
> >> (2) An initial performance test didn't look very good. I will be
> >> running a more controlled test to confirm but the logical
> >> replication of a benchmark with a lot of UPDATEs of c
Andres Freund wrote:
> Kevin Grittner wrote:
>> (2) An initial performance test didn't look very good. I will be
>> running a more controlled test to confirm but the logical
>> replication of a benchmark with a lot of UPDATEs of compressed text
>> values seemed to suffer with the logical repli
On 2013-07-10 12:21:23 -0700, Kevin Grittner wrote:
> Sorry for the delay in reviewing this. I must make sure never to
> take another vacation during a commitfest -- the backlog upon
> return is a killer
Heh. Yes. Been through it before...
> Kevin Grittner wrote:
> > Andres Freund wrote:
>
Sorry for the delay in reviewing this. I must make sure never to
take another vacation during a commitfest -- the backlog upon
return is a killer
Kevin Grittner wrote:
> Andres Freund wrote:
>> Otherwise, could you try applying my git tree so we are sure we
>> test the same thing?
>>
>> $
On 2013-07-07 15:43:17 -0400, Tom Lane wrote:
> Andres Freund writes:
> > 3b) Add catcache 'filter' that ensures the cache stays unique and use
> > that for the mapping
>
> > I slightly prefer 3b) because it's smaller, what's your opinions?
>
> This is just another variation on the theme of
Andres Freund writes:
> 3b) Add catcache 'filter' that ensures the cache stays unique and use
> that for the mapping
> I slightly prefer 3b) because it's smaller, what's your opinions?
This is just another variation on the theme of kluging the catcache to
do something it shouldn't. You're s
On 2013-06-28 21:47:47 +0200, Andres Freund wrote:
> So, from what I gather there's a slight leaning towards *not* storing
> the relation's oid in the WAL. Which means the concerns about the
> uniqueness issues with the syscaches need to be addressed. So far I know
> of three solutions:
> 1) develo
On 2013-07-05 11:33:20 -0400, Steve Singer wrote:
> On 06/14/2013 06:51 PM, Andres Freund wrote:
> >The git tree is at:
> >git://git.postgresql.org/git/users/andresfreund/postgres.git branch
> >xlog-decoding-rebasing-cf4
> >http://git.postgresql.org/gitweb/?p=users/andresfreund/postgres.git;a=shor
On 06/14/2013 06:51 PM, Andres Freund wrote:
The git tree is at:
git://git.postgresql.org/git/users/andresfreund/postgres.git branch
xlog-decoding-rebasing-cf4
http://git.postgresql.org/gitweb/?p=users/andresfreund/postgres.git;a=shortlog;h=refs/heads/xlog-decoding-rebasing-cf4
We discussed i
On 07/05/2013 09:34 AM, Andres Freund wrote:
On 2013-07-05 09:28:45 -0400, Steve Singer wrote:
On 07/05/2013 08:03 AM, Andres Freund wrote:
On 2013-06-27 21:52:03 -0700, Kevin Grittner wrote:
Tried that, too, and problem persists. The log shows the last commit on
your branch as 022c2da1873de2
On 2013-07-05 09:28:45 -0400, Steve Singer wrote:
> On 07/05/2013 08:03 AM, Andres Freund wrote:
> >On 2013-06-27 21:52:03 -0700, Kevin Grittner wrote:
> >>Tried that, too, and problem persists. The log shows the last commit on
> >>your branch as 022c2da1873de2fbc93ae524819932719ca41bdb.
> >Ok. I
On 07/05/2013 08:03 AM, Andres Freund wrote:
On 2013-06-27 21:52:03 -0700, Kevin Grittner wrote:
Tried that, too, and problem persists. The log shows the last commit
on your branch as 022c2da1873de2fbc93ae524819932719ca41bdb.
Ok. I think I have a slight idea what's going on. Could you check
w
On 2013-07-05 14:03:56 +0200, Andres Freund wrote:
> On 2013-06-27 21:52:03 -0700, Kevin Grittner wrote:
> > Andres Freund wrote:
> >
> > > Hm. There were some issues with the test_logical_decoding
> > > Makefile not cleaning up the regression installation properly.
> > > Which might have caused
On 2013-06-27 21:52:03 -0700, Kevin Grittner wrote:
> Andres Freund wrote:
>
> > Hm. There were some issues with the test_logical_decoding
> > Makefile not cleaning up the regression installation properly.
> > Which might have caused the issue.
> >
> > Could you try after applying the patches and
On 27 June 2013 23:18, Tom Lane wrote:
> Exactly what is the argument that says performance of this
> function is sufficiently critical to justify adding both the maintenance
> overhead of a new pg_class index, *and* a broken-by-design syscache?
>
I think we all agree on changing the syscache.
On 2013-07-01 14:16:55 -0400, Tom Lane wrote:
> Alvaro Herrera writes:
> > So the question is, do we take the overhead of the new index (which
> > means overhead on DML operations -- supposedly rare) or do we take the
> > overhead of larger WAL records (which means overhead on all DDL
> > operatio
Alvaro Herrera writes:
> So the question is, do we take the overhead of the new index (which
> means overhead on DML operations -- supposedly rare) or do we take the
> overhead of larger WAL records (which means overhead on all DDL
> operations)?
> Note we can make either thing apply to only peop
Since this discussion seems to have stalled, let me do a quick summary.
The goal of this subset of patches is to allow retroactive look up of
relations starting from a WAL record. Currently, the WAL record only
tracks the relfilenode that it affects, so there are two possibilities:
1. we add some
On 2013-06-28 12:26:52 -0400, Tom Lane wrote:
> Robert Haas writes:
> > On the other hand, I can't entirely shake the feeling that adding the
> > information into WAL would be more reliable.
>
> That feeling has been nagging at me too. I can't demonstrate that
> there's a problem when an ALTER T
On 28 June 2013 17:10, Robert Haas wrote:
> > But to tell the truth, I'm mostly exercised about the non-unique
> > syscache. I think that's simply a *bad* idea.
>
> +1.
>
> I don't think the extra index on pg_class is going to hurt that much,
> even if we create it always, as long as we use a p
Robert Haas writes:
> On the other hand, I can't entirely shake the feeling that adding the
> information into WAL would be more reliable.
That feeling has been nagging at me too. I can't demonstrate that
there's a problem when an ALTER TABLE is in process of rewriting a table
into a new relfile
On Fri, Jun 28, 2013 at 11:56 AM, Tom Lane wrote:
> Robert Haas writes:
>> I'm just talking out of my rear end here because I don't know what the
>> real numbers are, but it's far from obvious to me that there's any
>> free lunch here. That having been said, just because indexing
>> relfilenode
Robert Haas writes:
> I'm just talking out of my rear end here because I don't know what the
> real numbers are, but it's far from obvious to me that there's any
> free lunch here. That having been said, just because indexing
> relfilenode or adding relfilenodes to WAL records is expensive doesn'
Alvaro Herrera escribió:
> An INSERT wal record is:
>
> typedef struct xl_heap_insert
> {
> xl_heaptid target; /* inserted tuple id */
> boolall_visible_cleared;/* PD_ALL_VISIBLE was cleared */
> /* xl_heap_header & TUPLE DATA FOLLOWS AT END
Robert Haas escribió:
> On Fri, Jun 28, 2013 at 10:49 AM, Tom Lane wrote:
> > Robert's idea sounds fairly reasonable to me; another 4 bytes per
> > insert/update/delete WAL entry isn't that big a deal, ...
>
> How big a deal is it? This is a serious question, because I don't
> know. Let's suppo
On Fri, Jun 28, 2013 at 10:49 AM, Tom Lane wrote:
> Robert's idea sounds fairly reasonable to me; another 4 bytes per
> insert/update/delete WAL entry isn't that big a deal, ...
How big a deal is it? This is a serious question, because I don't
know. Let's suppose that the average size of an XLO
On 2013-06-28 10:49:26 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-06-28 08:41:46 -0400, Robert Haas wrote:
> >> The alternative I previously proposed was to make the WAL records
> >> carry the relation OID. There are a few problems with that: one is
> >> that it's a waste of space
Andres Freund writes:
> On 2013-06-28 08:41:46 -0400, Robert Haas wrote:
>> The alternative I previously proposed was to make the WAL records
>> carry the relation OID. There are a few problems with that: one is
>> that it's a waste of space when logical replication is turned off, and
>> it might
On 6/28/13 8:46 AM, Andres Freund wrote:
> I personally favor making catalog modifications a bit more more
> expensive instead of increasing the WAL volume during routine
> operations. I don't think index maintenance itself comes close to the
> biggest cost for DDL we have atm.
That makes sense to
On 2013-06-27 21:52:03 -0700, Kevin Grittner wrote:
> Tried that, too, and problem persists. The log shows the last
> commit on your branch as 022c2da1873de2fbc93ae524819932719ca41bdb.
> I get the same failure, with primary key or unique index column
> showing as 0 in results.
I have run enough
On 2013-06-28 08:41:46 -0400, Robert Haas wrote:
> On Fri, Jun 28, 2013 at 3:32 AM, Andres Freund wrote:
> > What that means is that for every heap record in the target database in
> > the WAL we need to query pg_class to turn the relfilenode into a
> > pg_class.oid. So, we can easily replace sysc
On Fri, Jun 28, 2013 at 3:32 AM, Andres Freund wrote:
> What that means is that for every heap record in the target database in
> the WAL we need to query pg_class to turn the relfilenode into a
> pg_class.oid. So, we can easily replace syscache.c with some custom
> caching code, but I don't think
On 2013-06-27 18:18:50 -0400, Tom Lane wrote:
> Alvaro Herrera writes:
> > I'm looking at the combined patches 0003-0005, which are essentially all
> > about adding a function to obtain relation OID from (tablespace,
> > filenode). It takes care to look through the relation mapper, and uses
> > a
Andres Freund wrote:
> Hm. There were some issues with the test_logical_decoding
> Makefile not cleaning up the regression installation properly.
> Which might have caused the issue.
>
> Could you try after applying the patches and executing a clean
> and then rebuild?
Tried, and problem persist
On Thu, Jun 27, 2013 at 6:18 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> I'm looking at the combined patches 0003-0005, which are essentially all
>> about adding a function to obtain relation OID from (tablespace,
>> filenode). It takes care to look through the relation mapper, and uses
>> a
Alvaro Herrera writes:
> I'm looking at the combined patches 0003-0005, which are essentially all
> about adding a function to obtain relation OID from (tablespace,
> filenode). It takes care to look through the relation mapper, and uses
> a new syscache underneath for performance.
> One questio
Andres Freund wrote:
> On 2013-06-27 17:33:04 -0400, Alvaro Herrera wrote:
> > One question about this patch, originally, was about the usage of
> > that relfilenode syscache. It is questionable because it would be the
> > only syscache to apply on top of a non-unique index. It is said that
> >
Hi,
On 2013-06-27 17:33:04 -0400, Alvaro Herrera wrote:
> One question about this patch, originally, was about the usage of
> that relfilenode syscache. It is questionable because it would be the
> only syscache to apply on top of a non-unique index. It is said that
> this doesn't matter because
I'm looking at the combined patches 0003-0005, which are essentially all
about adding a function to obtain relation OID from (tablespace,
filenode). It takes care to look through the relation mapper, and uses
a new syscache underneath for performance.
One question about this patch, originally, wa
On 2013-06-24 07:29:43 -0700, Kevin Grittner wrote:
> Andres Freund wrote:
> > On 2013-06-23 10:32:05 -0700, Kevin Grittner wrote:
>
> >> The contrib/test_logical_decoding/sql/ddl.sql script is generating
> >> unexpected results. For both table_with_pkey and
> >> table_with_unique_not_null, upda
Andres Freund wrote:
> On 2013-06-24 06:44:53 -0700, Kevin Grittner wrote:
>> Andres Freund wrote:
>>> On 2013-06-23 08:27:32 -0700, Kevin Grittner wrote:
> + rm -f '$(DESTDIR)$(bindir)/pg_receivellog$(X)'
Oops. That part is not needed.
>>>
>>> Hm. Why not?
>>
>> Well, I could easily
Andres Freund wrote:
> On 2013-06-23 10:32:05 -0700, Kevin Grittner wrote:
>> The contrib/test_logical_decoding/sql/ddl.sql script is generating
>> unexpected results. For both table_with_pkey and
>> table_with_unique_not_null, updates of the primary key column are
>> showing:
>>
>> old-pkey: id
On 2013-06-24 06:44:53 -0700, Kevin Grittner wrote:
> Andres Freund wrote:
> > On 2013-06-23 08:27:32 -0700, Kevin Grittner wrote:
>
> >> make maintainer-clean ; ./configure --prefix=$PWD/Debug --enable-debug
> >> --enable-cassert --enable-depend --with-libxml --with-libxslt
> >> --with-openssl
Andres Freund wrote:
> On 2013-06-23 08:27:32 -0700, Kevin Grittner wrote:
>> make maintainer-clean ; ./configure --prefix=$PWD/Debug --enable-debug
>> --enable-cassert --enable-depend --with-libxml --with-libxslt --with-openssl
>> --with-perl --with-python && make -j4 world
>> [ build failure r
On 2013-06-23 16:48:41 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-06-23 08:27:32 -0700, Kevin Grittner wrote:
> >> gcc: error: pg_receivellog.o: No such file or directory
> >> make[3]: *** [pg_receivellog] Error 1
>
> > I have seen that once as well. It's really rather strange sin
Andres Freund writes:
> On 2013-06-23 08:27:32 -0700, Kevin Grittner wrote:
>> gcc: error: pg_receivellog.o: No such file or directory
>> make[3]: *** [pg_receivellog] Error 1
> I have seen that once as well. It's really rather strange since
> pg_receivellog.o is a clear prerequisite for pg_recei
On 2013-06-23 10:32:05 -0700, Kevin Grittner wrote:
> Andres Freund wrote:
>
> > Pushed and attached.
>
> The contrib/test_logical_decoding/sql/ddl.sql script is generating
> unexpected results. For both table_with_pkey and
> table_with_unique_not_null, updates of the primary key column are
> s
On 2013-06-23 08:27:32 -0700, Kevin Grittner wrote:
> Kevin Grittner wrote:
>
> > Confirmed that all 17 patch files now apply cleanly, and that `make
> > check-world` builds cleanly after each patch in turn.
>
> Just to be paranoid, I did one last build with all 17 patch files
> applied to 7dfd5
Andres Freund wrote:
> Pushed and attached.
The contrib/test_logical_decoding/sql/ddl.sql script is generating
unexpected results. For both table_with_pkey and
table_with_unique_not_null, updates of the primary key column are
showing:
old-pkey: id[int4]:0
... instead of the expected value of
Kevin Grittner wrote:
> uninstall:
> rm -f '$(DESTDIR)$(bindir)/pg_basebackup$(X)'
> rm -f '$(DESTDIR)$(bindir)/pg_receivexlog$(X)'
> + rm -f '$(DESTDIR)$(bindir)/pg_receivellog$(X)'
Oops. That part is not needed.
> clean distclean maintainer-clean:
> - rm -f pg_basebackup$(X) p
Kevin Grittner wrote:
> Confirmed that all 17 patch files now apply cleanly, and that `make
> check-world` builds cleanly after each patch in turn.
Just to be paranoid, I did one last build with all 17 patch files
applied to 7dfd5cd21c0091e467b16b31a10e20bbedd0a836 using this
line:
make maintai
Andres Freund wrote:
> The git tree is at:
> git://git.postgresql.org/git/users/andresfreund/postgres.git branch
> xlog-decoding-rebasing-cf4
> http://git.postgresql.org/gitweb/?p=users/andresfreund/postgres.git;a=shortlog;h=refs/heads/xlog-decoding-rebasing-cf4
>
> On 2013-06-15 00:48:17 +0200,
Andres Freund wrote:
>> 0007: Adjust Satisfies* interface: required, mechanical,
> Version v5-01 attached
I'm still working on a review and hope to post something more
substantive by this weekend, but when applying patches in numeric
order, this one did not compile cleanly.
gcc -O2 -Wall -Wmis
60 matches
Mail list logo
