The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
This causes the pgbench tests to fail (consistently) with
not ok 194 -
On Mon, 31 Jul 2017, Merlin Moncure wrote:
On Sun, Jul 30, 2017 at 8:34 PM, Steve Singer <st...@ssinger.info> wrote:
We don't seem to describe logical replication on
https://www.postgresql.org/docs/10/static/different-replication-solutions.html
The attached patch adds a s
We don't seem to describe logical replication on
https://www.postgresql.org/docs/10/static/different-replication-solutions.html
The attached patch adds a section.
Steve
diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
index 138bdf2..1329d1f 100644
---
On 04/10/2017 01:28 PM, Fujii Masao wrote:
Hi,
src/backend/replication/logical/launcher.c
* Worker started and attached to our shmem. This check is safe
* because only launcher ever starts the workers, so nobody can steal
* the worker slot.
The tablesync
On 12/31/2016 01:27 AM, Peter Eisentraut wrote:
Another updated patch, with quite a bit of rebasing and some minor
code polishing.
Patch applies cleanly and the tests pass
The feature seems to work as expected.
I've tried this out and it behaves as expected and desired. I also
tested the
On 12/30/2016 05:53 AM, Petr Jelinek wrote:
Hi,
I rebased this for the changes made to inheritance and merged in the
fixes that I previously sent separately.
I'm not sure if the following is expected or not
I have 1 publisher and 1 subscriber.
I then do pg_dump on my subscriber
./pg_dump
On 12/18/2016 09:04 PM, Petr Jelinek wrote:
On 18/12/16 19:02, Steve Singer wrote:
pg_dump is also generating warnings
pg_dump: [archiver] WARNING: don't know how to set owner for object type
SUBSCRIPTION
I know that the plan is to add proper ACL's for publications and
subscriptions later. I
On 12/18/2016 05:28 AM, Petr Jelinek wrote:
On 17/12/16 18:34, Steve Singer wrote:
On 12/16/2016 07:49 AM, Petr Jelinek wrote:
Yeah subscriptions are per database. I don't want to make v14 just
for these 2 changes as that would make life harder for anybody
code-reviewing the v13 so attached
On 12/16/2016 07:49 AM, Petr Jelinek wrote:
Hi,
attached is version 13 of the patch.
I merged in changes from PeterE. And did following changes:
- fixed the ownership error messages for both provider and subscriber
- added ability to send invalidation message to invalidate whole
relcache and
On Sun, 20 Nov 2016, Petr Jelinek wrote:
On 13/11/16 23:02, Steve Singer wrote:
There is one exception though:
*** 195,214
A conflict will produce an error and will stop the replication; it
! must be resolved manually by the user.
! The resolution can
On 10/31/2016 06:38 AM, Petr Jelinek wrote:
On 31/10/16 00:52, Steve Singer wrote:
There are some fundamental issues with initial sync that need to be
discussed on list but this one is not known. I'll try to convert this
to test case (seems like useful one) and fix it, thanks for the
report
On 10/31/2016 06:38 AM, Petr Jelinek wrote:
There are some fundamental issues with initial sync that need to be
discussed on list but this one is not known. I'll try to convert this
to test case (seems like useful one) and fix it, thanks for the
report. In meantime I realized I broke the last
On 10/24/2016 09:22 AM, Petr Jelinek wrote:
Hi,
attached is updated version of the patch.
There are quite a few improvements and restructuring, I fixed all the
bugs and basically everything that came up from the reviews and was
agreed on. There are still couple of things missing, ie column
On Tue, 20 Sep 2016, Peter Eisentraut wrote:
On 9/18/16 4:17 PM, Steve Singer wrote:
I think if we want to prevent the creation of subscriptions that point
to self, then we need to create a magic token when the postmaster starts
and check for that when we connect. So more of a running
ion connects back to same db (although that check is somewhat
imperfect) and if it gets stuck on create slot it should be normally
cancelable (that should solve the issue Steve Singer had)
- fixed the tests to work in any timezone
- added DDL regress tests for subscription
- added proper detect
On 09/08/2016 06:59 PM, Petr Jelinek wrote:
- the CREATE SUBSCRIPTION also tries to check if the specified
connection connects back to same db (although that check is somewhat
imperfect) and if it gets stuck on create slot it should be normally
cancelable (that should solve the issue Steve
On 09/05/2016 03:58 PM, Steve Singer wrote:
On 08/31/2016 04:51 PM, Petr Jelinek wrote:
Hi,
and one more version with bug fixes, improved code docs and couple
more tests, some general cleanup and also rebased on current master
for the start of CF.
A few more things I noticed when
On 08/31/2016 04:51 PM, Petr Jelinek wrote:
Hi,
and one more version with bug fixes, improved code docs and couple
more tests, some general cleanup and also rebased on current master
for the start of CF.
To get the 'subscription' TAP tests to pass I need to set
export PGTZ=+02
On 08/05/2016 11:00 AM, Petr Jelinek wrote:
Hi,
as promised here is WIP version of logical replication patch.
Thanks for keeping on this. This is important work
Feedback is welcome.
+
+ Publication
+
+A Publication object can be defined on any master node, owned by one
+
On 01/26/2016 10:43 AM, Craig Ringer wrote:
On 23 January 2016 at 11:17, Steve Singer <st...@ssinger.info
<mailto:st...@ssinger.info>> wrote:
** Schema changes involving rewriting big tables
Sometimes you have a DDL change on a large table that will involve
a t
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: tested, failed
Spec compliant: not tested
Documentation:tested, failed
Here is some more review
+-
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
This reply will covers a 10,000 foot level review of the feature (some of
On 01/15/2016 12:07 PM, Petr Jelinek wrote:
That's bug, fixed.
Can you posted an updated patch with whatever fixes you have so far made?
There are several statuses the table goes through, during the COPY
it's in synchronizing status, so next logical step seemed to be
synchronized. Maybe
On 01/09/2016 01:30 PM, Steve Singer wrote:
On 12/31/2015 06:34 PM, Petr Jelinek wrote:
I'm not really sure what to do to 'recover' my cluster at this point
so I'll send this off and rebuild my cluster and start over.
I had a setup test1--->test2 (with 2 tables in the default set)
On 12/31/2015 06:34 PM, Petr Jelinek wrote:
Hi,
I'd like to submit the replication solution which is based on the
pglogical_output [1] module (which is obviously needed for this to
compile).
The pglogical contrib module provides extension which does the
master-slave logical replication
On 12/31/2015 06:34 PM, Petr Jelinek wrote:
Hi,
I'd like to submit the replication solution which is based on the
pglogical_output [1] module (which is obviously needed for this to
compile).
Hi,
make check gives me
for extra in ../../contrib/pglogical_output contrib/pglogical; do make
On 10/15/2015 05:47 PM, Kevin Grittner wrote:
All other issues raised by Álvaro and Steve have been addressed,
except for this one, which I will argue against:
I've been looking through the updated patch
In snapmgr.c
+ * XXX: If we can trust a read of an int64 value to be atomic, we can
On 08/31/2015 10:07 AM, Kevin Grittner wrote:
Kevin,
I've started to do a review on this patch but I am a bit confused with
some of what I am seeing.
The attached testcase fails I replace the cursor in your test case with
direct selects from the table.
I would have expected this to
On 04/19/2015 11:18 AM, Mikko Tiihonen wrote:
Hi,
I would like allow specifying multiple host names for libpq to try to
connecting to. This is currently only supported if the host name
resolves to multiple addresses. Having the support for it without
complex dns setup would be much easier.
On 12/19/2014 10:41 AM, Alex Shulgin wrote:
I don't think so. The scenario this patch relies on assumes that the
DBA will remember to look in the log if something goes wrong, and in
your case there would be a message like the following:
WARNING: pg_hba.conf not reloaded
So an extra hint
On 12/15/2014 11:38 AM, Alex Shulgin wrote:
These are all valid concerns IMHO. Attached is the modified version of
the original patch by Craig, addressing the handling of the new
hint_log error data field and removing the client-side HINT. I'm also
moving this to the current CF. -- Alex
On 11/19/2014 08:22 AM, Alvaro Herrera wrote:
I think we're overblowing the pg_upgrade issue. Surely we don't need to
preserve commit_ts data when upgrading across major versions; and
pg_upgrade is perfectly prepared to remove old data when upgrading
(actually it just doesn't copy it; consider
On 11/16/2014 04:49 PM, Steve Singer wrote:
I installed things following the above steps on a different system
than my usual development laptop and I have been unable to reproduce
the error so for (on that system). But I am still able to reproduce
it on occasion on my normal development
On 11/17/2014 10:37 AM, Andres Freund wrote:
On 2014-11-13 22:23:02 -0500, Steve Singer wrote:
Also since updating (to 2c267e47afa4f9a7c) I've seen a assertion failure in
a normal client connection, not the walsender
#3 0x006b4978 in GetSerializableTransactionSnapshotInt
On 11/17/2014 11:34 AM, Andres Freund wrote:
Hi,
Kevin: CCed you, because it doesn't really look like a logical decoding
related issue.
On 2014-11-17 11:25:40 -0500, Steve Singer wrote:
On 11/17/2014 10:37 AM, Andres Freund wrote:
On 2014-11-13 22:23:02 -0500, Steve Singer wrote:
Also
On 11/13/2014 02:44 PM, Andres Freund wrote:
Hi Steve,
If it still happens, could you send me instructions of how to reproduce
the problem after cloning the necessary source repositories? It's quite
hard to validate a possible fix otherwise.
1. Install PG 9.4
2. Perform an initdb
On 11/14/2014 08:21 PM, Simon Riggs wrote:
The requested information is already available, as discussed. Logical
decoding adds commit ordering for *exactly* the purpose of using it
for replication, available to all solutions. This often requested
feature has now been added and doesn't need to be
On 11/13/2014 02:44 PM, Andres Freund wrote:
H
I've pushed a fix for a bug that could possibly also cause
this. Although it'd be odd that it always hits the user catalog
table. Except if your tests mostly modify the slony tables, but do not
do much DDL otherwise?
The test I was running
On 11/10/2014 08:39 AM, Petr Jelinek wrote:
On 09/11/14 17:57, Steve Singer wrote:
On 11/07/2014 07:07 PM, Petr Jelinek wrote:
The list of what is useful might be long, but we can't have everything
there as there are space constraints, and LSN is another 8 bytes and I
still want to have some
On 11/07/2014 07:07 PM, Petr Jelinek wrote:
The list of what is useful might be long, but we can't have everything
there as there are space constraints, and LSN is another 8 bytes and I
still want to have some bytes for storing the origin or whatever you
want to call it there, as that's the
On 11/05/2014 11:23 AM, Jim Nasby wrote:
Except that commit time is not guaranteed unique *even on a single
system*. That's my whole point. If we're going to bother with all the
commit time machinery it seems really silly to provide a way to
uniquely order every commit.
Clearly trying to
On 11/05/2014 05:43 PM, Andres Freund wrote:
On 2014-11-05 17:17:05 -0500, Steve Singer wrote:
Imo that's essentially a different feature. What you essentially would
need here is a 'commit sequence number' - but no timestamps. And
probably to be useful that number has to be 8 bytes in itself
On 10/28/2014 01:27 PM, Andres Freund wrote:
Hi,
On 2014-10-25 18:09:36 -0400, Steve Singer wrote:
I sometimes get the error snapshot too large from my logical replication
walsender process when in response to a CREATE_REPLICATION_SLOT.
Yes. That's possible if 'too much' was going on until
On 10/28/2014 01:31 PM, Andres Freund wrote:
On 2014-10-25 18:18:07 -0400, Steve Singer wrote:
My logical decoding plugin is occasionally getting this error
could not resolve cmin/cmax of catalog tuple
I get this when my output plugin is trying to read one of the user defined
catalog tables
I sometimes get the error snapshot too large from my logical
replication walsender process when in response to a CREATE_REPLICATION_SLOT.
This is in SnapBuildExportSnapshot in snapbuild.c
newxcnt is 212 at that point
I have max_connections = 200
procArray-maxProcs=212
Should we be testing
My logical decoding plugin is occasionally getting this error
could not resolve cmin/cmax of catalog tuple
I get this when my output plugin is trying to read one of the user
defined catalog tables (user_catalog_table=true)
I am not sure if this is a bug in the time-travel support in the
On 10/16/2014 08:08 AM, Andres Freund wrote:
On 2014-10-16 08:04:17 -0400, Jan Wieck wrote:
Hi,
PostgreSQL has for ages defined INT64_FORMAT and UINT64_FORMAT in
pg_config.h. This commit
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=ce486056ecd28050
moved those definitions to
On 10/22/2014 04:17 PM, Robert Haas wrote:
Slonik used to include postgre_fe.h but back in 2011 or so we stopped doing
so because it was causing issues (I think on win32 builds)
That seems like something we ought to consider fixing, but obviously
we'd need more details.
When I'll try to find
On 10/16/2014 11:34 PM, Craig Ringer wrote:
Given the generally positive reception to this, here's a patch.
The first patch adds an errhint_log , akin to the current errdetail_log,
so we can send a different HINT to the server log than we do to the client.
The patch behaves as you describe.
On 09/26/2014 06:05 PM, Andres Freund wrote:
On 2014-09-26 14:57:12 -0400, Robert Haas wrote:
Sure, it'll possibly not be trivial to move them elsewhere. On the other
hand, the padding bytes have been unused for 8+ years without somebody
laying claim on them but me. I don't think it's a good
On 09/26/2014 10:21 AM, Andres Freund wrote:
On 2014-09-26 09:53:09 -0400, Robert Haas wrote:
On Fri, Sep 26, 2014 at 5:05 AM, Andres Freund and...@2ndquadrant.com wrote:
Let me try to summarize the information requirements for each of these
things. For #1, you need to know, after crash
On 08/15/2014 09:42 AM, Andres Freund wrote:
On 2014-08-14 16:03:08 -0400, Steve Singer wrote:
I hit the following on 9.4 testing logical decoding.
TRAP: FailedAssertion(!(prev_first_lsn cur_txn-first_lsn), File:
reorderbuffer.c, Line: 618)
LOG: server process (PID 3801) was terminated
I hit the following on 9.4 testing logical decoding.
TRAP: FailedAssertion(!(prev_first_lsn cur_txn-first_lsn), File:
reorderbuffer.c, Line: 618)
LOG: server process (PID 3801) was terminated by signal 6: Aborted
Unfortunately I don't have a core file and I haven't been able to
reproduce
On 07/14/2014 01:19 PM, Steve Singer wrote:
On 07/06/2014 10:11 AM, Andres Freund wrote:
Hi Steve,
Right. I thought about this for a while, and I think we should change
two things. For one, don't request replies here. It's simply not needed,
as this isn't dealing with timeouts. For another
On 07/06/2014 10:11 AM, Andres Freund wrote:
Hi Steve,
Right. I thought about this for a while, and I think we should change
two things. For one, don't request replies here. It's simply not needed,
as this isn't dealing with timeouts. For another don't just check -flush
sentPtr but also
I've encountered a corrupt pg_control file on my 9.4 development
cluster. I've mostly been using the cluster for changeset extraction /
slony testing.
This is a 9.4 (currently commit 6ad903d70a440e + a walsender change
discussed in another thread) but would have had the initdb done with an
On 07/08/2014 10:14 PM, Tom Lane wrote:
Steve Singer st...@ssinger.info writes:
I've encountered a corrupt pg_control file on my 9.4 development
cluster. I've mostly been using the cluster for changeset extraction /
slony testing.
This is a 9.4 (currently commit 6ad903d70a440e + a walsender
In 9.4 we've the below block of code to walsender.c as
/*
* We only send regular messages to the client for full decoded
* transactions, but a synchronous replication and walsender shutdown
* possibly are waiting for a later location. So we send pings
* containing the flush location every
On 05/28/2014 06:41 PM, Andres Freund wrote:
Hi,
Pushed a fix for it. I am pretty sure it will, but could you still test
that it fixes your problem?
Thanks!
The fix seems to work (I am no longer getting the timeout on slot creation)
Thanks
Andres Freund
--
Sent via pgsql-hackers
I am finding that my logical walsender connections are being terminated
due to a timeout on the CREATE REPLICATION SLOT command. with
terminating walsender process due to replication timeout
Below is the stack trace when this happens
#3 0x0067df28 in WalSndCheckTimeOut
On 05/16/2014 04:43 PM, Andres Freund wrote:
Hi,
I don't think that's going to cut it though. The creation can take
longer than whatever wal_sender_timeout is set to (when there's lots of
longrunning transactions). I think checking whether last_reply_timestamp
= 0 during timeout checking is
With master/9.4 from today (52e757420fa98a76015c2c88432db94269f3e8f4)
I am getting an assertion when doing a truncate via SPI when I have
wal_level=logical.
Stack trace is below.
I am just replicating a table with normal slony (2.2) I don't need to
establish any replication slots to get
On 04/17/2014 04:33 PM, Andres Freund wrote:
Hi,
On 2014-04-17 16:23:54 -0400, Steve Singer wrote:
With master/9.4 from today (52e757420fa98a76015c2c88432db94269f3e8f4)
I am getting an assertion when doing a truncate via SPI when I have
wal_level=logical.
Stack trace is below.
I am just
On 01/05/2014 09:13 PM, Michael Paquier wrote:
On Mon, Jan 6, 2014 at 4:51 AM, Mark Dilger markdil...@yahoo.com
mailto:markdil...@yahoo.com wrote:
I am building a regression test system for replication and came across
this email thread. I have gotten pretty far into my implementation, but
On 08/22/2013 02:02 AM, Pavel Stehule wrote:
rebased
Regards
Pavel
This patch again needs a rebase, it no longer applies cleanly.
plpgsql_estate_setup now takes a shared estate parameter and the call in
pl_check needs that. I passed NULL in and things seem to work.
I think this is
On 11/14/2013 12:26 PM, Andres Freund wrote:
Hello,
As you know, the reason we are working changeset extraction is that we
want to build logical unidirection and bidirectional replication
ontop. To use changeset extraction effectively, I think one set of
related features ontop is very useful:
On 11/11/2013 02:06 PM, Andres Freund wrote:
On 2013-11-10 14:45:17 -0500, Steve Singer wrote:
Not really keen - that'd be a noticeable overhead. Note that in the
cases where DEFAULT|INDEX is used, you can just use the new tuple to
extract what you need for the pkey lookup since they now have
On 11/10/2013 09:41 AM, Andres Freund wrote:
Still give me the following:
update disorder.do_inventory set ii_in_stock=2 where ii_id=251;
UPDATE 1
test1=# LOG: tuple in table with oid: 35122 without primary key
Hm. Could it be that you still have an older test_decoding plugin
lying around? The
On 11/05/2013 10:21 AM, Andres Freund wrote:
Hi,
Attached to this mail and in the xlog-decoding-rebasing-remapping branch
in my git[1] repository you can find the next version of the patchset that:
* Fixes full table rewrites of catalog tables using the method Robert
prefers (which is to log
On 11/09/2013 05:42 PM, Andres Freund wrote:
On 2013-11-09 17:36:49 -0500, Steve Singer wrote:
On 11/05/2013 10:21 AM, Andres Freund wrote:
Hi,
Attached to this mail and in the xlog-decoding-rebasing-remapping branch
in my git[1] repository you can find the next version of the patchset
On 10/07/2013 09:32 AM, Andres Freund wrote:
Todo:
* rename treat_as_catalog_table, after agreeing on the new name
* rename remaining timetravel function names
* restrict SuspendDecodingSnapshots usage to RelationInitPhysicalAddr,
that ought to be enough.
* add InLogicalDecoding() function.
*
On 10/03/2013 04:00 PM, Andres Freund wrote:
Ok, there were a couple of bugs because I thought mxacts wouldn't need
to be supported. So far your testcase doesn't crash the database
anymore - it spews some internal errors though, so I am not sure if
it's entirely fixed for you. Thanks for
On 09/30/2013 09:08 AM, Kevin Grittner wrote:
Steve Singer st...@ssinger.info wrote:
How about
To support matching of rows which include elements without a default
B-tree operator class, the following operators are defined for composite
type comparison:
literal
On 10/03/2013 12:38 PM, Andres Freund wrote:
Does your code use SELECT FOR UPDATE/SHARE on system or
treat_as_catalog tables? Greetings, Andres Freund
Yes.
It declares sl_table and sl_sequence and sl_set as catalog.
It does a
SELECT ..
from @NAMESPACE@.sl_table T, @NAMESPACE@.sl_set
On 09/30/2013 06:44 PM, Andres Freund wrote:
Hi,
The series from friday was a bit too buggy - obviously I was too
tired. So here's a new one:
With this series I've also noticed
#2 0x007741a7 in ExceptionalCondition (
conditionName=conditionName@entry=0x7c2908 !(!(tuple-t_infomask
On 09/28/2013 03:03 PM, Kevin Grittner wrote:
para
+To support matching of rows which include elements without a default
+B-tree operator class, the following operators are defined for composite
+type comparison:
+literal*=/,
+literal*lt;gt;/,
+literal*lt;/,
+
On 09/27/2013 11:44 AM, Andres Freund wrote:
I'm encountering a make error:
Gah. Lastminute changes. Always the same... Updated patch attached.
Greetings,
Andres Freund
I'm still encountering an error in the make.
make clean
.
.make[3]: Entering directory
On 09/27/2013 05:18 PM, Andres Freund wrote:
Hi Steve,
On 2013-09-27 17:06:59 -0400, Steve Singer wrote:
I've determined that when in this test the walsender seems to be hitting
this when it is decode the transactions that are behind the slonik
commands to add tables to replication (set add
On 09/26/2013 02:47 PM, Steve Singer wrote:
I've determined that when in this test the walsender seems to be
hitting this when it is decode the transactions that are behind the
slonik commands to add tables to replication (set add table, set add
sequence). This is before the SUBSCRIBE SET
On 09/25/2013 01:20 PM, Steve Singer wrote:
On 09/25/2013 11:08 AM, Andres Freund wrote:
On 2013-09-25 11:01:44 -0400, Steve Singer wrote:
On 09/17/2013 10:31 AM, Andres Freund wrote:
This patch set now fails to apply because of the commit Rename
various
freeze multixact variables.
And I am
On 09/17/2013 10:31 AM, Andres Freund wrote:
This patch set now fails to apply because of the commit Rename various
freeze multixact variables.
And I am even partially guilty for that patch...
Rebased patches attached.
While testing the logical replication changes against my WIP logical
On 09/25/2013 11:08 AM, Andres Freund wrote:
On 2013-09-25 11:01:44 -0400, Steve Singer wrote:
On 09/17/2013 10:31 AM, Andres Freund wrote:
This patch set now fails to apply because of the commit Rename various
freeze multixact variables.
And I am even partially guilty for that patch
On 09/24/2013 11:21 AM, Andres Freund wrote:
Not having a consumer of the walsender interface included sounds like a
bad idea to me, even if it were only useful for testing. Now, you could
argue it should be in /contrib - and I wouldn't argue against that
except it shares code with the rest of
On 09/20/2013 06:33 AM, Andres Freund wrote:
Hi,
The points I find daunting are the semantics, like:
* How do we control whether a standby is allowed prevent WAL file
removal. What if archiving is configured?
* How do we control whether a standby is allowed to peg xmin?
* How long do we
On 09/20/2013 08:38 AM, Kevin Grittner wrote:
Did you look at the record_eq and record_cmp functions which exist
before this patch? Is there a reason we should do it one way for the
default operators and another way for this alternative?
Do you think we should change record_eq and record_cmp
On 09/12/2013 06:27 PM, Kevin Grittner wrote:
Attached is a patch for a bit of infrastructure I believe to be
necessary for correct behavior of REFRESH MATERIALIZED VIEW
CONCURRENTLY as well as incremental maintenance of matviews.
Here is attempt at a review of the v1 patch.
There has been a
On 09/18/2013 11:39 AM, Stephen Frost wrote:
* Kevin Grittner (kgri...@ymail.com) wrote:
= and aren't listed above even though they do a byte-for-byte
comparison because, well, I guess because we have chosen to treat
two UTF8 strings which produce the same set of glyphs using
different bytes
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 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
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 06/27/2013 05:04 AM, Szymon Guz wrote:
On 27 June 2013 05:21, Steve Singer st...@ssinger.info
mailto:st...@ssinger.info wrote:
On 06/26/2013 04:47 PM, Szymon Guz wrote:
Hi Steve,
thanks for the changes.
You're idea about common code for decimal and cdecimal is good,
however
On 06/26/2013 04:47 PM, Szymon Guz wrote:
Attached patch has all changes against trunk code.
There is added a function for conversion from Postgres numeric to
Python Decimal. The Decimal type is taken from cdecimal.Decimal, if it
is available. It is an external library, quite fast, but
On 06/25/2013 06:42 AM, Szymon Guz wrote:
Hi,
I've attached a new patch. I've fixed all the problems you've found,
except for the efficiency problem, which has been described in
previous email.
thanks,
Szymon
This version of the patch addresses the issues I mentioned. Thanks for
On 05/28/2013 04:41 PM, Szymon Guz wrote:
Hi,
I've got a patch.
This is for a plpython enhancement.
There is an item at the TODO list
http://wiki.postgresql.org/wiki/Todo#Server-Side_Languages
Fix loss of information during conversion of numeric type to Python
float
This patch uses a
On 05/11/2013 04:58 PM, Bruce Momjian wrote:
On Fri, May 10, 2013 at 08:03:38PM -0400, Bruce Momjian wrote:
OK, this verifies that the table had a lot of DDL churn. I have no idea
how to pursue this further because I am unsure how we are going to
replicate the operations performed on this
but I
haven't yet seen a patch.
-Original Message-
From: Steve Singer [mailto:st...@ssinger.info]
Sent: Monday, April 22, 2013 4:35 PM
To: Anne Rosset
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Performance with the new security release?
On 13-04-22 04:41 PM, Anne Rosset
really need to make sure).
Thanks,
Anne
-Original Message-
From: Steve Singer [mailto:st...@ssinger.info]
Sent: Tuesday, April 23, 2013 6:33 AM
To: Anne Rosset
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Performance with the new security release?
On 13-04-22 11:46 PM, Anne
On 13-04-22 01:38 PM, Anne Rosset wrote:
Hi,
We are seeing some overall performance degradation in our application
since we installed the security release. Other commits were also done
at the same time in the application so we don't know yet if the
degradation has any relationship with the
this issue.
I will dig into our logs to see for the query times.
Thanks,
Anne
-Original Message-
From: Steve Singer [mailto:st...@ssinger.info]
Sent: Monday, April 22, 2013 12:59 PM
To: Anne Rosset
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Performance with the new security
and doing manual vacuums during those times.
-Original Message-
From: Steve Singer [mailto:st...@ssinger.info]
Sent: Monday, April 22, 2013 1:26 PM
To: Anne Rosset
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Performance with the new security release?
On 13-04-22 04:15 PM, Anne
1 - 100 of 223 matches
Mail list logo