On Fri, Aug 8, 2014 at 11:41 AM, Fujii Masao wrote:
>
> Yep, right. ParseConfigFp() is not good place to pick up data_directory.
> What about the attached patch which makes ProcessConfigFile() instead of
> ParseConfigFp() pick up data_directory just after the configuration file
is
> parsed?
I thi
On 08/10/2014 12:54 AM, Andres Freund wrote:
> On 2014-08-07 21:02:54 -0400, Tom Lane wrote:
>> Craig Ringer writes:
>>> On 08/08/2014 03:54 AM, Tom Lane wrote:
FWIW, I think it's a seriously bad idea to expose LSNs in the protocol
at all. What happens five years from now when we switc
On Thu, Aug 7, 2014 at 1:09 AM, Peter Geoghegan wrote:
> On Wed, Aug 6, 2014 at 10:36 PM, Peter Geoghegan wrote:
>> This *almost* applies to patched Postgres if you pick a benchmark that
>> is very sympathetic to my patch. To my surprise, work_mem = '10MB'
>> (which results in an external tape so
Kevin Grittner writes:
>> Stephen Frost writes:
>>> Trying to move the header to the end just for the sake of this
>>> doesn't strike me as a good solution as it'll make things quite
>>> a bit more complicated.
> Why is that? How much harder would it be to add a single offset
> field to the fro
Tom Lane wrote:
> Stephen Frost writes:
>> Trying to move the header to the end just for the sake of this
>> doesn't strike me as a good solution as it'll make things quite
>> a bit more complicated.
Why is that? How much harder would it be to add a single offset
field to the front to point to
On 2014-08-09 14:09:36 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-08-09 14:00:49 -0400, Tom Lane wrote:
> >> I don't think it's anywhere near as black-and-white as you guys claim.
> >> What it comes down to is whether allowing existing transactions/sessions
> >> to finish is more i
Andres Freund writes:
> On 2014-08-09 14:00:49 -0400, Tom Lane wrote:
>> I don't think it's anywhere near as black-and-white as you guys claim.
>> What it comes down to is whether allowing existing transactions/sessions
>> to finish is more important than allowing new sessions to start.
>> Dependi
Andres Freund writes:
> On 2014-08-04 10:54:25 -0400, Robert Haas wrote:
>> I believe that multiple people have said multiple times that we should
>> change the behavior so that orphaned backends exit immediately; I
>> think you are the only one defending the current behavior. There are
>> severa
On 2014-08-09 14:00:49 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-08-04 10:54:25 -0400, Robert Haas wrote:
> >> I believe that multiple people have said multiple times that we should
> >> change the behavior so that orphaned backends exit immediately; I
> >> think you are the only
Bruce,
* Bruce Momjian (br...@momjian.us) wrote:
> On Fri, Aug 8, 2014 at 08:25:04PM -0400, Stephen Frost wrote:
> > * Bruce Momjian (br...@momjian.us) wrote:
> > > FYI, pg_upgrade could be taught to refuse to upgrade from earlier 9.4
> > > betas and report the problem JSONB columns.
> >
> > Tha
David Rowley writes:
> On Sat, Aug 9, 2014 at 3:34 PM, Tom Lane wrote:
>> There's no need for a new error message I think, because we should just
>> ignore such indexes. After all, there might be a valid matching index
>> later on.
> hmm, but if the user attempts to define the foreign key that
On 2014-08-07 21:02:54 -0400, Tom Lane wrote:
> Craig Ringer writes:
> > On 08/08/2014 03:54 AM, Tom Lane wrote:
> >> FWIW, I think it's a seriously bad idea to expose LSNs in the protocol
> >> at all. What happens five years from now when we switch to some other
> >> implementation that doesn't
On 2014-08-04 10:54:25 -0400, Robert Haas wrote:
> On Thu, Jul 31, 2014 at 9:51 PM, Tom Lane wrote:
> > Even without that issue, there's no consensus that forcibly making
> > orphan backends exit would be a good thing. (Some people would
> > like to have such an option, but the key word in that s
On 20.7.2014 18:29, Tomas Vondra wrote:
> Attached v9 of the patch. Aside from a few minor fixes, the main change
> is that this is assumed to be combined with the "dense allocation" patch.
>
> It also rewrites the ExecHashIncreaseNumBuckets to follow the same
> pattern as ExecHashIncreaseNumBatc
Hi,
Le 9 août 2014 05:57, "Ramirez, Danilo" a écrit :
>
> Thanks to all for the great info. We are new to postgresql and this
discussion has both instructed us and increased our respect for the
database and the community.
>
> I am seeing a behavior that I don’t understand and hopefully you guys
15 matches
Mail list logo
