Tatsuo Ishii wrote:
> I think we should detect the cases as much as possible and warn users,
> rather than silently ignore that fact client encoding != file
> encoding. I don't think we can detect it in a reliable way, but at
> least we could check the cases above(sum of PQmblen is not equale to
>
On Tue, Nov 27, 2012 at 3:15 PM, Heikki Linnakangas wrote:
> I fail to see the point of DEALLOCATE IF EXISTS. Do you have real use case
> for this, or was this just a case of adding IF EXISTS to all commands for
> the sake of completeness?
>
> Usually the client knows what statements have been pr
Markus Wanner writes:
>> However, as you say, maybe we need more coding examples.
>
> Maybe a minimally usable extra daemon example? Showing how to avoid
> common pitfalls? Use cases, anybody? :-)
What about the PGQ ticker, pgqd?
https://github.com/markokr/skytools/tree/master/sql/ticker
htt
2012/11/30 Dimitri Fontaine :
> Markus Wanner writes:
>>> However, as you say, maybe we need more coding examples.
>>
>> Maybe a minimally usable extra daemon example? Showing how to avoid
>> common pitfalls? Use cases, anybody? :-)
>
> What about the PGQ ticker, pgqd?
>
> https://github.com/mar
On Sun, Nov 4, 2012 at 12:49 PM, Pavel Stehule wrote:
> Hello
>
> here is patch, that enables using a variadic parameter modifier for
> variadic "any" function.
>
> Motivation for this patch is consistent behave of "format" function,
> but it fixes behave of all this class variadic functions.
>
>
Hi,
I looked at the discussion for this patch and the patch itself. Here
are my comments and observations about the patch.
What I got from the discussion is that the patch tries to implement a
mechanism to install extension from series of SQL scripts from
base/full version e.g. if a user wants to
Hi,
Heikki Linnakangas writes:
> Attached is a patch to refactor that logic into a more straightforward state
> machine. It's always been a kind of a state machine, but it's been hard to
> see, as the code wasn't explicitly written that way. Any objections?
On a quick glance over, looks good to
On Thu, Nov 29, 2012 at 5:25 PM, Heikki Linnakangas wrote:
> One thing that bothers me with this algoritm is that the overflow
> mechanism is all-or-nothing. In many cases, even when there is a huge
> number of states in the diagram, you could still extract at least a few
> trigrams that must be
Hi!
On Thu, Nov 29, 2012 at 12:58 PM, er wrote:
> On Mon, November 26, 2012 20:49, Alexander Korotkov wrote:
>
> > trgm-regexp-0.6.patch.gz
>
> I ran the simple-minded tests against generated data (similar to the ones
> I did in January 2012).
> The problems of that older version seem pretty muc
On Fri, Nov 30, 2012 at 3:20 PM, Alexander Korotkov wrote:
> For depth-first it's not.
>
Oh, I didn't explained it.
In order to stop graph processing we need to be sure that we put all
outgoing arcs from state or assume that state to be final. In DFS we can be
in the final part of graph producing
On 2012-11-30 08:52:18 +0530, Pavan Deolasee wrote:
> On Fri, Nov 30, 2012 at 3:19 AM, Andres Freund wrote:
>
> > Hi,
> >
> > while looking at trigger.c from the POV of foreign key locks I noticed
> > that GetTupleForTrigger commentless assumes it can just look at a pages
> > content without a
> >
On 11/30/2012 11:09 AM, Dimitri Fontaine wrote:
> Markus Wanner writes:
>>> However, as you say, maybe we need more coding examples.
>>
>> Maybe a minimally usable extra daemon example? Showing how to avoid
>> common pitfalls? Use cases, anybody? :-)
>
> What about the PGQ ticker, pgqd?
>
> ht
Andres Freund escribió:
> On 2012-11-30 08:52:18 +0530, Pavan Deolasee wrote:
> > On Fri, Nov 30, 2012 at 3:19 AM, Andres Freund
> > wrote:
> > > I can't believe this is safe? Just about anything but eviction could
> > > happen to that buffer at that moment?
Yeah, it does seem fishy to me as wel
On Fri, Nov 30, 2012 at 5:28 PM, Andres Freund wrote:
>
> > >
> > That seems to be safe to me. Anything thats been read above can't really
> > change. The tuple is already locked, so a concurrent update/delete has to
> > wait on us. We have a pin on the buffer, so VACUUM or HOT-prune can't
> > hap
Markus Wanner writes:
> AFAICS pgqd currently uses libpq, so I think it would rather turn into
> what I call a background worker, with a connection to Postgres shared
> memory. I perfectly well see use cases (plural!) for those.
>
> What I'm questioning is the use for what I rather call "extra dae
On 30 November 2012 11:58, Andres Freund wrote:
> We only get the pin right there, I don't see any preexisting pin.
Seems easy enough to test with an Assert patch.
If the Assert doesn't fail, we apply it as "documentation" of the
requirement for a pin.
If it fails, we fix the bug.
--
Simon
On 2012-11-30 18:09:49 +0530, Pavan Deolasee wrote:
> On Fri, Nov 30, 2012 at 5:28 PM, Andres Freund wrote:
>
> >
> > > >
> > > That seems to be safe to me. Anything thats been read above can't really
> > > change. The tuple is already locked, so a concurrent update/delete has to
> > > wait on us.
Dimitri Fontaine wrote:
> Markus Wanner writes:
> > AFAICS pgqd currently uses libpq, so I think it would rather turn into
> > what I call a background worker, with a connection to Postgres shared
> > memory. I perfectly well see use cases (plural!) for those.
> >
> > What I'm questioning is the u
On 2012-11-30 12:50:06 +, Simon Riggs wrote:
> On 30 November 2012 11:58, Andres Freund wrote:
>
> > We only get the pin right there, I don't see any preexisting pin.
>
> Seems easy enough to test with an Assert patch.
>
> If the Assert doesn't fail, we apply it as "documentation" of the
> req
On 2012-11-30 09:57:20 -0300, Alvaro Herrera wrote:
> Dimitri Fontaine wrote:
> > Markus Wanner writes:
> > > AFAICS pgqd currently uses libpq, so I think it would rather turn into
> > > what I call a background worker, with a connection to Postgres shared
> > > memory. I perfectly well see use ca
Andres Freund writes:
>> One of the uses for bgworkers that don't have shmem connection is to
>> have them use libpq connections instead. I don't really see the point
>> of forcing everyone to use backend connections when libpq connections
>> are enough. In particular, they are easier to port fr
On Fri, Nov 30, 2012 at 6:21 PM, Andres Freund wrote:
> On 2012-11-30 18:09:49 +0530, Pavan Deolasee wrote:
> > On Fri, Nov 30, 2012 at 5:28 PM, Andres Freund >wrote:
> >
> > >
> > > > >
> > > > That seems to be safe to me. Anything thats been read above can't
> really
> > > > change. The tuple i
On 11/30/12 3:26 AM, Albe Laurenz wrote:
> Tatsuo Ishii wrote:
>> postgres=# \i ~/sql
>> CREATE DATABASE
>> You are now connected to database "mydb" as user "t-ishii".
>> CREATE SCHEMA
>> psql:/home/t-ishii/sql:7: warning: possible conflict between client
> encoding SJIS and input file
>> encoding
On Fri, Nov 30, 2012 at 5:28 PM, Andres Freund wrote:
>
>
> > heap_fetch() though looks very similar has an important difference. It
> > might be reading the tuple without lock on it and we need the buffer lock
> > to protect against concurrent update/delete to the tuple. AFAIK once the
> > tuple
2012/11/30 Dimitri Fontaine :
> Andres Freund writes:
>>> One of the uses for bgworkers that don't have shmem connection is to
>>> have them use libpq connections instead. I don't really see the point
>>> of forcing everyone to use backend connections when libpq connections
>>> are enough. In pa
On 11/30/2012 01:40 PM, Dimitri Fontaine wrote:
> I totally missed the need to connect to shared memory to be able to
> connect to a database and query it. Can't we just link the bgworkder
> code to the client libpq library, just as plproxy is doing I believe?
Well, sure you can use libpq. But so
On 2012-11-30 18:35:05 +0530, Pavan Deolasee wrote:
> On Fri, Nov 30, 2012 at 6:21 PM, Andres Freund wrote:
>
> > On 2012-11-30 18:09:49 +0530, Pavan Deolasee wrote:
> > > On Fri, Nov 30, 2012 at 5:28 PM, Andres Freund > >wrote:
> > >
> > > >
> > > > > >
> > > > > That seems to be safe to me. Anyt
On 11/30/2012 01:59 PM, Andres Freund wrote:
> On 2012-11-30 09:57:20 -0300, Alvaro Herrera wrote:
>> One of the uses for bgworkers that don't have shmem connection is to
>> have them use libpq connections instead. I don't really see the point
>> of forcing everyone to use backend connections when
On Fri, Nov 30, 2012 at 6:55 PM, Andres Freund wrote:
>
>
> Hm? It doesn't move the page contents around but it moves the ItemId
> array during completely normal operation (c.f. needshuffle in
> PageAddItem). Or am I missing something?
>
>
I think that probably only used for non-heap pages. For he
Kohei KaiGai writes:
> One thing we have to pay attention is, the backend code cannot distinguish
> connection from pgworker via libpq from other regular connections, from
> perspective of access control.
> Even if we implement major portion with C-function, do we have a reliable way
> to prohibit
Markus Wanner wrote:
> On 11/30/2012 01:40 PM, Dimitri Fontaine wrote:
> > I totally missed the need to connect to shared memory to be able to
> > connect to a database and query it. Can't we just link the bgworkder
> > code to the client libpq library, just as plproxy is doing I believe?
>
> Well
2012/11/30 Dimitri Fontaine :
> Kohei KaiGai writes:
>> One thing we have to pay attention is, the backend code cannot distinguish
>> connection from pgworker via libpq from other regular connections, from
>> perspective of access control.
>> Even if we implement major portion with C-function, do
Alvaro,
On 11/30/2012 02:44 PM, Alvaro Herrera wrote:
> So it
> makes easier to have processes that need to run alongside postmaster.
That's where we are in respectful disagreement, then. As I don't think
that's easier, overall, but in my eye, this looks like a foot gun.
As long as things like p
2012/11/30 Markus Wanner :
> Alvaro,
>
> On 11/30/2012 02:44 PM, Alvaro Herrera wrote:
>> So it
>> makes easier to have processes that need to run alongside postmaster.
>
> That's where we are in respectful disagreement, then. As I don't think
> that's easier, overall, but in my eye, this looks lik
On 30.11.2012 13:20, Alexander Korotkov wrote:
On Thu, Nov 29, 2012 at 5:25 PM, Heikki Linnakangas
wrote:
Would it be safe to simply stop short the depth-first search on overflow,
and proceed with the graph that was constructed up to that point?
For depth-first it's not. But your proposal na
On 11/30/2012 03:16 PM, Kohei KaiGai wrote:
> This feature does not enforce them to implement with this new framework.
> If they can perform as separate daemons, it is fine enough.
I'm not clear on what exactly you envision, but if a process needs
access to shared buffers, it sounds like it should
On 2012-11-30 13:57:46 +0100, Andres Freund wrote:
> On 2012-11-30 12:50:06 +, Simon Riggs wrote:
> > On 30 November 2012 11:58, Andres Freund wrote:
> >
> > > We only get the pin right there, I don't see any preexisting pin.
> >
> > Seems easy enough to test with an Assert patch.
> >
> > If t
On 11/29/2012 06:34 PM, Merlin Moncure wrote:
On Thu, Nov 29, 2012 at 4:14 PM, Andrew Dunstan wrote:
There are many things wrong with this. First, converting to hstore so you
can call populate_record is quite horrible and ugly and inefficient. And
it's dependent on having hstore loaded - you c
On Fri, Nov 30, 2012 at 8:38 AM, Andrew Dunstan wrote:
> OK, so based on this discussion, I'm thinking of the following:
ok, this is looking awesome -- couple naming suggestions (see inline):
> * keep the original functions and operators. json_keys is still
>required for the case where the
2012/11/30 Markus Wanner :
> On 11/30/2012 03:16 PM, Kohei KaiGai wrote:
>> This feature does not enforce them to implement with this new framework.
>> If they can perform as separate daemons, it is fine enough.
>
> I'm not clear on what exactly you envision, but if a process needs
> access to shar
On 11/30/2012 09:51 AM, Merlin Moncure wrote:
Two questions:
1) is it possible for these to work without a polymorphic object
passed through as hstore does (null::foo)?
select populate_record(anyelement, record, json)
I don't understand the question. The API I'm suggesting is exactly in
lin
On Fri, Nov 30, 2012 at 9:02 AM, Andrew Dunstan wrote:
>
> On 11/30/2012 09:51 AM, Merlin Moncure wrote:
>>
>>
>> Two questions:
>> 1) is it possible for these to work without a polymorphic object
>> passed through as hstore does (null::foo)?
>> select populate_record(anyelement, record, json)
>
On 11/30/2012 03:38 PM, Andrew Dunstan wrote:
On 11/29/2012 06:34 PM, Merlin Moncure wrote:
On Thu, Nov 29, 2012 at 4:14 PM, Andrew Dunstan
wrote:
There are many things wrong with this. First, converting to hstore
so you
can call populate_record is quite horrible and ugly and inefficient.
An
On 11/30/2012 03:58 PM, Kohei KaiGai wrote:
> It seemed to me you are advocating that any use case of background-
> worker can be implemented with existing separate daemon approach.
That sounds like a misunderstanding. All I'm advocating is that only
3rd-party processes with a real need (like acce
On 11/30/2012 10:04 AM, Hannu Krosing wrote:
OK, so based on this discussion, I'm thinking of the following:
* keep the original functions and operators. json_keys is still
required for the case where the json is not flat.
* json_each(json) => setof (text, text)
errors if the json is
Peter Eisentraut writes:
> On 11/30/12 3:26 AM, Albe Laurenz wrote:
>> If there is no possibility for false positives, I'd say
>> that the "possible" should go. Maybe it should even be
>> an error and no warning then.
> Yes, encoding mismatches are generally an error.
> I think the message shou
Andres Freund writes:
> But a failing Assert obviously proofs something.
It doesn't prove that the code is unsafe though.
I am suspicious that it is safe, because it's pretty darn hard to
believe we'd not have seen field reports of problems with triggers
otherwise. It's not like this is a seldo
On 2012-11-30 10:42:21 -0500, Tom Lane wrote:
> Andres Freund writes:
> > But a failing Assert obviously proofs something.
>
> It doesn't prove that the code is unsafe though.
Hehe.
> I am suspicious that it is safe, because it's pretty darn hard to
> believe we'd not have seen field reports of
On 11/30/2012 04:29 PM, Andrew Dunstan wrote:
On 11/30/2012 10:04 AM, Hannu Krosing wrote:
OK, so based on this discussion, I'm thinking of the following:
* keep the original functions and operators. json_keys is still
required for the case where the json is not flat.
* json_each(json)
> Peter Eisentraut writes:
>> On 11/30/12 3:26 AM, Albe Laurenz wrote:
>>> If there is no possibility for false positives, I'd say
>>> that the "possible" should go. Maybe it should even be
>>> an error and no warning then.
>
>> Yes, encoding mismatches are generally an error.
>
>> I think the
On 11/30/2012 10:59 AM, Hannu Krosing wrote:
Btw, how does current json type handle code pages - is json always
utf-8 even when server encoding is not ?
if so then we could at least have a shortcut conversion of json to
utf8-text which can skip codepage changes.
IIRC json is stored and
> I wonder about the "possible".
>
> Could there be false positives with the test?
> If yes, I don't like the idea.
Yes, there could be false positives. It was just because the input
file was broken. In the real world, I think probably encoding mismatch
is the most possible cause, but this is not
> I think the message should be more precise. Nobody will know what an
> "encoding conflict" is. The error condition is "last multibyte
> character ran over end of file" or something like that, which should be
> clearer.
"last multibyte character ran over" is not precise at all because the
error
On 11/27/2012 02:38 PM, Andrew Dunstan wrote:
On 11/26/2012 12:31 PM, Robert Haas wrote:
On Mon, Nov 26, 2012 at 11:43 AM, Andrew Dunstan
wrote:
I don't understand why you would want to create such a cast. If the
cast
doesn't exist it will do exactly what it does now, i.e. use the type's
ou
Andres Freund writes:
> On 2012-11-30 10:42:21 -0500, Tom Lane wrote:
>> I am suspicious that it is safe, because it's pretty darn hard to
>> believe we'd not have seen field reports of problems with triggers
>> otherwise. It's not like this is a seldom-executed code path.
> Thats true, but I th
On 2012-11-30 12:53:27 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2012-11-30 10:42:21 -0500, Tom Lane wrote:
> >> I am suspicious that it is safe, because it's pretty darn hard to
> >> believe we'd not have seen field reports of problems with triggers
> >> otherwise. It's not like this
Hi,
The subject says it all.
There are workloads where its detrimental, but in general having it
default to on improver experience tremendously because getting conflicts
because of vacuum is rather confusing.
In the workloads where it might not be a good idea (very long queries on
the standby, m
BTW, I went looking for other places that might have a similar mistake.
I found that contrib/pageinspect/btreefuncs.c pokes around in btree
pages without any buffer lock, which seems pretty broken --- don't we
want it to take share lock?
regards, tom lane
--
Sent via pgs
On 2012-11-30 14:08:05 -0500, Tom Lane wrote:
> BTW, I went looking for other places that might have a similar mistake.
> I found that contrib/pageinspect/btreefuncs.c pokes around in btree
> pages without any buffer lock, which seems pretty broken --- don't we
> want it to take share lock?
I seem
Andres Freund writes:
> On 2012-11-30 14:08:05 -0500, Tom Lane wrote:
>> BTW, I went looking for other places that might have a similar mistake.
>> I found that contrib/pageinspect/btreefuncs.c pokes around in btree
>> pages without any buffer lock, which seems pretty broken --- don't we
>> want i
On 30 November 2012 19:02, Andres Freund wrote:
> The subject says it all.
>
> There are workloads where its detrimental, but in general having it
> default to on improver experience tremendously because getting conflicts
> because of vacuum is rather confusing.
>
> In the workloads where it migh
On Wed, Nov 28, 2012 at 1:55 AM, Hari Babu wrote:
> I think backup should be done only files and folders present inside
> '/opt/tblspc/PG_*' directory (TABLESPACE_VERSION_DIRECTORY).
> Not all the files and folders in side '/opt/tblspc.' directory.
I think I agree. The current behavior would hav
On Fri, Nov 30, 2012 at 2:02 PM, Andres Freund wrote:
> Does anybody have an argument against changing the default value?
Well, the disadvantage of it is that the standby can bloat the master,
which might be surprising to some people, too. But I don't really
have a lot of skin in this game.
Whi
On Wed, Nov 28, 2012 at 9:47 AM, Amit kapila wrote:
> 5. PERSISTENT Keyword is added to the reserved keyword list. As it was giving
> some errors given below while parsing gram.y
> 15 shift/reduce conflicts .
Allow me to be the first to say that any syntax for this feature that
involve
Tatsuo Ishii writes:
>> TBH I think that a message here is unnecessary; it's sufficient to
>> ensure psql doesn't crash. The backend will produce a better message
>> than this anyway once the data gets there, and that way we don't have to
>> invent a new error recovery path inside psql. As-is, t
On Thu, Nov 29, 2012 at 8:50 AM, Andres Freund wrote:
> Hi,
>
> Currently "make -jN check" fails during "creating temporary installation"
> with:
> make[1]: *** read jobs pipe: Invalid argument. Stop.
> make[1]: *** Waiting for unfinished jobs
> make[2]: warning: jobserver unavailable: using
On Thu, Nov 29, 2012 at 11:23:59PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > In looking to add an fsync-only option to initdb, I found its main()
> > function to be 743 lines long, and very hard to understand.
>
> > The attached patch moves much of that code into separate functions,
> >
Robert Haas writes:
> On Wed, Nov 28, 2012 at 9:47 AM, Amit kapila wrote:
>> 5. PERSISTENT Keyword is added to the reserved keyword list. As it was
>> giving some errors given below while parsing gram.y
>> 15 shift/reduce conflicts .
> Allow me to be the first to say that any syntax for this fe
On Thu, Nov 29, 2012 at 3:03 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> The other interesting question remaining is what to do about the rm_desc
>> function in rmgr.c. We're split between these two ideas:
>
> Why try to link rmgr.c into frontend versions at all? Just make
> a new table fil
> In the workloads where it might not be a good idea (very long queries on
> the standby, many dead tuples on the primary) you need to think very
> carefuly about the strategy of avoiding conflicts anyway, and explicit
> configuration is required as well.
>
> Does anybody have an argument against
On 30.11.2012 21:02, Andres Freund wrote:
Hi,
The subject says it all.
There are workloads where its detrimental, but in general having it
default to on improver experience tremendously because getting conflicts
because of vacuum is rather confusing.
In the workloads where it might not be a go
BTW, on further inspection, there's yet another reason why we've not
heard about this from the field: even if all the wrong things happen and
GetTupleForTrigger manages to copy bogus data for the old tuple, that
data *is not passed to the trigger function*. The only thing we do with
it is decide w
On Fri, Nov 30, 2012 at 5:46 PM, Heikki Linnakangas
wrote:
>
> Think of someone setting up a test server, by setting it up as a standby
> from the master. Now, when someone holds a transaction open in the test
> server, you get bloat in the master. Or if you set up a standby for
> reporting purpos
Robert Haas writes:
> While we're talking about changing defaults, how about changing the
> default value of the recovery.conf parameter 'standby_mode' to on?
> Not sure about anybody else, but I never want it any other way.
Dunno, it's been only a couple of days since there was a thread about
so
On 30.11.2012 22:49, Claudio Freire wrote:
On Fri, Nov 30, 2012 at 5:46 PM, Heikki Linnakangas
wrote:
Think of someone setting up a test server, by setting it up as a standby
from the master. Now, when someone holds a transaction open in the test
server, you get bloat in the master. Or if you
Claudio Freire wrote:
> Without hot standby feedback, reporting queries are impossible.
> I've experienced it. Cancellations make it impossible to finish
> any decently complex reporting query.
With what setting of max_standby_streaming_delay? I would rather
default that to -1 than default hot_st
On Fri, Nov 30, 2012 at 6:06 PM, Kevin Grittner wrote:
>
>> Without hot standby feedback, reporting queries are impossible.
>> I've experienced it. Cancellations make it impossible to finish
>> any decently complex reporting query.
>
> With what setting of max_standby_streaming_delay? I would rath
Claudio Freire writes:
> Without hot standby feedback, reporting queries are impossible. I've
> experienced it. Cancellations make it impossible to finish any
> decently complex reporting query.
The original expectation was that slave-side cancels would be
infrequent. Maybe there's some fixing/t
On Mon, 2012-11-26 at 16:55 -0600, Merlin Moncure wrote:
> > Based on previous measurements, I think there *is* contention pinning
> > the root of an index. Currently, I believe it's largely overwhelmed
> > by contention from other sources, such as the buffer manager lwlocks
> > and the very-evil
Claudio Freire wrote:
>> With what setting of max_standby_streaming_delay? I would rather
>> default that to -1 than default hot_standby_feedback on. That
>> way what you do on the standby only affects the standby.
>
> 1d
Was there actually a transaction hanging open for an entire day on
the sta
On Thu, Nov 29, 2012 at 12:59:19PM -0500, Bruce Momjian wrote:
> I have polished up the patch (attached) and it is ready for application
> to 9.3.
Applied.
---
> Since there is no pg_dump/pg_restore pipe parallelism, I had t
On Fri, Nov 30, 2012 at 6:20 PM, Kevin Grittner wrote:
> Claudio Freire wrote:
>
>>> With what setting of max_standby_streaming_delay? I would rather
>>> default that to -1 than default hot_standby_feedback on. That
>>> way what you do on the standby only affects the standby.
>>
>> 1d
>
> Was ther
On Thu, Nov 29, 2012 at 11:12:23PM -0500, Bruce Momjian wrote:
> In looking to add an fsync-only option to initdb, I found its main()
> function to be 743 lines long, and very hard to understand.
>
> The attached patch moves much of that code into separate functions,
> which will make initdb.c eas
On 30.11.2012 23:40, Claudio Freire wrote:
On Fri, Nov 30, 2012 at 6:20 PM, Kevin Grittner wrote:
Claudio Freire wrote:
With what setting of max_standby_streaming_delay? I would rather
default that to -1 than default hot_standby_feedback on. That
way what you do on the standby only affects th
On Fri, Nov 30, 2012 at 6:49 PM, Heikki Linnakangas
wrote:
>>> I have most certainly managed databases where holding up vacuuming
>>> on the source would cripple performance to the point that users
>>> would have demanded that any other process causing it must be
>>> immediately canceled. And canc
On 11/30/2012 04:45 PM, Bruce Momjian wrote:
On Thu, Nov 29, 2012 at 11:12:23PM -0500, Bruce Momjian wrote:
In looking to add an fsync-only option to initdb, I found its main()
function to be 743 lines long, and very hard to understand.
The attached patch moves much of that code into separate
On Fri, Nov 30, 2012 at 06:06:39PM -0500, Andrew Dunstan wrote:
>
> On 11/30/2012 04:45 PM, Bruce Momjian wrote:
> >On Thu, Nov 29, 2012 at 11:12:23PM -0500, Bruce Momjian wrote:
> >>In looking to add an fsync-only option to initdb, I found its main()
> >>function to be 743 lines long, and very ha
On 2012-11-30 14:35:37 -0500, Robert Haas wrote:
> On Fri, Nov 30, 2012 at 2:02 PM, Andres Freund wrote:
> > Does anybody have an argument against changing the default value?
>
> Well, the disadvantage of it is that the standby can bloat the master,
> which might be surprising to some people, too.
On Fri, Nov 30, 2012 at 11:35 AM, Robert Haas wrote:
> On Fri, Nov 30, 2012 at 2:02 PM, Andres Freund wrote:
>> Does anybody have an argument against changing the default value?
>
> Well, the disadvantage of it is that the standby can bloat the master,
> which might be surprising to some people,
On 2012-11-30 14:41:14 -0500, Robert Haas wrote:
> On Thu, Nov 29, 2012 at 8:50 AM, Andres Freund wrote:
> > Hi,
> >
> > Currently "make -jN check" fails during "creating temporary installation"
> > with:
> > make[1]: *** read jobs pipe: Invalid argument. Stop.
> > make[1]: *** Waiting for unfini
> Yes. obviously. Stupid, errr, fingers.
This time round it really was fatfingering the wrong key after having
been climbing for 4h. Really.
Trivially updated patch attached.
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Serv
On Fri, Nov 30, 2012 at 9:46 PM, Heikki Linnakangas
wrote:
> On 30.11.2012 21:02, Andres Freund wrote:
>>
>> Hi,
>>
>> The subject says it all.
>>
>> There are workloads where its detrimental, but in general having it
>> default to on improver experience tremendously because getting conflicts
>> b
On Fri, Nov 30, 2012 at 10:09 PM, Tom Lane wrote:
> Claudio Freire writes:
>> Without hot standby feedback, reporting queries are impossible. I've
>> experienced it. Cancellations make it impossible to finish any
>> decently complex reporting query.
>
> The original expectation was that slave-sid
On 2012-11-30 22:46:06 +0200, Heikki Linnakangas wrote:
> On 30.11.2012 21:02, Andres Freund wrote:
> >Hi,
> >
> >The subject says it all.
> >
> >There are workloads where its detrimental, but in general having it
> >default to on improver experience tremendously because getting conflicts
> >becaus
All:
Well, the problem is that we have three configurations which only work
for one very common scenario:
- reporting slave: feedback off, very long replication_delay
- load-balancing slave: feedback on, short replication_delay
- backup/failover slave: feedback off, short replication_delay
I don
On 2012-11-30 16:09:15 -0500, Tom Lane wrote:
> Claudio Freire writes:
> > Without hot standby feedback, reporting queries are impossible. I've
> > experienced it. Cancellations make it impossible to finish any
> > decently complex reporting query.
>
> The original expectation was that slave-side
On Mon, Nov 26, 2012 at 02:43:19PM -0500, Bruce Momjian wrote:
> > >> In any event, I think the documentation should caution that the
> > >> upgrade should not be deemed to be a success until after a system-wide
> > >> sync has been done. Even if we use the link rather than copy method,
> > >> are
Some of the buildfarm members are failing the pg_upgrade regression test
since commit 12ee6ec71f8754ff3573711032b9b4d5a764ba84. I can duplicate
it here, and the symptom is:
pg_restore: creating TYPE float8range
pg_restore: creating TYPE insenum
pg_restore: [archiver (db)] Error while PROCESSING T
98 matches
Mail list logo
