On Tue, Sep 11, 2012 at 10:35 AM, Jeff Davis wrote:
> On Tue, 2012-09-04 at 19:21 +0400, Alexander Korotkov wrote:
>
> > New version of patch is attached. Parameter "randomization" was
> > introduced. It controls whether to randomize choose. Choose algorithm
> > was rewritten.
> >
> Do you expect
On Tue, 2012-09-04 at 19:21 +0400, Alexander Korotkov wrote:
> New version of patch is attached. Parameter "randomization" was
> introduced. It controls whether to randomize choose. Choose algorithm
> was rewritten.
>
Do you expect it to be bad in any reasonable situations? I'm inclined to
just m
On 09/10/2012 05:19 PM, Bruce Momjian wrote:
> On Mon, Sep 10, 2012 at 12:06:18PM -0300, Alvaro Herrera wrote:
>>> It is this kind of run-around that caused me to generate my own doc
>>> build in the past; maybe I need to return to doing my own doc build.
>>
>> You keep threatening with that. You
On 08/18/2012 10:11 AM, John Lumby wrote:
>
I've recently tried extending the postgresql prefetch mechanism on linux
to use the posix (i.e. librt)
aio_read and friends where possible. In other words, in
PrefetchBuffer(), try getting a buffer
and issuing aio_read before falling back to fpo
On Mon, 2012-09-10 at 21:59 -0400, Dan Ports wrote:
> It might be worth noting that serializable mode will not cause
> read-only transactions to fail to commit
For the archives, and for those not following the paper in detail, there
is one situation in which SSI will abort a read-only transaction.
Ok, here is the patch to implement 64-bit API for large object, to
allow to use up to 4TB large objects(or 16TB if BLCKSZ changed to
32KB). The patch is based on Jeremy Drake's patch posted on September
23, 2005
(http://archives.postgresql.org/pgsql-hackers/2005-09/msg01026.php)
and reasonably upda
On Mon, Sep 10, 2012 at 11:19:00AM -0400, Bruce Momjian wrote:
> On Mon, Sep 10, 2012 at 12:06:18PM -0300, Alvaro Herrera wrote:
> > > It is this kind of run-around that caused me to generate my own doc
> > > build in the past; maybe I need to return to doing my own doc build.
> >
> > You keep th
On Sat, Sep 08, 2012 at 11:34:56AM -0700, Jeff Davis wrote:
> If so, I think we need a documentation update. The serializable
> isolation level docs don't quite make it clear that serializability only
> applies to transactions that commit. It might not be obvious to a user
> that there's a differen
On Mon, 2012-09-10 at 20:15 -0400, Tom Lane wrote:
> "David E. Wheeler" writes:
> > Well given that OSSP seems to be abandon ware (no activity since July
> > 2008), it might be time to dump it in favor of something else.
>
> Yeah, maybe. It doesn't even seem to be the "standard" implementation
On Mon, 2012-09-10 at 16:23 -0700, David E. Wheeler wrote:
> Well given that OSSP seems to be abandon ware (no activity since July
> 2008), it might be time to dump it in favor of something else.
Are there any outstanding issues that would require an update?
--
Sent via pgsql-hackers mailing l
"David E. Wheeler" writes:
> Well given that OSSP seems to be abandon ware (no activity since July 2008),
> it might be time to dump it in favor of something else.
Yeah, maybe. It doesn't even seem to be the "standard" implementation
on Linux or Mac. A bit of research says that Theodore Ts'o's
On Sep 10, 2012, at 4:16 PM, Tom Lane wrote:
> The long and the short of it is that the OSSP guys need to fix their
> code. I'm not excited about kluges like
>
>> +#define _XOPEN_SOURCE
>
> which might band-aid around their mistake, but at what price? We have
> no idea what side-effects that
"David E. Wheeler" writes:
> I ran into an issue building 9.2 with the OSSP UUID module today. A bit of
> Googling and I found that the MacPorts guys ran into the same issue a few
> weeks ago. Their discussion:
The long and the short of it is that the OSSP guys need to fix their
code. I'm not
Hackers,
I ran into an issue building 9.2 with the OSSP UUID module today. A bit of
Googling and I found that the MacPorts guys ran into the same issue a few weeks
ago. Their discussion:
https://trac.macports.org/ticket/35153
And the fix:
https://trac.macports.org/browser/trunk/dports/datab
On Mon, Sep 10, 2012 at 9:59 AM, Josh Berkus wrote:
>
>> The point of the proposal that I am making is to have a simple,
>> low-maintenance solution for people who need a single-application
>> database. A compromise somewhere in the middle isn't likely to be an
>> improvement for anybody. For in
On 09/10/2012 02:44 PM, Tom Lane wrote:
I wrote:
And the answer is ... it's a gmake bug. Apparently introduced in 3.82.
http://savannah.gnu.org/bugs/?30653
https://bugzilla.redhat.com/show_bug.cgi?id=835424
So I think .NOTPARALLEL is just masking the true problem, but
nonetheless it's a proble
I wrote:
> And the answer is ... it's a gmake bug. Apparently introduced in 3.82.
> http://savannah.gnu.org/bugs/?30653
> https://bugzilla.redhat.com/show_bug.cgi?id=835424
> So I think .NOTPARALLEL is just masking the true problem, but
> nonetheless it's a problem. And given that the bug report
Jeff Davis wrote:
> Oh, I see the distinction you're making: in PL/pgSQL, the
> exception mechanism involves *implicit* subtransaction rollbacks.
> That's more of a language issue, but a valid point.
I think it holds for the general case of functions -- there's no
reason to believe that you ar
On Mon, 2012-09-10 at 11:15 -0500, Kevin Grittner wrote:
> ... and I know Jeff read that quite closely because he raised a
> question off-list about an error he found in it which managed to
> survive the many editing and review passes that paper went through.
> :-)
Well, I need to keep up with th
The attached patch adds argument of OAT_POST_CREATE hook;
to inform extensions type of the context of this object creation. It allows
extensions to know whether the new object is indirectly created apart
from user's operations, or not.
I found out this flag is necessary to add feature to support s
Josh Berkus wrote:
> In fact, most of the folks who would want an embedded PostgreSQL
> either want no authentication at all, or only a single password.
> So supporting authentication options other than trust or md5 is
> not required, or desired AFAIK.
I don't know whether it's worth the trou
On 9/10/12 9:26 AM, Alvaro Herrera wrote:
> I remember trying to do this for the mb/conversion_procs subdir years
> ago, to make them build in parallel to save some time. It didn't go
> anywhere but the basic idea seems similar in spirit. Maybe we can use
> this there too to make it fast.
Parall
> The point of the proposal that I am making is to have a simple,
> low-maintenance solution for people who need a single-application
> database. A compromise somewhere in the middle isn't likely to be an
> improvement for anybody. For instance, if you want to have additional
> connections, you
Gurjeet Singh writes:
> On Mon, Sep 10, 2012 at 11:43 AM, Heikki Linnakangas wrote:
>> [scratches head] How's that different from the normal postmaster mode?
> As I described in later paragraphs, it'd behave like an embedded database,
> like SQLite etc., so the database will startup and shutdown
On Fri, Sep 7, 2012 at 6:06 PM, Kevin Grittner
wrote:
> That makes sense to me. The reason I didn't make that change when I
> added the serializable special case to pg_dump was that it seemed
> like a separate question; I didn't want to complicate an already big
> patch with unnecessary changes
On Mon, Sep 10, 2012 at 11:43 AM, Heikki Linnakangas wrote:
> On 10.09.2012 18:12, Gurjeet Singh wrote:
>
>> On Sun, Sep 2, 2012 at 8:23 PM, Tom Lane wrote:
>>
>> Notably, while the lack of any background processes is just what you want
>>> for pg_upgrade and disaster recovery, an ordinary appli
Jeff Davis wrote:
> This question comes about after reading the VLDB paper
> "Serializable Snapshot Isolation in PostgreSQL".
... and I know Jeff read that quite closely because he raised a
question off-list about an error he found in it which managed to
survive the many editing and review passe
On 10.09.2012 18:12, Gurjeet Singh wrote:
On Sun, Sep 2, 2012 at 8:23 PM, Tom Lane wrote:
Notably, while the lack of any background processes is just what you want
for pg_upgrade and disaster recovery, an ordinary application is probably
going to want to rely on autovacuum; and we need bgwrite
On Mon, Sep 10, 2012 at 11:12 AM, Gurjeet Singh wrote:
> On Sun, Sep 2, 2012 at 8:23 PM, Tom Lane wrote:
>>
>> Notably, while the lack of any background processes is just what you want
>> for pg_upgrade and disaster recovery, an ordinary application is probably
>> going to want to rely on autovac
On Mon, Sep 10, 2012 at 12:06:18PM -0300, Alvaro Herrera wrote:
> > It is this kind of run-around that caused me to generate my own doc
> > build in the past; maybe I need to return to doing my own doc build.
>
> You keep threatening with that. You are free, of course, to do anything
> you want,
On Sun, Sep 2, 2012 at 8:23 PM, Tom Lane wrote:
> Notably, while the lack of any background processes is just what you want
> for pg_upgrade and disaster recovery, an ordinary application is probably
> going to want to rely on autovacuum; and we need bgwriter and other
> background processes for
Excerpts from Bruce Momjian's message of lun sep 10 11:55:58 -0300 2012:
> On Sun, Sep 9, 2012 at 08:52:37PM +0200, Stefan Kaltenbrunner wrote:
> > why would we want to publish docs for something that fails to build
> > and/or fails to pass regression testing - to me code and the docs for it
> >
On Sun, Sep 9, 2012 at 08:52:37PM +0200, Stefan Kaltenbrunner wrote:
> On 09/06/2012 12:13 AM, Peter Eisentraut wrote:
> > On 8/29/12 11:52 PM, Andrew Dunstan wrote:
> Why does this need to be tied into the build farm? Someone can surely
> >>> set up a script that just runs the docs build at
On Sunday, September 09, 2012 1:37 PM Amit Kapila wrote:
On Friday, September 07, 2012 11:19 PM Tom Lane wrote:
Heikki Linnakangas writes:
>>> Would socketpair(2) be simpler?
>>I've not done anything yet about the potential security issues
>>associated with untrusted libpq connection strings.
On Mon, Sep 10, 2012 at 8:42 AM, Petr Chmelar wrote:
> Hi there,
>
> we tried to create the libpqtypes enum binary send but it doesn't work:
>
> // register types
> PGregisterType user_def[] = { {"seqtype", enum_put, enum_get} };
> PQregisterTypes(connector->getConn(), PQT_USERDEFINED, user_def, 1
Hi there,
we tried to create the libpqtypes enum binary send but it doesn't work:
// register types
PGregisterType user_def[] = { {"seqtype", enum_put, enum_get} };
PQregisterTypes(connector->getConn(), PQT_USERDEFINED, user_def, 1, 0);
// enum_put throws format error
int enum_put (PGtypeArgs *
Excerpts from Peter Eisentraut's message of lun sep 10 09:50:42 -0300 2012:
> On Sun, 2012-09-09 at 03:35 -0400, Tom Lane wrote:
> > >> Another problem is that Makefile.shlib isn't designed to build more
> > >> than one shared library per directory,
> >
> > > That's the main problem, but fixing it
On Sun, 2012-09-09 at 03:35 -0400, Tom Lane wrote:
> >> Another problem is that Makefile.shlib isn't designed to build more
> >> than one shared library per directory,
>
> > That's the main problem, but fixing it would be very useful in other
> > places as well. I had it on my radar to do somethi
This is really late, but ...
On 08/21/12 11:20 PM, Robert Haas wrote:
Our sinval synchronization mechanism has a somewhat weird design that
makes this OK.
... I don't want to miss the change to thank you, Robert, for the detailed
explanation. I have backported b4fbe392f8ff6ff1a66b488eb7197eef
39 matches
Mail list logo
