2013-01-19 01:13 keltezéssel, Andrew Dunstan írta:
On 01/18/2013 05:43 PM, Boszormenyi Zoltan wrote:
Hi,
using the MinGW cross-compiled PostgreSQL binaries from Fedora 18,
I get the following error for both 32 and 64-bit compiled executables.
listen_addresses = '*' and "trust" authentication w
2013-01-19 06:52 keltezéssel, Amit kapila írta:
On Saturday, January 19, 2013 4:13 AM Boszormenyi Zoltan wrote:
Hi,
Unfortunately, I won't have time to do anything with my lock_timeout patch
for about 3 weeks. Does anyone have a little spare time to test it on Windows?
I shall try to do it,
2013-01-19 01:13 keltezéssel, Andrew Dunstan írta:
On 01/18/2013 05:43 PM, Boszormenyi Zoltan wrote:
Hi,
using the MinGW cross-compiled PostgreSQL binaries from Fedora 18,
I get the following error for both 32 and 64-bit compiled executables.
listen_addresses = '*' and "trust" authentication w
2013-01-19 02:03 keltezéssel, Andrew Dunstan írta:
On 01/18/2013 07:03 PM, Andrew Dunstan wrote:
It's not a good idea it seems.
Because that's only half of what I suggested.
This patch seems to do the right thing.
It probably needs to be applied to all the live branches.
cheers
and
2013-01-19 01:03 keltezéssel, Andrew Dunstan írta:
On 01/18/2013 05:45 PM, Boszormenyi Zoltan wrote:
2013-01-18 23:37 keltezéssel, Andrew Dunstan írta:
On 01/18/2013 05:19 PM, Boszormenyi Zoltan wrote:
2013-01-18 22:52 keltezéssel, Alvaro Herrera írta:
Boszormenyi Zoltan wrote:
I want to
On Friday, January 18, 2013 9:56 PM Andres Freund wrote:
On 2013-01-18 11:16:15 -0500, Tom Lane wrote:
> Andres Freund writes:
>>> > I am still stupefied nobody noticed that locking in HS (where just about
>>> > all locks are going to be fast path locks) was completely broken for
>>> > nearly two
On Saturday, January 19, 2013 2:37 AM Boszormenyi Zoltan wrote:
2013-01-18 21:48 keltezéssel, Boszormenyi Zoltan írta:
> 2013-01-18 21:32 keltezéssel, Tom Lane írta:
>> Boszormenyi Zoltan writes:
>>> 2013-01-18 11:05 keltezéssel, Amit kapila írta:
> On using mktemp, linux compilation gives be
On Saturday, January 19, 2013 4:13 AM Boszormenyi Zoltan wrote:
> Hi,
> Unfortunately, I won't have time to do anything with my lock_timeout patch
> for about 3 weeks. Does anyone have a little spare time to test it on Windows?
I shall try to do it, probably next week.
Others are also welcome
On Thu, Jan 17, 2013 at 2:04 PM, Simon Riggs wrote:
> On 17 January 2013 18:32, Josh Berkus wrote:
>> On 11/04/2012 07:22 PM, Qi Huang wrote:
>>> Dear hackers Sorry for not replying the patch review. I didn't see the
>>> review until recently as my mail box is full of Postgres mails and I di
On 01/18/2013 11:59 PM, Peter Eisentraut wrote:
The above is the way it's done everywhere else in the source tree.
I think the reason this works is that either make or the system call
that make uses is aware of this naming issue somehow.
Oh, hmm, all these years playing with this stuff and I
On Fri, 2013-01-18 at 17:37 -0500, Andrew Dunstan wrote:
> > ifdef PROGRAM
> > $(PROGRAM): $(OBJS)
> > - $(CC) $(CFLAGS) $(OBJS) $(PG_LIBS) $(LDFLAGS) $(LDFLAGS_EX)
> $(LIBS) -o $@
> > + $(CC) $(CFLAGS) $(OBJS) $(PG_LIBS) $(LDFLAGS) $(LDFLAGS_EX)
> $(LIBS) -o $@$(X)
> > endif
> >
>
>
On 01/18/2013 11:42 PM, Tom Lane wrote:
Andrew Dunstan writes:
This patch seems to do the right thing.
Hmm ... seems kinda grotty ... isn't there a cleaner way?
It probably needs to be applied to all the live branches.
Agreed on back-patching once we have the right thing, but I don't like
Andrew Dunstan writes:
> This patch seems to do the right thing.
Hmm ... seems kinda grotty ... isn't there a cleaner way?
> It probably needs to be applied to all the live branches.
Agreed on back-patching once we have the right thing, but I don't like
this version too much.
Hi,
I made a patch to divide privileges for replication role.
Currently(9.2), the privilege for replication role is
true / false which means that standby server is able to
connect to another server or not with the replication role.
This management and cascading replication make a strange behavio
> On Thu, Jan 17, 2013 at 7:43 PM, Tatsuo Ishii wrote:
>> So if my understating is correct, 1)Tomas Vondra commits to work on
>> Windows support for 9.4, 2)on the assumption that one of Andrew
>> Dunstan, Dave Page or Magnus Hagander will help him in Windows
>> development.
>>
>> Ok? If so, I can
On Tue, Jan 15, 2013 at 11:06 AM, Tom Lane wrote:
> Peter Eisentraut writes:
>> On 1/14/13 10:22 AM, Tom Lane wrote:
>>> Also it appears to me that the hunk at lines 812ff is changing the
>>> default behavior, which is not what the patch is advertised to do.
>
>> True, I had forgotten to mention
On 01/18/2013 07:03 PM, Andrew Dunstan wrote:
It's not a good idea it seems.
Because that's only half of what I suggested.
This patch seems to do the right thing.
It probably needs to be applied to all the live branches.
cheers
andrew
diff --git a/src/makefiles/pgxs.mk b/src/makefi
On 01/18/2013 05:43 PM, Boszormenyi Zoltan wrote:
Hi,
using the MinGW cross-compiled PostgreSQL binaries from Fedora 18,
I get the following error for both 32 and 64-bit compiled executables.
listen_addresses = '*' and "trust" authentication was set for both.
The firewall was disabled for the t
On 01/18/2013 05:45 PM, Boszormenyi Zoltan wrote:
2013-01-18 23:37 keltezéssel, Andrew Dunstan írta:
On 01/18/2013 05:19 PM, Boszormenyi Zoltan wrote:
2013-01-18 22:52 keltezéssel, Alvaro Herrera írta:
Boszormenyi Zoltan wrote:
I want to test my lock_timeout code under Windows and
I compi
On Sat, Dec 29, 2012 at 1:56 PM, Stephen Frost wrote:
> * Jon Erdman (postgre...@thewickedtribe.net) wrote:
>> Oops! Here it is in the proper diff format. I didn't have my env set up
>> correctly :(
>
> No biggie, and to get the bike-shedding started, I don't really like the
> column name or the
Stephen Frost writes:
> Tom,
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Don't see what. The main reason we've not yet attempted a global fix is
>> that the most straightforward way (take a new snapshot each time we
>> start a new SnapshotNow scan) seems too expensive. But CREATE DATABASE
>> is
2013-01-18 23:37 keltezéssel, Andrew Dunstan írta:
On 01/18/2013 05:19 PM, Boszormenyi Zoltan wrote:
2013-01-18 22:52 keltezéssel, Alvaro Herrera írta:
Boszormenyi Zoltan wrote:
I want to test my lock_timeout code under Windows and
I compiled the whole PG universe with the MinGW cross-compi
Hi,
using the MinGW cross-compiled PostgreSQL binaries from Fedora 18,
I get the following error for both 32 and 64-bit compiled executables.
listen_addresses = '*' and "trust" authentication was set for both.
The firewall was disabled for the tests and the server logs "incomplete startup
packet
On 01/18/2013 05:19 PM, Boszormenyi Zoltan wrote:
2013-01-18 22:52 keltezéssel, Alvaro Herrera írta:
Boszormenyi Zoltan wrote:
I want to test my lock_timeout code under Windows and
I compiled the whole PG universe with the MinGW cross-compiler
for 64-bit under Fedora 18.
The problem contrib
On Fri, Jan 18, 2013 at 5:12 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Jan 18, 2013 at 1:59 PM, Tom Lane wrote:
>>> Well, that burden already exists for non-utility statements --- why
>>> should utility statements get a pass? Other than that we tend to invent
>>> new utility syntax f
2013-01-18 22:52 keltezéssel, Alvaro Herrera írta:
Boszormenyi Zoltan wrote:
I want to test my lock_timeout code under Windows and
I compiled the whole PG universe with the MinGW cross-compiler
for 64-bit under Fedora 18.
The problem contrib directories where Makefile contains
PROGRAM =
Robert Haas writes:
> On Fri, Jan 18, 2013 at 1:59 PM, Tom Lane wrote:
>> Well, that burden already exists for non-utility statements --- why
>> should utility statements get a pass? Other than that we tend to invent
>> new utility syntax freely, which might be a good thing to discourage
>> anyh
Boszormenyi Zoltan wrote:
> I want to test my lock_timeout code under Windows and
> I compiled the whole PG universe with the MinGW cross-compiler
> for 64-bit under Fedora 18.
>
> The problem contrib directories where Makefile contains
> PROGRAM = ...
> The executables binaries are created
Hi,
I want to test my lock_timeout code under Windows and
I compiled the whole PG universe with the MinGW cross-compiler
for 64-bit under Fedora 18.
The problem contrib directories where Makefile contains
PROGRAM = ...
The executables binaries are created without the .exe suffix. E.g.:
[zoz
On Fri, Jan 18, 2013 at 1:59 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Andres Freund escribió:
>>> Dimitri's earlier patches had support for quite some commands via
>>> deparsing and while its a noticeable amount of code it seemed to work
>>> ok.
>>> The last revision I could dig out is
>>>
On Tue, Dec 25, 2012 at 1:47 AM, Michael Paquier
wrote:
>
>
> On Mon, Dec 24, 2012 at 12:44 AM, Phil Sorber wrote:
>>
>> Updated patch attached.
>
> Thanks. I am marking this patch as ready for committer.
>
> --
> Michael Paquier
> http://michael.otacoo.com
Updated patch is rebased against curre
On 2013-01-18 16:01:18 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-01-18 15:37:47 -0500, Tom Lane wrote:
> >> I doubt it ever came up before. What use is logging only the content of
> >> a buffer page? Surely you'd need to know, for example, which relation
> >> and page number it
2013-01-18 21:48 keltezéssel, Boszormenyi Zoltan írta:
2013-01-18 21:32 keltezéssel, Tom Lane írta:
Boszormenyi Zoltan writes:
2013-01-18 11:05 keltezéssel, Amit kapila írta:
On using mktemp, linux compilation gives below warning
warning: the use of `mktemp' is dangerous, better use `mkstemp'
Andres Freund writes:
> On 2013-01-18 15:37:47 -0500, Tom Lane wrote:
>> I doubt it ever came up before. What use is logging only the content of
>> a buffer page? Surely you'd need to know, for example, which relation
>> and page number it is from.
> It only got to be a length of 0 because the
2013-01-18 21:32 keltezéssel, Tom Lane írta:
Boszormenyi Zoltan writes:
2013-01-18 11:05 keltezéssel, Amit kapila írta:
On using mktemp, linux compilation gives below warning
warning: the use of `mktemp' is dangerous, better use `mkstemp'
So I planned to use mkstemp.
Good.
On my HPUX box, t
On 2013-01-18 15:37:47 -0500, Tom Lane wrote:
> Alvaro Herrera writes:
> > The reason is that there is an (unknown to me) rule that there must be
> > some data not associated with a buffer:
>
> > /*
> > * NOTE: We disallow len == 0 because it provides a useful bit of extra
> > * err
Alvaro Herrera writes:
> The reason is that there is an (unknown to me) rule that there must be
> some data not associated with a buffer:
> /*
>* NOTE: We disallow len == 0 because it provides a useful bit of extra
>* error checking in ReadRecord. This means that all caller
Boszormenyi Zoltan writes:
> 2013-01-18 11:05 keltezéssel, Amit kapila írta:
>> On using mktemp, linux compilation gives below warning
>> warning: the use of `mktemp' is dangerous, better use `mkstemp'
>>
>> So I planned to use mkstemp.
> Good.
On my HPUX box, the man page disapproves of both,
On 18 January 2013 20:02, Alvaro Herrera wrote:
> XLOG_HEAP2_LOCK_UPDATED
Every xlog record needs to know where to put the block.
Compare with XLOG_HEAP_LOCK
xlrec.target.node = relation->rd_node;
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Supp
Hi,
comments below.
2013-01-18 11:05 keltezéssel, Amit kapila írta:
On using mktemp, linux compilation gives below warning
warning: the use of `mktemp' is dangerous, better use `mkstemp'
So I planned to use mkstemp.
Good.
In Windows, there is an api _mktemp_s, followed by open call, behave
Alvaro Herrera wrote:
> Here's version 28 of this patch. The only substantive change here from
> v26 is that I've made GetTupleForTrigger() use either LockTupleExclusive
> or LockTupleNoKeyExclusive, depending on whether the key columns are
> being modified by the update. This needs to go through
Stephen Frost writes:
> Patch attached. Passes the regression tests and our internal testing
> shows that it eliminates the error we were seeing (and doesn't cause
> blocking, which is even better).
> We have a workaround in place for our build system (more-or-less
> "don't do that" ap
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> Tom Lane writes:
> > We already do: see text search templates. The code tends to call those
> > TSTEMPLATEs, so I'd suggest ACL_KIND_EXTTEMPLATE or some such. I agree
> > with Stephen's objection to use of the bare word "template".
>
> Yes, m
Tom Lane writes:
> We already do: see text search templates. The code tends to call those
> TSTEMPLATEs, so I'd suggest ACL_KIND_EXTTEMPLATE or some such. I agree
> with Stephen's objection to use of the bare word "template".
Yes, me too, but I had a hard time to convince myself of using such a
Alvaro Herrera writes:
> Andres Freund escribió:
>> Dimitri's earlier patches had support for quite some commands via
>> deparsing and while its a noticeable amount of code it seemed to work
>> ok.
>> The last revision I could dig out is
>> https://github.com/dimitri/postgres/blob/d2996303c7bc6daa
Stephen Frost writes:
> * Ali Dar (ali.munir@gmail.com) wrote:
>> Find attached an initial patch for ALTER RENAME RULE feature. Please
>> note that it does not have any documentation yet.
> Just took a quick look through this. Seems to be alright, but why do we
> allow renaming ON SELECT rul
Stephen Frost writes:
> 'Extension Template' is fine, I was just objecting to places in the code
> where it just says 'TEMPLATE'. I imagine we might have some 'XXX
> Template' at some point in the future and then we'd have confusion
> between "is this an *extension* template or an XXX template?".
On 2013-01-18 15:22:55 -0300, Alvaro Herrera wrote:
> Andres Freund escribió:
> > On 2013-01-18 12:44:13 -0500, Tom Lane wrote:
>
> > > An issue that would have to be thought about is that there are assorted
> > > scenarios where we generate "parse trees" that contain options that
> > > cannot be
On Fri, 2013-01-18 at 12:25 +0100, Stefan Keller wrote:
> Sounds good.
> Did you already had contact e.g. with Paul (cc'ed just in case)?
> And will this clever index also be available within all these hundreds
> of PostGIS functions?
Yes, I've brought the idea up to Paul before, but thank you.
I
Andres Freund escribió:
> On 2013-01-18 12:44:13 -0500, Tom Lane wrote:
> > An issue that would have to be thought about is that there are assorted
> > scenarios where we generate "parse trees" that contain options that
> > cannot be generated from SQL, so there's no way to reverse-list them
> > i
* Andres Freund (and...@2ndquadrant.com) wrote:
> On 2013-01-18 12:45:02 -0500, Stephen Frost wrote:
> > 'Template' seems like a really broad term which might end up being
> > associated with things beyond extensions, yet there are a number of
> > places where you just use 'TEMPLATE', eg, ACL_KIND_
* Ali Dar (ali.munir@gmail.com) wrote:
> Find attached an initial patch for ALTER RENAME RULE feature. Please
> note that it does not have any documentation yet.
Just took a quick look through this. Seems to be alright, but why do we
allow renaming ON SELECT rules at all, given that they must
On 2013-01-18 12:45:02 -0500, Stephen Frost wrote:
> * Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> > Please find attached a preliminary patch following the TEMPLATE ideas,
> > and thanks in particular to Tom and Heikki for a practical design about
> > how to solve that problem!
>
> Given th
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Why do we throw an error for too few arguments, but not too many?
Not sure offhand, though I could see how it might be useful. A use-case
might be that you have a variable template string which is user defined,
where they can choose from the arguments that
On 2013-01-18 12:44:13 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-01-18 11:42:47 -0500, Robert Haas wrote:
> >> I'm having trouble following this. Can you restate? I wasn't sure
> >> what you meant by libpqdump. I assumed you were speaking of a
> >> parsetree->DDL or catalog->DD
regression=# select format('%s %s', 'foo', 'bar');
format
-
foo bar
(1 row)
regression=# select format('%s %s', 'foo', 'bar', 'baz');
format
-
foo bar
(1 row)
regression=# select format('%s %s', 'foo');
ERROR: too few arguments for format
Why do we throw an
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> Please find attached a preliminary patch following the TEMPLATE ideas,
> and thanks in particular to Tom and Heikki for a practical design about
> how to solve that problem!
Given that it's preliminary and v0 and big and whatnot, it seems like
i
Andres Freund writes:
> On 2013-01-18 11:42:47 -0500, Robert Haas wrote:
>> I'm having trouble following this. Can you restate? I wasn't sure
>> what you meant by libpqdump. I assumed you were speaking of a
>> parsetree->DDL or catalog->DDL facility.
> Yea, that wasn't really clear, sorry for
Robert Haas writes:
> I took a quick look at this and am just curious why we're adding the
> requirement that t_tableOid has to be initialized?
I assume he meant it had been left at a random value, which is surely
bad practice even if a specific usage doesn't fall over today.
On 2013-01-18 11:48:43 -0500, Robert Haas wrote:
> On Fri, Jan 18, 2013 at 11:33 AM, Alvaro Herrera
> wrote:
> > Andres Freund wrote:
> >
> >> [09] Adjust all *Satisfies routines to take a HeapTuple instead of a
> >> HeapTupleHeader
> >>
> >> For timetravel access to the catalog we need to be abl
Andres Freund writes:
> On 2013-01-18 11:16:15 -0500, Tom Lane wrote:
>> I wonder if it'd be practical to, say, run all the contrib regression
>> tests concurrently in different databases of one installation.
> I think it would be a good idea, but I don't immediately have an idea
> how to impleme
On Thu, Jan 17, 2013 at 7:43 PM, Tatsuo Ishii wrote:
> So if my understating is correct, 1)Tomas Vondra commits to work on
> Windows support for 9.4, 2)on the assumption that one of Andrew
> Dunstan, Dave Page or Magnus Hagander will help him in Windows
> development.
>
> Ok? If so, I can commit t
On 2013-01-18 11:42:47 -0500, Robert Haas wrote:
> On Fri, Jan 18, 2013 at 10:47 AM, Andres Freund
> wrote:
> >> No, there's one also in heap_create_with_catalog. Took me a minute to
> >> find it, as it does not use InvokeObjectAccessHook. The idea is that
> >> OAT_POST_CREATE fires once per ob
Stephen Frost writes:
> [ quick review of patch ]
On reflection it seems to me that this is probably not a very good
approach overall. Our general theory for functions taking ANY has
been that the core system just computes the arguments and leaves it
to the function to make sense of them. Why s
On Fri, Jan 18, 2013 at 11:33 AM, Alvaro Herrera
wrote:
> Andres Freund wrote:
>
>> [09] Adjust all *Satisfies routines to take a HeapTuple instead of a
>> HeapTupleHeader
>>
>> For timetravel access to the catalog we need to be able to lookup (cmin,
>> cmax) pairs of catalog rows when were 'insi
Alvaro Herrera wrote:
> I had a look at this part. Running the regression tests unveiled a case
> where the tableOid wasn't being set (and thus caused an assertion to
> fail), so I added that. I also noticed that the additions to
> pruneheap.c are sometimes filling a tuple before it's strictly
>
On Fri, Jan 18, 2013 at 10:47 AM, Andres Freund wrote:
>> No, there's one also in heap_create_with_catalog. Took me a minute to
>> find it, as it does not use InvokeObjectAccessHook. The idea is that
>> OAT_POST_CREATE fires once per object creation, regardless of the
>> object type - table, col
Andres Freund wrote:
> [09] Adjust all *Satisfies routines to take a HeapTuple instead of a
> HeapTupleHeader
>
> For timetravel access to the catalog we need to be able to lookup (cmin,
> cmax) pairs of catalog rows when were 'inside' that TX. This patch just
> adapts the signature of the *Sati
On 2013-01-18 17:26:00 +0100, Andres Freund wrote:
> On 2013-01-18 11:16:15 -0500, Tom Lane wrote:
> > Andres Freund writes:
> > > I am still stupefied nobody noticed that locking in HS (where just about
> > > all locks are going to be fast path locks) was completely broken for
> > > nearly two ye
On 2013-01-18 11:16:15 -0500, Tom Lane wrote:
> Andres Freund writes:
> > I am still stupefied nobody noticed that locking in HS (where just about
> > all locks are going to be fast path locks) was completely broken for
> > nearly two years.
>
> IIUC it would only be broken for cases where activi
Andres Freund writes:
> I am still stupefied nobody noticed that locking in HS (where just about
> all locks are going to be fast path locks) was completely broken for
> nearly two years.
IIUC it would only be broken for cases where activity was going on
concurrently in two different databases, w
On 2013-01-18 11:11:50 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-01-18 10:33:16 -0500, Tom Lane wrote:
> >> Really I'd prefer not to move the backend definitions out of postgres.h
> >> at all, just because doing so will lose fifteen years of git history
> >> about those particular
Andres Freund writes:
> On 2013-01-18 10:33:16 -0500, Tom Lane wrote:
>> Really I'd prefer not to move the backend definitions out of postgres.h
>> at all, just because doing so will lose fifteen years of git history
>> about those particular lines (or at least make it a lot harder to
>> locate wi
On 2013-01-18 10:15:20 -0500, Robert Haas wrote:
> On Thu, Jan 17, 2013 at 9:00 PM, Andres Freund wrote:
> >> > I think it might also be a dangerous assumption for shared objects?
> >>
> >> Locks on shared objects can't be taken via the fast path. In order to
> >> take a fast-path lock, a backend
On 2013-01-18 10:33:16 -0500, Tom Lane wrote:
> Alvaro Herrera writes:
> > Here's a different idea: move all the Assert() and StaticAssert() etc
> > definitions from c.h and postgres.h into a new header, say pgassert.h.
> > That header is included directly by postgres.h (just like palloc.h and
> >
On Fri, Jan 18, 2013 at 10:36 AM, Merlin Moncure wrote:
> Any scenario that involves non-trivial amount of investigation or
> development should result in us pulling the patch for rework and
> resubmission in later 'festit's closing time as they say :-).
Amen.
--
Robert Haas
EnterpriseDB: h
On 2013-01-18 09:58:53 -0500, Robert Haas wrote:
> On Fri, Jan 18, 2013 at 9:07 AM, Andres Freund wrote:
> > I don't have a problem reusing the object access infrastructure at all. I
> > just
> > don't think its providing even remotely enough. You have (co-)written that
> > stuff, so you probably
Alvaro Herrera writes:
> One slight problem with this is the common port/*.c idiom would require
> an extra include:
> #ifndef FRONTEND
> #include "postgres.h"
> #else
> #include "postgres_fe.h"
> #include "pgassert.h" /* <--- new line required here */
> #endif /* FRONTEND */
> If this i
On Fri, Jan 18, 2013 at 8:57 AM, Atri Sharma wrote:
>
> Hello all,
>
> Sorry for the delay in updating the hackers list with the current status.
>
> I recently did some profiling using perf on PostgreSQL 9.2 with and without
> our patch.
>
> I noticed that maximum time is being spent on heapgettu
Alvaro Herrera wrote:
> Andres Freund wrote:
> > On 2013-01-18 15:48:01 +0100, Andres Freund wrote:
> > > Here's a trivially updated patch which also defines AssertArg() for
> > > FRONTEND-ish environments since Alvaro added one in xlogreader.c.
> >
> > This time for real. Please.
>
> Here's a di
Alvaro Herrera writes:
> Here's a different idea: move all the Assert() and StaticAssert() etc
> definitions from c.h and postgres.h into a new header, say pgassert.h.
> That header is included directly by postgres.h (just like palloc.h and
> elog.h already are) so we don't have to touch the backe
Andres Freund wrote:
> On 2013-01-18 15:48:01 +0100, Andres Freund wrote:
> > Here's a trivially updated patch which also defines AssertArg() for
> > FRONTEND-ish environments since Alvaro added one in xlogreader.c.
>
> This time for real. Please.
Here's a different idea: move all the Assert() an
On Thu, Jan 17, 2013 at 9:00 PM, Andres Freund wrote:
>> > I think it might also be a dangerous assumption for shared objects?
>>
>> Locks on shared objects can't be taken via the fast path. In order to
>> take a fast-path lock, a backend must be bound to a database and the
>> locktag must be for
On 2013-01-18 15:48:01 +0100, Andres Freund wrote:
> Here's a trivially updated patch which also defines AssertArg() for
> FRONTEND-ish environments since Alvaro added one in xlogreader.c.
This time for real. Please.
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL D
On 2013-01-09 15:07:10 -0500, Tom Lane wrote:
> I would like to know if other people get comparable results on other
> hardware (non-Intel hardware would be especially interesting). If this
> result holds up across a range of platforms, I'll withdraw my objection
> to making palloc a plain functio
On 18 January 2013 02:48, Tom Lane wrote:
> Andres Freund writes:
>> I have no problem requiring C code to use the even data, be it via hooks
>> or via C functions called from event triggers. The problem I have with
>> putting in some hooks is that I doubt that you can find sensible spots
>> with
* Peter Eisentraut (pete...@gmx.net) wrote:
> I noticed we don't implement the recursive view syntax, even though it's
> part of the standard SQL feature set for recursive queries. Here is a
> patch to add that. It basically converts
>
> CREATE RECURSIVE VIEW name (columns) AS SELECT ...;
>
> t
On Fri, Jan 18, 2013 at 9:07 AM, Andres Freund wrote:
> On 2013-01-17 22:39:18 -0500, Robert Haas wrote:
>> On Thu, Jan 17, 2013 at 8:33 PM, Andres Freund
>> wrote:
>> > I have no problem requiring C code to use the even data, be it via hooks
>> > or via C functions called from event triggers. T
On 18-Jan-2013, at 17:04, Craig Ringer wrote:
> On 12/14/2012 09:57 PM, Amit Kapila wrote:
>>>
>>> I need to validate the vacuum results. It's possible that this is
>>> solvable by tweaking xmin check inside vacuum. Assuming that's fixed,
>>> the question stands: do the results justify the cha
Pavel,
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> Now I fixed these issues and I hope so it will work on all platforms
As mentioned on the commitfest application, this needs documentation.
That is not the responsibility of the committer; if you need help, then
please ask for it.
I've al
On 2013-01-08 15:55:24 -0500, Tom Lane wrote:
> Alvaro Herrera writes:
> > Andres Freund wrote:
> >> Sorry, misremembered the problem somewhat. The problem is that code that
> >> includes postgres.h atm ends up with ExceptionalCondition() et
> >> al. declared even if FRONTEND is defined. So if any
Andres Freund escribió:
> On 2013-01-18 08:24:31 +0900, Michael Paquier wrote:
>
> > The replication delays are still here.
>
> That one is caused by this nice bug, courtesy of yours truly:
> diff --git a/src/backend/access/transam/xlog.c
> b/src/backend/access/transam/xlog.c
> index 90ba32e..11
On Fri, Jan 18, 2013 at 5:34 AM, Craig Ringer wrote:
> On 12/14/2012 09:57 PM, Amit Kapila wrote:
>>>
>>> I need to validate the vacuum results. It's possible that this is
>>> solvable by tweaking xmin check inside vacuum. Assuming that's fixed,
>>> the question stands: do the results justify the
On 2013-01-17 22:39:18 -0500, Robert Haas wrote:
> On Thu, Jan 17, 2013 at 8:33 PM, Andres Freund wrote:
> > I have no problem requiring C code to use the even data, be it via hooks
> > or via C functions called from event triggers. The problem I have with
> > putting in some hooks is that I doubt
On 17 January 2013 16:03, Thom Brown wrote:
> On 16 January 2013 17:25, Thom Brown wrote:
>
>> On 16 January 2013 17:20, Kevin Grittner wrote:
>>
>>> Thom Brown wrote:
>>>
>>> > Some weirdness:
>>> >
>>> > postgres=# CREATE VIEW v_test2 AS SELECT 1 moo;
>>> > CREATE VIEW
>>> > postgres=# CREATE
Heikki Linnakangas writes:
> You could still use environment variables and a service file to do it, but
> it's certainly more cumbersome. It clearly should be possible to pass a full
> connection string to pg_basebackup, that's an obvious oversight.
FWIW, +1. I would consider it a bugfix (backpat
On Friday, January 18, 2013 5:35 PM Heikki Linnakangas wrote:
> On 18.01.2013 13:41, Amit Kapila wrote:
> > On Friday, January 18, 2013 3:46 PM Heikki Linnakangas wrote:
> >> On 18.01.2013 08:50, Amit Kapila wrote:
> >>> I think currently user has no way to specify TCP keepalive settings
> >> from
Please find the rebased Patch for Compute MAX LSN.
There was one compilation error as "undefined reference to XLByteLT " as
earlier XLogRecPtr was a structure as
typedef struct XLogRecPtr
{
uint32xl
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Don't see what. The main reason we've not yet attempted a global fix is
> that the most straightforward way (take a new snapshot each time we
> start a new SnapshotNow scan) seems too expensive. But CREATE DATABASE
> is so expensive that the cost of
On 18.01.2013 06:38, Phil Sorber wrote:
On Tue, Jan 15, 2013 at 9:05 AM, Heikki Linnakangas
wrote:
Now that a standby server can follow timeline switches through streaming
replication, we should do teach pg_receivexlog to do the same. Patch
attached.
Is it possible to re-use walreceiver code
1 - 100 of 117 matches
Mail list logo
