2012/2/1 Tom Lane :
> Pavel Stehule 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.
>
Pavel Stehule 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 be these routines m
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 p
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 Berkus 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 g
On 01/31/2012 05:48 PM, Tom Lane wrote:
Andrew Dunstan 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 br
On Sun, Jan 29, 2012 at 5:01 PM, Simon Riggs 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 talking about the ind
On Mon, Jan 30, 2012 at 12:24 PM, Robert Haas wrote:
> On Fri, Jan 27, 2012 at 8:21 PM, Jeff Janes wrote:
>> On Fri, Jan 27, 2012 at 3:16 PM, Merlin Moncure wrote:
>>> On Fri, Jan 27, 2012 at 4:05 PM, Jeff Janes wrote:
Also, I think the general approach is wrong. The only reason to have
>
Daniel Farina writes:
> On Tue, Jan 17, 2012 at 2:14 AM, Daniel Farina 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 go considerably further than
Adrian Klaver writes:
> On 01/31/2012 04:36 AM, Robert Haas wrote:
>> On Mon, Jan 30, 2012 at 11:18 PM, Tom Lane 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 friendly
>>> towards the idea of an
Dean Rasheed 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 paths.
The real objection
Andrew Dunstan 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 enumerate its sho
On 01/31/2012 04:36 AM, Robert Haas wrote:
On Mon, Jan 30, 2012 at 11:18 PM, 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 i
On 31 January 2012 19:49, Robert Haas wrote:
> On Tue, Jan 31, 2012 at 2:15 PM, Dean Rasheed
> 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
Peter Eisentraut 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
code path that w
On Tue, Jan 31, 2012 at 9:05 AM, Robert Haas 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 that refactoring.
Robert Haas 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 allow both of those
On Tue, Jan 31, 2012 at 1:29 PM, Abhijit Menon-Sen 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 early as
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 sho
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 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
On Tue, Jan 31, 2012 at 2:15 PM, Dean Rasheed 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 been extended, and i
On Tue, Jan 31, 2012 at 12: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 Berkus wrote:
>>>
>>> Andrew,
>>>
based on Abhijit's feeling and some discussion offline, the consensus
seems to be to remove query_to_json.
On Fri, Jan 27, 2012 at 3:33 PM, Peter Geoghegan 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
> definitions in the .c fil
On 31 January 2012 19:01, Andres Freund 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 implicit dest
On 31 January 2012 17:35, Robert Haas wrote:
> On Sun, Jan 29, 2012 at 2:47 AM, Dean Rasheed
> 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_se
On Tuesday, January 31, 2012 07:52:52 PM Peter Geoghegan wrote:
> On 30 January 2012 23:04, Soules, Craig 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
2012/1/29 Kohei KaiGai :
> 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 remote-side?
> The c
On 30 January 2012 23:04, Soules, Craig 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.
>
> If anyone ha
On 01/31/2012 01:32 PM, Merlin Moncure wrote:
On Tue, Jan 31, 2012 at 12:15 PM, Josh Berkus 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 l
On Mon, Jan 30, 2012 at 6:04 PM, Soules, Craig 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.
Stack ba
On Tue, Jan 31, 2012 at 12:15 PM, Josh Berkus 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 make this
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
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
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
PostgreS
On 23 November 2011 02:49, Robert Haas 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 integrity, while the se
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 nee
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 wit
On Sun, Jan 29, 2012 at 2:47 AM, Dean Rasheed 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;
>
> EXPLAIN ANALYSE SELE
On Tue, Jan 31, 2012 at 11:58 AM, Alvaro Herrera
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
> fact that we're bloatin
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
>> aclexplo
On Mon, Jan 23, 2012 at 3:20 PM, Peter Eisentraut 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 doesn't re
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
> 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 extre
On Tue, Jan 31, 2012 at 9:19 AM, Alvaro Herrera
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
>> put a ton of thought i
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 _()
> > s
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 entries
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, w
On Fri, Jan 20, 2012 at 11:11 PM, Heikki Linnakangas
wrote:
> On 20.01.2012 15:32, Robert Haas wrote:
>>
>> On Sat, Jan 14, 2012 at 9:32 AM, Heikki Linnakangas
>> wrote:
>>>
>>> Here's another version of the patch to make XLogInsert less of a
>>> bottleneck
>>> on multi-CPU systems. The basic id
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 pu
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 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:
S
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 31 January 2012 14:24, Robert Haas 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 describing here is somethi
On Mon, Jan 30, 2012 at 9:37 AM, Andrew Dunstan 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 rea
On Tue, Jan 31, 2012 at 9:10 AM, Yeb Havinga wrote:
> On 2012-01-31 14:06, Robert Haas wrote:
>> On Tue, Jan 31, 2012 at 4:36 AM, Yeb Havinga wrote:
>>>
>>> What about always allowing a transition to the default / postgresql.conf
>>> configured client label, so in the case of errors, or RESET, th
On Tue, Jan 31, 2012 at 3:02 AM, Simon Riggs wrote:
> On Tue, Jan 31, 2012 at 7:43 AM, Heikki Linnakangas
> 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 compar
On 2012-01-31 14:06, Robert Haas wrote:
On Tue, Jan 31, 2012 at 4:36 AM, Yeb Havinga 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 als
On Tue, Jan 31, 2012 at 12:55 AM, Joachim Wieland wrote:
> On Mon, Jan 30, 2012 at 12:20 PM, Robert Haas 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 Windows (or anywhere else).
On Mon, Jan 30, 2012 at 6:48 PM, Noah Misch 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 be handled.
On Tue, Jan 31, 2012 at 4:36 AM, Yeb Havinga 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
> conjunction with a c
On Mon, Jan 30, 2012 at 11:18 PM, 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 b
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
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()
On 2012-01-30 19:19, Robert Haas wrote:
On Sun, Jan 29, 2012 at 7:27 AM, Kohei KaiGai 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 permission checks are harm
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 arc
On 27.01.2012 15:48, Pavel Stehule wrote:
2012/1/26 Abhijit Menon-Sen:
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
plpgsql_compile_inline(char *proc
On Tue, Jan 31, 2012 at 7:43 AM, Heikki Linnakangas
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 that needs to happen,
> like, flu
66 matches
Mail list logo
