On Thu, Jan 5, 2012 at 16:59, Andrew Dunstan wrote:
>
>
> On 01/05/2012 06:31 PM, Alex Hunsaker wrote:
>>
>> On Thu, Jan 5, 2012 at 16:02, Andrew Dunstan wrote:
>>>
>>> Fix breakage from earlier plperl fix.
>> I can't help but think this seems a bit inefficient
>
> So, yes, we should probably ad
* Simon Riggs (si...@2ndquadrant.com) wrote:
> I discover that non-all-zeroes holes are fairly common, just not very
> frequent.
Curious, might be interesting to find out why.
> That may or may not be a problem, but not something to be dealt with
> here and now.
But I agree that it's not the jo
Lately I have noticed buildfarm member jaguar occasionally failing
regression tests with
ERROR: invalid memory alloc request size 1073741824
during a VACUUM, as for example at
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jaguar&dt=2012-01-04%2023%3A05%3A02
Naturally I supposed it to be
On 1/5/12 3:00 PM, Jeremy Harris wrote:
> On 2012-01-05 10:04, Benedikt Grundmann wrote:
>> I have a question of how to benchmark hardware to determine
>> the appropriate ratio of seq_page_cost vs random_page_cost.
>
> It'd be really nice if the DBMS measured actual experienced values..
Certa
I wrote:
> Not easily: there could be newlines embedded in data strings or SQL
> identifiers. I'm not seeing any way around this except to restore the
> minimal lexing capability. One thing we could probably do is to
> restrict it to be used only when reading table data, and continue to
> assume
On 5 January 2012 22:27, Tom Lane wrote:
> There is no compiler anywhere that implements "always inline", unless
> you are talking about a macro. "inline" is a hint and nothing more,
> and if you think you can force it you are mistaken. So this controversy
> is easily resolved: we do not need an
On 01/05/2012 06:31 PM, Alex Hunsaker wrote:
On Thu, Jan 5, 2012 at 16:02, Andrew Dunstan wrote:
Fix breakage from earlier plperl fix.
Apparently the perl garbage collector was a bit too eager, so here
we control when the new SV is garbage collected.
I know im a little late to the party...
On Thu, Jan 5, 2012 at 16:02, Andrew Dunstan wrote:
> Fix breakage from earlier plperl fix.
>
> Apparently the perl garbage collector was a bit too eager, so here
> we control when the new SV is garbage collected.
I know im a little late to the party...
I can't help but think this seems a bit in
On 2012-01-05 10:04, Benedikt Grundmann wrote:
I have a question of how to benchmark hardware to determine
the appropriate ratio of seq_page_cost vs random_page_cost.
It'd be really nice if the DBMS measured actual experienced values..
--
Jeremy
--
Sent via pgsql-hackers mailing list (pgs
On 01/05/2012 05:30 PM, Alvaro Herrera wrote:
Excerpts from Andrew Dunstan's message of jue ene 05 19:06:54 -0300 2012:
On 01/05/2012 12:05 PM, Andrew Dunstan wrote:
Work around perl bug in SvPVutf8().
Certain things like typeglobs or readonly things like $^V cause
perl's SvPVutf8() to die n
Robert Haas writes:
> On Thu, Jan 5, 2012 at 2:57 PM, Tom Lane wrote:
>> I would be in favor of that, or perhaps some other formula (eg, maybe
>> the minimum should be less than 8 for when you've got very little shmem).
> I have some results that show that, under the right set of
> circumstances
Excerpts from Andrew Dunstan's message of jue ene 05 19:06:54 -0300 2012:
>
> On 01/05/2012 12:05 PM, Andrew Dunstan wrote:
> > Work around perl bug in SvPVutf8().
> >
> > Certain things like typeglobs or readonly things like $^V cause
> > perl's SvPVutf8() to die nastily and crash the backend. T
Robert Haas writes:
> On Thu, Dec 29, 2011 at 9:03 PM, Peter Geoghegan
> wrote:
>> The first (controversy A) is that I have added a new
>> piece of infrastructure, pg_always_inline, which, as the name
>> suggests, is a portable way of insisting that a function should be
>> invariably inlined.
>
Magnus Hagander writes:
> On Thu, Jan 5, 2012 at 17:13, Tom Lane wrote:
>> I think link(2) would create race conditions of its own. I'd be
>> inclined to suggest that maybe we should just special-case a zero length
>> postmaster.pid file as meaning "okay to proceed". In general, garbage
> That
On 01/03/2012 06:22 PM, Jim Nasby wrote:
On Jan 3, 2012, at 11:15 AM, Robert Haas wrote:
I think that our current freelist is practically useless, because it
is almost always empty, and the cases where it's not empty (startup,
and after a table or database drop) are so narrow that we don't r
On 01/05/2012 12:05 PM, Andrew Dunstan wrote:
Work around perl bug in SvPVutf8().
Certain things like typeglobs or readonly things like $^V cause
perl's SvPVutf8() to die nastily and crash the backend. To avoid
that bug we make a copy of the object, which will subsequently be
garbage collected
On Jan 5, 2012, at 9:55 AM, Andrew Dunstan wrote:
> perldoc perlvar says:
>
> The revision, version, and subversion of the Perl interpreter,
> represented as a "version" object.
>
> This variable first appeared in perl 5.6.0; earlier versions of perl
> will see an undefined value. Before
On Thu, Jan 5, 2012 at 2:25 PM, Robert Haas wrote:
> On Thu, Jan 5, 2012 at 2:44 PM, Kevin Grittner
> wrote:
>> If we go with such a formula, I think 32 MB would be a more
>> appropriate divisor than 128 MB. Even on very large machines where
>> 32 CLOG buffers would be a clear win, we often can'
On Thu, Jan 5, 2012 at 2:57 PM, Tom Lane wrote:
> I would be in favor of that, or perhaps some other formula (eg, maybe
> the minimum should be less than 8 for when you've got very little shmem).
I have some results that show that, under the right set of
circumstances, 8->32 is a win, and I can q
On Thu, Jan 5, 2012 at 2:44 PM, Kevin Grittner
wrote:
> If we go with such a formula, I think 32 MB would be a more
> appropriate divisor than 128 MB. Even on very large machines where
> 32 CLOG buffers would be a clear win, we often can't go above 1 or 2
> GB of shared_buffers without hitting la
On Thu, Dec 29, 2011 at 9:03 PM, Peter Geoghegan wrote:
> 3. Resolve two anticipated controversies that are, respectively,
> somewhat orthogonal and completely orthogonal to the binary bloat
> controversy. The first (controversy A) is that I have added a new
> piece of infrastructure, pg_always_in
Simon Riggs writes:
> Parameterised slru buffer sizes were proposed about for 8.3 and opposed by
> you.
> I guess we all reserve the right to change our minds...
When presented with new data, sure. Robert's results offer a reason to
worry about this, which we did not have before now.
On Thu, Jan 5, 2012 at 7:57 PM, Tom Lane wrote:
> I think that the reason it's historically been a constant is that the
> original coding took advantage of having a compile-time-constant number
> of buffers --- but since we went over to the common SLRU infrastructure
> for several different logs,
On Thu, Jan 5, 2012 at 17:13, Tom Lane wrote:
> Heikki Linnakangas writes:
>> My laptop ran out of battery and turned itself off while I was just
>> starting up postmaster. After plugging in the charger and rebooting, I
>> got the following error when I tried to restart PostgreSQL:
>
>> FATAL: b
Simon Riggs writes:
> On Thu, Jan 5, 2012 at 7:26 PM, Robert Haas wrote:
>> On the other hand, I think there's a decent argument that he should
>> change his opinion, because 192kB of memory is not a lot. However,
>> what I mostly want is something that nobody hates, so we can get it
>> committe
Robert Haas writes:
> I would like to do that, but I think we need to at least figure out a
> way to provide an escape hatch for people without much shared memory.
> We could do that, perhaps, by using a formula like this:
> 1 CLOG buffer per 128MB of shared_buffers, with a minimum of 8 and a
> m
Robert Haas wrote:
> Simon Riggs wrote:
>> Robert Haas wrote:
>>> Simon Riggs wrote:
Let's commit the change to 32.
>>>
>>> I would like to do that, but I think we need to at least figure
>>> out a way to provide an escape hatch for people without much
>>> shared memory. We could do that,
Excerpts from Simon Riggs's message of jue ene 05 16:21:31 -0300 2012:
> On Thu, Jan 5, 2012 at 7:12 PM, Robert Haas wrote:
> > On Thu, Jan 5, 2012 at 11:10 AM, Simon Riggs wrote:
> >> Let's commit the change to 32.
> >
> > I would like to do that, but I think we need to at least figure out a
>
On Thu, Jan 5, 2012 at 7:26 PM, Robert Haas wrote:
> On Thu, Jan 5, 2012 at 2:21 PM, Simon Riggs wrote:
>> On Thu, Jan 5, 2012 at 7:12 PM, Robert Haas wrote:
>>> On Thu, Jan 5, 2012 at 11:10 AM, Simon Riggs wrote:
Let's commit the change to 32.
>>>
>>> I would like to do that, but I think
On Thu, Jan 5, 2012 at 1:12 PM, Robert Haas wrote:
> On Thu, Jan 5, 2012 at 11:10 AM, Simon Riggs wrote:
>> Let's commit the change to 32.
>
> I would like to do that, but I think we need to at least figure out a
> way to provide an escape hatch for people without much shared memory.
> We could d
On Thu, Jan 5, 2012 at 2:21 PM, Simon Riggs wrote:
> On Thu, Jan 5, 2012 at 7:12 PM, Robert Haas wrote:
>> On Thu, Jan 5, 2012 at 11:10 AM, Simon Riggs wrote:
>>> Let's commit the change to 32.
>>
>> I would like to do that, but I think we need to at least figure out a
>> way to provide an escap
On Thu, Jan 5, 2012 at 7:12 PM, Robert Haas wrote:
> On Thu, Jan 5, 2012 at 11:10 AM, Simon Riggs wrote:
>> Let's commit the change to 32.
>
> I would like to do that, but I think we need to at least figure out a
> way to provide an escape hatch for people without much shared memory.
> We could d
On Thu, Jan 5, 2012 at 11:10 AM, Simon Riggs wrote:
> Let's commit the change to 32.
I would like to do that, but I think we need to at least figure out a
way to provide an escape hatch for people without much shared memory.
We could do that, perhaps, by using a formula like this:
1 CLOG buffer
On Thu, Jan 5, 2012 at 4:04 PM, Robert Haas wrote:
> I hypothesize that there are actually two kinds of latency spikes
> here. Just taking a wild guess, I wonder if the *remaining* latency
> spikes are caused by the effect that you mentioned before: namely, the
> need to write an old CLOG page e
On 01/05/2012 01:09 PM, Tom Lane wrote:
Andrew Dunstan writes:
The fix that has been applied, as Tom suggested, is at the point where
we call SvPVutf8(), so that's not just for elog().
That patch looks good, but do we want to look into the other point about
error recovery? The real bottom l
Andrew Dunstan writes:
> The fix that has been applied, as Tom suggested, is at the point where
> we call SvPVutf8(), so that's not just for elog().
That patch looks good, but do we want to look into the other point about
error recovery? The real bottom line here is that when SvPVutf8 threw a
c
On 01/05/2012 12:17 PM, David E. Wheeler wrote:
On Jan 5, 2012, at 9:08 AM, Andrew Dunstan wrote:
Unconditional sv_mortalcopy sounds like the thing to do then, but a
comment would help. And if this isn't a Perl bug, I would like to
know what is.
Indeed. David, can you file a bug on this?
I
On 01/05/2012 12:41 PM, Tom Lane wrote:
Is that actually a vstring? I confess I'd never heard of the things
before this thread, but I remember reading somewhere that you need
multiple dots in a string before it's considered a vstring and not
something else.
perldoc perlvar says:
The rev
On Jan 5, 2012, at 9:50 AM, Andrew Dunstan wrote:
> The fix that has been applied, as Tom suggested, is at the point where we
> call SvPVutf8(), so that's not just for elog().
Great, thanks.
> As documented, it's not a scalar, and you need to stop treating it as one. If
> you want it as a scal
On Jan 5, 2012, at 9:41 AM, Tom Lane wrote:
> I would imagine you could reproduce it by returning the same kinds of
> objects as function results, since the actual problem is in utf8 to
> database-encoding conversion.
>
>> No segfault, at least, though that‚s a rather bizarre error message. AFAIK
On 01/05/2012 12:28 PM, David E. Wheeler wrote:
On Jan 5, 2012, at 7:34 AM, Tom Lane wrote:
That still crashes, but doesn't if we use sv_mortalcopy unconditionally.
Unconditional sv_mortalcopy sounds like the thing to do then, but a
comment would help. And if this isn't a Perl bug, I would
"David E. Wheeler" writes:
> On Jan 5, 2012, at 7:34 AM, Tom Lane wrote:
>> Unconditional sv_mortalcopy sounds like the thing to do then, but a
>> comment would help. And if this isn't a Perl bug, I would like to
>> know what is.
> Question: Is this an issue anywhere else in PL/Perl, or just elo
On Jan 5, 2012, at 7:34 AM, Tom Lane wrote:
>> That still crashes, but doesn't if we use sv_mortalcopy unconditionally.
>
> Unconditional sv_mortalcopy sounds like the thing to do then, but a
> comment would help. And if this isn't a Perl bug, I would like to
> know what is.
Question: Is this a
On Jan 5, 2012, at 9:08 AM, Andrew Dunstan wrote:
>> Unconditional sv_mortalcopy sounds like the thing to do then, but a
>> comment would help. And if this isn't a Perl bug, I would like to
>> know what is.
>
> Indeed. David, can you file a bug on this?
I could, but don’t know what to say, and
On 01/05/2012 10:34 AM, Tom Lane wrote:
Unconditional sv_mortalcopy sounds like the thing to do then, but a
comment would help. And if this isn't a Perl bug, I would like to
know what is.
Indeed. David, can you file a bug on this?
BTW, shouldn't we be making some attempt to drop the resu
Jim Mlodgenski wrote:
> Any feedback is welcome.
You might want to add it here to make sure it doesn't slip through the
cracks:
https://commitfest.postgresql.org/action/commitfest_view/open
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to yo
I have a need to send banner messages to a psql client that I can set
on the server and will be displayed on any psql client that connects
to the database. This would be mostly used as an additional indicator
to which database you are connecting, but could also be used by people
to force their user
Simon Riggs wrote:
> Robert Haas wrote:
>> So it seems that at least on this machine, increasing the number
>> of CLOG buffers both improves performance and reduces latency.
>
> I believed before that the increase was worthwhile and now even
> more so.
>
> Let's commit the change to 32.
+1
On Thu, Jan 5, 2012 at 4:04 PM, Robert Haas wrote:
> It appears to me that increasing the number of CLOG buffers reduced
> the severity of the latency spikes considerably. In the last 100
> seconds, for example, master has several spikes in the 500-700ms
> range, but with 32 CLOG buffers it neve
Heikki Linnakangas writes:
> My laptop ran out of battery and turned itself off while I was just
> starting up postmaster. After plugging in the charger and rebooting, I
> got the following error when I tried to restart PostgreSQL:
> FATAL: bogus data in lock file "postmaster.pid": ""
> postm
On Tue, Dec 27, 2011 at 5:23 AM, Simon Riggs wrote:
> On Sat, Dec 24, 2011 at 9:25 AM, Simon Riggs wrote:
>> On Thu, Dec 22, 2011 at 4:20 PM, Robert Haas wrote:
>
>>> Also, if it is that, what do we do about it? I don't think any of the
>>> ideas proposed so far are going to help much.
>>
>> If
On Wed, Jan 4, 2012 at 1:35 PM, Kevin Grittner
wrote:
> Simon Riggs wrote:
>
>> My focus was on getting something working first, then tuning. If
>> we're agreed that we have everything apart from the tuning then we
>> can proceed with tests to see which works better.
>
> Sure. I just think you a
Andrew Dunstan writes:
> On 01/04/2012 06:20 PM, Tom Lane wrote:
>> Not easily: there could be newlines embedded in data strings or SQL
>> identifiers.
> Should we look at eliminating those newlines for the future by using
> U&"" identifiers where there are embedded newlines and unicode escapes
Andrew Dunstan writes:
> On 01/04/2012 08:32 PM, Tom Lane wrote:
>> Andrew Dunstan writes:
>>> How do we tell if it's readonly?
>> SvREADONLY(sv) macro.
> but it doesn't fix the one I found which passes a typeglob to elog():
> do '$foo=1; elog(NOTICE,*foo);' language plperl;
Mmm, I was wond
On Wed, Jan 4, 2012 at 3:13 PM, Simon Riggs wrote:
> On Wed, Jan 4, 2012 at 1:31 PM, Stephen Frost wrote:
>> Simon, all,
>>
>> * Simon Riggs (si...@2ndquadrant.com) wrote:
>>> (1) report all errors on a page, including errors that don't change
>>> PostgreSQL data. This involves checksumming long
Hi all,
I've been working on moving an extension that allows to move the ispell
dictionaries to shared segment. It's almost complete, the last FIXME is
about copying regex_t structure (stored in AFFIX).
According to regex.h the structure is fairly complex and not exactly easy
to understand, so I'
Benedikt Grundmann wrote:
> For what's worth here are the numbers on one of our biggest
> databases (same system as I posted about separately wrt
> seq_scan_cost vs random_page_cost).
That's would be a 88.4% hit rate on the summarized data.
-Kevin
--
Sent via pgsql-hackers mailing list (pg
For what's worth here are the numbers on one of our biggest databases
(same system as I posted about separately wrt seq_scan_cost vs
random_page_cost).
0053 1001
00BA 1009
0055 1001
00B9 1020
0054 983
00BB 1010
0056 1001
00BC 1019
0069 0
00BD 1009
006A 224
00BE 1018
006B 1009
00BF 1008
006C 1008
On 01/04/2012 06:20 PM, Tom Lane wrote:
Could we detect an appropriate line ending in ahwrite() after it's been
decompressed and buffer partial lines accordingly?
Not easily: there could be newlines embedded in data strings or SQL
identifiers.
Should we look at eliminating those ne
On 01/04/2012 08:32 PM, Tom Lane wrote:
Andrew Dunstan writes:
Tom said:
2. A slightly cleaner fix for this should be to duplicate the SV and
then release the copy around the SvPVutf8 call, only if it's readonly.
"Fixing" it in do_util_elog is entirely the wrong thing.
How do we tell if it'
On Thu, Jan 5, 2012 at 9:01 AM, Florian Weimer wrote:
> * Robert Haas:
>> and (c) architectures (like 32-bit x86) where ordinary 64-bit
>> operations aren't atomic but special instructions (cmpxchg8b) can be
>> used to get that behavior.
>
> FILD and FIST are atomic, too, and are supported by more
On 05/01/12 10:04, Benedikt Grundmann wrote:
>
> As a counter measure we are experimenting with
> enable_nestloop = off
> random_page_cost = 20 (instead of the previous 4).
>
For what it is worth we had to revert the enable_nestloop = off
change. It just moved the pain around by making other q
On Thu, Jan 5, 2012 at 5:04 AM, Benedikt Grundmann
wrote:
> We are experiencing a big performance regression in some queries.
> In those cases the planner seems to choose a nested loop index
> scan instead of hashing the index once and then joining.
I think you probably need to post EXPLAIN ANALY
On Thu, Jan 5, 2012 at 8:23 AM, Magnus Hagander wrote:
> On Thu, Jan 5, 2012 at 14:18, Heikki Linnakangas
> wrote:
>> My laptop ran out of battery and turned itself off while I was just starting
>> up postmaster. After plugging in the charger and rebooting, I got the
>> following error when I tri
On Thu, Jan 5, 2012 at 6:15 AM, Florian Pflug wrote:
> On 64-bit machines at least, we could simply mmap() the stable parts of the
> CLOG into the backend address space, and access it without any locking at all.
True. I think this could be done, but it would take some fairly
careful thought and
* Robert Haas:
> and (c) architectures (like 32-bit x86) where ordinary 64-bit
> operations aren't atomic but special instructions (cmpxchg8b) can be
> used to get that behavior.
FILD and FIST are atomic, too, and are supported by more
micro-architectures.
--
Florian Weimer
BFK
On Tue, Jan 3, 2012 at 2:22 PM, Tom Lane wrote:
>> Another thought is that it should always be safe to reuse an old
>> snapshot if no transactions have committed or aborted since it was
>> taken
>
> Yeah, that might work better. And it'd be a win for all MVCC snaps,
> not just the ones coming fro
On Thu, Jan 5, 2012 at 5:15 AM, Florian Pflug wrote:
> On Jan4, 2012, at 21:27 , Robert Haas wrote:
>> I think the first thing we need to look at is increasing the number of
>> CLOG buffers.
>
> What became of the idea to treat the stable (i.e. earlier than the oldest
> active xid) and the unstabl
On Thu, Jan 5, 2012 at 14:18, Heikki Linnakangas
wrote:
> My laptop ran out of battery and turned itself off while I was just starting
> up postmaster. After plugging in the charger and rebooting, I got the
> following error when I tried to restart PostgreSQL:
>
> FATAL: bogus data in lock file "
My laptop ran out of battery and turned itself off while I was just
starting up postmaster. After plugging in the charger and rebooting, I
got the following error when I tried to restart PostgreSQL:
FATAL: bogus data in lock file "postmaster.pid": ""
postmaster.pid file was present in the dat
On Thu, Dec 29, 2011 at 4:02 PM, Peter Eisentraut wrote:
> Is there a secret reason why
>
> ALTER DOMAIN foo DROP CONSTRAINT nonexistent;
>
> doesn't report any error?
>
> If not, I think we should add one and also add the usual IF EXISTS
> option.
+1.
--
Robert Haas
EnterpriseDB: http://www.en
On Jan4, 2012, at 21:27 , Robert Haas wrote:
> I think the first thing we need to look at is increasing the number of
> CLOG buffers.
What became of the idea to treat the stable (i.e. earlier than the oldest
active xid) and the unstable (i.e. the rest) parts of the CLOG differently.
On 64-bit mac
On 03.12.2011 01:05, Tom Lane wrote:
Heikki Linnakangas writes:
Hmm, so you're saying that the FDW function needs to be able to return
multiple paths for a single joinrel. Fair enough, and that's not
specific to remote joins. Even a single-table foreign scan could be
implemented differently dep
Hello list,
I have a question of how to benchmark hardware to determine
the appropriate ratio of seq_page_cost vs random_page_cost.
Emails in this mailing lists archive seem to indicate that
1.0 vs 3.0 - 4.0 are appropriate values on modern hardware.
Which surprised me a bit as I had thought th
74 matches
Mail list logo
