On Tue, Jan 31, 2012 at 7:43 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
That seems like a pretty marginal gain. If you're bound by the speed of
fsyncs, this will reduce the latency by the time it takes to mark the clog,
which is tiny in comparison to all the other stuff
On 27.01.2012 15:48, Pavel Stehule wrote:
2012/1/26 Abhijit Menon-Sena...@toroid.org:
Updated patch attached. Ready for committer.
I found a small issue - there was uninitialized fn_signature for
online blocks so I append line
function-fn_signature = pstrdup(func_name); to
Hi,
I Disabled autovacuuming and the warnings stopped logging.
After enabling Autovacuuming, the warnings again started logging.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/pgstat-wait-timeout-tp5078125p5444033.html
Sent from the PostgreSQL - hackers mailing list
On 2012-01-30 19:19, Robert Haas wrote:
On Sun, Jan 29, 2012 at 7:27 AM, Kohei KaiGaikai...@kaigai.gr.jp wrote:
However, I also assume one other possible use-case; the originator
has privileges to translate 10 of different domains, but disallows to
revert it. In this case, RESET without
Le 30/01/2012 22:14, Euler Taveira de Oliveira a écrit :
On 30-01-2012 15:33, Gilles Darold wrote:
Yesterday I was facing a little issue with a backup software (NetBackup)
that do not report error when a post backup script is run. The problem
is that this script execute pg_stop_backup() and if
On Mon, Jan 30, 2012 at 11:18:31PM -0500, Tom Lane wrote:
I don't recall that we thought very hard about what should happen when
pg_dump switches are used to produce a selective dump, but ISTM
reasonable that if it's user data then it should be dumped only if
data in a regular user table would
On Mon, Jan 30, 2012 at 11:18 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I don't recall that we thought very hard about what should happen when
pg_dump switches are used to produce a selective dump, but ISTM
reasonable that if it's user data then it should be dumped only if
data in a regular user
On Tue, Jan 31, 2012 at 4:36 AM, Yeb Havinga yebhavi...@gmail.com wrote:
What about always allowing a transition to the default / postgresql.conf
configured client label, so in the case of errors, or RESET, the transition
to this domain is hardcoded to succeed. This would also be useful in
On Mon, Jan 30, 2012 at 6:48 PM, Noah Misch n...@leadboat.com wrote:
On Tue, Jan 24, 2012 at 03:47:16PM -0300, Alvaro Herrera wrote:
The biggest item remaining is the point you raised about multixactid
wraparound. This is closely related to multixact truncation and the way
checkpoints are to
On Tue, Jan 31, 2012 at 12:55 AM, Joachim Wieland j...@mcknight.de wrote:
On Mon, Jan 30, 2012 at 12:20 PM, Robert Haas robertmh...@gmail.com wrote:
But the immediate problem is that pg_dump.c is heavily reliant on
global variables, which isn't going to fly if we want this code to use
threads
On 2012-01-31 14:06, Robert Haas wrote:
On Tue, Jan 31, 2012 at 4:36 AM, Yeb Havingayebhavi...@gmail.com wrote:
What about always allowing a transition to the default / postgresql.conf
configured client label, so in the case of errors, or RESET, the transition
to this domain is hardcoded to
On Tue, Jan 31, 2012 at 3:02 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Tue, Jan 31, 2012 at 7:43 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
That seems like a pretty marginal gain. If you're bound by the speed of
fsyncs, this will reduce the latency by the time it
On Tue, Jan 31, 2012 at 9:10 AM, Yeb Havinga yebhavi...@gmail.com wrote:
On 2012-01-31 14:06, Robert Haas wrote:
On Tue, Jan 31, 2012 at 4:36 AM, Yeb Havingayebhavi...@gmail.com wrote:
What about always allowing a transition to the default / postgresql.conf
configured client label, so in the
On Mon, Jan 30, 2012 at 9:37 AM, Andrew Dunstan and...@dunslane.net wrote:
On 01/30/2012 09:54 AM, Abhijit Menon-Sen wrote:
At 2012-01-27 09:47:05 +0530, a...@toroid.org wrote:
I've started reviewing this patch, but it'll take me a bit longer to go
through json.c properly.
OK, I finished
On 31 January 2012 14:24, Robert Haas robertmh...@gmail.com wrote:
I think you're trying to muddy the waters. Heikki's implementation
was different than yours, and there are some things about it I'm not
100% thrilled with, but it's fundamentally the same concept. The new
idea you're
Excerpts from Robert Haas's message of mar ene 31 10:17:40 -0300 2012:
I suspect you are right that it is unlikely, but OTOH that sounds like
an extremely painful recovery procedure. We probably don't need to
put a ton of thought into handling this case as efficiently as
possible, but I
On 2012-01-31 15:28, Robert Haas wrote:
*scratches head*
I'm not sure I follow you. If you're saying that we can make this
work by always allowing the value to be reset, then I agree with you,
but I'm not sure those are the semantics KaiGai wants. For instance,
if a connection pooler does:
Hi Robert,
sorry for the delay.
Il 27/01/12 15:47, Robert Haas ha scritto:
This email thread seems to have trailed off without reaching a
conclusion. The patch is marked as Waiting on Author in the CommitFest
application, but I'm not sure that's accurate. Can we try to nail this
down?
Here
Hi Alvaro,
Il 27/01/12 23:55, Alvaro Herrera ha scritto:
If you do that, please make sure you use two complete separate strings
instead of building one from spare parts. This bit is missing the _()
stuff though.
Currently pg_archivecleanup does not comply with localisation standards.
I can
On Fri, Jan 20, 2012 at 11:11 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 20.01.2012 15:32, Robert Haas wrote:
On Sat, Jan 14, 2012 at 9:32 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Here's another version of the patch to make XLogInsert less
On 01/30/2012 11:18 PM, Tom Lane wrote:
[ example showing pg_dump's odd behavior for extension config tables ]
[ traces through that with gdb... ]
As I suspected, the behavioral change from 9.1 to HEAD is not
intentional. It is an artifact of commit
7b070e896ca835318c90b02c830a5c4844413b64,
Hi Noah,
Il 21/01/12 21:42, Noah Misch ha scritto:
On Sat, Jan 14, 2012 at 08:18:48PM +0100, Marco Nenciarini wrote:
I greatly like that name; it would still make sense for other
aggregate types, should we ever expand its use. Please complete the
name change: the documentation, catalog
Excerpts from Gabriele Bartolini's message of mar ene 31 12:31:58 -0300 2012:
Hi Alvaro,
Il 27/01/12 23:55, Alvaro Herrera ha scritto:
If you do that, please make sure you use two complete separate strings
instead of building one from spare parts. This bit is missing the _()
stuff
On Tue, Jan 31, 2012 at 9:19 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of mar ene 31 10:17:40 -0300 2012:
I suspect you are right that it is unlikely, but OTOH that sounds like
an extremely painful recovery procedure. We probably don't need to
Excerpts from Robert Haas's message of mar ene 31 13:18:30 -0300 2012:
On Tue, Jan 31, 2012 at 9:19 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of mar ene 31 10:17:40 -0300 2012:
I suspect you are right that it is unlikely, but OTOH that sounds
On Mon, Jan 23, 2012 at 3:20 PM, Peter Eisentraut pete...@gmx.net wrote:
On sön, 2012-01-22 at 11:43 -0500, Andrew Dunstan wrote:
Actually, given recent discussion I think that test should just be
removed from json.c. We don't actually have any test that the code
point is valid (e.g. that it
On Mon, Jan 09, 2012 at 08:23:59PM +0200, Peter Eisentraut wrote:
On mån, 2012-01-02 at 06:43 +0200, Peter Eisentraut wrote:
I figured the best and most flexible way to address this is to export
acldefault() as an SQL function and replace
aclexplode(proacl)
with
On Tue, Jan 31, 2012 at 11:58 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Well, we're already storing a multixact in Xmax, so it's not like we
don't assume that we can store multis in space normally reserved for
Xids. What I've been wondering is not how ugly it is, but rather of the
On Sun, Jan 29, 2012 at 2:47 AM, Dean Rasheed dean.a.rash...@gmail.com wrote:
Given a freshly created table (not vacuumed), and a query that uses an
index-only scan, for example:
CREATE TABLE foo(a int PRIMARY KEY);
INSERT INTO foo SELECT * FROM generate_series(1,100);
ANALYSE foo;
Hello,
I've run into a very odd issue calling C++ code that uses exceptions from
within our PostgreSQL FDW. Specifically, we have broken our FDW into two
components, a C layer that looks quite similar to the FDW for text files and a
C++ layer that is called into by the C layer to interface
On 01/30/2012 10:37 AM, Andrew Dunstan wrote:
Aside: is query_to_json really necessary? It seems rather ugly and
easily avoidable using row_to_json.
I started with this, again by analogy with query_to_xml(). But I agree
it's a bit ugly. If we're not going to do it, then we definitely
On 23 November 2011 02:49, Robert Haas robertmh...@gmail.com wrote:
There is no sort of systematic labeling of error messages in the log
to enable the DBA to figure out that the first error message is likely
nothing more serious than an integrity constraint doing its bit to
preserve data
Andrew,
based on Abhijit's feeling and some discussion offline, the consensus
seems to be to remove query_to_json.
If we do that, what would getting complete query results back from a
query look like? It's important to make this as simple for developers
as possible.
--
Josh Berkus
Attached is a test case reduced from a real application. There is a
table with an index on a function written in PL/Python. There is a
second PL/Python function that executes an INSERT into the table,
causing an index update. If the function used by the index fails, we
get an error message with
At 2012-01-31 12:04:31 -0500, robertmh...@gmail.com wrote:
That fails to answer the question of what we ought to do if we get an
invalid sequence there.
I think it's best to categorically reject invalid surrogates as early as
possible, considering the number of bugs that are related to them
On Tue, Jan 31, 2012 at 12:15 PM, Josh Berkus j...@agliodbs.com wrote:
Andrew,
based on Abhijit's feeling and some discussion offline, the consensus
seems to be to remove query_to_json.
If we do that, what would getting complete query results back from a
query look like? It's important to
On Mon, Jan 30, 2012 at 6:04 PM, Soules, Craig craig.sou...@hp.com wrote:
When there are no errors everything works flawlessly, however, we noticed
that even throwing an exception in the C++ layer was causing an immediate
segmentation fault. Even when encapsulated in a try { } catch(...) { }
On 01/31/2012 01:32 PM, Merlin Moncure wrote:
On Tue, Jan 31, 2012 at 12:15 PM, Josh Berkusj...@agliodbs.com wrote:
Andrew,
based on Abhijit's feeling and some discussion offline, the consensus
seems to be to remove query_to_json.
If we do that, what would getting complete query results
On 30 January 2012 23:04, Soules, Craig craig.sou...@hp.com wrote:
When there are no errors everything works flawlessly, however, we noticed
that even throwing an exception in the C++ layer was causing an immediate
segmentation fault. Even when encapsulated in a try { } catch(...) { } block.
2012/1/29 Kohei KaiGai kai...@kaigai.gr.jp:
Remote SQL: DECLARE pgsql_fdw_cursor_0 SCROLL CURSOR FOR SELECT
a, b FROM public.t1 WHERE (a 2)
(3 rows)
Shouldn't we be using protocol-level cursors rather than SQL-level cursors?
[Design comment]
When BEGIN should be issued on the
On Tuesday, January 31, 2012 07:52:52 PM Peter Geoghegan wrote:
On 30 January 2012 23:04, Soules, Craig craig.sou...@hp.com wrote:
When there are no errors everything works flawlessly, however, we noticed
that even throwing an exception in the C++ layer was causing an
immediate segmentation
On 31 January 2012 17:35, Robert Haas robertmh...@gmail.com wrote:
On Sun, Jan 29, 2012 at 2:47 AM, Dean Rasheed dean.a.rash...@gmail.com
wrote:
Given a freshly created table (not vacuumed), and a query that uses an
index-only scan, for example:
CREATE TABLE foo(a int PRIMARY KEY);
INSERT
On 31 January 2012 19:01, Andres Freund and...@anarazel.de wrote:
I suggest that you generalise from the example of PLV8. The basic
problem is that the effect of longjmp()ing over an area of the stack
with a C++ non-POD type is undefined. I don't think you can even use
structs, as they have
On Fri, Jan 27, 2012 at 3:33 PM, Peter Geoghegan pe...@2ndquadrant.com wrote:
Patch is attached. I have not changed the duplicate functions. This is
because I concluded that it was the lesser of two evils to have to get
the template to generate both declarations in the header file, and
On Tue, Jan 31, 2012 at 12:48 PM, Andrew Dunstan and...@dunslane.net wrote:
On 01/31/2012 01:32 PM, Merlin Moncure wrote:
On Tue, Jan 31, 2012 at 12:15 PM, Josh Berkusj...@agliodbs.com wrote:
Andrew,
based on Abhijit's feeling and some discussion offline, the consensus
seems to be to
On Tue, Jan 31, 2012 at 2:15 PM, Dean Rasheed dean.a.rash...@gmail.com wrote:
In the case when we're asked to clear a bit, it would first try to pin
the relevant page, which would go through vm_readbuf() with extend set
to true. Then vm_extend() would notice that the visibility map had
already
On Mon, Jan 30, 2012 at 11:18:31PM -0500, Tom Lane wrote:
I don't recall that we thought very hard about what should happen when
pg_dump switches are used to produce a selective dump, but ISTM
reasonable that if it's user data then it should be dumped only if
data in a regular user table would
On 01/31/2012 02:49 PM, Merlin Moncure wrote:
The major hole in functionality I see for heavy json users is the
reverse; how do you get json back into the database? With xml, at
least you could (ab)use xpath for that...with json you have to rely on
add-on support and/or ad hoc string parsing
On 01/31/2012 03:02 PM, Martijn van Oosterhout wrote:
On Mon, Jan 30, 2012 at 11:18:31PM -0500, Tom Lane wrote:
I don't recall that we thought very hard about what should happen when
pg_dump switches are used to produce a selective dump, but ISTM
reasonable that if it's user data then it
On Tue, Jan 31, 2012 at 1:29 PM, Abhijit Menon-Sen a...@toroid.org wrote:
At 2012-01-31 12:04:31 -0500, robertmh...@gmail.com wrote:
That fails to answer the question of what we ought to do if we get an
invalid sequence there.
I think it's best to categorically reject invalid surrogates as
Robert Haas robertmh...@gmail.com writes:
and that's bad. More generally, the system security policy is
designed to answer questions about whether it's OK to transition from
A-B, and the fact that A-B is OK does not mean that B-A is OK, but
our GUC mechanism pretty much forces you to
On Tue, Jan 31, 2012 at 9:05 AM, Robert Haas robertmh...@gmail.com wrote:
And just for added fun and excitement, they all have inconsistent
naming conventions and inadequate documentation.
I think if we need more refactoring in order to support multiple
database connections, we should go do
Peter Eisentraut pete...@gmx.net writes:
Any ideas whether we could make this happen?
Presumably you could do it by setting up an error context stack entry
within FormIndexDatum. I'd want to be convinced that there was no
performance hit, but if you were to do it only in the expression-column
On 31 January 2012 19:49, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jan 31, 2012 at 2:15 PM, Dean Rasheed dean.a.rash...@gmail.com
wrote:
In the case when we're asked to clear a bit, it would first try to pin
the relevant page, which would go through vm_readbuf() with extend set
to
On 01/31/2012 04:36 AM, Robert Haas wrote:
On Mon, Jan 30, 2012 at 11:18 PM, Tom Lanet...@sss.pgh.pa.us wrote:
I don't recall that we thought very hard about what should happen when
pg_dump switches are used to produce a selective dump, but ISTM
reasonable that if it's user data then it should
Andrew Dunstan and...@dunslane.net writes:
On 01/30/2012 11:18 PM, Tom Lane wrote:
As I suspected, the behavioral change from 9.1 to HEAD is not
intentional. It is an artifact of commit
7b070e896ca835318c90b02c830a5c4844413b64, which is almost, but not
quite, entirely broken. I won't
Dean Rasheed dean.a.rash...@gmail.com writes:
The thing I'm unsure about is whether sending sinval
messages when the visibility map is extended is a good idea.
Seems perfectly reasonable to me. They'd occur so seldom as to be
more than repaid if we can scrape some cost out of the mainline
Adrian Klaver adrian.kla...@gmail.com writes:
On 01/31/2012 04:36 AM, Robert Haas wrote:
On Mon, Jan 30, 2012 at 11:18 PM, Tom Lanet...@sss.pgh.pa.us wrote:
What's not apparent to me is whether there's an argument for doing more
than that. It strikes me that the current design is not very
Daniel Farina dan...@heroku.com writes:
On Tue, Jan 17, 2012 at 2:14 AM, Daniel Farina dan...@heroku.com wrote:
See the attached patch. It has a detailed cover letter/comment at the
top of the file.
I have amended that description to be more accurate.
I looked at this a bit, and it seems to
On Mon, Jan 30, 2012 at 12:24 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Jan 27, 2012 at 8:21 PM, Jeff Janes jeff.ja...@gmail.com wrote:
On Fri, Jan 27, 2012 at 3:16 PM, Merlin Moncure mmonc...@gmail.com wrote:
On Fri, Jan 27, 2012 at 4:05 PM, Jeff Janes jeff.ja...@gmail.com wrote:
On Sun, Jan 29, 2012 at 5:01 PM, Simon Riggs si...@2ndquadrant.com wrote:
I can't see any way that situation can occur. The patch *explicitly*
waits until all people that can see the index as usable have dropped
their lock. So I don't think this is necessary. Having said that,
since we are
On 01/31/2012 05:48 PM, Tom Lane wrote:
Andrew Dunstanand...@dunslane.net writes:
On 01/30/2012 11:18 PM, Tom Lane wrote:
As I suspected, the behavioral change from 9.1 to HEAD is not
intentional. It is an artifact of commit
7b070e896ca835318c90b02c830a5c4844413b64, which is almost, but
On 01/31/2012 01:48 PM, Andrew Dunstan wrote:
On 01/31/2012 01:32 PM, Merlin Moncure wrote:
On Tue, Jan 31, 2012 at 12:15 PM, Josh Berkusj...@agliodbs.com wrote:
Andrew,
based on Abhijit's feeling and some discussion offline, the consensus
seems to be to remove query_to_json.
If we do
Hello
I looked to sources and I found a some useful routines for people who
write extensions and probably PL too.
There are datum_compute_size and datum_write from range_types.c. These
routines can be used in PL libs and maybe in other places.
Should be these routines moved to varlena.c and be
Pavel Stehule pavel.steh...@gmail.com writes:
I looked to sources and I found a some useful routines for people who
write extensions and probably PL too.
There are datum_compute_size and datum_write from range_types.c. These
routines can be used in PL libs and maybe in other places.
Should
2012/2/1 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
I looked to sources and I found a some useful routines for people who
write extensions and probably PL too.
There are datum_compute_size and datum_write from range_types.c. These
routines can be used in PL
66 matches
Mail list logo
