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 branch a
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
On 2013-07-22 13:50:08 -0400, Robert Haas wrote:
On Fri, Jun 14, 2013 at 6:51 PM, Andres Freund and...@2ndquadrant.com wrote:
The git tree is at:
git://git.postgresql.org/git/users/andresfreund/postgres.git branch
xlog-decoding-rebasing-cf4
On Tue, Jul 16, 2013 at 9:00 AM, Robert Haas robertmh...@gmail.com wrote:
On Sun, Jul 7, 2013 at 4:34 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-07-07 15:43:17 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
3b) Add catcache 'filter' that ensures the cache
On Fri, Jun 14, 2013 at 6:51 PM, Andres Freund and...@2ndquadrant.com wrote:
The git tree is at:
git://git.postgresql.org/git/users/andresfreund/postgres.git branch
xlog-decoding-rebasing-cf4
On Sun, Jul 7, 2013 at 4:34 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-07-07 15:43:17 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
3b) Add catcache 'filter' that ensures the cache stays unique and use
that for the mapping
I slightly prefer 3b)
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 kgri...@ymail.com wrote:
Andres Freund and...@2ndquadrant.com wrote:
Otherwise, could you try applying my git tree so we are
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 kgri...@ymail.com wrote:
Andres
Andres Freund and...@2ndquadrant.com wrote:
Kevin Grittner kgri...@ymail.com 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
On 2013-07-10 15:14:58 -0700, Kevin Grittner wrote:
Andres Freund and...@2ndquadrant.com wrote:
Kevin Grittner kgri...@ymail.com 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
Andres Freund and...@2ndquadrant.com 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
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) develop a
Andres Freund and...@2ndquadrant.com 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
On 2013-07-07 15:43:17 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com 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
On 2013-06-27 21:52:03 -0700, Kevin Grittner wrote:
Andres Freund and...@2ndquadrant.com 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
On 2013-07-05 14:03:56 +0200, Andres Freund wrote:
On 2013-06-27 21:52:03 -0700, Kevin Grittner wrote:
Andres Freund and...@2ndquadrant.com wrote:
Hm. There were some issues with the test_logical_decoding
Makefile not cleaning up the regression installation properly.
Which might
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
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 think 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
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
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
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
Alvaro Herrera alvhe...@2ndquadrant.com 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
On 2013-07-01 14:16:55 -0400, Tom Lane wrote:
Alvaro Herrera alvhe...@2ndquadrant.com 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
On 27 June 2013 23:18, Tom Lane t...@sss.pgh.pa.us 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
On 2013-06-27 18:18:50 -0400, Tom Lane wrote:
Alvaro Herrera alvhe...@2ndquadrant.com 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
On Fri, Jun 28, 2013 at 3:32 AM, Andres Freund and...@2ndquadrant.com 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
On 2013-06-28 08:41:46 -0400, Robert Haas wrote:
On Fri, Jun 28, 2013 at 3:32 AM, Andres Freund and...@2ndquadrant.com 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
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 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 me
Andres Freund and...@2ndquadrant.com 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,
On 2013-06-28 10:49:26 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com 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
On Fri, Jun 28, 2013 at 10:49 AM, Tom Lane t...@sss.pgh.pa.us 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
Robert Haas escribió:
On Fri, Jun 28, 2013 at 10:49 AM, Tom Lane t...@sss.pgh.pa.us 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.
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 OF
Robert Haas robertmh...@gmail.com 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
On Fri, Jun 28, 2013 at 11:56 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
Robert Haas robertmh...@gmail.com 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
On 28 June 2013 17:10, Robert Haas robertmh...@gmail.com 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
On 2013-06-28 12:26:52 -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com 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
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,
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
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
this
Alvaro Herrera alvhe...@2ndquadrant.com 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
On Thu, Jun 27, 2013 at 6:18 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@2ndquadrant.com 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
Andres Freund and...@2ndquadrant.com 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,
Andres Freund and...@2ndquadrant.com 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
[
On 2013-06-24 06:44:53 -0700, Kevin Grittner wrote:
Andres Freund and...@2ndquadrant.com 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
Andres Freund and...@2ndquadrant.com 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:
Andres Freund and...@2ndquadrant.com wrote:
On 2013-06-24 06:44:53 -0700, Kevin Grittner wrote:
Andres Freund and...@2ndquadrant.com 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?
On 2013-06-24 07:29:43 -0700, Kevin Grittner wrote:
Andres Freund and...@2ndquadrant.com 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
Andres Freund and...@2ndquadrant.com 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
Kevin Grittner kgri...@ymail.com 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
Kevin Grittner kgri...@ymail.com 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
Andres Freund and...@2ndquadrant.com 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
On 2013-06-23 08:27:32 -0700, Kevin Grittner wrote:
Kevin Grittner kgri...@ymail.com 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
On 2013-06-23 10:32:05 -0700, Kevin Grittner wrote:
Andres Freund and...@2ndquadrant.com 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
Andres Freund and...@2ndquadrant.com 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
On 2013-06-23 16:48:41 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com 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
Andres Freund and...@2ndquadrant.com 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.
60 matches
Mail list logo
