On Fri, Apr 27, 2012 at 03:12, Tom Lane wrote:
> Does anybody else have an opinion as to which of these solutions is
> more preferable?
>
I think all unquoted whitespace should be ignored, so I prefer your
solution. (note: I haven't actually tested it, I'm going off these emails)
> And should
On Fri, Apr 27, 2012 at 11:27:03AM +0200, Vik Reykja wrote:
> On Fri, Apr 27, 2012 at 03:12, Tom Lane wrote:
>
> > Does anybody else have an opinion as to which of these solutions is
> > more preferable?
> >
>
> I think all unquoted whitespace should be ignored, so I prefer your
> solution. (not
The following bug has been logged on the website:
Bug reference: 6619
Logged by: Petteri Räty
Email address: petteri.r...@aalto.fi
PostgreSQL version: 9.1.3
Operating system: Gentoo Linux
Description:
I setup a hot standby master and slave following instructions at:
On Fri, Apr 27, 2012 at 8:47 AM, wrote:
> LOG: entering standby mode
> WARNING: WAL was generated with wal_level=minimal, data may be missing
> HINT: This happens if you temporarily set wal_level=minimal without taking
> a new base backup.
> FATAL: hot standby is not possible because wal_lev
Ryan Kelly writes:
> As long as we make it consistent on both sides of the '=>' (and document
> it, too), then I don't really care either way. Currently you have to use
> quotes to get an empty key, so I thought it natural to that you should
> have to quote to get an empty value.
> I've attached
The following bug has been logged on the website:
Bug reference: 6620
Logged by: sathish
Email address: sath...@myc2s.com
PostgreSQL version: 9.1.3
Operating system: windows Xp 32 bit
Description:
i have a Postgis table with about 2 million polyline records. The most
A few times today, we've seen postgresql 9.1.3 backends on Ubuntu 11.10 x86_64
get stuck in 'startup' mode. By that I mean the set_ps_output mode. Postgres
is installed via Martin Pitt's packages.
It manifests like this:
Server has been humming along fine, then suddenly many backends get stuck i
On 04/27/12 09:07, Jeff Frost wrote:
> A few times today, we've seen postgresql 9.1.3 backends on Ubuntu 11.10 x86_64
> get stuck in 'startup' mode. By that I mean the set_ps_output mode. Postgres
> is installed via Martin Pitt's packages.
quick followup on this..when it happens, you can connect
Jeff Frost writes:
> A few times today, we've seen postgresql 9.1.3 backends on Ubuntu 11.10 x86_64
> get stuck in 'startup' mode.
Well, the one you backtraced seems to be waiting for somebody else to
release one of the buffer mapping locks ... which is not a lock I'd
expect to get held long, eve
On Mon, Apr 23, 2012 at 7:49 AM, Matteo Beccati wrote:
> I've tried to come up with a self-contained test case but I haven't been
> able to replicate the error above. However the following script performs a
> few concurrent CREATE TABLE IF NOT EXISTS statements that produce some
> unexpected error
On Fri, Apr 27, 2012 at 3:47 AM, wrote:
> When I started the slave without the master running I got the following
> output:
>
> $ postgres -D gsd-replica/
> LOG: database system was interrupted while in recovery at log time
> 2012-04-25 12:01:33 UTC
> HINT: If this has occurred more than once s
On 04/27/12 10:14, Tom Lane wrote:
> Jeff Frost writes:
>> A few times today, we've seen postgresql 9.1.3 backends on Ubuntu 11.10
>> x86_64
>> get stuck in 'startup' mode.
> Well, the one you backtraced seems to be waiting for somebody else to
> release one of the buffer mapping locks ... which
On 04/27/12 11:54, Jeff Frost wrote:
> On 04/27/12 10:14, Tom Lane wrote:
>> Jeff Frost writes:
>>> A few times today, we've seen postgresql 9.1.3 backends on Ubuntu 11.10
>>> x86_64
>>> get stuck in 'startup' mode.
>> Well, the one you backtraced seems to be waiting for somebody else to
>> relea
Jeff Frost writes:
> Alright, found one that's a little different (at least it wasn't in
> InitPostgres):
It's still blocking at bufmgr.c:531 though ... so AFAICS this is another
victim of somebody monopolizing a buffer mapping lock.
regards, tom lane
--
Sent via pgsql
On 04/27/12 12:17, Tom Lane wrote:
> Jeff Frost writes:
>> Alright, found one that's a little different (at least it wasn't in
>> InitPostgres):
> It's still blocking at bufmgr.c:531 though ... so AFAICS this is another
> victim of somebody monopolizing a buffer mapping lock.
>
>
Any idea what I
Jeff Frost writes:
> Any idea what I should be looking for in the backtraces?
> I would imagine I can ignore any that are in InitPostgres, but that still
> leaves quite a few to look through.
I think you can probably skip all that are blocked in LWLockAcquire
called from bufmgr.c:531, at least f
On 04/27/12 12:27, Tom Lane wrote:
> Jeff Frost writes:
>> Any idea what I should be looking for in the backtraces?
>> I would imagine I can ignore any that are in InitPostgres, but that still
>> leaves quite a few to look through.
> I think you can probably skip all that are blocked in LWLockAcqu
> I think you can probably skip all that are blocked in LWLockAcquire
> called from bufmgr.c:531, at least for a first pass. Calls from
> elsewhere in bufmgr.c might be more interesting, and anything that's not
> blocked at an LWLockAcquire at all might be even more interesting.
A few more that i
It's tough to catch the thing in the act on the new server as they always
eventually clear..though they still sit in startup for up to 30 seconds on
occasion.
A few here that look interesting:
#0 0x7f62b6150583 in __select_nocancel () at
../sysdeps/unix/syscall-template.S:82
#1 0x7f62b8
Jeff Frost writes:
> and I've got 81 more that do not contain bufmgr.c and are also not block on
> LWLockAcquire.
Hm ... no smoking gun in what you showed so far. I also took another
look through 9.1 bufmgr.c, and I'm darned if I can see any code path
there that holds a buffer mapping lock for a
On 04/27/12 17:30, Tom Lane wrote:
> Jeff Frost writes:
>> and I've got 81 more that do not contain bufmgr.c and are also not block on
>> LWLockAcquire.
> Hm ... no smoking gun in what you showed so far. I also took another
> look through 9.1 bufmgr.c, and I'm darned if I can see any code path
>
On 04/27/12 17:45, Jeff Frost wrote:
> Oh, good idea! Looks like pg_buffercache is installed in this DB. Customer
> reports that it has been installed since the server has existed (and on the
> previous server) but is not currently being used, though the issue with the
> hanging startups did not
Jeff Frost writes:
> Oh, good idea! Looks like pg_buffercache is installed in this DB. Customer
> reports that it has been installed since the server has existed (and on the
> previous server) but is not currently being used, though the issue with the
> hanging startups did not start until this
> Well, sorry, but you can't have that. SHOW will tell you what your own
> backend thinks the value of the GUC variable is, but there is no way to
> know what's happening inside the logging collector process. And I'd be
> against trying to add a signaling mechanism that would support telling
> yo
On 04/27/12 18:15, Tom Lane wrote:
> No, it shouldn't. Perhaps we should start asking questions around the
> idea of "so what changed this morning?". There has to have been some
> triggering cause, a configuration change or application change or
> something.
Oh, we've been asking those questions
On 04/27/12 18:27, Jeff Frost wrote:
> To make it more interesting, today is a
> slow day.
And since it's a slow day..one more question..any further logging we could do
to help find the culprit?
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
Josh Berkus writes:
> You can end up in a situation where the logs aren't going where they're
> supposed to due to some external problem, and that the DBA has no way to
> find out what went wrong because he doesn't know where the logs are *now*.
Well, if nothing else, lsof would help. Another po
The following bug has been logged on the website:
Bug reference: 6621
Logged by: Kris Bushover
Email address: k...@spiceworks.com
PostgreSQL version: 9.1.3
Operating system: Red Hat Enterprise Linux Server release 6.2 (Santi
Description:
We have been getting constant
To Support,
I'm assisting our dba on this issue during a db setup. When the dba
runs: initdb -D directory_path, the following errors results:
dbadev-postgres[1]% initdb -D /u01/app/postgres/postgres_data
ld.so.1: initdb: fatal: libxslt.so.1: open failed: No such file or
directory Killed
Please a
On Apr 27, 2012, at 6:34 PM, Jeff Frost wrote:
> On 04/27/12 18:27, Jeff Frost wrote:
>> To make it more interesting, today is a
>> slow day.
>
> And since it's a slow day..one more question..any further logging we could do
> to help find the culprit?
FYI, reindexed the system tables and red
30 matches
Mail list logo
