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
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 birthd
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
>
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
>> shoul
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:
c
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
oth
"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 chec
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 th
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_s
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_authorizatio
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;
>
> Se
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 var
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;
>
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 real
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
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
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 r
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
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:
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
>>> intenti
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.
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
22 matches
Mail list logo
