On 13-03-26 12:40 AM, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
On Mon, Mar 25, 2013 at 07:07:42PM -0400, Tom Lane wrote:
Well, plan B would be to invent a replacement function that does have
the ability to return an error message, but that seems like a lot of
work for a problem
On 13-03-20 05:54 PM, Tom Lane wrote:
Steve Singer ssin...@ca.afilias.info writes:
From a end-user expectations point of view I am okay with somehow
marking the structure returned by PQconndefaults in a way that the
connect calls will later fail.
Unless the program changes the value
On 13-03-20 02:17 PM, Bruce Momjian wrote:
On Wed, Mar 20, 2013 at 01:30:20PM -0400, Tom Lane wrote:
While this surely isn't the nicest answer, it doesn't seem totally
unreasonable to me. A bad service name indeed does not contribute
anything to the set of defaults available.
I think the
On 13-03-18 09:17 PM, Bruce Momjian wrote:
On Mon, Mar 18, 2013 at 12:08:09PM -0400, Steve Singer wrote:
If you try running pg_upgrade with the PGSERVICE environment
variable set to some invalid/non-existent service pg_upgrade
segfaults
Program received signal SIGSEGV, Segmentation fault
If you try running pg_upgrade with the PGSERVICE environment variable
set to some invalid/non-existent service pg_upgrade segfaults
Program received signal SIGSEGV, Segmentation fault.
0x0040bdd1 in check_pghost_envvar () at server.c:304
304 for (option = start;
On 13-03-03 08:13 PM, Josh Berkus wrote:
This (creating the extensions) works fine for me on a Ubuntu 10.x system
Now if only we can work out the combinatorics issue ...
The plpython2u extensions worked fine but I haven't been able to get
this to work with plpython3u (python 3.1).
On 13-03-03 06:15 PM, Josh Berkus wrote:
transforms=# create extension hstore_plperl;
ERROR: could not load library
/home/josh/pg93/lib/postgresql/hstore_plperl.so:
/home/josh/pg93/lib/postgresql/hstore_plperl.so: undefined symbol:
hstoreUniquePairs
STATEMENT: create extension hstore_plperl;
On 13-02-25 05:37 PM, Andrew Dunstan wrote:
On 02/24/2013 01:09 AM, Steve Singer wrote:
On 13-01-11 11:03 AM, Andrew Dunstan wrote:
On 01/11/2013 11:00 AM, Andrew Dunstan wrote:
I have not had anyone follow up on this, so I have added docs and
will add this to the commitfest.
Recap
On 13-01-11 11:03 AM, Andrew Dunstan wrote:
On 01/11/2013 11:00 AM, Andrew Dunstan wrote:
I have not had anyone follow up on this, so I have added docs and
will add this to the commitfest.
Recap:
This adds the following:
json_agg(anyrecord) - json
to_json(any) - json
On 13-01-07 09:58 PM, Peter Eisentraut wrote:
By implementing a str handler for the result object, it now prints
something like
PLyResult status=5 nrows=2 rows=[{'foo': 1, 'bar': '11'}, {'foo': 2, 'bar':
'22'}]
Patch attached for review.
Here is a review:
This patch adds a function that
On 13-01-28 06:17 AM, Andres Freund wrote:
Hi,
3. Pass the delete (with no key values) onto the replication client and let
it deal with it (see 1 and 2)
Hm.
While I agree that nicer behaviour would be good I think the real
enforcement should happen on a higher level, e.g. with event triggers
On 13-01-28 06:23 AM, Andres Freund wrote:
The CF is also there to find UI warts and such, so something like this
seems perfectly fine. Even moreso as it doesn't look this will get
into 9.3 anyway. I wanted to add such an option, but I was too
lazy^Wbusy to think about the sematics. Your
On 13-01-26 11:11 PM, Robert Haas wrote:
On Fri, Jan 25, 2013 at 11:58 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
My understanding is that if the command string we give to event triggers
is ambiguous (sub-object names, schema qualifications, etc), it comes
useless for logical
176087bacec6cbf0b86e4ffeb918f41b4a5b8d7a Mon Sep 17 00:00:00 2001
From: Steve Singer ssin...@ca.afilias.info
Date: Sun, 27 Jan 2013 12:24:33 -0500
Subject: [PATCH] allow pg_receivellog to pass plugin options from the command line to the plugin
---
src/bin/pg_basebackup/pg_receivellog.c | 14
On 13-01-24 11:15 AM, Steve Singer wrote:
On 13-01-24 06:40 AM, Andres Freund wrote:
Fair enough. I am also working on a user of this infrastructure but that
doesn't help you very much. Steve Singer seemed to make some stabs at
writing an output plugin as well. Steve, how far did you get
On 13-01-24 11:15 AM, Steve Singer wrote:
On 13-01-24 06:40 AM, Andres Freund wrote:
Fair enough. I am also working on a user of this infrastructure but that
doesn't help you very much. Steve Singer seemed to make some stabs at
writing an output plugin as well. Steve, how far did you get
On 13-01-24 06:40 AM, Andres Freund wrote:
Fair enough. I am also working on a user of this infrastructure but that
doesn't help you very much. Steve Singer seemed to make some stabs at
writing an output plugin as well. Steve, how far did you get there?
I was able to get something
On 13-01-24 05:43 AM, Dimitri Fontaine wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Jan 21, 2013 at 12:27 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
- Context exposing and filtering
I'm not feeling very sanguine about any of this. I feel strongly that
we should try to
On 13-01-21 02:28 AM, Andres Freund wrote:
I haven't removed it from the patch afaik, so it would be great to get a
profile here! Its only for xlogdump, but that tool helped me immensely
and I don't want to maintain it independently...
Here is the output from tprof
Here is the baseline:
On 13-01-21 12:15 PM, Andres Freund wrote:
On 2013-01-21 11:59:18 -0500, Steve Singer wrote:
On 13-01-21 02:28 AM, Andres Freund wrote:
I haven't removed it from the patch afaik, so it would be great to get a
profile here! Its only for xlogdump, but that tool helped me immensely
and I don't
On 13-01-09 03:07 PM, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
Well, I *did* benchmark it as noted elsewhere in the thread, but thats
obviously just machine (E5520 x 2) with one rather restricted workload
(pgbench -S -jc 40 -T60). At least its rather palloc heavy.
Here are
On 13-01-14 08:38 PM, Andres Freund wrote:
Hi everyone,
Here is the newest version of logical changeset generation.
2) Currently the logical replication infrastructure assigns a 'slot-id'
when a new replica is setup. That slot id isn't really nice
(e.g. id-321578-3). It also requires that
The only animal in the buildfarm running AIX is grebe
(http://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=grebebr=HEAD)
It is likely that the server running this animal will go away sometime
this year and the machine replacing it isn't running AIX.
If someone else in the community is
On 12-12-12 06:20 AM, Andres Freund wrote:
Possible solutions:
1) INIT_LOGICAL_REPLICATION waits for an answer from the client that
confirms that logical replication initialization is finished. Before
that the walsender connection cannot be used for anything else.
2) we remove the snapshot as
On 12-12-11 06:52 PM, Andres Freund wrote:
Hi,
Problem 1:
One problem I see is that while exporting a snapshot solves the
visibility issues of the table's contents it does not protect against
schema changes. I am not sure whether thats a problem.
If somebody runs a CLUSTER or something
On 12-12-03 07:42 AM, Andres Freund wrote:
Two things:
1) Which exact options are you using for pg_receivellog? Not -d
replication by any chance?
Yes that is exactly what I'md doing. Using a real database name instead
makes this go away.
Thanks
This seems to produce exactly that kind off
On 12-12-03 09:48 AM, Andres Freund wrote:
On 2012-12-03 09:35:55 -0500, Steve Singer wrote:
On 12-12-03 07:42 AM, Andres Freund wrote:
Yes that is exactly what I'md doing. Using a real database name
instead makes this go away.
Was using replication an accident or do you think it makes sense
On 12-11-14 08:17 PM, Andres Freund wrote:
I am getting errors like the following when I try to use either your
test_decoding plugin or my own (which does even less than yours)
LOG: database system is ready to accept connections
LOG: autovacuum launcher started
WARNING: connecting to
First, you can add me to the list of people saying 'wow', I'm impressed.
The approach I am taking to reviewing this to try and answer the
following question
1) How might a future version of slony be able to use logical
replication as described by your patch and design documents
and what
On 12-11-18 11:07 AM, Andres Freund wrote:
Hi Steve!
I think we should provide some glue code to do this, otherwise people
will start replicating all the bugs I hacked into this... More
seriously: I think we should have support code here, no user will want
to learn the intracacies of feedback
On 12-11-14 08:17 PM, Andres Freund wrote:
For the regular satisfies routines this is needed in prepareation of logical
decoding. I changed the non-regular ones for consistency as well.
The naming between htup, tuple and similar is rather confused, I could not find
any consistent naming
On 12-10-15 04:51 PM, Andres Freund wrote:
Well, as a crosscheck, could you list your requirements?
Do you need anything more than outputting data in a format compatible to whats
stored in sl_log_*? You wouldn't have sl_actionseq, everything else should be
there (Well, you would need to do
On 12-10-11 06:27 PM, Josh Berkus wrote:
On 10/10/12 7:26 PM, Bruce Momjian wrote:
How does Slony write its changes without causing serialization replay
conflicts?
Since nobody from the Slony team answered this:
a) Slony replicates *rows*, not *statements*
True, but the proposed logical
On 12-07-24 01:48 PM, Robert Haas wrote:
I am running into a lot of customer situations where the customer
reports that canceling autovacuum task shows up in the logs, and
it's unclear whether this is happening often enough to matter, and
even more unclear what's causing it.
Could autovacuum
On 12-06-21 04:37 AM, Andres Freund wrote:
Hi Steve,
Thanks!
Attached is a detailed review of the patch.
Very good analysis, thanks!
Another reasons why we cannot easily do 1) is that subtransactions aren't
discernible from top-level transactions before the top-level commit happens,
we can
On 12-06-13 07:28 AM, Andres Freund wrote:
From: Andres Freundand...@anarazel.de
The individual changes need to be identified by an xid. The xid can be a
subtransaction or a toplevel one, at commit those can be reintegrated by doing
a k-way mergesort between the individual transaction.
On 12-06-18 07:30 AM, Andres Freund wrote:
Hrmpf #666. I will go through through the series commit-by-commit again to
make sure everything compiles again. Reordinging this late definitely wasn't a
good idea...
I pushed a rebased version with all those fixups (and removal of the
zeroRecPtr
On 12-06-18 11:50 AM, Andres Freund wrote:
Hi Simon,
I think we need to agree on the parameter name. It currently is
'multimaster_node_id'. In the discussion with Steve we got to
replication_node_id. I don't particularly like either.
Other suggestions?
Other things that come to mind (for
On 12-06-13 01:27 PM, Andres Freund wrote:
The previous mail contained a patch with a mismerge caused by reording
commits. Corrected version attached.
Thanks to Steve Singer for noticing this quickly.
Attached is a more complete review of this patch.
I agree that we will need to identify
On 12-06-15 04:03 PM, Robert Haas wrote:
On Thu, Jun 14, 2012 at 4:13 PM, Andres Freundand...@2ndquadrant.com wrote:
I don't plan to throw in loads of conflict resolution smarts. The aim is to get
to the place where all the infrastructure is there so that a MM solution can
be built by
On 12-06-13 07:27 AM, Andres Freund wrote:
Its also available in the 'cabal-rebasing' branch on
git.postgresql.org/users/andresfreund/postgres.git . That branch will modify
history though.
That branch has a merge error in f685a11ce43b9694cbe61ffa42e396c9fbc32b05
gcc -O2 -Wall
On 12-01-17 05:38 AM, Fujii Masao wrote:
On Fri, Jan 13, 2012 at 5:02 PM, Fujii Masaomasao.fu...@gmail.com wrote:
The amount of code changes to allow pg_basebackup to make a backup from
the standby seems to be small. So I ended up merging that changes and the
infrastructure patch. WIP patch
On 11-12-09 11:13 AM, Andrew Dunstan wrote:
Recently I attempted to build an external package (pg_bulkload)
against the latest Fedora packages. Unfortunately this fails, as pgxs
adds -lpgport to any link line for an executable, and the
corresponding libpgport.a isn't there. And in fact,
On 11-11-23 01:58 PM, Jan Urbański wrote:
On 20/11/11 19:14, Steve Singer wrote:
On 11-10-15 07:28 PM, Jan Urbański wrote:
Hi,
attached is a patch implementing the usage of SPI cursors in PL/Python.
Currently when trying to process a large table in PL/Python you have
slurp it all into memory
On 11-10-15 07:28 PM, Jan Urbański wrote:
Hi,
attached is a patch implementing the usage of SPI cursors in PL/Python.
Currently when trying to process a large table in PL/Python you have
slurp it all into memory (that's what plpy.execute does).
J
I found a few bugs (see my testing section
On 11-10-31 12:11 AM, Jun Ishiduka wrote:
Agreed. I'll extract FPW stuff from the patch that I submitted, and revise it
as the infrastructure patch.
The changes of pg_start_backup() etc that Ishiduka-san did are also
a server-side infrastructure. I will extract them as another infrastructure
On 11-11-09 06:35 PM, Tom Lane wrote:
Steve Singerssin...@ca.afilias.info writes:
I've tracked the issue down to collectSecLabels in pg_dump.c
SELECT label, provider, classoid, objoid, objsbid FROM
pg_catalog.pg_seclabel;
returns 0 rows.
The code in collectSecLabels() is not prepared
On 11-11-10 02:00 PM, Tom Lane wrote:
Steve Singerssin...@ca.afilias.info writes:
The man page for malloc on AIX is pretty clear on what happens when you
try to malloc 0 bytes. It returns NULL.
Yes, that's a pretty common behavior for malloc(0). It should not cause
a problem here AFAICS.
We have a cluster running 9.1.1 where pg_dump hangs when we try to dump
some a database inside of the cluster. The server is running AIX.
I can see this on clean cluster where we do an initdb, followed by a
createdb and try running pg_dump.
I've tracked the issue down to collectSecLabels in
On 11-10-25 02:44 AM, Heikki Linnakangas wrote:
With pg_basebackup, we have a fighting chance of getting this right,
because we have more control over how the backup is made. For example,
we can co-operate with the buffer manager to avoid torn-pages,
eliminating the need for
On 11-10-11 11:17 AM, Jun Ishiduka wrote:
Done.
Updated patch attached.
I have taken Jun's latest patch and applied it on top of Fujii's most
recent patch. I did some testing with the result but nothing theory
enough to stumble on any race conditions.
Some testing notes
On 11-09-26 10:56 PM, Fujii Masao wrote:
Looks weired. Though the WAL record starting from 0/6000298 was read
successfully, then re-fetch of the same record fails at the end of recovery.
One possible cause is the corruption of archived WAL file. What
restore_command on the standby and
On 11-09-22 09:24 AM, Fujii Masao wrote:
On Wed, Sep 21, 2011 at 11:50 AM, Fujii Masaomasao.fu...@gmail.com wrote:
2011/9/13 Jun Ishidukaishizuka@po.ntts.co.jp:
Update patch.
Changes:
* set 'on' full_page_writes by user (in document)
* read FROM: XX in backup_label (in xlog.c)
*
On 11-08-30 07:58 AM, Weiss, Wilfried wrote:
Hello,
I am just trying to compile postgresql-9.0.4 on AIX 6100-06-03-1048
using gcc 4.4.6.
Unfortunately that was not all.
There was also:
[Bug target/46072] AIX linker chokes on debug info for uninitialized
static variables
This is an IBM
The attached patch adds an option to the COPY command to skip writing
WAL when the following conditions are all met:
1) The table is empty (zero size on disk)
2) The copy command can obtain an access exclusive lock on the table
with out blocking.
3) The WAL isn't needed for replication
For
On 11-08-23 04:17 PM, Tom Lane wrote:
Robert Haasrobertmh...@gmail.com writes:
What I think would be really interesting is a way to make this work
when the table *isn't* empty. In other words, have a COPY option that
(1) takes an exclusive lock on the table, (2) writes the data being
inserted
On 11-08-16 02:09 AM, Jun Ishiduka wrote:
Thanks.
This has the following two problems.
* pg_start_backup() must set 'on' to full_page_writes of the master that
is actual writing of the WAL, but not the standby.
Is there any way to tell from the WAL segments if they contain the full
On 11-08-15 10:00 AM, Peter Geoghegan wrote:
Without commenting on what should be done in your specific case, I
wonder whether it's time to fully retire the deprecated double
representation of timestamps. Is anyone actually expected to rely on
their availability when 9.2 is released? This also
On 11-08-15 12:33 PM, Peter Geoghegan wrote:
On 15 August 2011 16:56, Steve Singerssin...@ca.afilias.info wrote:
This would mean that anyone using the floating point timestamps today won't
be able to use pg_upgrade to upgrade to whichever version we remove them
from. 8.3 had float based
On 11-07-07 09:22 PM, Jun Ishiduka wrote:
As you proposed, adding new field which stores the backup end location
taken from minRecoveryPoint, into pg_control sounds good idea.
Update patch.
Here is a review of the updated patch
This version of the patch adds a field into pg_controldata that
On 11-06-28 02:14 PM, Martin Pihlak wrote:
Thanks for the review!
I have since simplified the patch to assume that partial SSL writes are
disabled -- according to SSL_write(3) this is the default behaviour.
Now the SSL retry buffer only holds the data to be retried, the
remainder is moved to the
On 11-06-28 02:14 PM, Martin Pihlak wrote:
Hmm, I thought I thought about that. There was a check in the original
patch: if (conn-sslRetryBytes || (conn-outCount - remaining) 0)
So if the SSL retry buffer was emptied it would return 1 if there was
something left in the regular output buffer.
On 11-06-28 01:52 AM, Jun Ishiduka wrote:
Considering everything that has been discussed on this thread so far.
Do you still think your patch is the best way to accomplish base backups
from standby servers?
If not what changes do you think should be made?
I reconsider the way to not use
On 11-06-24 12:41 AM, Jun Ishiduka wrote:
The logic that not use pg_stop_backup() would be difficult,
because pg_stop_backup() is used to identify minRecoveryPoint.
Considering everything that has been discussed on this thread so far.
Do you still think your patch is the best way to
On 11-06-15 03:20 PM, Martin Pihlak wrote:
Yes, that sounds like a good idea -- especially considering that COPY
is not the only operation that can cause SSL_write retries.
This is of course still work in progress, needs cleaning up and
definitely more testing. But at this point before going
On 11-06-23 02:41 AM, Jun Ishiduka wrote:
I receive this mail, so I notice I do wrong recognition to what
Heikki is proposing.
my recognition:
Before:
* I thought Heikki proposes, Execute SQL(pg_start_backup('x'); copy
the data directory and pg_stop_backup();) from the standby
On 11-06-20 03:44 PM, Pavel Stehule wrote:
Hello
You need to update config.sgml at the same time you update this format.
You need to append a , after application name but before constraintName.
As it stands the CSV log has something like:
.nbtinsert.c:433,psqla_pkey,public,a,a
fixed
On 11-06-14 02:52 AM, Jun Ishiduka wrote:
I still think that's headed in the wrong direction.
(http://archives.postgresql.org/pgsql-hackers/2011-05/msg01405.php)
Please check these mails, and teach the reason for content of the wrong
direction.
On Sun, 19 Jun 2011, Pavel Stehule wrote:
Maybe there is second issue (little bit - performance - you have to
call a output function), But I agree, so this information is very
interesting and can help.
I am concerned about the performance impact of doing that. Not all
constraints are on
.
Everything I've mentioned above is a minor issue, I will move the patch
to 'waiting for author' and wait for you to release an updated patch.
Steve Singer
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
On 11-06-18 06:36 PM, Steve Singer wrote:
On 11-06-08 04:14 PM, Pavel Stehule wrote:
Here is my review of this patch
Submission Review:
The patch applies cleanly against master
The patch does not include any documentation updates (see note below
to update config.sgml
On 11-06-01 09:30 AM, Christopher Browne wrote:
On Wed, Jun 1, 2011 at 8:29 AM, Dave Pagedp...@pgadmin.org wrote:
On Wed, Jun 1, 2011 at 12:27 PM, Andrew Dunstanand...@dunslane.net wrote:
The whole point of the revamp was that pg_listener was a major performance
bottleneck and needed to go,
On 11-05-27 12:35 PM, Tom Lane wrote:
grebe, which is also a PPC64 machine, isn't showing the bug. And I just
failed to reproduce the problem on a RHEL6 PPC64 box. About to go try
it on RHEL5, which has a gcc version much closer to what wombat says
it's using, but I'm not very hopeful about
On 11-04-25 03:40 PM, Robert Haas wrote:
At the risk of getting a bit cranky, you haven't participated in a
material way in any CommitFest we've had in well over a year. AFAICS,
the first, last, and only time you are listed in the CommitFest
application is as co-reviewer of a patch in July
I'm getting JDBC exceptions when I try to connect to 9.1 (master) with
the postgresql-9.0-801.jdbc3.jar I don't have this issue with 9.0.
There is nothing obvious at http://jdbc.postgresql.org or in the 9.1
alpha release notes that indicate a newer JDBC driver will be required.
Have other
On 11-04-18 09:44 AM, Tom Lane wrote:
Steve Singerssin...@ca.afilias.info writes:
I'm getting JDBC exceptions when I try to connect to 9.1 (master) with
the postgresql-9.0-801.jdbc3.jar I don't have this issue with 9.0.
Hmm, what shows up in the postmaster log?
On 11-02-12 05:58 AM, Jan Urbański wrote:
On 11/02/11 10:53, Jan Urbański wrote:
On 10/02/11 22:26, Steve Singer wrote:
Here's an updated patch with documentation. It's an incremental patch on
top of the latest explicit-subxacts version.
This looks fine. I've attached a one word
On 11-02-10 05:20 AM, Jan Urbański wrote:
D'oh, I was thinking about whether it's safe to skip the internal
subxact if you're in an implicit one and somehow I always convinced
myself that since you eventually close the explicit one, it is.
Obviously my testing wasn't enough :( Attaching an
On 11-02-10 10:13 AM, Robert Haas wrote:
On Tue, Feb 1, 2011 at 1:33 PM, Robert Haasrobertmh...@gmail.com wrote:
On Tue, Feb 1, 2011 at 1:09 PM, Peter Eisentrautpete...@gmx.net wrote:
On tis, 2011-01-18 at 19:24 -0500, Steve Singer wrote:
However if I connect with a line in pg_hba
On 11-02-10 10:32 AM, Robert Haas wrote:
I was assuming those changes were sufficiently trivial that they could
be made at commit-time, especially if Peter is committing it himself.
Of course if he'd like a re-review, he can always post an updated
patch, but I just thought that was overly
On 11-02-10 03:13 PM, Jan Urbański wrote:
On 10/02/11 20:24, Peter Eisentraut wrote:
Here is the rest of my review.
Submission Review
---
Patch applies cleanly.
Documentation is still outstanding but Jan has promised it soon.
Usability Review
---
We don't
On 11-02-09 05:22 PM, Peter Eisentraut wrote:
On tis, 2011-02-08 at 00:32 -0500, Steve Singer wrote:
On 11-02-06 11:40 AM, Jan Urbański wrote:
PFA an updated patch with documentation.
Yeah, changed them.
Those changes look fine. The tests now pass.
I've attached a new version of the patch
On 11-02-08 10:07 AM, Jan Urbański wrote:
* custom SPI exceptions - I'd really like this one to go in, because it
allows writing UPSERT-kind functions in PL/Python very easily, and it's
just a handful of lines of code
I will try to do a review of this one (probably tomorrow night) since
On 11-02-07 10:37 PM, Robert Haas wrote:
- The PL/python extravaganza. I'm not really clear where we stand
with this. There are a lot of patches here.
Some of the patches have been committed a few others are ready (or
almost ready) for a committer. The table function one is the only
On 11-02-06 11:40 AM, Jan Urbański wrote:
PFA an updated patch with documentation.
Yeah, changed them.
Those changes look fine. The tests now pass.
I've attached a new version of the patch that fixes a few typos/wording
issues I saw in the documentation. I also changed the link to the
On 11-01-27 05:11 PM, Jan Urbański wrote:
On 23/12/10 15:32, Jan Urbański wrote:
Here's a patch implementing explicitly starting subtransactions mentioned in
http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php. It's
an incremental patch on top of the spi-in-subxacts patch sent
On 11-01-27 04:33 PM, Jan Urbański wrote:
Right, without the patch you can never catch errors originating from
plpy.execute, so any error terminates the whole function, and so rolls
back the statement. FWIW PL/Perl works the same:
begin;
create table foo(i int primary key);
DO $$
On 11-01-29 03:39 PM, Jan Urbański wrote:
D'oh, you're right, thanks. Attached patch with fix. Curiosly, right now
in master your example with plpy.prepare will result in savepoint
being swallowed, but it's of course better to react with an error.
Cheers,
Jan
This seems to fix it.
You
On 10-12-23 08:45 AM, Jan Urbański wrote:
Here's a patch implementing a executing SPI in an subtransaction
mentioned in
http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php. It's
an incremental patch on top of the plpython-refactor patch sent eariler.
Git branch for this patch:
Here is my review for this patch
Submission Review
-Patch applies cleanly
-Patch does not include documentation changes. At a minimum: update the
table that lists what pg_stat_activity and pg_stat_replication includes
in monitoring.sgml but I propose more below.
-No
-
I wasn't able to find any issues in my testing
I'm marking this as returned with feedback pending your answer on the
possible memory leak above but I think the patch is very close to being
ready.
Steve Singer
diff --git a/doc/src/sgml/ref/alter_table.sgml b/doc/src/sgml/ref/alter_table.sgml
On 10-12-06 09:00 PM, Josh Berkus wrote:
Steve,
If you tell me which options to pgbench and which .conf file settings
you'd like to see I can probably arrange to run some tests on AIX.
Compile and run test_fsync in PGSRC/src/tools/fsync.
Attached are runs against two different disk
On 10-12-06 06:56 PM, Greg Smith wrote:
Tom Lane wrote:
The various testing that's been reported so far is all for
Linux and thus doesn't directly address the question of whether other
kernels will have similar performance properties.
Survey of some popular platforms:
snip
So my guess is
On 10-11-22 03:24 PM, Steve Singer wrote:
On 10-11-22 09:37 AM, Gurjeet Singh wrote:
On Sat, Nov 20, 2010 at 9:00 AM, Steve Singer ssinger...@sympatico.ca
Almost fixed.
I still get an unexpected difference.
! DETAIL: cannot create PRIMARY KEY/UNIQUE constraint with a non-unique
index
On 10-11-22 09:37 AM, Gurjeet Singh wrote:
On Sat, Nov 20, 2010 at 9:00 AM, Steve Singer ssinger...@sympatico.ca
mailto:ssinger...@sympatico.ca wrote:
Submission Review:
Tests
The expected output for the regression tests you added don't
On 10-11-07 01:54 PM, Gurjeet Singh wrote:
Attached is the patch that extends the same feature for UNIQUE indexes.
It also includes some doc changes for the ALTER TABLE command, but I
could not verify the resulting changes since I don't have the
doc-building infrastructure installed.
Regards,
On 10-11-17 03:00 PM, Marc Cousin wrote:
The Wednesday 17 November 2010 19:41:19, Tom Lane wrote :
Marc Cousincousinm...@gmail.com writes:
- Does the feature work as advertised?
Yes. It works consistently, isn't fooled by savepoints or multiple
serials in a table, or concurrent transactions
The attached patch modifies TRUNCATE ... RESTART IDENTITY so that if the
transaction rolls back the restart of the sequence will also be rolled back.
It follows the general outline discussed at
http://archives.postgresql.org/pgsql-hackers/2008-05/msg00550.php of
assigning a new reffilenode to
On Sun, 10 Oct 2010, Marko Tiikkaja wrote:
On 2010-10-07 5:21 AM +0300, Steve Singer wrote:
Since no one else has proposed a better idea and the commit fest is ticking
away I think you should go ahead and do that.
Here's a new version of the patch, deprecating pg_parse_and_rewrite.
I
On 10-10-07 05:52 AM, Fujii Masao wrote:
On Wed, Oct 6, 2010 at 4:06 PM, Simon Riggssi...@2ndquadrant.com wrote:
The problem is how much WAL is stored on (any) node. Currently that is
wal_keep_segments, which doesn't work very well, but I've seen no better
ideas that cover all important cases.
101 - 200 of 223 matches
Mail list logo
