[BUGS] UNLISTEN bug
In honor of the very first bug report I sent to postgresql more than 10
years ago regarding UNLISTEN[1], I have decided to submit another
UNLISTEN bug (against HEAD):
Session1:
LISTEN foo;
BEGIN;
UNLISTEN foo;
Session2:
NOTIFY foo;
Session1:
SELECT 1;
COMMIT;
SELECT 1;
I seem to recall testing out similar situations during my review of this
patch, but I think the code has changed since that time.
The bug is pretty simple: ProcessIncomingNotify() is called in a tight
loop in EnableNotifyInterrupt() while notifyInterruptOccurred is true.
EnableNotifyInterrupt() is assuming that ProcessIncomingNotify() will
unset it, but it has an early return that's triggered by my UNLISTEN.
Simply adding an additional "notifyInterruptOccurred = 0" in the early
return path (patch attached) seems to work. I added it there rather than
moving the whole line up, because I wasn't sure if it's safe to do that
before DisableCatchupInterrupt().
Regards,
Jeff Davis
[1] http://www.mail-archive.com/pgsql-bugs@postgresql.org/msg00225.html
Note: I couldn't even find that in our email archive, but thanks to our
new git repo, I found the commit fix by Bruce:
bdeeb4fe8ac22179eb0e12f16486e79c16090a2b
*** a/src/backend/commands/async.c
--- b/src/backend/commands/async.c
***
*** 2092,2098 ProcessIncomingNotify(void)
--- 2092,2101
/* Do nothing if we aren't actively listening */
if (listenChannels == NIL)
+ {
+ notifyInterruptOccurred = 0;
return;
+ }
/* Must prevent catchup interrupt while I am running */
catchup_enabled = DisableCatchupInterrupt();
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5672: Can't input julian days BC
The following bug has been logged online:
Bug reference: 5672
Logged by: Benjamin Gigot
Email address: therealval...@hotmail.com
PostgreSQL version: 8.4.4
Operating system: Ubuntu
Description:Can't input julian days BC
Details:
After trying to enter Confucius birthday (28th September 551BC) I had the
following error :
Query failed: ERROR: date/time field value out of range: "J1520447"
I then used a psql to try to enter different dates in the Julian days
format.
The date down to 0001-01-01 is working :
test=> INSERT INTO datetest (date) VALUES ('J1721426');
INSERT 0 1
But then under that it's not working anymore :
test=> INSERT INTO datetest (date) VALUES ('J1721425');
ERROR: date/time field value out of range: "J1721425"
LINE 1: INSERT INTO datetest (date) VALUES ('J1721425');
Documentation specify that dates can go down to J0, that is 4713BC.
Am I missing something ?
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5662: Incomplete view
On sön, 2010-09-19 at 14:28 -0400, Tom Lane wrote: > What about inventing a function to extract a sequence's parameters? > Perhaps something like > > pg_sequence_parameter(seq regclass, colname text) returns > bigint > > which would do an appropriate permissions check and then fetch the > named column. (This could actually be implemented in a line or two in > plpgsql, but I think we want it in C because information_schema > shouldn't depend on plpgsql.) Why shouldn't it? -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5662: Incomplete view
Peter Eisentraut writes: > On sön, 2010-09-19 at 14:28 -0400, Tom Lane wrote: >> which would do an appropriate permissions check and then fetch the >> named column. (This could actually be implemented in a line or two in >> plpgsql, but I think we want it in C because information_schema >> shouldn't depend on plpgsql.) > Why shouldn't it? Because plpgsql is removable (and I don't think that property is negotiable). regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5669: server process was terminated by exception 0xC0000005
I think I've tracked down the problem, although I haven't been able to
get a stack trace yet. I'm afraid that it's my own stupidity, but I
still don't understand why this crashes the entire engine.
On the collection table, I have a FTS index. I probably should have
defined the index this way:
create index ix_collection_name_fts on collection using
gin(to_tsvector('english', name));
but instead I defined it this way:
create index ix_collection_name_fts on collection using
gin(to_tsvector(get_fts_config_name(), name));
where the definition of the function is:
create or replace function get_fts_config_name() returns regconfig as $$
select setting::regconfig from pg_settings
where name = 'default_text_search_config';
$$ language sql immutable;
Once I remove the bad FTS index and replaced it with the good index,
the server no longer crashes.
Reading about immutable functions here
[http://developer.postgresql.org/pgdocs/postgres/xfunc-volatility.html],
made it sound like the only problem with making a volatile function
immutable is that the query planner might do the wrong thing. I
didn't realize it could have such drastic results... Is it still
worth getting a stack trace or is this just a don't-ever-do-that
thing?
Thanks
Andrew
On Tue, Sep 21, 2010 at 5:50 PM, Alvaro Herrera
wrote:
> Excerpts from Andrew Geery's message of mar sep 21 16:37:20 -0400 2010:
>> Running the server in debug mode, I see the following before the
>> server crashes -- it looks like something goes wrong with
>> autovac_balance_cost when trying to analyze the collection table (that
>> was the table the inserts were being done into).
>>
>> Thanks
>
> Hmm, can you get a stack trace? Please see
> http://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Windows
>
> Probably the easiest way to catch a dying autovacuum process is to set a
> very high value of vacuum_cost_delay, so that it sleeps for long enough
> that you can attach to it with the debugger before it dies.
>
> Thanks
>
> --
> Álvaro Herrera
> The PostgreSQL Company - Command Prompt, Inc.
> PostgreSQL Replication, Consulting, Custom Development, 24x7 support
>
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5669: server process was terminated by exception 0xC0000005
Andrew Geery writes: > I think I've tracked down the problem, although I haven't been able to > get a stack trace yet. I'm afraid that it's my own stupidity, but I > still don't understand why this crashes the entire engine. Me either. Can you narrow it down to a self-contained test case so others can reproduce the problem? regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5672: Can't input julian days BC
"Benjamin Gigot" writes: > After trying to enter Confucius birthday (28th September 551BC) I had the > following error : > Query failed: ERROR: date/time field value out of range: "J1520447" Hmm ... this did work in versions before 8.4, but got broken as a side-effect of tightening up error checking for other cases. It looks like we need to tweak ValidateDate() so that it won't throw an error for BC dates when Julian notation was used. Thanks for the report! regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5669: server process was terminated by exception 0xC0000005
The schema below crashes pretty reliably for me. There are three objects: an immutable function, a table called a and a gin index on table a using the immutable function. To reproduce the crash, do enough inserts into table a to kick off the auto-vacuum process; the insert statement below with the generate_series should do this. I tested this on Windows Vista using PG 9.0 and also on Linux (RHES4) using 8.4.4 (both packaged by EnterpriseDB) and it crashed both servers. Thanks Andrew create or replace function get_fts_config_name() returns regconfig as $$ select setting::regconfig from pg_settings where name = 'default_text_search_config'; $$ language sql immutable; CREATE TABLE a ( id serial primary key, my_text varchar(128) not null ); create index ix_a_my_text on a using gin(to_tsvector(get_fts_config_name(), my_text)); insert into a (my_text) select 'Test' from generate_series(1,1); On Wed, Sep 22, 2010 at 11:58 AM, Tom Lane wrote: > Andrew Geery writes: >> I think I've tracked down the problem, although I haven't been able to >> get a stack trace yet. I'm afraid that it's my own stupidity, but I >> still don't understand why this crashes the entire engine. > > Me either. Can you narrow it down to a self-contained test case so > others can reproduce the problem? > > regards, tom lane > -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5669: server process was terminated by exception 0xC0000005
Andrew Geery writes: > The schema below crashes pretty reliably for me. OK ... so the problem is that the function uses the pg_settings view, which results in calling show_all_settings(), and in particular it runs show_session_authorization(), which then dumps core because session_authorization_string is NULL in an autovacuum process. As far as a fix for the crash goes, I'm not sure if it'd be better to try to make show_session_authorization() return some sort of default value in this scenario, or to try to ensure that the variable has been set to something valid before we start running user-supplied code. In either case the problem is potentially wider than this one function and variable. Thoughts anyone? As far as the function itself goes, ISTM you ought to rethink it, because this looks like the very opposite of immutable to me: > create or replace function get_fts_config_name() returns regconfig as $$ >select setting::regconfig from pg_settings > where name = 'default_text_search_config'; > $$ language sql immutable; That's no excuse for the backend crashing, of course, but I would not be surprised at all if you end up with corrupt indexes due to the allegedly-immutable value changing. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5669: server process was terminated by exception 0xC0000005
Excerpts from Tom Lane's message of mié sep 22 12:39:24 -0400 2010: > OK ... so the problem is that the function uses the pg_settings view, > which results in calling show_all_settings(), and in particular it > runs show_session_authorization(), which then dumps core because > session_authorization_string is NULL in an autovacuum process. Ugh. > As far as a fix for the crash goes, I'm not sure if it'd be better to > try to make show_session_authorization() return some sort of default > value in this scenario, or to try to ensure that the variable has been > set to something valid before we start running user-supplied code. > In either case the problem is potentially wider than this one function > and variable. Thoughts anyone? My first thought is that the weird encoding of session_authorization_string should better be contained in as few places as possible, so we shouldn't try to initialize it to something valid-looking. Seems easier to have show_session_authorization() cope with a NULL value. But what would this default value be? -- Álvaro Herrera The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] UNLISTEN bug
Jeff Davis wrote: > In honor of the very first bug report I sent to postgresql more than 10 > years ago regarding UNLISTEN[1], I have decided to submit another > UNLISTEN bug (against HEAD): > > Session1: > >LISTEN foo; >BEGIN; >UNLISTEN foo; > > Session2: > >NOTIFY foo; > > Session1: > >SELECT 1; >COMMIT; >SELECT 1; > > I seem to recall testing out similar situations during my review of this > patch, but I think the code has changed since that time. So the problem report is? I tested it and the problem is that the final SELECT 1 hung. Is that the problem? -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5669: server process was terminated by exception 0xC0000005
Alvaro Herrera writes: > Excerpts from Tom Lane's message of mié sep 22 12:39:24 -0400 2010: >> As far as a fix for the crash goes, I'm not sure if it'd be better to >> try to make show_session_authorization() return some sort of default >> value in this scenario, or to try to ensure that the variable has been >> set to something valid before we start running user-supplied code. >> In either case the problem is potentially wider than this one function >> and variable. Thoughts anyone? > My first thought is that the weird encoding of > session_authorization_string should better be contained in as few places > as possible, so we shouldn't try to initialize it to something > valid-looking. Seems easier to have show_session_authorization() cope > with a NULL value. Yeah, coping with a NULL seems like the best thing to me too after further reflection: the other way couldn't possibly cope with scenarios like "show_session_authorization gets called before we got around to initializing the variable". > But what would this default value be? Wouldn't an empty string be acceptable? SQL doesn't allow zero-length identifiers, so this couldn't be confused with any really-valid value. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] UNLISTEN bug
Bruce Momjian wrote: > Jeff Davis wrote: > > In honor of the very first bug report I sent to postgresql more than 10 > > years ago regarding UNLISTEN[1], I have decided to submit another > > UNLISTEN bug (against HEAD): > > > > Session1: > > > >LISTEN foo; > >BEGIN; > >UNLISTEN foo; > > > > Session2: > > > >NOTIFY foo; > > > > Session1: > > > >SELECT 1; > >COMMIT; > >SELECT 1; > > > > I seem to recall testing out similar situations during my review of this > > patch, but I think the code has changed since that time. > > So the problem report is? I tested it and the problem is that the final > SELECT 1 hung. Is that the problem? To confirm, it was majorly hung. Cancel and kill did not work, pg_ctl -m fast did not work either. I had to kill -3. Bad. :-( -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5669: server process was terminated by exception 0xC0000005
Excerpts from Tom Lane's message of mié sep 22 13:03:06 -0400 2010: > Alvaro Herrera writes: > > But what would this default value be? > > Wouldn't an empty string be acceptable? SQL doesn't allow zero-length > identifiers, so this couldn't be confused with any really-valid value. I dunno really -- what is this value used for, anyway? If it's just to be able to generate the SHOW table which is then parsed to obtain the fulltext configuration, seems OK. -- Álvaro Herrera The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5669: server process was terminated by exception 0xC0000005
Alvaro Herrera writes: > Excerpts from Tom Lane's message of mié sep 22 13:03:06 -0400 2010: >> Wouldn't an empty string be acceptable? SQL doesn't allow zero-length >> identifiers, so this couldn't be confused with any really-valid value. > I dunno really -- what is this value used for, anyway? If it's just to be > able to generate the SHOW table which is then parsed to obtain the > fulltext configuration, seems OK. Well, the more general point is what should "SHOW session_authorization" show in an autovacuum process? The fact that Andrew wasn't intentionally doing that doesn't mean that someone else might not try it. I think we can either decide it should be an obviously-illegal value, or try to make it return the name of the cluster-creating superuser. The latter seems like more work than it's worth though. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] UNLISTEN bug
On Wed, 2010-09-22 at 13:06 -0400, Bruce Momjian wrote: > To confirm, it was majorly hung. Cancel and kill did not work, pg_ctl > -m fast did not work either. I had to kill -3. Bad. :-( Yes, that was the problem. I believe the fix is simple, however. If there had to be a problem with in 9.0.0, but we could pick the command, I think we would all choose UNLISTEN ;) As an aside, one of the things that really impressed me about PostgreSQL so long ago was how quickly you, Tom, and Jan responded to my first UNLISTEN bug report 10 years ago. It was handled seriously, professionally, honestly, and openly; even though it seemed like the most trivial bug that I could imagine at the time. Regards, Jeff Davis -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5669: server process was terminated by exception 0xC0000005
Excerpts from Tom Lane's message of mié sep 22 13:36:18 -0400 2010: > Alvaro Herrera writes: > > Excerpts from Tom Lane's message of mié sep 22 13:03:06 -0400 2010: > >> Wouldn't an empty string be acceptable? SQL doesn't allow zero-length > >> identifiers, so this couldn't be confused with any really-valid value. > > > I dunno really -- what is this value used for, anyway? If it's just to be > > able to generate the SHOW table which is then parsed to obtain the > > fulltext configuration, seems OK. > > Well, the more general point is what should "SHOW session_authorization" > show in an autovacuum process? The fact that Andrew wasn't > intentionally doing that doesn't mean that someone else might not try > it. I think we can either decide it should be an obviously-illegal > value, or try to make it return the name of the cluster-creating > superuser. The latter seems like more work than it's worth though. +1 for the illegal value. -- Álvaro Herrera The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5669: server process was terminated by exception 0xC0000005
Alvaro Herrera writes: > Excerpts from Tom Lane's message of mié sep 22 13:36:18 -0400 2010: >> Well, the more general point is what should "SHOW session_authorization" >> show in an autovacuum process? The fact that Andrew wasn't >> intentionally doing that doesn't mean that someone else might not try >> it. I think we can either decide it should be an obviously-illegal >> value, or try to make it return the name of the cluster-creating >> superuser. The latter seems like more work than it's worth though. > +1 for the illegal value. OK. I just dug through all the other show-hook functions and confirmed that show_session_authorization is the only one that will dump core if its variable is NULL, so it looks like we have just one case to fix. Will get on it once I get my repo back together ... regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5671: ERROR: out of memory
On Tue, Sep 21, 2010 at 4:54 PM, Jairo Carrillo wrote: > > The following bug has been logged online: > > Bug reference: 5671 > Logged by: Jairo Carrillo > Email address: carsof...@gmail.com > PostgreSQL version: 8.4 > Operating system: windows server 2003 r2 > Description: ERROR: out of memory > Details: > > INFO: vacuuming "public.localizacion" >>> ERROR: out of memory >>> DETAIL: Failed on request of size 1048575996. >>> >>> ERROR: out of memory >>> DETAIL: Failed on request of size 1048575996. I'm not sure if there's a bug here or not, but it sounds like you're out of memory. :-) What is the value of maintenance_work_mem? How large is the table? How much memory do you have on your machine? Exactly which 8.4 release are you running? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5669: server process was terminated by exception 0xC0000005
On Wed, Sep 22, 2010 at 1:54 PM, Tom Lane wrote: > Alvaro Herrera writes: >> Excerpts from Tom Lane's message of mié sep 22 13:36:18 -0400 2010: >>> Well, the more general point is what should "SHOW session_authorization" >>> show in an autovacuum process? The fact that Andrew wasn't >>> intentionally doing that doesn't mean that someone else might not try >>> it. I think we can either decide it should be an obviously-illegal >>> value, or try to make it return the name of the cluster-creating >>> superuser. The latter seems like more work than it's worth though. > >> +1 for the illegal value. > > OK. I just dug through all the other show-hook functions and confirmed > that show_session_authorization is the only one that will dump core if > its variable is NULL, so it looks like we have just one case to fix. > Will get on it once I get my repo back together ... Can SHOW return a NULL value, rather than the empty string? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5669: server process was terminated by exception 0xC0000005
Robert Haas writes: > Can SHOW return a NULL value, rather than the empty string? I think that would take some work in guc.c, and likely a redefinition of the API for show-hook functions. I'm not excited about doing it, particularly not in a bug fix that needs to be back-patched. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] libpq: system-wide root.crt
On Thu, Aug 19, 2010 at 23:11, Martin Pitt wrote: > Hello PostgreSQL developers, > > Martin Pitt [2010-08-17 6:49 +0200]: >> I received a request to support system-wide root certificates in >> libpq. Right now it only looks in ~/.postgresql/root.crt, but since >> such certificates are usually set up system wide and be maintained by >> the sysadmins, it would be very convenient if there was a fallback >> lookup in /etc/postgresql/ or similar. > > Patch attached against current git head. I tested it with both the > default case (new option not specified), as well as with > --with-ssl-root-cert-dir=/etc/postgresql-common, and confirm that in > the latter case root.crt gets picked up from > /etc/postgresql-common/ if it's not in ~/.postgresql/. I wonder if we want to have a default value for this rather than disabling it when it's not specified by configure. But is there any kind of reasonable default that's not going to be platform/distribution specific? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
