Hello, This is new version of dblink.c
- Memory is properly freed when realloc returns NULL in storeHandler().
- The bug that free() in finishStoreInfo() will be fed with
garbage pointer when malloc for sinfo->valbuflen fails is
fixed.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software
On Thu, Feb 2, 2012 at 08:26, Jaime Casanova wrote:
> On Wed, Feb 1, 2012 at 9:18 PM, Fujii Masao wrote:
--On 15. Januar 2012 02:50:00 -0500 Jaime Casanova
wrote:
> Attached is a patch thats implements a pg_stat_recovery view that
> keeps counters about processed wal
Hey all,
Could you tell me please an objective reason why PQunescapeBytea()
returns unsigned char* rather than just char* ?
I am asking because a bit confused. How this intermixes with LO's API,
which based on signed chars (although as we all know large object -
is a just bytea splitted on chunks)
On Wed, Feb 1, 2012 at 9:18 PM, Fujii Masao wrote:
>>>
>>> --On 15. Januar 2012 02:50:00 -0500 Jaime Casanova
>>> wrote:
>>>
Attached is a patch thats implements a pg_stat_recovery view that
keeps counters about processed wal records. I just notice that it
still lacks documentation
On 02.02.2012 08:19, Simon Riggs wrote:
On Wed, Feb 1, 2012 at 10:42 PM, Jim Nasby wrote:
On Feb 1, 2012, at 4:25 AM, Simon Riggs wrote:
At present log_newpage() produces log records called XLOG_HEAP_NEWPAGE.
That routine is used by HEAP, BTREE, GIN, SPGIST rmgrs, as well as
various forks.
W
On Wed, Feb 1, 2012 at 10:42 PM, Jim Nasby wrote:
> On Feb 1, 2012, at 4:25 AM, Simon Riggs wrote:
>> At present log_newpage() produces log records called XLOG_HEAP_NEWPAGE.
>>
>> That routine is used by HEAP, BTREE, GIN, SPGIST rmgrs, as well as
>> various forks.
>>
>> WAL contains no information
In miracee's review of Peter's patch for new -A options in initdb (in
commitfest app only), it is noted that pg_hba.conf keyword parsing is
done in a case sensitive manner. So if you write "Trust" rather than
"trust", it's not recognized.
This seemed pretty nonsensical to me, and it's not documen
So freezing multixacts is not all that easy. I mean, you just scan the
page looking for multis lesser than the cutoff; for those that are dead,
they can just be removed completely, but what about ones that still have
members running? This is pretty unlikely but not impossible.
If there's only o
Alvaro Herrera writes:
> ! if (!(tuple->t_infomask & HEAP_XMAX_INVALID))
> {
> ! if (!(tuple->t_infomask & HEAP_XMAX_IS_MULTI))
How about just one test,
if (!(tuple->t_infomask & (HEAP_XMAX_INVALID | HEAP_XMAX_IS_MULTI)))
But other than that quibble, yeah, it's a b
Robert Haas writes:
> Is spgist intended to support prefix searches with LIKE?
Too lazy to look at the code right now, but I think indxpath.c contains
hardwired assumptions that LIKE prefix optimizations are only possible
with btree indexes. Possibly it would be worth relaxing that. (The
whole
Alvaro Herrera writes:
> Excerpts from Jim Nasby's message of mié feb 01 20:47:05 -0300 2012:
>> I'm not certain this in what Pavel is referring to, but I have often wished
>> that I could pass something like an array into a function and have the
>> function tell me exactly how much space that
(2012/02/01 3:56), Robert Haas wrote:
> 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?
Yes, we should, if we have pro
On Fri, Jan 27, 2012 at 6:01 AM, Jaime Casanova wrote:
> On Thu, Jan 26, 2012 at 4:03 AM, Bernd Helmle wrote:
>>
>>
>> --On 15. Januar 2012 02:50:00 -0500 Jaime Casanova
>> wrote:
>>
>>> Attached is a patch thats implements a pg_stat_recovery view that
>>> keeps counters about processed wal reco
On Wed, Feb 1, 2012 at 11:01 PM, Robert Haas wrote:
> On Wed, Feb 1, 2012 at 12:23 PM, Tom Lane wrote:
> > On the other hand it isn't
> > all that far beyond what I had in mind of inventing relation aliases
> > to cure relation-name conflicts. Should we take the existence of such
> > cases as e
On Wed, Feb 1, 2012 at 10:53 PM, Tom Lane wrote:
> Ashutosh Bapat writes:
> > Looking at the code, it seems that the fake aliases (eref) for relations
> > (may be views as well) are not generated per say, but they do not get
> > changed when the relation name changes OR in case of inherited tabl
On Wed, Feb 1, 2012 at 7:44 PM, Robert Haas wrote:
> On Wed, Feb 1, 2012 at 4:09 AM, Dean Rasheed wrote:
>>> The real objection to this probably is that if it only saves anything
>>> for tables that don't have a VM yet, it's dubious whether it's worth
>>> doing. But if we can avoid wasted checks
Excerpts from Jim Nasby's message of mié feb 01 19:12:58 -0300 2012:
> On Jan 26, 2012, at 9:32 PM, Robert Haas wrote:
> > But if we want to put it on a diet, the first thing I'd probably be
> > inclined to lose is the float4 specialization. Some members of the
> > audience will recall that I tak
Excerpts from Jim Nasby's message of mié feb 01 20:47:05 -0300 2012:
> I'm not certain this in what Pavel is referring to, but I have often wished
> that I could pass something like an array into a function and have the
> function tell me exactly how much space that would require on-disk. It's
Hi,
I noticed that heap_tuple_needs_freeze might return true in cases where
the Xmax is leftover junk from somebody who set HEAP_XMAX_INVALID in the
far past without resetting the Xmax value itself to Invalid. I think
this is incorrect usage; the rule, I think, is that one shouldn't even
read Xma
Excerpts from Jim Nasby's message of mié feb 01 21:33:47 -0300 2012:
>
> On Jan 31, 2012, at 10:58 AM, Alvaro Herrera wrote:
> >> I think it's butt-ugly, but it's only slightly uglier than
> >> relfrozenxid which we're already stuck with. The slight amount of
> >> additional ugliness is that you
On Wed, Feb 1, 2012 at 4:09 AM, Dean Rasheed wrote:
>> The real objection to this probably is that if it only saves anything
>> for tables that don't have a VM yet, it's dubious whether it's worth
>> doing. But if we can avoid wasted checks for VM extension as well,
>> then I think it's probably
On Jan 31, 2012, at 10:58 AM, Alvaro Herrera wrote:
>> I think it's butt-ugly, but it's only slightly uglier than
>> relfrozenxid which we're already stuck with. The slight amount of
>> additional ugliness is that you're going to use an XID column to store
>> a uint4 that is not an XID - but I don
I've just been running some timings of my JSON-producing functions, in
particular array_to_json, and comparing them with the current
XML-producing functions. Here's a typical result:
andrew=# explain analyse select array_to_json(array_agg(q),true)
from (select * from pg_attribute) q;
On Feb 1, 2012, at 12:45 AM, Pavel Stehule wrote:
>>> 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
Is spgist intended to support prefix searches with LIKE?
I ask because, first, it seems like something spgist ought to be good
at (unless I'm confused), and, second, the text_ops opfamily includes
these operators:
~<~(text,text)
~<=~(text,text)
~>=~(text,text)
~>~(text,text)
...which seems to
On Feb 1, 2012, at 4:25 AM, Simon Riggs wrote:
> At present log_newpage() produces log records called XLOG_HEAP_NEWPAGE.
>
> That routine is used by HEAP, BTREE, GIN, SPGIST rmgrs, as well as
> various forks.
>
> WAL contains no information as to which rmgr the data refers to,
> making debugging
On Jan 26, 2012, at 9:32 PM, Robert Haas wrote:
> But if we want to put it on a diet, the first thing I'd probably be
> inclined to lose is the float4 specialization. Some members of the
> audience will recall that I take dim view of floating point arithmetic
> generally, but I'll concede that the
Hi,
Sorry to be late in the thread, I'm too busy right now. Cédric called
it to my immediate attention though.
Martijn van Oosterhout writes:
> Perhaps a better way of dealing with this is providing a way of dumping
> extensions explicitly. Then you could say:
>
> pg_dump --extension=postgis -s
On Wed, Feb 1, 2012 at 12:23 PM, Tom Lane wrote:
> On the other hand it isn't
> all that far beyond what I had in mind of inventing relation aliases
> to cure relation-name conflicts. Should we take the existence of such
> cases as evidence that we shouldn't try hard in this area? It seems
> rea
On tor, 2012-01-12 at 22:43 -0600, Joshua Berkus wrote:
> Most normal uses of alter table ... rename constraint ... worked
> normally. However, the patch does not deal correctly with constraints
> which are not inherited, such as primary key constraints:
New patch which works around that issue.
On ons, 2012-01-18 at 18:17 -0500, Robert Haas wrote:
> I agree with Peter that we should have we should have CHECK ONLY.
> ONLY is really a property of the constraint, not the ALTER TABLE
> command -- if it were otherwise, we wouldn't need to store it the
> system catalogs, but of course we do. T
On Wed, Feb 1, 2012 at 7:31 PM, Peter Eisentraut wrote:
> On sön, 2012-01-29 at 22:01 +, Simon Riggs wrote:
>> Patch now locks index in AccessExclusiveLock in final stage of drop.
>
> Doesn't that defeat the point of doing the CONCURRENTLY business in the
> first place?
That was my initial re
On sön, 2012-01-29 at 22:01 +, Simon Riggs wrote:
> Patch now locks index in AccessExclusiveLock in final stage of drop.
Doesn't that defeat the point of doing the CONCURRENTLY business in the
first place?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
On Wed, Feb 1, 2012 at 5:47 PM, Robert Haas wrote:
> On Wed, Jan 25, 2012 at 8:49 AM, Robert Haas wrote:
>> On Tue, Jan 24, 2012 at 4:28 PM, Simon Riggs wrote:
>>> I think we should be working to commit XLogInsert and then Group
>>> Commit, then come back to the discussion.
>>
>> I definitely ag
On tis, 2012-01-17 at 16:46 +0900, Fujii Masao wrote:
> When I tested the patch, "create ta" was converted unexpectedly to
> "create TABLE"
> though "alter ta" was successfully converted to "alter table". As far
> as I read the patch,
> you seems to have forgotten to change create_or_drop_command_g
Marti Raudsepp writes:
> On Wed, Dec 21, 2011 at 18:21, Marti Raudsepp wrote:
>> I think the least invasive fix, as proposed by Jeroen, is to fail only
>> when ERANGE is set *and* the return value is 0.0 or +/-HUGE_VAL.
>> Reading relevant specifications, this seems to be a fairly safe
>> assumpt
On sön, 2012-01-15 at 18:14 -0500, Josh Kupershmidt wrote:
> I see this patch includes a small change to dropuser, to make the
> 'username' argument mandatory if --interactive is not set, for
> symmetry with createuser's new behavior. That's dandy, though IMO we
> shouldn't have "-i" be shorthand f
On Wed, Jan 25, 2012 at 8:49 AM, Robert Haas wrote:
> On Tue, Jan 24, 2012 at 4:28 PM, Simon Riggs wrote:
>> I think we should be working to commit XLogInsert and then Group
>> Commit, then come back to the discussion.
>
> I definitely agree that those two have way more promise than anything
> el
> 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 destructors in C++.
I had thought that this was only an
On Tue, Jan 31, 2012 at 4:46 PM, Joachim Wieland wrote:
> 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 mult
Ashutosh Bapat writes:
> Looking at the code, it seems that the fake aliases (eref) for relations
> (may be views as well) are not generated per say, but they do not get
> changed when the relation name changes OR in case of inherited tables, they
> do not get changed when the inheritance is expan
On Wed, Feb 1, 2012 at 2:56 AM, Robert Haas wrote:
> I improved the grammar issues in the attached version of the patch -
> the syntax is now simpler and more consistent, IF EXISTS now works,
> and RESTRICT is accepted (without changing the behavior) while CASCADE
> fails with a nicer error messa
On Tue, Jan 31, 2012 at 3:47 PM, Joey Adams wrote:
> I'm mostly in favor of allowing \u. Banning \u means users
> can't use JSON strings to marshal binary blobs, e.g. by escaping
> non-printable characters and only using U+..U+00FF. Instead, they
> have to use base64 or similar.
I a
On Wed, Feb 1, 2012 at 13:56, Marko Kreen wrote:
> freePGconn() does not free sslcompression. Fix.
Thanks, applied.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
On Tue, Jan 31, 2012 at 11:46 PM, Andrew Dunstan wrote:
> The array(select...) locution turns out to have less flexibility than the
> array_agg(record-ref) locution.
Less flexible maybe, but it can cleaner for exactly the type of
queries that will tend to come up in exactly the type of functional
On 31 January 2012 19:47, Robert Haas wrote:
> 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 declaratio
On Tue, Jan 31, 2012 at 10:29 AM, Gabriele Bartolini
wrote:
> Here is my final version which embeds comments from Josh. I have also added
> debug information to be printed in case '-d' is given.
Looks fine; will mark Ready For Committer.
Josh
--
Sent via pgsql-hackers mailing list (pgsql-hack
freePGconn() does not free sslcompression. Fix.
Found with valgrind.
--
marko
diff --git a/src/interfaces/libpq/fe-connect.c b/src/interfaces/libpq/fe-connect.c
index 5add143..4605e49 100644
--- a/src/interfaces/libpq/fe-connect.c
+++ b/src/interfaces/libpq/fe-connect.c
@@ -2803,6 +2803,8 @@ f
Hello,
This is my first patch review ever, so please bear with me.
The patch[1] is in the context diff format and applies cleanly to
current git HEAD. Documentation is updated by the patch.
The code does implement what's the patch is supposed to do.
Do we want that? According to Greg's orig
Looking at the code, it seems that the fake aliases (eref) for relations
(may be views as well) are not generated per say, but they do not get
changed when the relation name changes OR in case of inherited tables, they
do not get changed when the inheritance is expanded
(expand_inherited_rtentry).
Hi All,
This is regarding the TODO item :
"Add SPI_gettypmod() to return a field's typemod from a TupleDesc"
The related message is:
http://archives.postgresql.org/pgsql-hackers/2005-11/msg00250.php
This basically talks about having an SPI_gettypemod() which returns the
typmod of a field of tupd
At present log_newpage() produces log records called XLOG_HEAP_NEWPAGE.
That routine is used by HEAP, BTREE, GIN, SPGIST rmgrs, as well as
various forks.
WAL contains no information as to which rmgr the data refers to,
making debugging much harder and skewing efforts to optimise WAL
traffic and i
On Wed, Feb 1, 2012 at 10:32 AM, Kyotaro HORIGUCHI
wrote:
>> Another thing: if realloc() fails, the old pointer stays valid.
>> So it needs to be assigned to temp variable first, before
>> overwriting old pointer.
>
> mmm. I've misunderstood of the realloc.. I'll fix there in the
> next patch.
P
On 31 January 2012 23:04, Tom Lane wrote:
> 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
Hello,
> Another thing: if realloc() fails, the old pointer stays valid.
> So it needs to be assigned to temp variable first, before
> overwriting old pointer.
mmm. I've misunderstood of the realloc.. I'll fix there in the
next patch.
> And seems malloc() is preferable to palloc() to avoid
> ex
55 matches
Mail list logo
