While speccing out a new B-Tree verification tool, I had the
opportunity to revisit a thought I had during review concerning
_bt_findinsertloc(): that the new coding is unsafe in the event of
deferred split completion of a leaf page of a unique index. To recap,
we now do the following in
On 25 May 2014 17:52, Heikki Linnakangas hlinnakan...@vmware.com wrote:
Here's an idea I tried to explain to Andres and Simon at the pub last night,
on how to reduce the spikes in the amount of WAL written at beginning of a
checkpoint that full-page writes cause. I'm just writing this down for
David Fetter da...@fetter.org writes:
Also worth considering: functions which take any part of the view
as a parameter.
Sorry, I don't get it: do you suggest we should re-create dependent
functions too?
I'd throw an error in cases where such functions had an obvious and
deterministic
Hi Tom,
On 27/05/2014 03:07, Tom Lane wrote:
I've verified functionality of this patch on these scenarios:
(1) --with-ossp-uuid on RHEL6, using uuid-1.6.1-10.el6.x86_64
(2) --with-linux-uuid on RHEL6, using libuuid-2.17.2-12.14.el6_5.x86_64
(3) --with-linux-uuid on OS X 10.9.3, Intel
(4)
On Tue, May 27, 2014 at 3:57 PM, Simon Riggs si...@2ndquadrant.com wrote:
On 25 May 2014 17:52, Heikki Linnakangas hlinnakan...@vmware.com wrote:
Here's an idea I tried to explain to Andres and Simon at the pub last night,
on how to reduce the spikes in the amount of WAL written at beginning
On 05/26/2014 11:15 PM, Robert Haas wrote:
On Mon, May 26, 2014 at 1:22 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
I don't think we know that. The server might have crashed before that
second record got generated. (This appears to be an unfixable flaw in
this proposal.)
The second
On Tue, May 27, 2014 at 12:32:50AM -0300, Fabrízio de Royes Mello wrote:
On Mon, May 26, 2014 at 11: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
On 05/26/2014 02:26 PM, Greg Stark wrote:
On Mon, May 26, 2014 at 1:22 PM, Heikki Linnakangas hlinnakan...@vmware.com
wrote:
The second record is generated before the checkpoint is finished and the
checkpoint record is written. So it will be there.
(if you crash before the checkpoint is
On Tue, May 27, 2014 at 10:07 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 05/26/2014 02:26 PM, Greg Stark wrote:
Another idea would be to have separate checkpoints for each buffer
partition. You would have to start recovery from the oldest checkpoint of
any of the partitions.
Additionally, I don't really see how that would be useful in a general
case.
With an in-core defined meaning of type transformation, any FDW that
doesn't
fit exactly into the model would have a hard time. For example, what
happens
if an FDW is only ever capable of returning text ?
On 05/27/2014 09:17 AM, Peter Geoghegan wrote:
While speccing out a new B-Tree verification tool, I had the
opportunity to revisit a thought I had during review concerning
_bt_findinsertloc(): that the new coding is unsafe in the event of
deferred split completion of a leaf page of a unique
On 05/27/2014 02:42 PM, Greg Stark wrote:
On Tue, May 27, 2014 at 10:07 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 05/26/2014 02:26 PM, Greg Stark wrote:
Another idea would be to have separate checkpoints for each buffer
partition. You would have to start recovery from the
On 27 May 2014 03:49, Fujii Masao masao.fu...@gmail.com wrote:
So that gives us a few approaches
* Compressing FPWs gives A
* Background FPWs gives us B
which look like we can combine both ideas
* Double-buffering would give us A and B, but not C
and would be incompatible with other
On 05/27/2014 03:18 PM, Simon Riggs wrote:
IIRC Koichi had a patch for prefetch during recovery. Heikki, is that
the reason you also discussed changing the WAL record format to allow
us to identify the blocks touched by recovery more easily?
Yeah, that was one use case I had in mind for the
On 27 May 2014 07:42, Greg Stark st...@mit.edu wrote:
On Tue, May 27, 2014 at 10:07 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 05/26/2014 02:26 PM, Greg Stark wrote:
Another idea would be to have separate checkpoints for each buffer
partition. You would have to start recovery
* David Fetter (da...@fetter.org) wrote:
- We make type mappings settable at the level of:
- FDW
- Instance (a.k.a. cluster)
- Database
- Schema
- Table
- Column
While I like the general idea, you seem to be making this appear much
more complex than it actually is.
* David Fetter (da...@fetter.org) wrote:
In the easy case of PostgreSQL, you might also be able to establish
whether the UDT in the already defined locally case above is
identical to the one defined remotely, but I don't think it's possible
even in principle for non-PostgreSQL remote systems,
Matteo Beccati p...@beccati.com writes:
On 27/05/2014 03:07, Tom Lane wrote:
I do not have a machine on which to try --with-bsd-uuid, so it's
possible I broke that portion of Matteo's patch. Would someone try
that case on a FreeBSD box?
I've tested on NetBSD i386 and --with-bsd-uuid worked
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Albe Laurenz laurenz.a...@wien.gv.at writes:
Oracle follows the SQL standard in folding table names to upper case.
So this would normally result in a lot of PostgreSQL foreign tables
with upper case names, which would be odd and unpleasant.
I
* Ronan Dunklau (ronan.dunk...@dalibo.com) wrote:
So, without extending the syntax too much, we could add options:
IMPORT FOREIGN SCHEMA remote_schema FROM SERVER server_name INTO local_schema
[ { LIMIT TO | EXCEPT } (table_name [, ...])]
[ OPTIONS (option_list) ]
This option list could
On 27/05/14 13:49, Ronan Dunklau wrote:
Between this and the type-mapping questions, it seems likely that
we're going to need a way for IMPORT FOREIGN SCHEMA to accept
user-supplied control options, which would in general be specific
to the FDW being used. (Another thing the SQL committee
Stephen Frost wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Albe Laurenz laurenz.a...@wien.gv.at writes:
Oracle follows the SQL standard in folding table names to upper case.
So this would normally result in a lot of PostgreSQL foreign tables
with upper case names, which would be odd
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
Stephen Frost wrote:
It seems like it would often be desirable for the Oracle FDW to smash
all-upper-case names to all-lower-case while importing, so that no quoting
is needed on either side. I doubt though that this is so desirable
Hi Tom,
On 27/05/2014 15:52, Tom Lane wrote:
Matteo Beccati p...@beccati.com writes:
On 27/05/2014 03:07, Tom Lane wrote:
I do not have a machine on which to try --with-bsd-uuid, so it's
possible I broke that portion of Matteo's patch. Would someone try
that case on a FreeBSD box?
I've
Stephen Frost sfr...@snowman.net writes:
Sure, I was being a bit over-simplistic. As was mentioned up-thread,
the option would rather be flip all-uppercase to lowercase and all-
lowercase to uppercase, quote any which are mixed, or something along
those lines. What I was trying to get at is
Tom Lane wrote:
David E. Wheeler da...@justatheory.com writes:
On May 26, 2014, at 9:30 PM, Tom Lane t...@sss.pgh.pa.us wrote:
How about --with-unix-uuid? Or --with-ext2-uuid?
Meh. Unix certainly subsumes BSD, so that doesn't seem like a very
useful distinction. I guess we could use
Matteo Beccati p...@beccati.com writes:
On 27/05/2014 15:52, Tom Lane wrote:
Ah, cool. I had documented this option as only working for FreeBSD,
but that's obviously too conservative. Anyone know about whether it
works on OpenBSD?
I've tried to google man uuid openbsd and I got the e2fs
On 2014-05-27 16:36:45 +0200, Matteo Beccati wrote:
On 27/05/2014 15:52, Tom Lane wrote:
Ah, cool. I had documented this option as only working for FreeBSD,
but that's obviously too conservative. Anyone know about whether it
works on OpenBSD?
I've tried to google man uuid openbsd and I
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Why not --with-uuid-implementation=impl, and have impl be one of
e2utils, bsd, ossp, with the latter being default? We could also have
offer the value list or help which would list the available options.
That way, if we come up with a new
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stephen Frost sfr...@snowman.net writes:
This, plus the generic ability to pass an OPTIONS clause to the IMPORT
(allowing you to have different defaults for different IMPORT
statements) and having it be transactional, as you mention, appears to
be
Tom Lane wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Why not --with-uuid-implementation=impl, and have impl be one of
e2utils, bsd, ossp, with the latter being default? We could also have
offer the value list or help which would list the available options.
That way, if we come
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Tom Lane wrote:
The problem is that the long-established spelling is --with-ossp-uuid.
I don't think we can break that case. While we could set up something
like what you propose alongside it, it doesn't seem like there's any
advantage to doing
On May 27, 2014, at 7:44 AM, Tom Lane t...@sss.pgh.pa.us wrote:
In either case, the problem remains of exactly what to call the
e2fsprogs-derived implementation. It does seem that people who are
familiar with these libraries call it that, but I'm worried that such
a name will confuse those
On 27 May 2014 18:33:48 EEST, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Tom Lane wrote:
The problem is that the long-established spelling is
--with-ossp-uuid.
I don't think we can break that case. While we could set up
something
like what you propose
Le mardi 27 mai 2014 09:52:27 Stephen Frost a écrit :
* David Fetter (da...@fetter.org) wrote:
In the easy case of PostgreSQL, you might also be able to establish
whether the UDT in the already defined locally case above is
identical to the one defined remotely, but I don't think it's
On Mon, May 26, 2014 at 8:15 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, May 26, 2014 at 1:22 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
I don't think we know that. The server might have crashed before that
second record got generated. (This appears to be an unfixable
Heikki Linnakangas hlinnakan...@vmware.com writes:
On 27 May 2014 18:33:48 EEST, Tom Lane t...@sss.pgh.pa.us wrote:
If we were going to do it like that, I'd vote for
--with-uuid={ossp,e2fs,bsd}
with no default at present (ie you can't say just --with-uuid,
though we'd have the option to
On Tue, May 27, 2014 at 4:54 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
The left sibling referred to here is the first page this key could
be on, an important concept for unique index enforcement.
No, it's not the first page this key could be on.
Well, it may be initially. I could
Feel free to flame me if I should be posting this elsewhere, but after reading
the submitting a patch guide, it appears I should ask for guidance here.
I was reading the Postgres MVCC documentation today (which is generally
fantastic BTW), and am slightly confused by a single sentence example,
On 05/27/2014 09:47 PM, Peter Geoghegan wrote:
On Tue, May 27, 2014 at 4:54 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Also note that _bt_moveright() also finishes any incomplete splits it
encounters (when called for an insertion). So _bt_findinsertloc() never gets
called on a page
One of these doesn't belong:
postgres=# select typname, typcategory from pg_type where typispreferred;
typname | typcategory
-+-
bool| B
text| S
oid | N
float8 | N
inet| I
timestamptz | D
interval| T
varbit | V
On 05/27/2014 10:12 PM, Evan Jones wrote:
I was reading the Postgres MVCC documentation today (which is
generally fantastic BTW), and am slightly confused by a single
sentence example, describing possible read-only snapshot isolation
anomalies. I would like to submit a patch to clarify this
On Mon, May 26, 2014 at 12:33 PM, Amit Langote amitlangot...@gmail.comwrote:
Hi,
Just noticed pg_llog is not mentioned in the Database File Layout
section. Wonder if it's an oversight?
Yes, it is an oversight. Patch attached.
Regards,
--
Fabrízio de Royes Mello
Consultoria/Coaching
Oh yeah, I shared an office with Dan so I should have thought to check their
paper. Oops. Thanks for the suggestion; I'll try to summarize this into
something that is similar to the Read Committed and Serializable mode examples.
It may take me a week or two to find the time, but thanks for the
I've been on the receiving end of a couple of mumbles about the fact
that the JSON rendering code ignores casts of builtin types to JSON.
This was originally done as an optimization to avoid doing cache lookups
for casts for things we knew quite well how to turn into JSON values
(unlike, say,
On 05/27/2014 10:53 PM, Andrew Dunstan wrote:
I've been on the receiving end of a couple of mumbles about the fact
that the JSON rendering code ignores casts of builtin types to JSON.
This was originally done as an optimization to avoid doing cache lookups
for casts for things we knew quite well
On 05/27/2014 03:57 PM, Heikki Linnakangas wrote:
On 05/27/2014 10:53 PM, Andrew Dunstan wrote:
I've been on the receiving end of a couple of mumbles about the fact
that the JSON rendering code ignores casts of builtin types to JSON.
This was originally done as an optimization to avoid doing
On Tue, May 27, 2014 at 12:19 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Ah, sorry, I got that wrong. The downlinks store the *low* key of the child
page, not the high key as I depicted. Let me try again:
Would you mind humoring me, and including a corrected final
On 05/27/2014 11:30 PM, Peter Geoghegan wrote:
On Tue, May 27, 2014 at 12:19 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Ah, sorry, I got that wrong. The downlinks store the *low* key of the child
page, not the high key as I depicted. Let me try again:
Would you mind humoring me,
Andrew Dunstan and...@dunslane.net writes:
On 05/27/2014 03:57 PM, Heikki Linnakangas wrote:
On 05/27/2014 10:53 PM, Andrew Dunstan wrote:
I've been on the receiving end of a couple of mumbles about the fact
that the JSON rendering code ignores casts of builtin types to JSON.
This was
On 5/22/14, 7:50 AM, Abhijit Menon-Sen wrote:
At 2014-05-22 07:22:42 -0400, pete...@gmx.net wrote:
We need a volunteer to manage the first commit fest.
I volunteer.
Congratulations, you're the new commit fest manager.
I trust that you know your way around, but if you have any questions
On 05/27/2014 11:00 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 05/27/2014 03:57 PM, Heikki Linnakangas wrote:
On 05/27/2014 10:53 PM, Andrew Dunstan wrote:
I've been on the receiving end of a couple of mumbles about the fact
that the JSON rendering code ignores casts of
Heikki Linnakangas-6 wrote
On 05/27/2014 10:12 PM, Evan Jones wrote:
I was reading the Postgres MVCC documentation today (which is
generally fantastic BTW), and am slightly confused by a single
sentence example, describing possible read-only snapshot isolation
anomalies. I would like to
On 05/27/2014 05:43 PM, Hannu Krosing wrote:
On 05/27/2014 11:00 PM, Tom Lane wrote:
See src/backend/utils/adt/json.c:json_categorize_type() lines 1280-1300.
When rendering some value as part of a json string, if a cast exists
from the data type to json, then the cast function is used to
* Andrew Dunstan (and...@dunslane.net) wrote:
I'd be inclined to think a more useful answer to this issue would be to
make json.c special-case timestamps, as it already does for numerics.
OK, that's another approach.
I'm all for doing this for JSON, but it'd sure be
On Tue, May 27, 2014 at 12:19 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Fair enough, but I don't think that affects correctness either way (I
don't think that you meant to imply that this was a necessary
precaution that you'd taken - right?).
Right.
So, the comments within
Stephen Frost sfr...@snowman.net writes:
* Andrew Dunstan (and...@dunslane.net) wrote:
Given that this would be a hard coded behaviour change, is it too
late to do this for 9.4?
No, for my 2c.
If we do it by adding casts then it'd require an initdb, so I'd vote
against that for 9.4. If we
On 05/27/2014 07:17 PM, Tom Lane wrote:
Stephen Frost sfr...@snowman.net writes:
* Andrew Dunstan (and...@dunslane.net) wrote:
Given that this would be a hard coded behaviour change, is it too
late to do this for 9.4?
No, for my 2c.
If we do it by adding casts then it'd require an initdb,
On Wed, May 28, 2014 at 4:27 AM, Tom Lane t...@sss.pgh.pa.us wrote:
One of these doesn't belong:
postgres=# select typname, typcategory from pg_type where typispreferred;
typname | typcategory
-+-
bool| B
text| S
oid | N
float8
Pushed; thanks for working on this!
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, May 21, 2014 at 4:53 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Hmm. The patch looks correct as far as it goes. But that function is still a
bit funny. When it compares two identical arrays (or objects), and reaches
the WJB_END_ARRAY token, it will still fall into the code
On Sat, May 17, 2014 at 10:36:59PM +0300, Marko Kreen wrote:
- Clarify ECDH decription in release notes.
- Fix default value - it's 'prime256v1'.
- List curves with good cross-platform support explicitly
(NIST P-256 / P-384 / P-521).
The -list_curves output is full of garbage, it's hard
Please find attached the updated code of Postgres Hibenator. Notable
changes since the first proposal are:
.) The name has been changed to pg_hibernator (from pg_hibernate), to
avoid confusion with the ORM Hibernate.
.) Works with Postgres 9.4
.) Uses DynamicBackgroundWorker infrastructure.
.)
On Mon, May 26, 2014 at 10:39 AM, Stephen Frost sfr...@snowman.net wrote:
* ash (a...@commandprompt.com) wrote:
This came up recently on general list (and I've just hit the same issue
today):
On 5/26/14, 1:25 PM, Tom Lane wrote:
Assuming this works as advertised, does anyone have an objection to
pushing it into 9.4?
Yes, it's way too late for that.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On 5/27/14, 2:41 PM, Tom Lane wrote:
Heikki Linnakangas hlinnakan...@vmware.com writes:
On 27 May 2014 18:33:48 EEST, Tom Lane t...@sss.pgh.pa.us wrote:
If we were going to do it like that, I'd vote for
--with-uuid={ossp,e2fs,bsd}
with no default at present (ie you can't say just
Peter Eisentraut pete...@gmx.net writes:
I'm shocked that this new feature has been committed post beta with less
than 48 hours of review time over a holiday weekend. This issue has
been known for years. Why does it need to be solved right now?
As per the commit message: our packagers were
Alexander Shulgin wrote
Hi Hackers,
This came up recently on general list (and I've just hit the same issue
today):
http://www.postgresql.org/message-id/
CAB7nPqTLmMn1LTb5WE0v0dO57iP0U73yKwzbZytAXDF1CAWLZg@.gmail
Why couldn't postgres re-create the dependent views automatically? I
Robert Haas robertmh...@gmail.com writes:
It'd need to be explicitly requested, eg a 'CASCADE' option.
Why? Would any sane person NOT want this behavior?
I think the question here is whether there's any way to make this work
at all, not whether we'd want it if we could get it. Consider:
David G Johnston david.g.johns...@gmail.com writes:
Would it be possible to handle the specific case of varchar(n) to
varchar/text by just ignoring the error?
Simply for the reference, my case is INT to BIGINT.
--
Alex
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
On Tue, May 27, 2014 at 11:20 PM, ash a...@commandprompt.com wrote:
Now, consider the situation in which we want to achieve the same
result without having to drop and recreate v. When the column type of
t.a is changed, we can use the dependencies to figure out that v might
be impacted. We
On Tue, May 27, 2014 at 5:00 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'd be inclined to think a more useful answer to this issue would be to
make json.c special-case timestamps, as it already does for numerics.
I wonder if anyone besides me is nervous about changing the semantics
here. It seems
On Tue, May 27, 2014 at 1:19 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Tue, May 27, 2014 at 3:57 PM, Simon Riggs si...@2ndquadrant.com
wrote:
The requirements we were discussing were around
A) reducing WAL volume
B) reducing foreground overhead of writing FPWs - which spikes badly
73 matches
Mail list logo
