On 27 May 2014 18:18, Jeff Janes wrote:
> On Mon, May 26, 2014 at 8:15 PM, Robert Haas wrote:
>>
>> On Mon, May 26, 2014 at 1:22 PM, Heikki Linnakangas
>> wrote:
>> >>I don't think we know that. The server might have crashed before that
>> >>second record got generated. (This appears to be an u
On 27 May 2014 13:20, Heikki Linnakangas wrote:
> 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 ea
On 05/27/2014 11:55 PM, Robert Haas wrote:
On Tue, May 27, 2014 at 5:00 PM, Tom Lane 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
On Wed, May 28, 2014 at 7:31 AM, Gurjeet Singh wrote:
> Caveats
> --
>
> - Buffer list is saved only when Postgres is shutdown in "smart" and
> "fast" modes.
>
> That is, buffer list is not saved when database crashes, or on
"immediate"
> shutdown.
>
> - A reduction in `shared
On Tue, May 27, 2014 at 1:19 PM, Fujii Masao wrote:
> On Tue, May 27, 2014 at 3:57 PM, Simon Riggs
wrote:
> > The requirements we were discussing were around
> >
> > A) reducing WAL volume
> > B) reducing foreground overhead of writing FPWs - which spikes badly
> > after checkpoint and the overhe
On Tue, May 27, 2014 at 5:00 PM, Tom Lane 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 like the sort of
On Tue, May 27, 2014 at 11:20 PM, ash 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 can trace through
David G Johnston 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)
To make changes to your
Robert Haas 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:
>
> CREATE OR
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 automaticall
Peter Eisentraut 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 screaming abou
On 5/27/14, 2:41 PM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> On 27 May 2014 18:33:48 EEST, Tom Lane 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 hav
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:
http://www.postgresql.or
On Mon, May 26, 2014 at 10:39 AM, Stephen Frost wrote:
> * ash (a...@commandprompt.com) wrote:
>> This came up recently on general list (and I've just hit the same issue
>> today):
>>
>> http://www.postgresql.org/message-id/cab7npqtlmmn1ltb5we0v0do57ip0u73ykwzbzytaxdf1caw...@mail.gmail.com
>>
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.
.) Abi
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 h
On Wed, May 21, 2014 at 4:53 AM, Heikki Linnakangas
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 that checks what
> the
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 28, 2014 at 4:27 AM, Tom Lane 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 | N
> in
On 05/27/2014 07:17 PM, Tom Lane wrote:
Stephen Frost 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
Stephen Frost 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 just change be
On Tue, May 27, 2014 at 12:19 PM, Heikki Linnakangas
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 _bt_search() suggest
* 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 i
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 rende
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
On 05/27/2014 11:00 PM, Tom Lane wrote:
> Andrew Dunstan 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 built
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 questio
Andrew Dunstan 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 originally done
On 05/27/2014 11:30 PM, Peter Geoghegan wrote:
On Tue, May 27, 2014 at 12:19 PM, Heikki Linnakangas
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
On Tue, May 27, 2014 at 12:19 PM, Heikki Linnakangas
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
post-downlink-insert diagram, when the sp
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 ca
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
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, h
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 s
On Mon, May 26, 2014 at 12:33 PM, Amit Langote wrote:
> 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 PostgreSQL
>> Timbira
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 examp
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
pg
On 05/27/2014 09:47 PM, Peter Geoghegan wrote:
On Tue, May 27, 2014 at 4:54 AM, Heikki Linnakangas
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 with the incomplete-split
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 Tue, May 27, 2014 at 4:54 AM, Heikki Linnakangas
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 have been mo
Heikki Linnakangas writes:
> On 27 May 2014 18:33:48 EEST, Tom Lane 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 allow that in future). But
On Mon, May 26, 2014 at 8:15 PM, Robert Haas wrote:
> On Mon, May 26, 2014 at 1:22 PM, Heikki Linnakangas
> 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
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
On 27 May 2014 18:33:48 EEST, Tom Lane wrote:
>Alvaro Herrera 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
On May 27, 2014, at 7:44 AM, Tom Lane 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 not so familiar.
Alvaro Herrera 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 so compared to
Tom Lane wrote:
> Alvaro Herrera writes:
> > Why not --with-uuid-implementation=, and have 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 imple
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost 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 covering all
Alvaro Herrera writes:
> Why not --with-uuid-implementation=, and have 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 implementation in the future, t
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 open
Matteo Beccati 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 package
>
Tom Lane wrote:
> "David E. Wheeler" writes:
> > On May 26, 2014, at 9:30 PM, Tom Lane 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 "ext2" but that would j
Stephen Frost 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 that it's up
Hi Tom,
On 27/05/2014 15:52, Tom Lane wrote:
> Matteo Beccati 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 tes
* 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 desi
Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > Albe Laurenz 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 unpleasan
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 failed
* 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 c
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Albe Laurenz 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 cannot see a way ou
Matteo Beccati 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 out of th
* 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 sy
* 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 actuall
On 27 May 2014 07:42, Greg Stark wrote:
> On Tue, May 27, 2014 at 10:07 AM, Heikki Linnakangas
> 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 check
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 WAL
On 27 May 2014 03:49, Fujii Masao 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 two i
On 05/27/2014 02:42 PM, Greg Stark wrote:
On Tue, May 27, 2014 at 10:07 AM, Heikki Linnakangas
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 o
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 index
>> 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 Tue, May 27, 2014 at 10:07 AM, Heikki Linnakangas
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.
>
> Yeah. Simon
On 05/26/2014 02:26 PM, Greg Stark wrote:
On Mon, May 26, 2014 at 1:22 PM, Heikki Linnakangas
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 finished, the in-progress
c
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
> wrote:
> >
> > 2014-05-24 0:09 GMT+09:00 Sandro Santilli :
> > > Indeed I tried "DISCARD ALL" in hope it would have helped, so I find
> > > good your idea of allowing exten
On 05/26/2014 11:15 PM, Robert Haas wrote:
On Mon, May 26, 2014 at 1:22 PM, Heikki Linnakangas
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 record is generated bef
On Tue, May 27, 2014 at 3:57 PM, Simon Riggs wrote:
> On 25 May 2014 17:52, Heikki Linnakangas 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
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
>
David Fetter 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
> deterministi
75 matches
Mail list logo
