On Wed, Mar 5, 2014 at 12:07 PM, Amit Langote amitlangot...@gmail.com wrote:
On Wed, Mar 5, 2014 at 2:09 AM, Sawada Masahiko sawada.m...@gmail.com wrote:
xlog.c:6177
if (ControlFile-wal_level WAL_LEVEL_HOT_STANDBY)
ereport(ERROR,
(errmsg(hot standby is not possible
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 about
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
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
On 4 March 2014 21:37, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Mar 4, 2014 at 2:39 PM, Simon Riggs si...@2ndquadrant.com wrote:
Your earlier claim that the dump is inconsistent just isn't accurate.
We now have MVCC catalogs, so any dump is going to
On Wed, Mar 5, 2014 at 7:44 AM, Andrew Dunstan and...@dunslane.net 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
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
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
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.
On Mar4, 2014, at 21:09 , Dean Rasheed dean.a.rash...@gmail.com wrote:
On 3 March 2014 23:00, Florian Pflug f...@phlo.org wrote:
* In show_windowagg_info(), this calculation looks suspicious to me:
double tperrow = winaggstate-aggfwdtrans /
(inst-nloops * inst-ntuples);
If
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
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.
Consider
2014-03-05 23:27 GMT+09:00 Andrew Dunstan and...@dunslane.net:
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
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
On Wed, Mar 5, 2014 at 11:37 PM, Ian Lawrence Barwick barw...@gmail.com wrote:
2014-03-05 23:27 GMT+09:00 Andrew Dunstan and...@dunslane.net:
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
On Wed, Mar 5, 2014 at 11:58 PM, Michael Paquier
michael.paqu...@gmail.com 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
Andrew Dunstan and...@dunslane.net 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
Hi
I hope, so this patch fix it
Regards
Pavel
2014-03-04 21:00 GMT+01:00 Pavel Stehule pavel.steh...@gmail.com:
2014-03-04 20:20 GMT+01:00 Alvaro Herrera alvhe...@2ndquadrant.com:
Pavel Stehule escribió:
2014-03-04 19:12 GMT+01:00 Alvaro Herrera alvhe...@2ndquadrant.com:
Pavel
On Wed, Mar 5, 2014 at 8:39 AM, Bruce Momjian br...@momjian.us 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
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 and...@dunslane.net 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
On Wed, Mar 5, 2014 at 9:24 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net 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
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
Merlin Moncure mmonc...@gmail.com writes:
On Wed, Mar 5, 2014 at 9:24 AM, Tom Lane t...@sss.pgh.pa.us 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
On 03/05/2014 10:30 AM, Tom Lane wrote:
Merlin Moncure mmonc...@gmail.com writes:
On Wed, Mar 5, 2014 at 9:24 AM, Tom Lane t...@sss.pgh.pa.us 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
On Wed, Mar 5, 2014 at 09:19:33AM -0600, Merlin Moncure wrote:
On Wed, Mar 5, 2014 at 8:39 AM, Bruce Momjian br...@momjian.us 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,
On Wed, Mar 5, 2014 at 10:19 AM, Merlin Moncure mmonc...@gmail.com wrote:
On Wed, Mar 5, 2014 at 8:39 AM, Bruce Momjian br...@momjian.us 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.
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
Robert Haas robertmh...@gmail.com 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
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 mmonc...@gmail.com writes:
On Wed, Mar 5, 2014 at 9:24 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Also, there might be other cases besides arrays where we've embedded
type OIDs
On Wed, Mar 5, 2014 at 9:52 AM, Bruce Momjian br...@momjian.us 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 br...@momjian.us wrote:
So, I am going to ask a back-track question and ask why we can't move
hstore into core.
On Mon, Mar 3, 2014 at 11:20 PM, Peter Geoghegan p...@heroku.com wrote:
On Mon, Mar 3, 2014 at 6:59 PM, Josh Berkus j...@agliodbs.com wrote:
Also, please recognize that the current implementation was what we
collectively decided on three months ago, and what Andrew worked pretty
hard to
Bruce Momjian br...@momjian.us 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
On 2014-03-05 10:10:23 -0600, Merlin Moncure wrote:
On Wed, Mar 5, 2014 at 9:52 AM, Bruce Momjian br...@momjian.us 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
Merlin Moncure mmonc...@gmail.com 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
On Wed, Mar 5, 2014 at 10:19 AM, Andres Freund and...@2ndquadrant.com 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
* 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 and...@2ndquadrant.com 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
On Wed, Mar 5, 2014 at 11:07 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
On Wed, Mar 5, 2014 at 11:24 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Merlin Moncure mmonc...@gmail.com 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
* 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 t...@sss.pgh.pa.us wrote:
Merlin Moncure mmonc...@gmail.com 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
* Merlin Moncure (mmonc...@gmail.com) wrote:
On Wed, Mar 5, 2014 at 10:24 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Merlin Moncure mmonc...@gmail.com 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
On Wed, Mar 5, 2014 at 11:16:01AM -0500, Tom Lane wrote:
Bruce Momjian br...@momjian.us 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
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
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 decide
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,
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 br...@momjian.us 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.
On Wed, Mar 5, 2014 at 10:43 AM, Stephen Frost sfr...@snowman.net wrote:
* Merlin Moncure (mmonc...@gmail.com) wrote:
On Wed, Mar 5, 2014 at 10:24 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Merlin Moncure mmonc...@gmail.com writes:
*All* non-sql standard types ought to be in extensions in an
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 split
On Mar 5, 2014, at 8:49 AM, Andrew Dunstan and...@dunslane.net 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
$ 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 mmonc...@gmail.com writes:
On Wed, Mar 5, 2014 at 10:24 AM, Tom Lane t...@sss.pgh.pa.us 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
On Wed, Mar 5, 2014 at 11:50 AM, Bruce Momjian br...@momjian.us 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
On 5 March 2014 14:35, Florian Pflug f...@phlo.org wrote:
On Mar4, 2014, at 21:09 , Dean Rasheed dean.a.rash...@gmail.com wrote:
On 3 March 2014 23:00, Florian Pflug f...@phlo.org wrote:
* In show_windowagg_info(), this calculation looks suspicious to me:
double tperrow =
* Robert Haas (robertmh...@gmail.com) wrote:
On Wed, Mar 5, 2014 at 11:50 AM, Bruce Momjian br...@momjian.us 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
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,
and have
Dean Rasheed dean.a.rash...@gmail.com 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
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.
On March 5, 2014 6:07:43 PM CET, Tom Lane t...@sss.pgh.pa.us 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
* Merlin Moncure (mmonc...@gmail.com) wrote:
On Wed, Mar 5, 2014 at 10:43 AM, Stephen Frost sfr...@snowman.net 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
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 t...@sss.pgh.pa.us wrote:
Merlin Moncure mmonc...@gmail.com writes:
On Wed, Mar 5, 2014 at 10:24 AM, Tom Lane t...@sss.pgh.pa.us 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
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,
On Wed, Mar 5, 2014 at 12:57 PM, Erik Rijkers e...@xs4all.nl 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
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 you can
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
On Tue, Mar 4, 2014 at 6:26 PM, Andres Freund and...@2ndquadrant.com 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.
Craig Ringer cr...@hobby.2ndquadrant.com 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
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=true
On Wed, Mar 5, 2014 at 8:30 AM, Robert Haas robertmh...@gmail.com 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
Kyotaro HORIGUCHI horiguchi.kyot...@lab.ntt.co.jp 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
On Wed, Mar 5, 2014 at 1:57 PM, Josh Berkus j...@agliodbs.com 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
On Wed, Mar 5, 2014 at 10:59:37AM -0800, Peter Geoghegan wrote:
On Wed, Mar 5, 2014 at 8:30 AM, Robert Haas robertmh...@gmail.com 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
On Tue, Mar 4, 2014 at 3:33 PM, Fabrízio de Royes Mello
fabriziome...@gmail.com 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
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 the
On Wed, Mar 5, 2014 at 5:13 PM, Amit Langote amitlangot...@gmail.com wrote:
On Wed, Mar 5, 2014 at 12:07 PM, Amit Langote amitlangot...@gmail.com wrote:
On Wed, Mar 5, 2014 at 2:09 AM, Sawada Masahiko sawada.m...@gmail.com
wrote:
xlog.c:6177
if (ControlFile-wal_level
Alex Hunsaker escribió:
On Tue, Feb 25, 2014 at 6:56 AM, Sergey Burladyan eshkin...@gmail.com 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
Kouhei Kaigai kai...@ak.jp.nec.com 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
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 be
On Wed, Mar 5, 2014 at 10:59:37AM -0800, Peter Geoghegan wrote:
On Wed, Mar 5, 2014 at 8:30 AM, Robert Haas robertmh...@gmail.com 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
On Wed, Mar 5, 2014 at 4:06 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Mar 4, 2014 at 3:33 PM, Fabrízio de Royes Mello
fabriziome...@gmail.com 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
On Wed, Mar 5, 2014 at 12:22 PM, Alvaro Herrera
alvhe...@2ndquadrant.com 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
On Wed, Mar 5, 2014 at 11:44 AM, Stephen Frost sfr...@snowman.net wrote:
* Merlin Moncure (mmonc...@gmail.com) wrote:
On Wed, Mar 5, 2014 at 10:43 AM, Stephen Frost sfr...@snowman.net wrote:
Yeah, from what I gather you're suggesting, that's more-or-less move it
all to core, except that all
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 to
On Mon, Mar 3, 2014 at 8:12 AM, Robert Haas robertmh...@gmail.com 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:
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 t...@sss.pgh.pa.us 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
On Wed, Mar 5, 2014 at 5:32 PM, Rohit Goyal rhtgyl...@gmail.com 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
* Merlin Moncure (mmonc...@gmail.com) wrote:
On Wed, Mar 5, 2014 at 11:44 AM, Stephen Frost sfr...@snowman.net 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
Merlin Moncure escribió:
On Wed, Mar 5, 2014 at 11:44 AM, Stephen Frost sfr...@snowman.net 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
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 and...@2ndquadrant.com
wrote:
Usually that state will be reached very quickly because before
that we're writing data to the network as fast as it
On Wed, Mar 5, 2014 at 3:04 PM, Andres Freund and...@2ndquadrant.com 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
On Wed, Mar 5, 2014 at 2:45 PM, Alvaro Herrera alvhe...@2ndquadrant.com 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
On Wed, Mar 5, 2014 at 12:32 PM, Rohit Goyal rhtgyl...@gmail.com 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
On Mar5, 2014, at 18:37 , Tom Lane t...@sss.pgh.pa.us wrote:
Dean Rasheed dean.a.rash...@gmail.com 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
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 with the
* Merlin Moncure (mmonc...@gmail.com) wrote:
On Wed, Mar 5, 2014 at 2:46 PM, Stephen Frost sfr...@snowman.net 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
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
