On Wed, May 28, 2014 at 10:49 PM, Fujii Masao masao.fu...@gmail.com wrote:
You're concerned about the scenario using pg_upgrade? I'm not sure the detail
of pg_upgrade. But if it doesn't work properly, we should have gotten
the trouble
I'm not worried about pg_upgrade, because by design
On Thu, May 29, 2014 at 11:32 AM, Peter Geoghegan p...@heroku.com wrote:
On Wed, May 28, 2014 at 10:49 PM, Fujii Masao masao.fu...@gmail.com
wrote:
You're concerned about the scenario using pg_upgrade?
Yeah - I was.
I'm not sure the detail
of pg_upgrade. But if it doesn't work properly,
On 05/29/2014 04:59 AM, Peter Geoghegan wrote:
Consider this example:
[local]/postgres=# SELECT to_char(1e9::float8,'9D9');
to_char
--
10.0
(1 row)
[local]/postgres=# SELECT
On 29 May 2014 01:07, Bruce Momjian br...@momjian.us wrote:
On Wed, May 28, 2014 at 04:04:13PM +0100, Simon Riggs wrote:
On 28 May 2014 15:34, Fujii Masao masao.fu...@gmail.com wrote:
Also, compress_backup_block GUC needs to be merged with full_page_writes.
Basically I agree with you
Hi all,
I'm little confused by the *convertJsonbValue* functon at *jsonb_utils.c*
Maybe I misunderstood something, so I need help =)
if (IsAJsonbScalar(val) || val-type == jbvBinary)
convertJsonbScalar(buffer, header, val);
As I can see, the *convertJsonbScalar* function is used for
On May 29, 2014 12:12 AM, Amit Kapila amit.kapil...@gmail.com wrote:
I agree with you that there are only few corner cases where evicting
shared buffers by this utility would harm, but was wondering if we could
even save those, say if it would only use available free buffers. I think
# select '\uaBcD'::json;
json
--
\uaBcD
but
# select '\uaBcD'::jsonb;
ERROR: invalid input syntax for type json
LINE 1: select '\uaBcD'::jsonb;
^
DETAIL: Unicode escape values cannot be used for code point values above 007F
when the server encoding is not UTF8.
postgres=# select '[\u]'::json-0;
?column?
--
\u
(1 row)
Time: 1,294 ms
postgres=# select '[\u]'::jsonb-0;
?column?
---
\\u
(1 row)
It seems to me that escape_json() is wrongly used in jsonb_put_escaped_value(),
right name of escape_json() is a
Thanks for extending and revising the FPW-compress patch! Could you add
your patch into next CF?
Sure. I will make improvements and add it to next CF.
Isn't it worth measuring the recovery performance for each compression
algorithm?
Yes I will post this soon.
On Wed, May 28, 2014 at 8:04 PM,
On 05/29/2014 07:55 AM, Teodor Sigaev wrote:
# select '\uaBcD'::json;
json
--
\uaBcD
but
# select '\uaBcD'::jsonb;
ERROR: invalid input syntax for type json
LINE 1: select '\uaBcD'::jsonb;
^
DETAIL: Unicode escape values cannot be used for code point values
So I ran into the case again where a system crashed while a hot backup
was being taken. Postgres couldn't start up automatically because the
backup_label was present. This has come up before e.g.
On 5/27/14, 10:37 PM, Tom Lane wrote:
I'm not terribly happy about pushing such a change post-beta1 either,
but it's not like this isn't something we've known was needed. Anyway,
what's the worst case if we find a bug here? Tell people not to use
uuid-ossp?
Mainly some more discussion time
On 5/27/14, 10:37 PM, Tom Lane wrote:
If you don't like this change, we can revert it and also revert the upgrade
to 2.69.
Nobody else appears to be concerned, but I would have preferred this option.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
On 05/29/2014 08:00 AM, Teodor Sigaev wrote:
postgres=# select '[\u]'::json-0;
?column?
--
\u
(1 row)
Time: 1,294 ms
postgres=# select '[\u]'::jsonb-0;
?column?
---
\\u
(1 row)
It seems to me that escape_json() is wrongly used in
inconsistent. It's been the subject of some discussion on -hackers previously,
IIRC. I actually referred to this difference in my talk at pgCon last Friday.
I see, and I wasn't on your talk :( I'm playing around jsquery and now trying to
implement UTF escapes there.
--
Teodor Sigaev
On 2014-05-29 08:14:48 -0400, Peter Eisentraut wrote:
On 5/27/14, 10:37 PM, Tom Lane wrote:
If you don't like this change, we can revert it and also revert the upgrade
to 2.69.
Nobody else appears to be concerned, but I would have preferred this option.
I am pretty concerned actually.
On 5/28/14, 7:02 PM, Andres Freund wrote:
That's a good idea. What i've been thinking about is to add
-Wno-deprecated to the bison rule in the interim. Maybe after a
configure test for the option. All deprecation warnings so far seem to
be pretty unhelpful.
Here is a patch.
diff --git
On 05/29/2014 08:21 AM, Andres Freund wrote:
On 2014-05-29 08:14:48 -0400, Peter Eisentraut wrote:
On 5/27/14, 10:37 PM, Tom Lane wrote:
If you don't like this change, we can revert it and also revert the upgrade to
2.69.
Nobody else appears to be concerned, but I would have preferred this
On 5/29/14, 8:21 AM, Andres Freund wrote:
But I don't see downgrading to an
earlier autoconf as something really helpful.
Well, we could have just hacked up that particular header check to do
what we want.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
On 2014-05-29 08:49:38 -0400, Peter Eisentraut wrote:
On 5/29/14, 8:21 AM, Andres Freund wrote:
But I don't see downgrading to an
earlier autoconf as something really helpful.
Well, we could have just hacked up that particular header check to do
what we want.
Still wouldn't have solved
Thanks for looking at it!
Date: Thu, 29 May 2014 00:19:33 +0300
From: hlinnakan...@vmware.com
To: johnlu...@hotmail.com; pgsql-hackers@postgresql.org
CC: klaussfre...@gmail.com
Subject: Re: [HACKERS] Extended Prefetching using Asynchronous IO - proposal
and patch
On 05/28/2014 11:52 PM,
I have pasted below the EXPLAIN of one of my benchmark queries
(the one I reference in the README).
Plenty of nested loop joins.
However I think I understand your question as to how effective it would be
if the outer is not sorted, and I will see if I can dig into that
if I get time (and it
On 2014-05-29 08:33:05 -0400, Peter Eisentraut wrote:
On 5/28/14, 7:02 PM, Andres Freund wrote:
That's a good idea. What i've been thinking about is to add
-Wno-deprecated to the bison rule in the interim. Maybe after a
configure test for the option. All deprecation warnings so far seem to
El 28/05/2014 22:12, Peter Geoghegan p...@heroku.com escribió:
On Wed, May 28, 2014 at 5:59 PM, Claudio Freire klaussfre...@gmail.com
wrote:
For nestloop, correct me if I'm wrong, but index scan nodes don't have
visibility of the next tuple to be searched for.
Nested loop joins are
Andres Freund and...@2ndquadrant.com writes:
On 2014-05-29 08:49:38 -0400, Peter Eisentraut wrote:
Well, we could have just hacked up that particular header check to do
what we want.
Still wouldn't have solved that ossp already didn't work on several
platforms at all anymore and is likely to
Andres Freund and...@2ndquadrant.com writes:
FWIW, I vote for applying something like it. It seems better to collect
the -Wno-deprecated in one place (i.e. configure) instead of having it
in every developer's Makefile.custom. The latter will be harder to get
rid of.
Yeah, that's a good point.
Andrew Dunstan and...@dunslane.net writes:
On 05/29/2014 08:21 AM, Andres Freund wrote:
Yes, it'd have been nice if this were done a month+ ago. But nobody
stepped up :(. Seems like the least bad choice :/
The most worrying thing is that we didn't find the occasioning problem
when we
I don't think that checkAllTheSame is broken, but it probably would be
after this patch --- ISTM you're breaking the corner case described in the
header comment for checkAllTheSame, where we need to force splitting of a
set of existing tuples that the opclass can't distinguish.
INHO, this patch
On 05/29/2014 08:15 AM, Andrew Dunstan wrote:
On 05/29/2014 08:00 AM, Teodor Sigaev wrote:
postgres=# select '[\u]'::json-0;
?column?
--
\u
(1 row)
Time: 1,294 ms
postgres=# select '[\u]'::jsonb-0;
?column?
---
\\u
(1 row)
It seems to me that
On Thu, May 29, 2014 at 3:09 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Yeah, the code is pretty crufty, I'm not sure what the proper fix would be.
I wonder if psprintf would be useful.
I don't know that it's worth worrying about the case you highlight. It
is certainly worth
On Thu, May 29, 2014 at 08:33:05AM -0400, Peter Eisentraut wrote:
On 5/28/14, 7:02 PM, Andres Freund wrote:
That's a good idea. What i've been thinking about is to add
-Wno-deprecated to the bison rule in the interim. Maybe after a
configure test for the option. All deprecation warnings so
What features in 9.4 need more beta testing for recovery?
I've applied my partial-write testing harness to several scenarios in 9.4.
So far its found a recovery bug for gin indexes, a recovery bug for btree,
a vacuum bug for btree indexes (with foreign keys, but that is not relevant
to the bug),
Actually, this is just the tip of the iceberg.
Funny, but
postgres=# select '\u'::text;
text
\u
(1 row)
postgres=# select array['\u']::text[];
array
-
{\\u}
postgres=# select '{\u}'::text[];
text
-
{u}
postgres=# select
On Wed, May 28, 2014 at 11:23 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Buildfarm critters smew and shearwater are reporting regression test
failures that suggest that the UUID library can't get a system MAC
address:
On Thu, May 29, 2014 at 11:21:44AM +0100, Simon Riggs wrote:
Uh, how would that work if you want to compress the background_FPWs?
Use compressed_background_FPWs?
We've currently got 1 technique for torn page protection, soon to have
2 and with a 3rd on the horizon and likely to receive
On Thu, May 29, 2014 at 02:21:57PM +0200, Andres Freund wrote:
On 2014-05-29 08:14:48 -0400, Peter Eisentraut wrote:
On 5/27/14, 10:37 PM, Tom Lane wrote:
If you don't like this change, we can revert it and also revert the
upgrade to 2.69.
Nobody else appears to be concerned, but I
On Thu, May 29, 2014 at 09:39:56AM -0700, Jeff Janes wrote:
What features in 9.4 need more beta testing for recovery?
I've applied my partial-write testing harness to several scenarios in 9.4. So
far its found a recovery bug for gin indexes, a recovery bug for btree, a
vacuum bug for btree
Bruce Momjian br...@momjian.us writes:
One thing that concerns me is that we already had the problem that users
creating the uuid-ossp extension had to double-quote the name because of
the dash, and we have regularly questioned the viability of the
uuid-ossp codebase.
Now that we know we
Josh Kupershmidt schmi...@gmail.com writes:
On Wed, May 28, 2014 at 11:23 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I've just committed regression test adjustments to prevent that from
being a failure case, but I am confused about why it's happening.
I wouldn't be surprised at not getting a MAC
On Thu, May 29, 2014 at 01:56:22PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
One thing that concerns me is that we already had the problem that users
creating the uuid-ossp extension had to double-quote the name because of
the dash, and we have regularly questioned the
Jeff Janes wrote:
One thing is that I want to find a way to drive multixact in fast forward,
so that the freezing cycle gets a good workout. Currently I can't consume
enough of them to make them wrap around within the time frame of a test.
IIRC I lobotomized it up by removing the XLogInsert()
On Sun, May 25, 2014 at 11:34 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
I noticed a couple of typos in Solution.pm, fixed by the patch
attached. Those things have been introduced by commits cec8394 (visual
2013 support) and 0a78320 (latest pgident run, not actually a problem
of
On 05/29/2014 09:39 AM, Jeff Janes wrote:
I've applied my partial-write testing harness to several scenarios in
9.4. So far its found a recovery bug for gin indexes, a recovery bug
for btree, a vacuum bug for btree indexes (with foreign keys, but that
is not relevant to the bug), and
Teodor Sigaev teo...@sigaev.ru writes:
I don't think that checkAllTheSame is broken, but it probably would be
after this patch --- ISTM you're breaking the corner case described in the
header comment for checkAllTheSame, where we need to force splitting of a
set of existing tuples that the
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Jeff Janes wrote:
One thing is that I want to find a way to drive multixact in fast forward,
so that the freezing cycle gets a good workout. Currently I can't consume
enough of them to make them wrap around within the time frame of a test.
IIRC
On 05/29/2014 02:38 PM, Tom Lane wrote:
Josh Kupershmidt schmi...@gmail.com writes:
On Wed, May 28, 2014 at 11:23 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I've just committed regression test adjustments to prevent that from
being a failure case, but I am confused about why it's happening.
I
On Sun, May 25, 2014 at 6:12 AM, Anastasia Lubennikova
lubennikov...@gmail.com wrote:
Hi, hackers!
There are first results of my work on GSoC project Index-only scans for
GIST.
Cool.
1. Version of my project code is in forked repository
On 05/29/2014 04:12 PM, John Lumby wrote:
Thanks for looking at it!
Date: Thu, 29 May 2014 00:19:33 +0300
From: hlinnakan...@vmware.com
To: johnlu...@hotmail.com; pgsql-hackers@postgresql.org
CC: klaussfre...@gmail.com
Subject: Re: [HACKERS] Extended Prefetching using Asynchronous IO -
One of the annoying things about the SPGiST bug Teodor pointed out is
that once you're in the infinite loop, query cancel doesn't work to get
you out of it. There are a couple of CHECK_FOR_INTERRUPTS() calls in
spgdoinsert() that are meant to get you out of exactly this sort of
buggy-opclass
On Thu, May 22, 2014 at 12:18 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Thu, May 22, 2014 at 12:44 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
Hi all,
As written in subject, replication protocol documentation lacks
details about logical slots in CREATE_REPLICATION_SLOT
On 05/29/2014 11:25 PM, Tom Lane wrote:
One of the annoying things about the SPGiST bug Teodor pointed out is
that once you're in the infinite loop, query cancel doesn't work to get
you out of it. There are a couple of CHECK_FOR_INTERRUPTS() calls in
spgdoinsert() that are meant to get you out
On Thu, May 29, 2014 at 5:23 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 05/29/2014 04:12 PM, John Lumby wrote:
Thanks for looking at it!
Date: Thu, 29 May 2014 00:19:33 +0300
From: hlinnakan...@vmware.com
To: johnlu...@hotmail.com; pgsql-hackers@postgresql.org
CC:
On Thu, May 29, 2014 at 1:34 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Also checking that CritSectionCount == 0 seems like a good idea...
What do you do if it isn't?
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On 05/29/2014 11:34 PM, Claudio Freire wrote:
On Thu, May 29, 2014 at 5:23 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 05/29/2014 04:12 PM, John Lumby wrote:
On 05/28/2014 11:52 PM, John Lumby wrote:
The patch seems to assume that you can put the aiocb struct in shared
memory,
Heikki Linnakangas hlinnakan...@vmware.com writes:
On 05/29/2014 11:25 PM, Tom Lane wrote:
In point of fact, we'd be happy to give up the locks and then throw
the error. So I was thinking about inventing some macro or out-of-line
function that went about like this:
if (InterruptPending
Peter Geoghegan p...@heroku.com writes:
On Thu, May 29, 2014 at 1:34 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Also checking that CritSectionCount == 0 seems like a good idea...
What do you do if it isn't?
Not throw the error. (If we did, it'd turn into a PANIC, which doesn't
On Thu, May 29, 2014 at 5:39 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 05/29/2014 11:34 PM, Claudio Freire wrote:
On Thu, May 29, 2014 at 5:23 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 05/29/2014 04:12 PM, John Lumby wrote:
On 05/28/2014 11:52 PM, John Lumby
On Thu, May 29, 2014 at 1:42 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Not throw the error. (If we did, it'd turn into a PANIC, which doesn't
seem like what we want.)
Of course, but it isn't obvious to me that that isn't what we'd want,
if the alternative is definitely that we'd be stuck in an
Peter Geoghegan p...@heroku.com writes:
On Thu, May 29, 2014 at 1:42 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Not throw the error. (If we did, it'd turn into a PANIC, which doesn't
seem like what we want.)
Of course, but it isn't obvious to me that that isn't what we'd want,
if the
Claudio Freire klaussfre...@gmail.com writes:
Didn't fix that, but the attached patch does fix regression tests when
scanning over index types other than btree (was invoking elog when the
index am didn't have ampeeknexttuple)
ampeeknexttuple? That's a bit scary. It would certainly be unsafe
On Thu, May 29, 2014 at 4:06 PM, Andrew Dunstan and...@dunslane.net wrote:
On 05/29/2014 02:38 PM, Tom Lane wrote:
Josh Kupershmidt schmi...@gmail.com writes:
Interesting. Looks like you have access only to virtual network
interfaces, and they report all-zero MAC addresses, which the UUID
On Thu, May 29, 2014 at 6:19 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Claudio Freire klaussfre...@gmail.com writes:
Didn't fix that, but the attached patch does fix regression tests when
scanning over index types other than btree (was invoking elog when the
index am didn't have ampeeknexttuple)
On Thu, May 29, 2014 at 6:43 PM, Claudio Freire klaussfre...@gmail.com wrote:
On Thu, May 29, 2014 at 6:19 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Claudio Freire klaussfre...@gmail.com writes:
Didn't fix that, but the attached patch does fix regression tests when
scanning over index types other
Date: Thu, 29 May 2014 18:00:28 -0300
Subject: Re: [HACKERS] Extended Prefetching using Asynchronous IO - proposal
and patch
From: klaussfre...@gmail.com
To: hlinnakan...@vmware.com
CC: johnlu...@hotmail.com; pgsql-hackers@postgresql.org
On Thu, May 29, 2014 at 5:39 PM, Heikki
Claudio Freire klaussfre...@gmail.com writes:
On Thu, May 29, 2014 at 6:43 PM, Claudio Freire klaussfre...@gmail.com
wrote:
On Thu, May 29, 2014 at 6:19 PM, Tom Lane t...@sss.pgh.pa.us wrote:
ampeeknexttuple? That's a bit scary. It would certainly be unsafe
for non-MVCC snapshots (read
From: t...@sss.pgh.pa.us
To: klaussfre...@gmail.com
CC: hlinnakan...@vmware.com; johnlu...@hotmail.com;
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Extended Prefetching using Asynchronous IO - proposal
and patch
Date: Thu, 29 May 2014 17:56:57 -0400
Claudio Freire
On Thu, May 29, 2014 at 6:56 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Claudio Freire klaussfre...@gmail.com writes:
On Thu, May 29, 2014 at 6:43 PM, Claudio Freire klaussfre...@gmail.com
wrote:
On Thu, May 29, 2014 at 6:19 PM, Tom Lane t...@sss.pgh.pa.us wrote:
ampeeknexttuple? That's a bit
On Thu, May 29, 2014 at 7:11 PM, John Lumby johnlu...@hotmail.com wrote:
Nonetheless, getting the next tid out of the index may involve stepping
to the next index page, at which point you've lost your interlock
I think we are ok as peeknexttuple (yes bad name, sorry, can change it
...
Hi,
On 2014-05-29 17:53:51 -0400, John Lumby wrote:
to see how we have done it. And I am attaching corrected version
of your test program which runs just fine.
It's perfectly fine to not be up to the coding style at this point, but
trying to adhere to it to some degree will make code review
Date: Thu, 29 May 2014 18:00:28 -0300
Subject: Re: [HACKERS] Extended Prefetching using Asynchronous IO - proposal
and patch
From: klaussfre...@gmail.com
To: hlinnakan...@vmware.com
CC: johnlu...@hotmail.com; pgsql-hackers@postgresql.org
Even if it worked on Linux today, it would
On Thu, May 29, 2014 at 6:53 PM, John Lumby johnlu...@hotmail.com wrote:
Well, as mentioned earlier, it is not broken. Whether it is efficient
I am not sure.
I have looked at the mutex in aio_suspend that you mentioned and I am not
quite convinced that, if caller is not the original
On Thu, May 29, 2014 at 7:26 PM, Claudio Freire klaussfre...@gmail.com wrote:
1) If it's the same process, wait for the full timeout (no looping).
If you have to loop (EAGAIN or EINTR - which I just noticed you don't
check for), that's ok.
Sorry, meant to say just looping on EINTR.
About the
On 05/29/2014 05:41 PM, Josh Kupershmidt wrote:
On Thu, May 29, 2014 at 4:06 PM, Andrew Dunstan and...@dunslane.net wrote:
Almost all my critters run in VMs (all but jacana and bowerbird).
They're not running on OpenVZ, are they? `ifconfig` on shearwater says:
[...]
and it seems this
On Fri, May 30, 2014 at 5:31 AM, Robert Haas robertmh...@gmail.com wrote:
Thanks, this looks good. But shouldn't the bit about output plugin
options mention say something like:
( option_name option_argument [, ...] )
...instead of just:
( option [, ...] )
?
Yes, true. Here is an updated
Here is a draft patch for some of the issues to do with unicode escapes
that Teodor raised the other day.
I think it does the right thing, although I want to add a few more
regression cases before committing it.
Comments welcome.
cheers
andrew
diff --git a/src/backend/utils/adt/json.c
On Thu, May 29, 2014 at 10:09 PM, Jeff Janes jeff.ja...@gmail.com wrote:
What features in 9.4 need more beta testing for recovery?
Another feature which have interaction with recovery is reduced WAL
for Update operation:
On Tue, May 27, 2014 at 12:11 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
The feature itself is already mentioned in the release notes in a very
general manner, by telling that bgworkers can be dynamically
registered and started. Users can still refer to the documentation
to see more
On Tue, May 27, 2014 at 8:15 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Since you will be flushing the buffers one redo partition at a time, you
would want to allow the OS to do merge the writes within a partition as much
as possible. So my even-odd split would in fact be pretty bad.
On Mon, May 26, 2014 at 10:47 PM, Shigeru Hanada
shigeru.han...@gmail.com wrote:
2014-05-24 0:09 GMT+09:00 Sandro Santilli s...@keybit.net:
Indeed I tried DISCARD ALL in hope it would have helped, so I find
good your idea of allowing extensions to register an hook there.
Still, I'd like the
On Wed, May 28, 2014 at 8:53 PM, Andres Freund and...@2ndquadrant.com
wrote:
Hi,
Since a64ca63e59c11d8fe6db24eee3d82b61db7c2c83 pg_sleep() uses
WaitLatch() to wait. That's fine in itself. But
procsignal_sigusr1_handler, which is used e.g. when resolving recovery
conflicts, doesn't
80 matches
Mail list logo
