On Wed, Mar 5, 2014 at 12:07 PM, Amit Langote wrote:
> On Wed, Mar 5, 2014 at 2:09 AM, Sawada Masahiko wrote:
>
>>
>> xlog.c:6177
>> if (ControlFile->wal_level < WAL_LEVEL_HOT_STANDBY)
>> ereport(ERROR,
>> (errmsg("hot standby is not possible because wal_level was not
>>
>> So
Tom, thanks for your detailed comments.
> I apologize for not having paid much attention to this thread so far.
> It kept getting stuck on my "to look at later" queue. Anyway, I've taken
> a preliminary look at the v7 patch now.
>
> While the patch seems roughly along the lines of what we talked
Hello,
After all, I have confirmed that this fixes the problem on crash
recovery of hot-standby botfor 9.3 and HEAD and no problem was
found except unreadability :(
By the way, I moderately want to fix an assertion message to a
ordinary one. Details are below.
The server stops with followi
On 2014-03-05 04:02, Craig Ringer wrote:
On 03/04/2014 09:41 PM, Yeb Havinga wrote:
On 04/03/14 02:36, Craig Ringer wrote:
I've pushed an update to the branch with the fix for varno handling.
Thanks. It's tagged rls-9.4-upd-sb-views-v8 .
I've almost run out of time to spend on row security for
On 4 March 2014 21:37, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Mar 4, 2014 at 2:39 PM, Simon Riggs wrote:
>>> Your earlier claim that the dump is inconsistent just isn't accurate.
>>> We now have MVCC catalogs, so any dump is going to see a perfectly
>>> consistent set of data plus DDL.
On Wed, Mar 5, 2014 at 7:44 AM, Andrew Dunstan wrote:
> I have picked this up and committed the patch. Thanks to all.
Sorry for coming after the battle, but while looking at what has been
committed I noticed that copy2.sql is actually doing twice in a row
the same test:
COPY forcetest (a, b, c) FR
On 03/05/2014 10:51 AM, Kyotaro HORIGUCHI wrote:
Hello,
After all, I have confirmed that this fixes the problem on crash
recovery of hot-standby botfor 9.3 and HEAD and no problem was
found except unreadability :(
Ok, committed. Thanks!
Any concrete suggestions about the readability? Is there
After testing this feature, I noticed that FORCE_NULL and
FORCE_NOT_NULL can both be specified with COPY on the same column.
This does not seem correct. The attached patch adds some more error
handling, and a regression test case for that.
Regards,
--
Michael
diff --git a/src/backend/commands/copy
On 03/05/2014 09:11 AM, Michael Paquier wrote:
After testing this feature, I noticed that FORCE_NULL and
FORCE_NOT_NULL can both be specified with COPY on the same column.
This does not seem correct. The attached patch adds some more error
handling, and a regression test case for that.
Stric
On Mar4, 2014, at 21:09 , Dean Rasheed wrote:
> On 3 March 2014 23:00, Florian Pflug wrote:
>>> * In show_windowagg_info(), this calculation looks suspicious to me:
>>>
>>> double tperrow = winaggstate->aggfwdtrans /
>>> (inst->nloops * inst->ntuples);
>>>
>>> If the node is exe
On Mon, Mar 3, 2014 at 06:59:37PM -0800, Josh Berkus wrote:
> Realistically, hstore will never go away. I'll bet you a round or two
> of pints that, if we get both hstore2 and jsonb, within 2 years the
> users of jsonb will be an order of magnitude more numerous that then
> users of hstore, but f
On 03/05/2014 05:25 PM, Yeb Havinga wrote:
> Maybe a naive thought, but shouldn't all plans that include a table with
> an RLS clause be invalidated when the session role switches, regardless
> of which users from and to?
Only if the plan is actually accessed when under a different user ID.
Consid
2014-03-05 23:27 GMT+09:00 Andrew Dunstan :
>
> On 03/05/2014 09:11 AM, Michael Paquier wrote:
>>
>> After testing this feature, I noticed that FORCE_NULL and
>> FORCE_NOT_NULL can both be specified with COPY on the same column.
>> This does not seem correct. The attached patch adds some more error
On 03/05/2014 09:39 AM, Bruce Momjian wrote:
So, I am going to ask a back-track question and ask why we can't move
hstore into core. Is this a problem with the oids of the hstore data
type and functions? Is this a pg_upgrade-only problem? Can this be
fixed?
Yes, pg_upgrade is the problem,
On Wed, Mar 5, 2014 at 11:37 PM, Ian Lawrence Barwick wrote:
> 2014-03-05 23:27 GMT+09:00 Andrew Dunstan :
>>
>> On 03/05/2014 09:11 AM, Michael Paquier wrote:
>>>
>>> After testing this feature, I noticed that FORCE_NULL and
>>> FORCE_NOT_NULL can both be specified with COPY on the same column.
>
On Wed, Mar 5, 2014 at 11:58 PM, Michael Paquier
wrote:
> So if we specify both this produces the exact opposite of the default,
> default being an empty string inserted for a quoted empty string and
> NULL inserted for a non-quoted empty string. So yes I'm fine with a
> note on the docs about tha
Andrew Dunstan writes:
> On 03/05/2014 09:11 AM, Michael Paquier wrote:
>> After testing this feature, I noticed that FORCE_NULL and
>> FORCE_NOT_NULL can both be specified with COPY on the same column.
> Strictly they are not actually contradictory, since FORCE NULL relates
> to quoted null str
Hi
I hope, so this patch fix it
Regards
Pavel
2014-03-04 21:00 GMT+01:00 Pavel Stehule :
>
>
>
> 2014-03-04 20:20 GMT+01:00 Alvaro Herrera :
>
> Pavel Stehule escribió:
>> > 2014-03-04 19:12 GMT+01:00 Alvaro Herrera :
>> >
>> > > Pavel Stehule escribió:
>> > > > Hello
>> > > >
>> > > > update
On Wed, Mar 5, 2014 at 8:39 AM, Bruce Momjian wrote:
> So, I am going to ask a back-track question and ask why we can't move
> hstore into core.
This is exactly the opposite of what should be happening. Now, jsonb
might make it into core because of the json precedent but the entire
purpose of th
Pavel Stehule escribió:
> Hi
>
> I hope, so this patch fix it
wtf?
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
Andrew Dunstan writes:
> On 03/05/2014 09:39 AM, Bruce Momjian wrote:
>> So, I am going to ask a back-track question and ask why we can't move
>> hstore into core. Is this a problem with the oids of the hstore data
>> type and functions? Is this a pg_upgrade-only problem? Can this be
>> fixed?
On Wed, Mar 5, 2014 at 9:24 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 03/05/2014 09:39 AM, Bruce Momjian wrote:
>>> So, I am going to ask a back-track question and ask why we can't move
>>> hstore into core. Is this a problem with the oids of the hstore data
>>> type and functions? Is
On 03/05/2014 10:24 AM, Tom Lane wrote:
Also, there might be other cases besides arrays where we've embedded
type OIDs in on-disk data; anyone remember?
Don't we do that in composites too?
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postg
Merlin Moncure writes:
> On Wed, Mar 5, 2014 at 9:24 AM, Tom Lane wrote:
>> Also, there might be other cases besides arrays where we've embedded
>> type OIDs in on-disk data; anyone remember?
> composite types.
But that's only the composite type's own OID, no? So it's not really
a problem unle
On 03/05/2014 10:30 AM, Tom Lane wrote:
Merlin Moncure writes:
On Wed, Mar 5, 2014 at 9:24 AM, Tom Lane wrote:
Also, there might be other cases besides arrays where we've embedded
type OIDs in on-disk data; anyone remember?
composite types.
But that's only the composite type's own OID, no?
On Wed, Mar 5, 2014 at 09:19:33AM -0600, Merlin Moncure wrote:
> On Wed, Mar 5, 2014 at 8:39 AM, Bruce Momjian wrote:
> > So, I am going to ask a back-track question and ask why we can't move
> > hstore into core.
>
> This is exactly the opposite of what should be happening. Now, jsonb
> might
On Wed, Mar 5, 2014 at 10:19 AM, Merlin Moncure wrote:
> On Wed, Mar 5, 2014 at 8:39 AM, Bruce Momjian wrote:
>> So, I am going to ask a back-track question and ask why we can't move
>> hstore into core.
>
> This is exactly the opposite of what should be happening. Now, jsonb
> might make it int
Tomas Vondra wrote:
> On 22.2.2014 01:13, Thom Brown wrote:
> > I've noticed that files for dropped databases aren't removed from
> > pg_stat_tmp. After a cluster-wide VACUUM ANALYSE, and restarting
> > Postgres, all the old database pg_stat_tmp files remain.
> Yeah, that's a bug in pgstat_recv_
Robert Haas writes:
> And despite the assertions from various people here that these
> decisions were all made a long time ago and it's way too late to
> question them, I don't buy it. There's not a single email on this
> mailing list clearly laying out the design that we've ended up with,
> and
On Wed, Mar 5, 2014 at 10:39:56AM -0500, Andrew Dunstan wrote:
>
> On 03/05/2014 10:30 AM, Tom Lane wrote:
> >Merlin Moncure writes:
> >>On Wed, Mar 5, 2014 at 9:24 AM, Tom Lane wrote:
> >>>Also, there might be other cases besides arrays where we've embedded
> >>>type OIDs in on-disk data; anyo
On Wed, Mar 5, 2014 at 9:52 AM, Bruce Momjian wrote:
> On Wed, Mar 5, 2014 at 09:19:33AM -0600, Merlin Moncure wrote:
>> On Wed, Mar 5, 2014 at 8:39 AM, Bruce Momjian wrote:
>> > So, I am going to ask a back-track question and ask why we can't move
>> > hstore into core.
>>
>> This is exactly th
On Mon, Mar 3, 2014 at 11:20 PM, Peter Geoghegan wrote:
> On Mon, Mar 3, 2014 at 6:59 PM, Josh Berkus wrote:
>> Also, please recognize that the current implementation was what we
>> collectively decided on three months ago, and what Andrew worked pretty
>> hard to implement based on that collecti
Bruce Momjian writes:
> It seems only pg_type.oid is an issue for hstore. We can easily modify
> pg_dump --binary-upgrade mode to suppress the creation of the hstore
> extension. That should allow user hstore columns to automatically map
> to the new constant hstore oid. We can also modify pg_u
On 2014-03-05 10:10:23 -0600, Merlin Moncure wrote:
> On Wed, Mar 5, 2014 at 9:52 AM, Bruce Momjian wrote:
> > On Wed, Mar 5, 2014 at 09:19:33AM -0600, Merlin Moncure wrote:
> >> *All* non-sql standard types ought to be in extensions in an ideal world.
> >
> > I have seen your opinion on this but
Merlin Moncure writes:
>>> *All* non-sql standard types ought to be in extensions in an ideal world.
While there's certainly much to be said for the idea that jsonb should be
an extension, I don't think we have the technology to package it as a
*separate* extension; it'd have to be included in th
On Wed, Mar 5, 2014 at 10:19 AM, Andres Freund wrote:
> There's the absolutely significant issue that you cannot reasonably
> write extensions that interact on a C level. You can't call from
> extension to extension directly, but you can from extension to pg core
> provided ones.
Certainly. Note
* Merlin Moncure (mmonc...@gmail.com) wrote:
> *All* non-sql standard types ought to be in extensions in an ideal world.
While I appreciate that you'd like to see it that way, others don't
agree (I certainly don't), and that ship sailed quite a long time ago
regardless. I'm not advocating putting
On 02/25/2014 06:41 PM, Robert Haas wrote:
On Tue, Feb 25, 2014 at 11:23 AM, Andres Freund wrote:
Usually that state will be reached very quickly because before
that we're writing data to the network as fast as it can be read from
disk.
I'm unimpressed. Even if that is in practice true, maki
On Wed, Mar 5, 2014 at 11:07 AM, Tom Lane wrote:
> Robert Haas writes:
>> And despite the assertions from various people here that these
>> decisions were all made a long time ago and it's way too late to
>> question them, I don't buy it. There's not a single email on this
>> mailing list clearl
On Wed, Mar 5, 2014 at 11:24 AM, Tom Lane wrote:
> Merlin Moncure writes:
*All* non-sql standard types ought to be in extensions in an ideal world.
>
> While there's certainly much to be said for the idea that jsonb should be
> an extension, I don't think we have the technology to package it
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Just out of curiosity, exactly what features are missing from jsonb
> today that are available with hstore? How long would it take to
> copy-and-paste all that code, if someone were to decide to do the
> work instead of argue about it?
Somewhere upthread,
On Wed, Mar 5, 2014 at 10:24 AM, Tom Lane wrote:
> Merlin Moncure writes:
*All* non-sql standard types ought to be in extensions in an ideal world.
>
> While there's certainly much to be said for the idea that jsonb should be
> an extension, I don't think we have the technology to package it
* Merlin Moncure (mmonc...@gmail.com) wrote:
> On Wed, Mar 5, 2014 at 10:24 AM, Tom Lane wrote:
> > Merlin Moncure writes:
> *All* non-sql standard types ought to be in extensions in an ideal world.
> >
> > While there's certainly much to be said for the idea that jsonb should be
> > an exte
On Wed, Mar 5, 2014 at 11:16:01AM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > It seems only pg_type.oid is an issue for hstore. We can easily modify
> > pg_dump --binary-upgrade mode to suppress the creation of the hstore
> > extension. That should allow user hstore columns to automatica
On 03/05/2014 11:34 AM, Stephen Frost wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Just out of curiosity, exactly what features are missing from jsonb
today that are available with hstore? How long would it take to
copy-and-paste all that code, if someone were to decide to do the
work instead
On Wed, Mar 5, 2014 at 11:34:10AM -0500, Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > Just out of curiosity, exactly what features are missing from jsonb
> > today that are available with hstore? How long would it take to
> > copy-and-paste all that code, if someone were to d
On Wed, Mar 5, 2014 at 11:11:51AM -0500, Robert Haas wrote:
> An excellent question. This thread has become mostly about whether
> someone (like, say, me, or in this case Peter) is attempting to pull
> the rug out from under a previously-agreed consensus path forward.
> But despite my asking, nob
On 03/05/2014 11:44 AM, Bruce Momjian wrote:
On Wed, Mar 5, 2014 at 11:16:01AM -0500, Tom Lane wrote:
Bruce Momjian writes:
It seems only pg_type.oid is an issue for hstore. We can easily modify
pg_dump --binary-upgrade mode to suppress the creation of the hstore
extension. That should all
On Wed, Mar 5, 2014 at 10:43 AM, Stephen Frost wrote:
> * Merlin Moncure (mmonc...@gmail.com) wrote:
>> On Wed, Mar 5, 2014 at 10:24 AM, Tom Lane wrote:
>> > Merlin Moncure writes:
>> *All* non-sql standard types ought to be in extensions in an ideal
>> world.
>> >
>> > While there's
On Wed, Mar 5, 2014 at 11:53:31AM -0500, Andrew Dunstan wrote:
> >I think we also have to break out how much of the feeling that JSONB is
> >not ready is because of problems with the core/contrib split, and how
> >much of it is because of the type itself. I am suggesting that
> >core/contrib spli
On Mar 5, 2014, at 8:49 AM, Andrew Dunstan wrote:
> I think that was my estimate, but Peter did offer to do it. He certainly
> asserted that the effort required would not be great. I'm all for taking up
> his offer.
+1 to this. Can you and Peter collaborate somehow to get it knocked out?
> In
$ pg_dump -F d -j 4 -f foo regression
pg_dump: [archiver (db)] query failed: pg_dump: [parallel archiver] query was:
SET TRANSACTION SNAPSHOT '2130-1'
pg_dump: [archiver (db)] query failed: pg_dump: [archiver (db)] query failed:
pg_dump: [archiver (db)] query failed: $
postmaster log shows:
On 2014-03-05 12:07:43 -0500, Tom Lane wrote:
> $ pg_dump -F d -j 4 -f foo regression
> pg_dump: [archiver (db)] query failed: pg_dump: [parallel archiver] query
> was: SET TRANSACTION SNAPSHOT '2130-1'
> pg_dump: [archiver (db)] query failed: pg_dump: [archiver (db)] query failed:
> pg_dump:
Merlin Moncure writes:
> On Wed, Mar 5, 2014 at 10:24 AM, Tom Lane wrote:
>> While there's certainly much to be said for the idea that jsonb should be
>> an extension, I don't think we have the technology to package it as a
>> *separate* extension; it'd have to be included in the hstore extension
On Wed, Mar 5, 2014 at 11:50 AM, Bruce Momjian wrote:
> On Wed, Mar 5, 2014 at 11:34:10AM -0500, Stephen Frost wrote:
>> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> > Just out of curiosity, exactly what features are missing from jsonb
>> > today that are available with hstore? How long would it ta
On 5 March 2014 14:35, Florian Pflug wrote:
> On Mar4, 2014, at 21:09 , Dean Rasheed wrote:
>> On 3 March 2014 23:00, Florian Pflug wrote:
* In show_windowagg_info(), this calculation looks suspicious to me:
double tperrow = winaggstate->aggfwdtrans /
(inst->n
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Mar 5, 2014 at 11:50 AM, Bruce Momjian wrote:
> > What _would_ be interesting is to move all the hstore code into core,
> > and have hstore contrib just call the hstore core parts. That way, you
> > have one copy of the code, it is shared wit
On Wed, Mar 5, 2014 at 12:26:13PM -0500, Robert Haas wrote:
> >> It's not clear how much different it would be if we waited til 9.5
> >> either- do we anticipate a lot of code changes beyond the copy/paste for
> >> these?
> >
> > What _would_ be interesting is to move all the hstore code into core
Dean Rasheed writes:
> I think we really need a larger consensus on this though, so I'd be
> interested to hear what others think.
My advice is to lose the EXPLAIN output entirely. If the authors of
the patch can't agree on what it means, what hope have everyday users
got of making sense of it?
On 03/05/2014 12:01 PM, Bruce Momjian wrote:
On Wed, Mar 5, 2014 at 11:53:31AM -0500, Andrew Dunstan wrote:
I think we also have to break out how much of the feeling that JSONB is
not ready is because of problems with the core/contrib split, and how
much of it is because of the type itself. I
On March 5, 2014 6:07:43 PM CET, Tom Lane wrote:
>$ pg_dump -F d -j 4 -f foo regression
>pg_dump: [archiver (db)] query failed: pg_dump: [parallel archiver]
>query was: SET TRANSACTION SNAPSHOT '2130-1'
>pg_dump: [archiver (db)] query failed: pg_dump: [archiver (db)] query
>failed: pg_dump: [a
* Merlin Moncure (mmonc...@gmail.com) wrote:
> On Wed, Mar 5, 2014 at 10:43 AM, Stephen Frost wrote:
> > Yeah, from what I gather you're suggesting, that's more-or-less "move it
> > all to core", except that all of the actual interface bits end up in an
> > extension that has to be installed to us
Craig Ringer escribió:
> One of the remaining issues with row security is how to pass plan
> invalidation information generated in the rewriter back into the planner.
I think I already asked this, but would it work to extract this info by
walking the rewritten list of queries instead; and in case
On Wed, Mar 5, 2014 at 11:19 AM, Tom Lane wrote:
> Merlin Moncure writes:
>> On Wed, Mar 5, 2014 at 10:24 AM, Tom Lane wrote:
>>> While there's certainly much to be said for the idea that jsonb should be
>>> an extension, I don't think we have the technology to package it as a
>>> *separate* ext
Four files with comment typos.
--- src/backend/replication/logical/decode.c.orig 2014-03-05 18:44:31.725317514 +0100
+++ src/backend/replication/logical/decode.c 2014-03-05 18:45:09.577190828 +0100
@@ -497,7 +497,7 @@
/*
* Check whether we are interested in this specific transaction, an
On Wed, Mar 5, 2014 at 12:57 PM, Erik Rijkers wrote:
> Four files with comment typos.
Committed, thanks. For future reference, a single patch is easier
than four separate ones.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hacke
On 03/05/2014 09:26 AM, Robert Haas wrote:
>> > What _would_ be interesting is to move all the hstore code into core,
>> > and have hstore contrib just call the hstore core parts. That way, you
>> > have one copy of the code, it is shared with JSONB, but hstore remains
>> > as an extension that yo
Tom,
I did not follow the thread very close, so I need to look what the
ambiguity is there, however I would love to see window rescans in explain
analyze.
I have great experience in tuning Oracle queries.
There are features in PostgreSQL's explain analyze that I miss badly in
Oracle: 'rows remove
On Tue, Mar 4, 2014 at 6:26 PM, Andres Freund wrote:
> On 2014-03-03 16:48:15 -0500, Robert Haas wrote:
>> OK, I've committed the 0001 patch, which is the core of this feature,
>> with a bit of minor additional hacking.
>
> Attached are the rebased patches that are remaining.
>
> Changes:
> * mino
Craig Ringer writes:
> One of the remaining issues with row security is how to pass plan
> invalidation information generated in the rewriter back into the planner.
> With row security, it's necessary to set a field in PlannerGlobal,
> tracking the user ID of the user the query was planned for if
On 03/05/2014 10:49 AM, Robert Haas wrote:
> This patch still treats "allow a walsender to connect to a database"
> as a separate feature from "allow logical replication". I'm not
> convinced that's a good idea. What you're proposing to do is allow
> replication=database in addition to replication
On Wed, Mar 5, 2014 at 8:30 AM, Robert Haas wrote:
>> Just out of curiosity, exactly what features are missing from jsonb
>> today that are available with hstore? How long would it take to
>> copy-and-paste all that code, if someone were to decide to do the
>> work instead of argue about it?
>
>
Kyotaro HORIGUCHI writes:
>> ec_relids has never included child relids.
> relation.h says that,
> |Relids ec_relids; /* all relids appearing in ec_members */
> ...
> |Relids em_relids; /* all relids appearing in em_expr */
Ah. Those comments could use improvement, I guess.
On Wed, Mar 5, 2014 at 1:57 PM, Josh Berkus wrote:
> On 03/05/2014 10:49 AM, Robert Haas wrote:
>> This patch still treats "allow a walsender to connect to a database"
>> as a separate feature from "allow logical replication". I'm not
>> convinced that's a good idea. What you're proposing to do i
On Wed, Mar 5, 2014 at 10:59:37AM -0800, Peter Geoghegan wrote:
> On Wed, Mar 5, 2014 at 8:30 AM, Robert Haas wrote:
> >> Just out of curiosity, exactly what features are missing from jsonb
> >> today that are available with hstore? How long would it take to
> >> copy-and-paste all that code, if
On Tue, Mar 4, 2014 at 3:33 PM, Fabrízio de Royes Mello
wrote:
> Is the TODO item "CREATE SCHEMA ... LIKE ..." [1] a good GSoC project?
Maybe. I'm not sure that everyone would agree that it's a good idea.
And it'd probably involve mucking with a bunch of tablecmds.c code
that is kind of a mess a
On 03/05/2014 11:05 AM, Bruce Momjian wrote:
> Can you clarify what hstore2 is? It that the name of a type? Is that
> hierarchical hstore with the same hstore name?
hstore2 == nested heirarchical hstore. It's just a shorthand; there
won't be any actual type called "hstore2", by design. Unlike
On Wed, Mar 5, 2014 at 5:13 PM, Amit Langote wrote:
> On Wed, Mar 5, 2014 at 12:07 PM, Amit Langote wrote:
>> On Wed, Mar 5, 2014 at 2:09 AM, Sawada Masahiko
>> wrote:
>>
>>>
>>> xlog.c:6177
>>> if (ControlFile->wal_level < WAL_LEVEL_HOT_STANDBY)
>>> ereport(ERROR,
>>> (errms
Alex Hunsaker escribió:
> On Tue, Feb 25, 2014 at 6:56 AM, Sergey Burladyan wrote:
>
> > It looks like I found the problem, Perl use reference count and something
> > that
> > is called "Mortal" for memory management. As I understand it, mortal is
> > free
> > after FREETMPS. Plperl call FREET
Kouhei Kaigai writes:
>> * Please drop the whole register_custom_provider/get_custom_provider API.
> One thing I was worrying about is how copyObject() and nodeToString() support
> set of function pointer tables around custom-scan node, however, you suggested
> to change the assumption here. So,
Joel Jacobson wrote:
> Hi,
>
> I've tried to fix some bugs reported by Andrey Karpov in an article at
> http://www.viva64.com/en/b/0227/
>
> The value returned by socket() is unsigned on Windows and can thus not
> be checked if less than zero to detect an error, instead
> PGINVALID_SOCKET should
On Wed, Mar 5, 2014 at 10:59:37AM -0800, Peter Geoghegan wrote:
> On Wed, Mar 5, 2014 at 8:30 AM, Robert Haas wrote:
> >> Just out of curiosity, exactly what features are missing from jsonb
> >> today that are available with hstore? How long would it take to
> >> copy-and-paste all that code, if
On Wed, Mar 5, 2014 at 4:06 PM, Robert Haas wrote:
>
> On Tue, Mar 4, 2014 at 3:33 PM, Fabrízio de Royes Mello
> wrote:
> > Is the TODO item "CREATE SCHEMA ... LIKE ..." [1] a good GSoC project?
>
> Maybe. I'm not sure that everyone would agree that it's a good idea.
> And it'd probably involve
On Wed, Mar 5, 2014 at 12:22 PM, Alvaro Herrera
wrote:
> Can I bug you into verifying what supported releases need this patch,
> and to which does it backpatch cleanly? And if there's any to which it
> doesn't, can I further bug you into providing one that does?
Sure! Not bugging at all. I'll d
On Wed, Mar 5, 2014 at 11:44 AM, Stephen Frost wrote:
> * Merlin Moncure (mmonc...@gmail.com) wrote:
>> On Wed, Mar 5, 2014 at 10:43 AM, Stephen Frost wrote:
>> > Yeah, from what I gather you're suggesting, that's more-or-less "move it
>> > all to core", except that all of the actual interface bi
Hi,
On 2014-03-05 13:49:23 -0500, Robert Haas wrote:
> PLEASE stop using a comma to join two independent thoughts.
Ok. I'll try.
Is this a personal preference, or a general rule? There seems to be a
fair amount of comments in pg doing so?
> This patch still treats "allow a walsender to connect
On Mon, Mar 3, 2014 at 8:12 AM, Robert Haas wrote:
>
> Unfortunately, I don't believe that it's possible to do this easily
> today because of the way bucket splits are handled. I wrote about
> this previously here, with an idea for solving the problem:
>
>
> http://www.postgresql.org/message-id/
Hi All,
Is there any ways by which i can disable the hot-update functionality?
--
Regards,
Rohit Goyal
On 2014-03-05 18:39:52 +0100, Andres Freund wrote:
> On March 5, 2014 6:07:43 PM CET, Tom Lane wrote:
> >$ pg_dump -F d -j 4 -f foo regression
> >pg_dump: [archiver (db)] query failed: pg_dump: [parallel archiver]
> >query was: SET TRANSACTION SNAPSHOT '2130-1'
> >pg_dump: [archiver (db)] quer
On Wed, Mar 5, 2014 at 5:32 PM, Rohit Goyal wrote:
>
> Hi All,
>
> Is there any ways by which i can disable the hot-update functionality?
>
Why do you want do that?
Grettings,
--
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL
>> Timbira: http://www.timbira.com.br
>> Blog sobre TI: http
* Merlin Moncure (mmonc...@gmail.com) wrote:
> On Wed, Mar 5, 2014 at 11:44 AM, Stephen Frost wrote:
> > We have backwards compatibility "problems" because we don't want to
> > *break* things for people. Moving things into extensions doesn't
> > magically fix that- if you break something in a bac
Merlin Moncure escribió:
> On Wed, Mar 5, 2014 at 11:44 AM, Stephen Frost wrote:
> > We have backwards compatibility "problems" because we don't want to
> > *break* things for people. Moving things into extensions doesn't
> > magically fix that- if you break something in a backwards-incompatible
On 2014-03-05 18:26:13 +0200, Heikki Linnakangas wrote:
> On 02/25/2014 06:41 PM, Robert Haas wrote:
> >On Tue, Feb 25, 2014 at 11:23 AM, Andres Freund
> >wrote:
> >>Usually that state will be reached very quickly because before
> >>that we're writing data to the network as fast as it can be read
On Wed, Mar 5, 2014 at 3:04 PM, Andres Freund wrote:
> Hi,
>
> On 2014-03-05 13:49:23 -0500, Robert Haas wrote:
>> PLEASE stop using a comma to join two independent thoughts.
>
> Ok. I'll try.
>
> Is this a personal preference, or a general rule? There seems to be a
> fair amount of comments in pg
On Wed, Mar 5, 2014 at 2:45 PM, Alvaro Herrera wrote:
> Merlin Moncure escribió:
>> It doesn't magically fix it, but at least provides a way forward. If
>> the function you want to modify is in an extension 'foo', you get to
>> put your new stuff in 'foo2' extension. That way your users do not
>>
On Wed, Mar 5, 2014 at 12:32 PM, Rohit Goyal wrote:
> Hi All,
>
> Is there any ways by which i can disable the hot-update functionality?
>
Build an index on a volatile column. For example, to force pgbench to
bypass HOT updates for testing purposes I build an index on
pgbench_accounts (abalance
On Mar5, 2014, at 18:37 , Tom Lane wrote:
> Dean Rasheed writes:
>> I think we really need a larger consensus on this though, so I'd be
>> interested to hear what others think.
>
> My advice is to lose the EXPLAIN output entirely. If the authors of
> the patch can't agree on what it means, what
On 2014-03-05 17:05:24 -0500, Robert Haas wrote:
> > I very much dislike having the three different event loops, but it's
> > pretty much forced by the design of the xlogreader. "My" xlogreader
> > version didn't block when it neeeded to wait for WAL but just returned
> > "need input/output", but w
* Merlin Moncure (mmonc...@gmail.com) wrote:
> On Wed, Mar 5, 2014 at 2:46 PM, Stephen Frost wrote:
> > I don't see why we can't do exactly what you're suggesting in core.
>
> Because you can't (if you're defining core to mean 'not an
> extension'). Functions can't be removed or changed because
I don't believe that this is legal per C90:
typedef struct ReorderBufferChange
{
XLogRecPtrlsn;
/* type of change */
union
{
enum ReorderBufferChangeType action;
/* do not leak internal enum values to the outside */
intaction_internal;
}
1 - 100 of 127 matches
Mail list logo
