On 04/25/2014 02:40 AM, Tom Lane wrote:
* The patch changes HeapTupleGetDatum from a simple inline macro into
a function call. This means that third-party extensions will not get
protection against creation of toast-pointer-containing composite Datums
until they recompile.
One consequence of t
Gurjeet Singh writes:
> I tried to eliminate the 'pending' list, but I don't see a way around it.
> We need temporary storage somewhere to store the branches encountered on
> the right; in recursion case the call stack was serving that purpose.
I still think we should fix this in the grammar, rat
On Thu, Apr 24, 2014 at 8:43 PM, Marti Raudsepp wrote:
> On Fri, Apr 25, 2014 at 3:36 AM, Tom Lane wrote:
> > Of course, the weak spot in this analysis is the assumption that there
> > are actually 122 independent bits in the value. It's not difficult to
> > imagine that systems with crummy ran
On Thu, 2014-04-24 at 13:45 -0400, Tom Lane wrote:
> Having said that, though, the argument around whether such facilities
> belong in core seems to devolve to whether you want to buy into
> maintaining libuuid for ourselves (in fact worse than that: it's not
> clear
> that libuuid ever has worked
* Craig Ringer (cr...@2ndquadrant.com) wrote:
> On 04/15/2014 10:06 AM, Stephen Frost wrote:
> > I've uploaded the latest patch, rebased against master, with my
> > changes to here: http://snowman.net/~sfrost/rls_ringerc_sf.patch.gz
> > as I don't believe it'd clear the mailing list (it's 29k).
>
On Thu, Jul 18, 2013 at 1:54 PM, Gurjeet Singh wrote:
> On Thu, Jul 18, 2013 at 10:19 AM, Tom Lane wrote:
>
>>
>> > Because simpler code is less likely to have bugs and is easier to
>> > maintain.
>>
>> I agree with that point, but one should also remember Polya's Inventor's
>> Paradox: the more
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/15/2014 10:06 AM, Stephen Frost wrote:
> I've uploaded the latest patch, rebased against master, with my
> changes to here: http://snowman.net/~sfrost/rls_ringerc_sf.patch.gz
> as I don't believe it'd clear the mailing list (it's 29k).
Does this
On Fri, Apr 25, 2014 at 3:36 AM, Tom Lane wrote:
> Of course, the weak spot in this analysis is the assumption that there
> are actually 122 independent bits in the value. It's not difficult to
> imagine that systems with crummy random() implementations might only have
> something like 32 bits wo
Marti Raudsepp writes:
> On Thu, Apr 24, 2014 at 8:40 PM, Josh Berkus wrote:
>> A pseudo-random UUID is frankly pretty
>> useless to me because (a) it's not really unique
> This is FUD. A pseudorandom UUID contains 122 bits of randomness. As
> long as you can trust the random number generator, t
On Thu, Apr 24, 2014 at 8:40 PM, Josh Berkus wrote:
> A pseudo-random UUID is frankly pretty
> useless to me because (a) it's not really unique
This is FUD. A pseudorandom UUID contains 122 bits of randomness. As
long as you can trust the random number generator, the chances of a
value occurring
I wrote:
> I'm actually planning to set this patch on the shelf for a bit and go
> investigate the other alternative, ie, not generating composite Datums
> containing toast pointers in the first place.
Here's a draft patch along those lines. It turned out to be best to
leave heap_form_tuple() alo
On Mon, Apr 21, 2014 at 11:57 PM, Peter Geoghegan wrote:
> Here is a benchmark that is similar to my earlier one, but with a rate
> limit of 125 tps, to help us better characterize how the prototype
> patch helps performance:
>
> http://postgres-benchmarks.s3-website-us-east-1.amazonaws.com/3-sec-
On 2014-04-24 12:43:13 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-04-24 11:02:44 -0400, Tom Lane wrote:
> >> FWIW, I like the LWLockAssignBatch idea a lot better than the currently
> >> proposed patch. LWLockAssign is a low-level function that has no business
> >> making risky ass
Alvaro Herrera wrote:
> Alvaro Herrera wrote:
>
> > I'm thinking about the comparison of full infomask as you propose
> > instead of just the bits that we actually care about. I think the only
> > thing that could cause a spurious failure (causing an extra execution of
> > the HeapTupleSatisfies
Last year, I built a pl/pgsql generator of "version 1-ish" UUIDs, which
would combine timestamps with local information to construct data that kind
of emulated the timestamp+MAC address that is version #1 of UUID.
Note that there are several versions of UUIDs:
1. Combines MAC address, timestamp,
Alvaro Herrera writes:
> Oh, I think I see your point: it's that no matter what we do here, there
> would be no way to guarantee that a value we generate does not collide
> with any other value elsewhere (either on other uuidserial columns, or
> on other servers).
Not that way, anyway.
> Because
Alvaro,
>> I don't understand your point. I'm only replying to Tom's assertion
>> that UUID generation might not be all that unique after all (or, in
>> other words, AIUI, that the "universally unique" part of the name is
>> wishful thinking and not an actual property of the real thing.)
>
> Oh,
On 04/24/2014 08:23 PM, Alvaro Herrera wrote:
Alvaro Herrera wrote:
Heikki Linnakangas wrote:
On 04/24/2014 08:00 PM, Alvaro Herrera wrote:
Tom Lane wrote:
This is not our fault, and I don't want us to get caught up in trying
to fix a fundamentally broken concept --- which is what a generic
Alvaro Herrera wrote:
> Heikki Linnakangas wrote:
> > On 04/24/2014 08:00 PM, Alvaro Herrera wrote:
> > >Tom Lane wrote:
> > >
> > >>This is not our fault, and I don't want us to get caught up in trying
> > >>to fix a fundamentally broken concept --- which is what a generic
> > >>"uuidserial" API w
Heikki Linnakangas wrote:
> On 04/24/2014 08:00 PM, Alvaro Herrera wrote:
> >Tom Lane wrote:
> >
> >>This is not our fault, and I don't want us to get caught up in trying
> >>to fix a fundamentally broken concept --- which is what a generic
> >>"uuidserial" API would be. If you try to paper over t
On 04/24/2014 03:46 AM, Dmitry Dolgov wrote:
> Hi all,
>
> As you know, PostgreSQL introduced Json(b) support at the 9.4 version [1],
> and hstore v2.0 saved in separate repository [2]. But although PostgreSQL
> has this support at the core level, there are many useful functions, which
> wasn't po
On 04/24/2014 10:00 AM, Alvaro Herrera wrote:
> Tom Lane wrote:
>
>> This is not our fault, and I don't want us to get caught up in trying
>> to fix a fundamentally broken concept --- which is what a generic
>> "uuidserial" API would be. If you try to paper over the difficulties
>> here, they'll
On 04/24/2014 08:00 PM, Alvaro Herrera wrote:
Tom Lane wrote:
This is not our fault, and I don't want us to get caught up in trying
to fix a fundamentally broken concept --- which is what a generic
"uuidserial" API would be. If you try to paper over the difficulties
here, they'll just bite you
Tom Lane wrote:
> This is not our fault, and I don't want us to get caught up in trying
> to fix a fundamentally broken concept --- which is what a generic
> "uuidserial" API would be. If you try to paper over the difficulties
> here, they'll just bite you on the rear someday.
But we have non-co
David Fetter writes:
> On Thu, Apr 24, 2014 at 11:30:15AM -0400, Tom Lane wrote:
>> Essentially, that would mean carrying around our own implementation
>> of libuuid --- which includes a bunch of not-terribly-portable
>> stuff, such as discovering the machine's MAC address(es). That's
>> not real
Andres Freund writes:
> On 2014-04-24 11:02:44 -0400, Tom Lane wrote:
>> FWIW, I like the LWLockAssignBatch idea a lot better than the currently
>> proposed patch. LWLockAssign is a low-level function that has no business
>> making risky assumptions about the context it's invoked in.
> I don't t
On Thu, Apr 24, 2014 at 11:30:15AM -0400, Tom Lane wrote:
> Hannu Krosing writes:
> > On 04/24/2014 04:57 PM, Tom Lane wrote:
> >> The reason why there's no generation function in core is that
> >> there is no standardized,
> >> guaranteed-to-produce-a-universally-unique-value generation
> >> algo
On 04/24/2014 07:24 PM, Andres Freund wrote:
On 2014-04-24 11:02:44 -0400, Tom Lane wrote:
Andres Freund writes:
On 2014-04-24 15:56:45 +0300, Heikki Linnakangas wrote:
Another idea is to add an LWLockAssignBatch(int) function that assigns a
range of locks in one call. That would be very simp
On 2014-04-24 11:02:44 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-04-24 15:56:45 +0300, Heikki Linnakangas wrote:
> >> Another idea is to add an LWLockAssignBatch(int) function that assigns a
> >> range of locks in one call. That would be very simple, and I think it would
> >> be l
Hannu Krosing writes:
> On 04/24/2014 04:57 PM, Tom Lane wrote:
>> The reason why there's no generation function in core is that there is no
>> standardized, guaranteed-to-produce-a-universally-unique-value generation
>> algorithm. That was the reason for not putting something in core when the
>>
Hi Everyone,
Sorry, i got this now. :)
Regards,
Rohit Goyal
On Thu, Apr 24, 2014 at 4:24 PM, Rohit Goyal wrote:
> Hi Peter/All,
>
> Can you please elaborate a bit in details the steps? where are how to run
> these steps?
>
> Regards,
> Rohit Goyal
>
>
> On Thu, Apr 24, 2014 at 6:57 AM, Peter
On 04/24/2014 04:57 PM, Tom Lane wrote:
> Simon Riggs writes:
>> On 24 April 2014 05:32, David Fetter wrote:
>>> Since contrib/pgcrypto is a module that might well not be installed,
>>> people can't just build software for PostgreSQL and have UUIDs
>>> available, certainly not in the sense that,
Andres Freund writes:
> On 2014-04-24 15:56:45 +0300, Heikki Linnakangas wrote:
>> Another idea is to add an LWLockAssignBatch(int) function that assigns a
>> range of locks in one call. That would be very simple, and I think it would
>> be less likely to break things than a new global flag. I wou
On Thu, Apr 24, 2014 at 11:21 AM, Pavel Stehule wrote:
>
> 2014-04-24 15:40 GMT+02:00 Marti Raudsepp :
>
> On Wed, Apr 23, 2014 at 11:26 AM, David Rowley
>> wrote:
>> > but for a long time I've thought that it would be nice if
>> > PostgreSQL came with an example database that had a number of tab
Simon Riggs writes:
> On 24 April 2014 05:32, David Fetter wrote:
>> Since contrib/pgcrypto is a module that might well not be installed,
>> people can't just build software for PostgreSQL and have UUIDs
>> available, certainly not in the sense that, for example, BIGSERIAL is.
> +1 to include in
Soroosh Sardari writes:
> In cost functions such as cost_seqscan, a RelOptinfo indicate a base
> relation.
> But there is no relfilenode in the RelOptinfo, So how could i find
> relfilenode or reloid of the relation?
You could get the table OID out of the associated RTE. But I fail to
see what
Just a quickie: I remember noticing earlier that a few comments on
functions would probably get mangled badly by pgindent. You probably
want to wrap them in /*- */ to avoid this. In a very quick glance
now I saw them in ecpg_get_data, ecpg_cursor_next_pos, ECPGfetch.
Perhaps you want to run
Hi Peter/All,
Can you please elaborate a bit in details the steps? where are how to run
these steps?
Regards,
Rohit Goyal
On Thu, Apr 24, 2014 at 6:57 AM, Peter Geoghegan wrote:
> On Wed, Apr 23, 2014 at 2:33 AM, Rohit Goyal wrote:
> > I am trying to install dbt2 on postgresql database.
> >
2014-04-24 15:40 GMT+02:00 Marti Raudsepp :
> On Wed, Apr 23, 2014 at 11:26 AM, David Rowley
> wrote:
> > but for a long time I've thought that it would be nice if
> > PostgreSQL came with an example database that had a number of tables,
> > perhaps that mock up some easy to relate to real-world
Hi
In cost functions such as cost_seqscan, a RelOptinfo indicate a base
relation.
But there is no relfilenode in the RelOptinfo, So how could i find
relfilenode or reloid of the relation?
Thanks,
Soroosh Sardari
On Wed, Apr 23, 2014 at 11:26 AM, David Rowley wrote:
> but for a long time I've thought that it would be nice if
> PostgreSQL came with an example database that had a number of tables,
> perhaps that mock up some easy to relate to real-world application. These
> would be very useful to use as exa
2014-04-24 14:50 keltezéssel, Michael Meskes írta:
Thanks an awful lot Antonin.
Committer availability might well be the issue, but missing review
probably too.
Yes, you're right. If my taks is mostly one last glance and a commit I will
make time for that.
Whether this review is enough to m
On 2014-04-24 15:56:45 +0300, Heikki Linnakangas wrote:
> On 04/17/2014 12:06 PM, Andres Freund wrote:
> >On 2014-04-16 19:33:52 -0400, Bruce Momjian wrote:
> >>On Tue, Feb 4, 2014 at 12:58:49AM +0100, Andres Freund wrote:
> >>>On 2014-02-03 11:22:45 -0500, Tom Lane wrote:
> Andres Freund wri
On 04/17/2014 12:06 PM, Andres Freund wrote:
On 2014-04-16 19:33:52 -0400, Bruce Momjian wrote:
On Tue, Feb 4, 2014 at 12:58:49AM +0100, Andres Freund wrote:
On 2014-02-03 11:22:45 -0500, Tom Lane wrote:
Andres Freund writes:
On larger, multi-socket, machines, startup takes a fair bit of ti
Thanks an awful lot Antonin.
> Committer availability might well be the issue, but missing review
> probably too.
Yes, you're right. If my taks is mostly one last glance and a commit I will
make time for that.
> Whether this review is enough to move the patch to "ready for committer"
> - I tend
Hi all,
The patch attached improves docs in fdwhandler.sgml a little bit.
Thanks,
Best regards,
Etsuro Fujita
diff --git a/doc/src/sgml/fdwhandler.sgml b/doc/src/sgml/fdwhandler.sgml
index 9c818cd..ffb38af 100644
--- a/doc/src/sgml/fdwhandler.sgml
+++ b/doc/src/sgml/fdwhandler.sgml
@@ -873,11 +8
On Thu, Apr 24, 2014 at 3:59 PM, Simon Riggs wrote:
> On 24 April 2014 05:32, David Fetter wrote:
>> Since contrib/pgcrypto is a module that might well not be installed,
>> people can't just build software for PostgreSQL and have UUIDs
>> available, certainly not in the sense that, for example, B
Hi all,
As you know, PostgreSQL introduced Json(b) support at the 9.4 version [1],
and hstore v2.0 saved in separate repository [2]. But although PostgreSQL
has this support at the core level, there are many useful functions, which
wasn't ported to Json(b) from hstore v2.0 and json. Here [3], I've
On 24/04/14 07:39, Craig Ringer wrote:
On 04/17/2014 08:35 AM, Craig Ringer wrote:
As far as I can tell we have a couple of options:
- Redefine what the exit codes mean so that exit 0 suppresses
auto-restart and exits silently. Probably simplest.
I'm now strongly in favour of this alternativ
On 24/04/14 09:26, Tatsuo Ishii wrote:
> Included is the graph (from PostgreSQL Enterprise Consortium's 2014
> report page 13: https://www.pgecons.org/downloads/43). I see up to 14%
> degration (at 128 concurrent users) comparing with 9.2.
That URL returns 'Forbidden'...
>>>
>
On 2014-04-24 09:46:07 +0200, Magnus Hagander wrote:
> On Thu, Apr 24, 2014 at 9:43 AM, Andres Freund wrote:
>
> > On 2014-04-24 09:39:21 +0200, Magnus Hagander wrote:
> > > I can't find that this discussion actually came to a proper consensus,
> > but
> > > I may be missing something. Did we go w
On Thu, Apr 24, 2014 at 9:43 AM, Andres Freund wrote:
> On 2014-04-24 09:39:21 +0200, Magnus Hagander wrote:
> > I can't find that this discussion actually came to a proper consensus,
> but
> > I may be missing something. Did we go with pg_recvlogical just because we
> > couldn't decide on a bette
On 2014-04-24 09:39:21 +0200, Magnus Hagander wrote:
> I can't find that this discussion actually came to a proper consensus, but
> I may be missing something. Did we go with pg_recvlogical just because we
> couldn't decide on a better name, or did we intentionally decide it was the
> best?
I went
On Mon, Sep 23, 2013 at 7:03 PM, Peter Geoghegan wrote:
> On Mon, Sep 23, 2013 at 9:54 AM, Andres Freund
> wrote:
> > I still find it wierd/inconsistent to have:
> > * pg_receivexlog
> > * pg_recvlogical
> > binaries, even from the same source directory. Why once "pg_recv" and
> > once "pg_recei
On Thu, Apr 24, 2014 at 8:49 AM, Michael Paquier
wrote:
> Hi all,
>
> I noticed that pg_recvlogical is not currently compiled on Windows
> when using the msvc scripts. The patch attached corrects that.
>
Applied, thanks.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redp
On 24 April 2014 05:32, David Fetter wrote:
> On Wed, Apr 23, 2014 at 08:27:52PM -0400, Tom Lane wrote:
>> David Fetter writes:
>> > Is there any good reason not to roll native UUID generation into
>> > our standard distribution?
>>
>> It's already there (as of 9.4) in pg_crypto.
>
> Sorry I wasn
56 matches
Mail list logo
