On 27.4.2012. 0:39, Tom Lane wrote:
>
> There is no supported method for changing the order of attributes in a
> composite type, so I wonder exactly how you did step 4. If it involved
> direct manipulation of the system catalogs, I would say this falls in
> the category of "if you break it, you ge
Josh Berkus writes:
> We do have one piece of unituitive behavior here though, which forms a
> bit of a catch-22:
> 1. DBA changes the log directory
> 2. Log directory is unwriteable
> 3. Postgres continues writing to the old log_directory
> 4. SHOW log_directory displays the *new* log_directory
I wrote:
> Mark Kirkwood writes:
>> Might be a red herring, but I was able to reproduce this if (and only
>> if) I forgot to create the new dest directory before doing the reload.
>> Subsequently creating the directory and reloading did not result in a
>> file in the new location.
> Whoever wr
> Whoever wrote that thought that Log_RotationAge/Log_RotationSize would
> get reset to normal values during SIGHUP, but it's far from clear to me
> that any such thing would actually happen. However, this would only
> apply to Josh's problem if he was trying to set a bogus new value of
> log_dir
Mark Kirkwood writes:
> Might be a red herring, but I was able to reproduce this if (and only
> if) I forgot to create the new dest directory before doing the reload.
> Subsequently creating the directory and reloading did not result in a
> file in the new location.
Hmm, interesting point. Th
Josh Berkus writes:
>> Do you want to try attaching to the collector with a debugger and seeing
>> if it ever gets into the "if (got_SIGHUP)" block in SysLoggerMain?
> Hmmm. No debugger on this system, not unexpectedly. I'll see if I can
> get authorization to add one.
How about strace --- if
> Do you want to try attaching to the collector with a debugger and seeing
> if it ever gets into the "if (got_SIGHUP)" block in SysLoggerMain?
Hmmm. No debugger on this system, not unexpectedly. I'll see if I can
get authorization to add one.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pge
On 27/04/12 13:11, Josh Berkus wrote:
On 4/26/12 5:50 PM, Tom Lane wrote:
Josh Berkus writes:
Summary: despite pg_reload(), log directory, filename and destination
don't change
Looking at the code, it's really hard to see how this could possibly
happen, unless maybe the process is blocking re
Josh Berkus writes:
> On 4/26/12 5:50 PM, Tom Lane wrote:
>> check the process's signal masks like this:
>> grep ^Sig /proc//status
>> where is the logging collector's PID. Could we see that?
> SigQ: 0/399360
> SigPnd:
> SigBlk:
> SigIgn: 0100
I wrote:
> Ryan Kelly writes:
>> In my mind, all of these should have been rejected as erroneous input.
>> To that end, I have attached a patch which causes all of these inputs
>> to be rejected as invalid.
> Hm, I would have expected all three of these to result in "a" having
> an empty-string v
On 4/26/12 5:50 PM, Tom Lane wrote:
> Josh Berkus writes:
>> Summary: despite pg_reload(), log directory, filename and destination
>> don't change
>
> Looking at the code, it's really hard to see how this could possibly
> happen, unless maybe the process is blocking receipt of SIGHUP. Which
> it
Josh Berkus writes:
> Summary: despite pg_reload(), log directory, filename and destination
> don't change
Looking at the code, it's really hard to see how this could possibly
happen, unless maybe the process is blocking receipt of SIGHUP. Which
it shouldn't be. Not sure about RHEL5, but on rec
Summary: despite pg_reload(), log directory, filename and destination
don't change
Version: 9.1.3
Platform: RHEL5, custom compile
Severity: Persistant annoyance
Description:
1) change log_directory in postgresql.conf
2) pg_reload_conf()
3) show log_directory displays the correct new directory
4)
On 4/26/12 3:48 PM, Tom Lane wrote:
> Josh Berkus writes:
>> Also, have we discussed maybe hiding these schemas from \dn?
>
> We've done more than discuss it:
> http://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=e43fb604d6db229d70d3101aa53348cc16a5473a
>
> I take it you're using s
Ryan Kelly writes:
> It seems that ALTER TABLE ... OWNER TO does not change the ownership of
> any inheriting tables. The documentation states:
>> If ONLY is specified, only that table is altered. If ONLY is not
>> specified, the table and any descendant tables are altered.
If you read further (
On Thu, Apr 26, 2012 at 5:48 PM, Tom Lane wrote:
> Josh Berkus writes:
>> Also, have we discussed maybe hiding these schemas from \dn?
>
> We've done more than discuss it:
> http://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=e43fb604d6db229d70d3101aa53348cc16a5473a
>
> I take it yo
Josh Berkus writes:
> Also, have we discussed maybe hiding these schemas from \dn?
We've done more than discuss it:
http://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=e43fb604d6db229d70d3101aa53348cc16a5473a
I take it you're using something older than 9.1.
On Thu, Apr 26, 2012 at 5:35 PM, Josh Berkus wrote:
>
> Also, have we discussed maybe hiding these schemas from \dn?
>
+1 from this idea... maybe do them visible only on \dn+
--
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL: Soporte 24x7 y capacitación
--
Sent via pgsql-b
rikard.pave...@zg.htnet.hr writes:
> Steps to reproduce problem:
> 1) create composite type
> 2) use composite type as column in a table
> 3) clone database
> 4) change order of attributes in cloned database
> 5) dump to plain sql with column names
> 6) restore sql dump to cloned database
There is
On 4/26/12 11:22 AM, Tom Lane wrote:
> Josh Berkus writes:
>> summary: database has 291 empty pg_toast_temp schemas.
>
> If your max_connections is 300 or more, this isn't surprising in the
> least.
Yes, they are.
>> ... so, apparently we still have an issue with cleaning up pg_toast_temp
>> sc
The following bug has been logged on the website:
Bug reference: 6618
Logged by: Rikard Pavelic
Email address: rikard.pave...@zg.htnet.hr
PostgreSQL version: 9.1.3
Operating system: Windows 7
Description:
We've run into another issue with composite types.
I've search
Ryan Kelly writes:
> It seems that the hstore parser has some odd behavior in the the
> handling of certain malformed input constructions:
> [db]> select 'a=>,b=>1'::hstore;
> hstore
> --
> "a"=>",b=>1"
> [db]> select 'a=> ,b=>1'::hstore;
> hstore
> --
>
It seems that the hstore parser has some odd behavior in the the
handling of certain malformed input constructions:
[db]> select 'a=>,b=>1'::hstore;
hstore
--
"a"=>",b=>1"
[db]> select 'a=> ,b=>1'::hstore;
hstore
--
"a"=>",b=>1"
[db]> select 'a=>, b=>1':
Josh Berkus writes:
> summary: database has 291 empty pg_toast_temp schemas.
If your max_connections is 300 or more, this isn't surprising in the
least.
> ... so, apparently we still have an issue with cleaning up pg_toast_temp
> schema?
If they are empty, no we don't have a problem with cleani
summary: database has 291 empty pg_toast_temp schemas.
severity: head-scratcher
version: 9.0.7
platform: RHEL6
description:
* medium-large production database (300GB)
* does data collection and analytics
* lately has been having chronic lock-blocking issues
* does many, daily batch jobs which inv
wrote:
> When tried setting FETCH FIRST parameter dynamically in RETURN
> QUERY EXECUTE some_query USING param1 it resulted with a syntax
> error on FETCH FIRST parameter.
>
> Apparently, it only accepts constants so it works with ($1)
That's not a bug. Use the parentheses as specified in t
The following bug has been logged on the website:
Bug reference: 6617
Logged by: Dražen Odobašić
Email address: dodo...@geoinfo.geof.hr
PostgreSQL version: 9.1.3
Operating system: Linux 3.3.3
Description:
When tried setting FETCH FIRST parameter dynamically in RETURN
It seems that ALTER TABLE ... OWNER TO does not change the ownership of
any inheriting tables. The documentation states:
> If ONLY is specified, only that table is altered. If ONLY is not
> specified, the table and any descendant tables are altered.
Which to me indicates that ownership should be
28 matches
Mail list logo
