Hi all,
I noticed that pg_recvlogical is not currently compiled on Windows
when using the msvc scripts. The patch attached corrects that.
Regards,
--
Michael
commit b552fbe5bc5ef705ee5a320f1afae66b40dcaedd
Author: Michael Paquier mich...@otacoo.com
Date: Thu Apr 24 15:46:26 2014 +0900
On 24 April 2014 05:32, David Fetter da...@fetter.org wrote:
On Wed, Apr 23, 2014 at 08:27:52PM -0400, Tom Lane wrote:
David Fetter da...@fetter.org 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
On Thu, Apr 24, 2014 at 8:49 AM, Michael Paquier
michael.paqu...@gmail.comwrote:
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/
On Mon, Sep 23, 2013 at 7:03 PM, Peter Geoghegan p...@heroku.com wrote:
On Mon, Sep 23, 2013 at 9:54 AM, Andres Freund and...@2ndquadrant.com
wrote:
I still find it wierd/inconsistent to have:
* pg_receivexlog
* pg_recvlogical
binaries, even from the same source directory. Why once
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 Thu, Apr 24, 2014 at 9:43 AM, Andres Freund and...@2ndquadrant.comwrote:
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
On 2014-04-24 09:46:07 +0200, Magnus Hagander wrote:
On Thu, Apr 24, 2014 at 9:43 AM, Andres Freund and...@2ndquadrant.comwrote:
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.
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'...
Sorry for this. I sent a
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
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],
On Thu, Apr 24, 2014 at 3:59 PM, Simon Riggs si...@2ndquadrant.com wrote:
On 24 April 2014 05:32, David Fetter da...@fetter.org 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
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
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 to
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 and...@2ndquadrant.com writes:
On larger, multi-socket, machines, startup
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
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
On Wed, Apr 23, 2014 at 11:26 AM, David Rowley dgrowle...@gmail.com 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
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
2014-04-24 15:40 GMT+02:00 Marti Raudsepp ma...@juffo.org:
On Wed, Apr 23, 2014 at 11:26 AM, David Rowley dgrowle...@gmail.com
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
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 p...@heroku.com wrote:
On Wed, Apr 23, 2014 at 2:33 AM, Rohit Goyal rhtgyl...@gmail.com wrote:
I am trying to install
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
Soroosh Sardari soroosh.sard...@gmail.com 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.
Simon Riggs si...@2ndquadrant.com writes:
On 24 April 2014 05:32, David Fetter da...@fetter.org 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,
On Thu, Apr 24, 2014 at 11:21 AM, Pavel Stehule pavel.steh...@gmail.comwrote:
2014-04-24 15:40 GMT+02:00 Marti Raudsepp ma...@juffo.org:
On Wed, Apr 23, 2014 at 11:26 AM, David Rowley dgrowle...@gmail.com
wrote:
but for a long time I've thought that it would be nice if
PostgreSQL came
Andres Freund and...@2ndquadrant.com 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
On 04/24/2014 04:57 PM, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
On 24 April 2014 05:32, David Fetter da...@fetter.org 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,
Hi Everyone,
Sorry, i got this now. :)
Regards,
Rohit Goyal
On Thu, Apr 24, 2014 at 4:24 PM, Rohit Goyal rhtgyl...@gmail.com 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
Hannu Krosing ha...@2ndquadrant.com 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
On 2014-04-24 11:02:44 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com 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
On 04/24/2014 07:24 PM, Andres Freund wrote:
On 2014-04-24 11:02:44 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com 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.
On Thu, Apr 24, 2014 at 11:30:15AM -0400, Tom Lane wrote:
Hannu Krosing ha...@2ndquadrant.com 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
Andres Freund and...@2ndquadrant.com 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
David Fetter da...@fetter.org 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
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
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
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 just bite
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 ported
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 the difficulties
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 would be. If you try
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,
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, I think I
Alvaro Herrera alvhe...@2ndquadrant.com 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
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 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 HeapTupleSatisfiesUpdate
On 2014-04-24 12:43:13 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com 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
On Mon, Apr 21, 2014 at 11:57 PM, Peter Geoghegan p...@heroku.com 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:
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() alone
On Thu, Apr 24, 2014 at 8:40 PM, Josh Berkus j...@agliodbs.com 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
Marti Raudsepp ma...@juffo.org writes:
On Thu, Apr 24, 2014 at 8:40 PM, Josh Berkus j...@agliodbs.com 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
On Fri, Apr 25, 2014 at 3:36 AM, Tom Lane t...@sss.pgh.pa.us 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
-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 Thu, Jul 18, 2013 at 1:54 PM, Gurjeet Singh gurj...@singh.im wrote:
On Thu, Jul 18, 2013 at 10:19 AM, Tom Lane t...@sss.pgh.pa.us 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
* 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).
Does
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 on
On Thu, Apr 24, 2014 at 8:43 PM, Marti Raudsepp ma...@juffo.org wrote:
On Fri, Apr 25, 2014 at 3:36 AM, Tom Lane t...@sss.pgh.pa.us 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
Gurjeet Singh gurj...@singh.im 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
56 matches
Mail list logo
