On 11/18/2013 02:06 AM, Rohit Goyal wrote:
> Hi All,
>
> I want to modify postgresql code for the first time.
> I tried to use netbeans to compile the code.
If you are doing something for the first time, do it exactly how the
documentation advises.
Once you've got it working that way, *THEN*
2013/11/20 Craig Ringer
> On 11/17/2013 08:40 AM, Tom Lane wrote:
> > That's an even worse idea than plain CREATE IF NOT EXISTS (which was
> > put in over vocal objections from me and some other people).
>
> I'm pretty uncomfortable with CREATE TABLE IF NOT EXISTS too - but it
> doesn't hurt some
Please look at elog() with right error code like DEBUG or NOTICE.
On Sun, Nov 17, 2013 at 11:36 PM, Rohit Goyal wrote:
> Hi All,
>
> I want to modify postgresql code for the first time.
> I tried to use netbeans to compile the code.
>
> Now, I wanted to print something on console when I create
On 11/17/2013 08:40 AM, Tom Lane wrote:
> That's an even worse idea than plain CREATE IF NOT EXISTS (which was
> put in over vocal objections from me and some other people).
I'm pretty uncomfortable with CREATE TABLE IF NOT EXISTS too - but it
doesn't hurt someone who doesn't use it and it does ha
On Wed, Nov 20, 2013 at 2:05 AM, Christopher Browne wrote:
> On Mon, Nov 18, 2013 at 1:01 AM, Amit Kapila wrote:
>> On Sat, Nov 16, 2013 at 4:57 AM, Christopher Browne
>> wrote:
>
> I picked the location of the 'g:' in the opt_long() call basically
> arbitrarily;
I think this is okay, the
On Wed, Nov 20, 2013 at 2:10 AM, Peter Eisentraut wrote:
>
> On Mon, 2013-11-18 at 11:16 -0200, Fabrízio de Royes Mello wrote:
> > I'm planning to implement it for the next commit fest (2014-01)...
>
> This email was registered in the commit fest as a patch, but contains no
> patch and you indicat
On Tue, Nov 19, 2013 at 12:12 PM, Jeff Janes wrote:
>> > The same idea was proposed before but not committed because
>> > Itagaki thought that pg_stat_statements view should report only raw
>> > values.
>> > Please read the following thread. I have the same feeling with him.
>> > Anyway we should
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> The issue is that if you want to dig column type information out
> Tom> of a function RTE, that won't necessarily work after
> Tom> preprocess_expression has had its way with the contained
> Tom> expressions. That's needed at the very
Patch needs to be rebased again.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, 2013-11-18 at 11:16 -0200, Fabrízio de Royes Mello wrote:
> I'm planning to implement it for the next commit fest (2014-01)...
This email was registered in the commit fest as a patch, but contains no
patch and you indicate that it belongs in different commit fest. Please
sort that out.
On Tue, Nov 19, 2013 at 7:32 PM, Tom Lane wrote:
> Paul Ramsey writes:
>> As we've added different kinds of caching, in our own project, we've banged
>> up against problems of multiple functions trying to stuff information into
>> the same pointer, and ended up putting an extra container of our
Peter Eisentraut writes:
> With the attached patch, that warning goes way, and the logic is
> arguably slightly clearer, too.
No objection.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
htt
Paul Ramsey writes:
> As we've added different kinds of caching, in our own project, we've banged
> up against problems of multiple functions trying to stuff information into
> the same pointer, and ended up putting an extra container of our own into
> fn_extra, to hold the different kinds of s
Andres Freund writes:
> On 2013-11-19 22:09:48 +0900, Michael Paquier wrote:
>> On Tue, Nov 19, 2013 at 2:27 AM, Andres Freund
>> wrote:
>>> * Why did you change some of the recovery gucs to lowercase names, but
>>> left out XLogRestoreCommand?
>> This was part of the former patch, perhaps you
Bruce Momjian writes:
> Does anyone know if this C comment justifies why ABORT is a NOTICE and
> not WARNING?
> /*
> * The user issued ABORT when not inside a transaction. Issue a
> * NOTICE and go to abort state. The upcoming call to
> * Commit
On Wed, 2013-11-13 at 12:43 -0500, Tom Lane wrote:
> Kevin Grittner writes:
> > If nobody objects, I'll fix that small memory leak in the
> > regression test driver. Hopefully someone more familiar with
> > pg_basebackup will fix the double-free (and related problems
> > mentioned by Tom) in strea
On Nov 19, 2013, at 4:05 PM, Andres Freund wrote:
> Hi,
>
> On 2013-11-19 15:53:36 -0800, Christophe Pettus wrote:
>> From my understanding, the problem only occurs over streaming
>> replication; if the secondary was never a hot standby, and only used
>> the archived WAL segments, that would be
On 2013-11-19 15:41:58 -0800, Josh Berkus wrote:
> On 11/19/2013 06:20 AM, Andres Freund wrote:
> > Imo this warrants and expedited point release :(
>
> Yes, I agree. I'd go further and say it's worth releasing source as
> soon as we have it on this one.
>
> What amount of testing were you able
Hi,
On 2013-11-19 15:53:36 -0800, Christophe Pettus wrote:
> From my understanding, the problem only occurs over streaming
> replication; if the secondary was never a hot standby, and only used
> the archived WAL segments, that would be safe. Is that correct?
Not entirely.
It's related to a sta
Hi, Andres,
>From my understanding, the problem only occurs over streaming replication; if
>the secondary was never a hot standby, and only used the archived WAL
>segments, that would be safe. Is that correct?
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pgsql-hackers mailing li
On 11/14/2013 12:26 PM, Andres Freund wrote:
Hello,
As you know, the reason we are working changeset extraction is that we
want to build logical unidirection and bidirectional replication
ontop. To use changeset extraction effectively, I think one set of
related features ontop is very useful:
W
On 11/19/2013 06:20 AM, Andres Freund wrote:
> Imo this warrants and expedited point release :(
Yes, I agree. I'd go further and say it's worth releasing source as
soon as we have it on this one.
What amount of testing were you able to give your patch? We're trying
to arrange some testing on ou
On Mon, Nov 18, 2013 at 08:48:13PM -0500, Peter Eisentraut wrote:
> On Tue, 2013-11-05 at 18:29 +0200, Oskari Saarenmaa wrote:
> > This can be used to tag custom built packages with an extra version string
> > such as the git describe id or distribution package release version.
>
> I think this is
On Fri, Nov 15, 2013 at 11:19 AM, Alexander Korotkov
wrote:
> On Fri, Nov 15, 2013 at 12:34 AM, Heikki Linnakangas <
> hlinnakan...@vmware.com> wrote:
>
>> On 14.11.2013 19:26, Alexander Korotkov wrote:
>>
>>> On Sun, Jun 30, 2013 at 3:00 PM, Heikki Linnakangas <
>>> hlinnakan...@vmware.com
>>>
>>
As an extension with a lot of CPU load, we (postgis) tend to use
flinfo->fn_extra a lot, for caching things that are intensive to calculate at
the start of a query and reuse throughout subsequent functions calls.
- coordinate projection objects
- indexes of the edges of large geometries
- other
On 2013-11-19 17:25:21 -0500, Bruce Momjian wrote:
> On Tue, Nov 19, 2013 at 11:21:06PM +0100, Andres Freund wrote:
> > On 2013-11-19 17:16:56 -0500, Bruce Momjian wrote:
> > > On Tue, Nov 19, 2013 at 10:39:19PM +0100, Andres Freund wrote:
> > Do you mean inline? Or atomics? If the former no, if th
On Tue, Nov 19, 2013 at 11:21:06PM +0100, Andres Freund wrote:
> On 2013-11-19 17:16:56 -0500, Bruce Momjian wrote:
> > On Tue, Nov 19, 2013 at 10:39:19PM +0100, Andres Freund wrote:
> > > On 2013-11-19 16:37:32 -0500, Bruce Momjian wrote:
> > > > On Tue, Nov 19, 2013 at 04:34:59PM +0100, Andres Fr
On 2013-11-19 17:16:56 -0500, Bruce Momjian wrote:
> On Tue, Nov 19, 2013 at 10:39:19PM +0100, Andres Freund wrote:
> > On 2013-11-19 16:37:32 -0500, Bruce Momjian wrote:
> > > On Tue, Nov 19, 2013 at 04:34:59PM +0100, Andres Freund wrote:
> > > > On 2013-11-19 10:30:24 -0500, Tom Lane wrote:
> > >
On Tue, Nov 19, 2013 at 10:39:19PM +0100, Andres Freund wrote:
> On 2013-11-19 16:37:32 -0500, Bruce Momjian wrote:
> > On Tue, Nov 19, 2013 at 04:34:59PM +0100, Andres Freund wrote:
> > > On 2013-11-19 10:30:24 -0500, Tom Lane wrote:
> > > > > I don't have an informed opinion about requiring inlin
On 19 November 2013 23:02, Szymon Guz wrote:
> On 19 November 2013 22:54, Kevin Grittner wrote:
>
>> Szymon Guz wrote:
>>
>> > is clang supported for compiling Postgres? I found some websites
>> > with information that some people compiled Postgres succesfully,
>> > but I got plenty of errors e
On 19 November 2013 22:54, Kevin Grittner wrote:
> Szymon Guz wrote:
>
> > is clang supported for compiling Postgres? I found some websites
> > with information that some people compiled Postgres succesfully,
> > but I got plenty of errors even with running ./configure. So I'm
> > wondering if i
On Tue, Nov 19, 2013 at 11:26:34AM -0500, Tom Lane wrote:
> Robert Haas writes:
> >> However, pggit log 9f0ae0c82060e3dcd1fa7ac8bbe35a3f9a44dbba does not
> >> show that line being added by the diff.
>
> > I dunno what your pggit script does, but "git log" doesn't normally
> > show the diff at all
Szymon Guz wrote:
> is clang supported for compiling Postgres? I found some websites
> with information that some people compiled Postgres succesfully,
> but I got plenty of errors even with running ./configure. So I'm
> wondering if it's my fault, however gcc works properly.
I am able to build
Hi,
is clang supported for compiling Postgres? I found some websites with
information that some people compiled Postgres succesfully, but I got
plenty of errors even with running ./configure. So I'm wondering if it's my
fault, however gcc works properly.
thanks,
Szymon
On 2013-11-19 16:37:32 -0500, Bruce Momjian wrote:
> On Tue, Nov 19, 2013 at 04:34:59PM +0100, Andres Freund wrote:
> > On 2013-11-19 10:30:24 -0500, Tom Lane wrote:
> > > > I don't have an informed opinion about requiring inline support
> > > > (although it would surely be nice).
> > >
> > > inli
On Tue, Nov 19, 2013 at 04:34:59PM +0100, Andres Freund wrote:
> On 2013-11-19 10:30:24 -0500, Tom Lane wrote:
> > > I don't have an informed opinion about requiring inline support
> > > (although it would surely be nice).
> >
> > inline is C99, and we've generally resisted requiring C99 features.
On 11/19/2013 04:23 PM, Andres Freund wrote:
On 2013-11-19 16:04:12 -0500, Andrew Dunstan wrote:
On 11/19/2013 03:54 PM, Andres Freund wrote:
On 2013-11-19 12:45:27 -0800, Josh Berkus wrote:
On 11/19/2013 08:42 AM, Andres Freund wrote:
Could you explain a bit what the use case of this is and
On 2013-11-19 16:04:12 -0500, Andrew Dunstan wrote:
>
> On 11/19/2013 03:54 PM, Andres Freund wrote:
> >On 2013-11-19 12:45:27 -0800, Josh Berkus wrote:
> >>On 11/19/2013 08:42 AM, Andres Freund wrote:
> >>>Could you explain a bit what the use case of this is and why it's not
> >>>sufficient to al
> "Tom" == Tom Lane writes:
>> Inlining should already check that the type doesn't change as a
>> result; where exactly is the issue here?
Tom> The issue is that if you want to dig column type information out
Tom> of a function RTE, that won't necessarily work after
Tom> preprocess_expr
On Tue, Nov 19, 2013 at 1:22 PM, Josh Berkus wrote:
> On 11/19/2013 10:12 AM, Robert Haas wrote:
>> On Tue, Nov 19, 2013 at 1:10 PM, Fujii Masao wrote:
>>> On Tue, Nov 19, 2013 at 11:51 PM, Robert Haas wrote:
On Fri, Nov 15, 2013 at 9:01 PM, Fabrízio de Royes Mello
http://www.postgresq
On 11/19/2013 03:54 PM, Andres Freund wrote:
On 2013-11-19 12:45:27 -0800, Josh Berkus wrote:
On 11/19/2013 08:42 AM, Andres Freund wrote:
Could you explain a bit what the use case of this is and why it's not
sufficient to allow constraint triggers to work on a statement level?
"Just" that the
On 2013-11-19 12:45:27 -0800, Josh Berkus wrote:
> On 11/19/2013 08:42 AM, Andres Freund wrote:
> > Could you explain a bit what the use case of this is and why it's not
> > sufficient to allow constraint triggers to work on a statement level?
> > "Just" that there would be multiple ones fired?
>
On 11/19/2013 08:42 AM, Andres Freund wrote:
> Could you explain a bit what the use case of this is and why it's not
> sufficient to allow constraint triggers to work on a statement level?
> "Just" that there would be multiple ones fired?
The main reason is to enforce arbitrary assertions which ne
Andres Freund writes:
> On 2013-11-19 13:09:16 -0500, Bruce Momjian wrote:
>> Because as Tom stated, we already do warnings for other useless
>> transaction commands like BEGIN WORK inside a transaction block:
>
> Which imo is a bad, bad historical accident. I've repeatedly seen this
> hide bugs c
On Mon, Nov 18, 2013 at 1:01 AM, Amit Kapila wrote:
> On Sat, Nov 16, 2013 at 4:57 AM, Christopher Browne
> wrote:
> Few comments:
>
> 1.
> + -g
> + --roles
>
> All other options which require argument are of form:
> -c class="parameter">number
> --connection-limit= class="para
On 11/19/2013 03:06 PM, Merlin Moncure wrote:
Therefore I am interested only in supporting two:
a) the legacy behavior from 9.2 and 9.3 so we don't destroy people's
I'm uncomfortable with the word 'legacy'. This suggests the new type
will essentially deprecate the old type.
"Existing"
On 2013-11-19 22:09:48 +0900, Michael Paquier wrote:
> On Tue, Nov 19, 2013 at 2:27 AM, Andres Freund wrote:
> > * --write-standby-enable seems to loose quite some functionality in
> > comparison to --write-recovery-conf since it doesn't seem to set
> > primary_conninfo, standby anymore.
> Ye
On Tue, Nov 19, 2013 at 01:37:56PM -0500, Bruce Momjian wrote:
> On Tue, Nov 19, 2013 at 01:31:55PM -0500, Bruce Momjian wrote:
> > On Tue, Nov 19, 2013 at 01:20:47PM -0500, Robert Haas wrote:
> > > I think the pattern is and should be different for toplevel
> > > transaction control commands than
On Mon, Nov 18, 2013 at 09:15:39AM -0500, Sev Zaslavsky wrote:
> Thank you all for considering my feature request.
>
> Dimitri's suggestion is a very good one - I feel it will accomplish
> the goal of allowing more granularity in the "Listen".
>
> We might also want to add a flag in postgresql.co
On Mon, Nov 18, 2013 at 10:56 AM, Peter Geoghegan wrote:
> On Mon, Nov 18, 2013 at 10:49 AM, Fujii Masao
> wrote:
> > The same idea was proposed before but not committed because
> > Itagaki thought that pg_stat_statements view should report only raw
> values.
> > Please read the following thread
On Tue, Nov 19, 2013 at 11:59 AM, Josh Berkus wrote:
> On 11/19/2013 08:14 AM, Robert Haas wrote:
>> On Thu, Nov 14, 2013 at 2:54 PM, Hannu Krosing wrote:
>>> I am sure you could also devise an json encoding scheme
>>> where white space is significant ;)
>>
>> I don't even have to think hard. If
On Wed, Nov 13, 2013 at 03:27:14PM -0500, Peter Eisentraut wrote:
> When pg_upgrade generates a rebuild_tsvector_tables.sql script to
> rewrite tsvector columns, it includes ALTER TABLE commands for child
> tables that cannot be altered independently from their parents:
>
> psql:rebuild_tsvector_t
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> I've been hacking on this patch all day yesterday. What I'm on
> Tom> about at the moment is reversing the decision to move range
> Tom> functions' funccoltypes etc into FuncExpr. That's a bad idea on
> Tom> the grounds of bloating Fu
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> BTW, the reason we need to store the column count explicitly is
> Tom> that we have to ignore the added columns if a composite type has
> Tom> had an ADD COLUMN done to it since the RTE was made. The
> Tom> submitted patch fails rather
> "Tom" == Tom Lane writes:
Tom> BTW, the reason we need to store the column count explicitly is
Tom> that we have to ignore the added columns if a composite type has
Tom> had an ADD COLUMN done to it since the RTE was made. The
Tom> submitted patch fails rather nastily in such cases, if
On Nov 19, 2013, at 10:51 AM, Andres Freund wrote:
> You seem to imply that I/we should do that work?
No, just that it be done. Of course, the more support from the professional PG
community that is given to it, the better.
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pgsql-h
On 11/19/2013 10:51 AM, Andres Freund wrote:
> That's actually easier to test since you can relatively easily integrate
> it into pg_regress and isolationtester - thus the patchset actually
> contains tests.
> You seem to imply that I/we should do that work? That's a bit onesided,
> isn't it?
Nope
On 11/19/2013 01:43 PM, David Johnston wrote:
I have not really pondered storing scalars into jsonb but before pondering
usability are there any technical concerns. If the goal is to share the
backend with hstore then current hstore does not allow for this and so the
json aspect would either
Gavin Flower-2 wrote
> More seriously, there are obviously variants in what people consider
> useful human readable form of JSON output, but it is probably
> inefficient to store white space.
Enough to matter? Maybe the extra whitespace causes a marginal value to be
toasted but, IIUC, for a v
> "Tom" == Tom Lane writes:
Tom> I've been hacking on this patch all day yesterday. What I'm on
Tom> about at the moment is reversing the decision to move range
Tom> functions' funccoltypes etc into FuncExpr. That's a bad idea on
Tom> the grounds of bloating FuncExpr, but the real probl
On 11/19/2013 01:43 PM, David Johnston wrote:
Andrew Dunstan wrote
Given that, I'm not sure we shouldn't permit them in b) either. I think
I lost that argument back in the 9.2 dev cycle. I really don't want to
get to a situation where foo::json::jsonb can produce an error.
So what do you propo
On 20/11/13 05:14, Robert Haas wrote:
On Thu, Nov 14, 2013 at 2:54 PM, Hannu Krosing wrote:
I am sure you could also devise an json encoding scheme
where white space is significant ;)
I don't even have to think hard. If you want your JSON to be
human-readable, it's entirely possible that you
On 2013-11-19 10:43:14 -0800, Josh Berkus wrote:
> I think this last issue shows that it's critical as a community to have
> such a testing framework in place, otherwise we really need to halt all
> work on replication until we have such a thing.
> I can't see how you expect to complete streaming
Andrew Dunstan wrote
> Given that, I'm not sure we shouldn't permit them in b) either. I think
> I lost that argument back in the 9.2 dev cycle. I really don't want to
> get to a situation where foo::json::jsonb can produce an error.
So what do you propose happens when the input json has duplica
On 11/19/2013 10:40 AM, Andres Freund wrote:
> On 2013-11-19 10:32:10 -0800, Christophe Pettus wrote:
>> What concerns me more is that we don't seem to have a framework to put
>> in a regression test on the bug you just found (and thank you for
>> finding it so quickly!).
>
> Agreed. But regarding
On 2013-11-19 10:34:09 -0800, Josh Berkus wrote:
> On 11/19/2013 10:29 AM, Andres Freund wrote:
> > It's pretty unlikely that any automated testing would have cought this,
> > the required conditions are too unlikely for that.
>
> Given our almost total lack of automated testing for replication, h
On 2013-11-19 10:32:10 -0800, Christophe Pettus wrote:
>
> On Nov 19, 2013, at 10:29 AM, Andres Freund wrote:
>
> > It's pretty unlikely that any automated testing would have cought this,
> > the required conditions are too unlikely for that.
>
> I would expect that "promote secondary while pri
On Tue, Nov 19, 2013 at 01:31:55PM -0500, Bruce Momjian wrote:
> On Tue, Nov 19, 2013 at 01:20:47PM -0500, Robert Haas wrote:
> > I think the pattern is and should be different for toplevel
> > transaction control commands than for other things. If you issue a
> > BEGIN, we want it to end up that
On 11/19/2013 10:29 AM, Andres Freund wrote:
> It's pretty unlikely that any automated testing would have cought this,
> the required conditions are too unlikely for that.
Given our almost total lack of automated testing for replication, how
would you (or anyone else) possibly know that? We certa
On Tue, Nov 19, 2013 at 01:20:47PM -0500, Robert Haas wrote:
> I think the pattern is and should be different for toplevel
> transaction control commands than for other things. If you issue a
> BEGIN, we want it to end up that you're definitely in a transaction at
> that point, and if you issue a
On Nov 19, 2013, at 10:29 AM, Andres Freund wrote:
> It's pretty unlikely that any automated testing would have cought this,
> the required conditions are too unlikely for that.
I would expect that "promote secondary while primary is under heavy load" is
clear-cut test case. What concerns me
On 2013-11-19 10:27:30 -0800, Christophe Pettus wrote:
>
> On Nov 19, 2013, at 10:25 AM, Andres Freund wrote:
> > I am not sure how much code it's going to take (I'd hope somewhat less),
> > but it certainly will take some time to agree how it should be built and
> > then building and integrating
On Nov 19, 2013, at 10:25 AM, Andres Freund wrote:
> I am not sure how much code it's going to take (I'd hope somewhat less),
> but it certainly will take some time to agree how it should be built and
> then building and integrating it.
Given that the situation we're in right now is that we have
On 2013-11-19 10:16:26 -0800, Josh Berkus wrote:
> On 11/19/2013 09:58 AM, Andres Freund wrote:
> > On 2013-11-19 09:51:28 -0800, Josh Berkus wrote:
> >> Maybe it's worth it now to devise some automated replication testing?
> >
> > It'd be a good idea, but I am not sure where to get resources for
On 11/19/2013 10:12 AM, Robert Haas wrote:
> On Tue, Nov 19, 2013 at 1:10 PM, Fujii Masao wrote:
>> On Tue, Nov 19, 2013 at 11:51 PM, Robert Haas wrote:
>>> On Fri, Nov 15, 2013 at 9:01 PM, Fabrízio de Royes Mello
>>> http://www.postgresql.org/docs/9.3/static/app-pg-isready.html
>>
>> Attached is
On Tue, Nov 19, 2013 at 1:14 PM, Bruce Momjian wrote:
> On Tue, Nov 19, 2013 at 07:12:32PM +0100, Andres Freund wrote:
>> On 2013-11-19 13:09:16 -0500, Bruce Momjian wrote:
>> > > Why change the historical behaviour for savepoints?
>> >
>> > Because as Tom stated, we already do warnings for other
On 2013-11-19 12:47:29 -0500, Robert Haas wrote:
> On Tue, Nov 19, 2013 at 11:57 AM, Andres Freund
> wrote:
> > Agreed. As an alternative we could just have a single - probably longer
> > than NAMEDATALEN - string to identify replication progress and rely on
> > the users of the facility to build
Tom Lane-2 wrote
> David Johnston <
> polobo@
> > writes:
>> Robert Haas wrote
>>> I don't think it's worth breaking backward compatibility. I'm not
>>> entirely sure what I would have decided here in a vacuum, but at this
>>> point existing precedent seems determinative.
>
>> Well, at this poi
On Tue, Nov 19, 2013 at 11:43 PM, Mike Blackwell wrote:
> This patch looks good to me. It applies, builds, and runs the regression
> tests. Documentation is included and it seems to do what it says. I don't
> consider myself a code expert, but as far as I can see it looks fine. This
> is a pre
On 2013-11-19 13:14:34 -0500, Bruce Momjian wrote:
> On Tue, Nov 19, 2013 at 07:12:32PM +0100, Andres Freund wrote:
> > But even if that weren't a concern, the fact that BEGIN does it one way
> > currently doesn't seem very indicative of changing other historical
> > behaviour.
>
> Look at this g
On 11/19/2013 09:58 AM, Andres Freund wrote:
> On 2013-11-19 09:51:28 -0800, Josh Berkus wrote:
>> Maybe it's worth it now to devise some automated replication testing?
>
> It'd be a good idea, but I am not sure where to get resources for it
> from.
Well, servers isn't hard ... various cloud comp
On Tue, Nov 19, 2013 at 07:12:32PM +0100, Andres Freund wrote:
> On 2013-11-19 13:09:16 -0500, Bruce Momjian wrote:
> > > Why change the historical behaviour for savepoints?
> >
> > Because as Tom stated, we already do warnings for other useless
> > transaction commands like BEGIN WORK inside a tr
This patch looks good to me. It applies, builds, and runs the regression
tests. Documentation is included and it seems to do what it says. I don't
consider myself a code expert, but as far as I can see it looks fine. This
is a pretty straightforward enhancement to the existing pg_stat_* code.
On Tue, Nov 19, 2013 at 1:10 PM, Fujii Masao wrote:
> On Tue, Nov 19, 2013 at 11:51 PM, Robert Haas wrote:
>> On Fri, Nov 15, 2013 at 9:01 PM, Fabrízio de Royes Mello
>> wrote:
>>> On Wed, Nov 13, 2013 at 9:37 PM, Josh Berkus wrote:
handyrep@john:~/handyrep$ pg_isready --version
pg_is
On 2013-11-19 13:09:16 -0500, Bruce Momjian wrote:
> > Why change the historical behaviour for savepoints?
>
> Because as Tom stated, we already do warnings for other useless
> transaction commands like BEGIN WORK inside a transaction block:
Which imo is a bad, bad historical accident. I've repea
On Tue, Nov 19, 2013 at 11:51 PM, Robert Haas wrote:
> On Fri, Nov 15, 2013 at 9:01 PM, Fabrízio de Royes Mello
> wrote:
>> On Wed, Nov 13, 2013 at 9:37 PM, Josh Berkus wrote:
>>> handyrep@john:~/handyrep$ pg_isready --version
>>> pg_isready (PostgreSQL) 9.3.1
>>>
>>> handyrep@john:~/handyrep$ p
On Tue, Nov 19, 2013 at 1:05 PM, Bruce Momjian wrote:
> A patch to issue only warnings is attached. In a way this change
> improves the code by throwing errors only when the commands are invalid,
> rather than just useless. You could argue that ROLLBACK TO SAVEPOINT
> should throw an error becau
On 11/19/2013 12:59 PM, Josh Berkus wrote:
On 11/19/2013 08:14 AM, Robert Haas wrote:
On Thu, Nov 14, 2013 at 2:54 PM, Hannu Krosing wrote:
I am sure you could also devise an json encoding scheme
where white space is significant ;)
I don't even have to think hard. If you want your JSON to b
On Tue, Nov 19, 2013 at 12:59 PM, Josh Berkus wrote:
> On 11/19/2013 08:14 AM, Robert Haas wrote:
>> On Thu, Nov 14, 2013 at 2:54 PM, Hannu Krosing wrote:
>>> I am sure you could also devise an json encoding scheme
>>> where white space is significant ;)
>>
>> I don't even have to think hard. If
On Tue, Nov 19, 2013 at 07:08:05PM +0100, Andres Freund wrote:
> On 2013-11-19 13:05:01 -0500, Bruce Momjian wrote:
> > SAVEPOINT
>
> > test=> ROLLBACK TO SAVEPOINT asdf;
> > ERROR: ROLLBACK TO SAVEPOINT can only be used in transaction blocks
> >
> > Notice that they do _not_ check t
On 2013-11-19 13:05:01 -0500, Bruce Momjian wrote:
> SAVEPOINT
> test=> ROLLBACK TO SAVEPOINT asdf;
> ERROR: ROLLBACK TO SAVEPOINT can only be used in transaction blocks
>
> Notice that they do _not_ check their arguments; they just throw
> errors. With this patch they issue
On Tue, Nov 19, 2013 at 12:24:50PM -0500, Tom Lane wrote:
> David Johnston writes:
> > Robert Haas wrote
> >> I don't think it's worth breaking backward compatibility. I'm not
> >> entirely sure what I would have decided here in a vacuum, but at this
> >> point existing precedent seems determinat
On Sat, Nov 9, 2013 at 02:15:52PM -0500, Robert Haas wrote:
> On Fri, Nov 8, 2013 at 5:36 PM, Tom Lane wrote:
> > [ I'm so far behind ... ]
> >
> > Bruce Momjian writes:
> >> Applied. Thank you for all your suggestions.
> >
> > I thought the suggestion had been to issue a *warning*. How did th
On 11/19/2013 08:29 AM, Robert Haas wrote:
> On Mon, Nov 18, 2013 at 8:20 PM, Josh Berkus wrote:
>> Oh, and one more:
>>
>> c) that "stop" defaults to "smart" mode, instead of "fast" mode.
>
> And that "smart" mode is called "smart" instead of "footgun".
Right, exactly.
Personally, I can't thin
On 11/19/2013 08:14 AM, Robert Haas wrote:
> On Thu, Nov 14, 2013 at 2:54 PM, Hannu Krosing wrote:
>> I am sure you could also devise an json encoding scheme
>> where white space is significant ;)
>
> I don't even have to think hard. If you want your JSON to be
> human-readable, it's entirely po
On 2013-11-19 09:51:28 -0800, Josh Berkus wrote:
> On 11/19/2013 06:20 AM, Andres Freund wrote:
> > Hi,
> >
> > On 2013-11-18 23:15:59 +0100, Andres Freund wrote:
> >> Afaics it's likely a combination/interaction of bugs and fixes between:
> >> * the initial HS code
> >> * 5a031a5556ff83b8a9646892
On 2013-11-19 12:43:44 -0500, Robert Haas wrote:
> > * To be useful they usually will need to be placed in memory shared between
> > * processes or threads, most frequently by embedding them in structs. Be
> > * careful to align atomic variables to their own size!
>
> What does that mean exactl
On 11/19/2013 06:20 AM, Andres Freund wrote:
> Hi,
>
> On 2013-11-18 23:15:59 +0100, Andres Freund wrote:
>> Afaics it's likely a combination/interaction of bugs and fixes between:
>> * the initial HS code
>> * 5a031a5556ff83b8a9646892715d7fef415b83c3
>> * f44eedc3f0f347a856eea8590730769125964597
On Tue, Nov 19, 2013 at 11:57 AM, Andres Freund wrote:
> Agreed. As an alternative we could just have a single - probably longer
> than NAMEDATALEN - string to identify replication progress and rely on
> the users of the facility to build the identifier automatically
> themselves using components
On Tue, Nov 19, 2013 at 11:38 AM, Andres Freund wrote:
> /*-
> *
> * atomics.h
> *Generic atomic operations support.
> *
> * Hardware and compiler dependent functions for manipulating memory
> * atomically and de
1 - 100 of 194 matches
Mail list logo
