Re: [BUGS] BUG #4509: array_cat's null behaviour is inconsistent
Kevin Field wrote:
Section 9.2 in the docs say, 'The ordinary comparison operators yield null
(signifying "unknown") when either input is null.' This applies to other
operators too. For example, the result of tacking an unknown value onto a
known one is unknown, because you don't know what exactly you just tacked
on. So
select null::text || 'hello';
...returns NULL, which makes sense. But then this
select array_cat(null::integer[], '{3}'::integer[]);
...doesn't return NULL, which it should, for consistency.
Doesn't make sense to me either. I found that this was changed between
8.1 (where it returns null) and 8.2, but I find nothing in the
respective release notes or commit messages about this change. Tom?
--
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 #4510: memory leak with libpg.dll
The following bug has been logged online: Bug reference: 4510 Logged by: MWendt Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.x, 8.2.x Operating system: windows xp (client), linux (postgres server) Description:memory leak with libpg.dll Details: 1) DB server is down. 2) the client will connect to these DB server and is running correctly in a timeout. the problem is: for each connection attempt that will fail the memory usage is growing. that will result in massive memory allocation, if the client try to reconnect in high frequency. and furthermore the memory is not freed when the next connection can be established. 3) I guess in libpg.dll are some connection structures that are not freed correctly if the connection coult not established well. -- 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] plperl & sort
On Nov 4, 2008, at 4:43 PM, Andrew Dunstan wrote:
OK, the first thing to note is that there is an easy workaround,
which is to use a sort routine that doesn't need $a/$b. Example:
create or replace function mysort() returns text language plperl
as $f$
my $sfunc = sub ($$) { $_[0] <=> $_[1] };
my @vals = (5,3,4,2,7);
return join(' ',sort $sfunc @vals);
$f$;
Andrew for the win!
Thanks a lot!
I agree, a documentation note would be fine for this rather doing all
sorts of complicated perl trickery.
--
Jeff Trout <[EMAIL PROTECTED]>
http://www.stuarthamm.net/
http://www.dellsmartexitin.com/
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [ODBC] [BUGS] Behavior change of FK info query
Ok, agree. I will prepare it. Then, I need carefully packaging. - Original Message - From: "Dave Page" <[EMAIL PROTECTED]> 2008/11/4 Hiroshi Saito <[EMAIL PROTECTED]>: Furthermore, I think it good to use libpq by which 8.3.5 was released. So, it is better to pack up 08.03.0310.? to Dave and Inoue-san. What do you think? 08.03.0400 sounds better to me. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com -- Sent via pgsql-odbc mailing list ([EMAIL PROTECTED]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-odbc -- 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 #4510: memory leak with libpg.dll
MWendt wrote: The following bug has been logged online: Bug reference: 4510 Logged by: MWendt Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.x, 8.2.x Operating system: windows xp (client), linux (postgres server) Description:memory leak with libpg.dll Details: 1) DB server is down. 2) the client will connect to these DB server and is running correctly in a timeout. the problem is: for each connection attempt that will fail the memory usage is growing. that will result in massive memory allocation, if the client try to reconnect in high frequency. and furthermore the memory is not freed when the next connection can be established. 3) I guess in libpg.dll are some connection structures that are not freed correctly if the connection coult not established well. Is there any chance you can supply the source code of a self-contained, compileable test case (example program) that can demonstrate this? Your description doesn't exclude the possibility of leaks occurring as a consequence of failure to free resources in the program using libpq. -- Craig Ringer -- 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 #4510: memory leak with libpg.dll
Craig Ringer <[EMAIL PROTECTED]> writes: > MWendt wrote: >> 2) the client will connect to these DB server and is running correctly in a >> timeout. the problem is: for each connection attempt that will fail the >> memory usage is growing. that will result in massive memory allocation, if >> the client try to reconnect in high frequency. > Is there any chance you can supply the source code of a self-contained, > compileable test case (example program) that can demonstrate this? Your > description doesn't exclude the possibility of leaks occurring as a > consequence of failure to free resources in the program using libpq. In particular I wonder whether the application is neglecting to call PQfinish() on the failed connection objects ... 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 #4509: array_cat's null behaviour is inconsistent
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Kevin Field wrote:
>> select array_cat(null::integer[], '{3}'::integer[]);
>> ...doesn't return NULL, which it should, for consistency.
> Doesn't make sense to me either. I found that this was changed between
> 8.1 (where it returns null) and 8.2, but I find nothing in the
> respective release notes or commit messages about this change. Tom?
Hm, I seem to have changed it in the patch that added support for nulls
within arrays, but I don't recall the reasoning for this detail ATM.
I'm loath to change just this one thing though. If we're going to
monkey with it, I think we should start by having a thought-through
proposal about the behavior of all the array functions for corner
cases like null arrays and empty arrays (cf recent discussion about
zero-dimensional arrays).
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
[BUGS] BUG #4512: PostgreSQL crash on update command
The following bug has been logged online: Bug reference: 4512 Logged by: Keven Guindon Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3.5 Operating system: Windows XP sp3 Description:PostgreSQL crash on update command Details: SQl Update command: UPDATE prod.man_insert_line2 SET "Feed" = (SELECT "Feed" FROM "Production_Line2" WHERE "Date" BETWEEN '2008-02-14 13:00:03'::timestamp + ((252000 - 6000) || ' second')::interval AND'2008-02-14 13:00:03'::timestamp + ((252000 + 6000) || ' second')::interval AND "AC_TorchTime" BETWEEN 252000 - 1000 AND 252000 LIMIT 1), "GFI7" = (SELECT "GFI7" FROM "Production_Line2" WHERE "Date" BETWEEN '2008-02-14 13:00:03'::timestamp + ((252000 - 6000) || ' second')::interval AND '2008-02-14 13:00:03'::timestamp + ((252000 + 6000) || ' second')::interval AND "AC_TorchTime" BETWEEN 252000 - 1000 AND 252000 LIMIT 1), "GFI9" = (SELECT "GFI9" FROM "Production_Line2" WHERE "Date" BETWEEN '2008-02-14 13:00:03'::timestamp + ((252000 - 6000) || ' second')::interval AND '2008-02-14 13:00:03'::timestamp + ((252000 + 6000) || ' second')::interval AND "AC_TorchTime" BETWEEN 252000 - 1000 AND 252000 LIMIT 1), "Scraper Powder" = (SELECT "Scraper Powder" FROM "Production_Line2" WHERE "Date" BETWEEN '2008-02-14 13:00:03'::timestamp + ((252000 - 6000) || ' second')::interval AND '2008-02-14 13:00:03'::timestamp + ((252000 + 6000) || ' second')::interval AND "AC_TorchTime" BETWEEN 252000 - 1000 AND 252000 LIMIT 1) WHERE torchtime = 70.0; Event Type: Error Event Source: Application Error Event Category: (100) Event ID: 1000 Date: 11/5/2008 Time: 10:56:04 AM User: N/A Computer: SYSTEMDB Description: Faulting application postgres.exe, version 8.3.5.8304, faulting module msvcr80.dll, version 8.0.50727.1433, fault address 0x0001500a. For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp. Data: : 41 70 70 6c 69 63 61 74 Applicat 0008: 69 6f 6e 20 46 61 69 6c ion Fail 0010: 75 72 65 20 20 70 6f 73 ure pos 0018: 74 67 72 65 73 2e 65 78 tgres.ex 0020: 65 20 38 2e 33 2e 35 2e e 8.3.5. 0028: 38 33 30 34 20 69 6e 20 8304 in 0030: 6d 73 76 63 72 38 30 2e msvcr80. 0038: 64 6c 6c 20 38 2e 30 2e dll 8.0. 0040: 35 30 37 32 37 2e 31 34 50727.14 0048: 33 33 20 61 74 20 6f 66 33 at of 0050: 66 73 65 74 20 30 30 30 fset 000 0058: 31 35 30 30 611500a -- 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 #4512: PostgreSQL crash on update command
"Keven Guindon" <[EMAIL PROTECTED]> writes: > Description:PostgreSQL crash on update command Please provide sufficient information to let us reproduce the crash (the query alone is not sufficient). See http://www.postgresql.org/docs/8.3/static/bug-reporting.html if you need advice about how to prepare an adequate bug 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] plperl & sort
> "nathan" == nathan wagner <[EMAIL PROTECTED]> writes: nathan> Completely untested speculation based on my knowledge of perl nathan> and a bit of reading: nathan> The reason you can't see $a and $b is that sort internally nathan> sets these variables in the main package. That is, sort is nathan> setting $main::a and $main::b, and when you run the plperl nathan> code in the safe compartment, main:: isn't visible any more. Nice theory, but completely wrong: sort creates $a and $b in the current package, not in main::. -- Andrew (irc:RhodiumToad) -- 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] plperl & sort
Andrew Gierth <[EMAIL PROTECTED]> writes: > Nice theory, but completely wrong: sort creates $a and $b in the > current package, not in main::. Hmm ... so then why are we seeing a failure? 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] plperl & sort
On Wed, Nov 5, 2008 at 10:54, Andrew Gierth <[EMAIL PROTECTED]> wrote: >> "nathan" == nathan wagner <[EMAIL PROTECTED]> writes: > > nathan> Completely untested speculation based on my knowledge of perl > nathan> and a bit of reading: > > nathan> The reason you can't see $a and $b is that sort internally > nathan> sets these variables in the main package. That is, sort is > nathan> setting $main::a and $main::b, and when you run the plperl > nathan> code in the safe compartment, main:: isn't visible any more. > > Nice theory, but completely wrong: sort creates $a and $b in the > current package, not in main::. current package is main ;) -- 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] plperl & sort
On Wed, Nov 5, 2008 at 11:14, Tom Lane <[EMAIL PROTECTED]> wrote: > Andrew Gierth <[EMAIL PROTECTED]> writes: >> Nice theory, but completely wrong: sort creates $a and $b in the >> current package, not in main::. > > Hmm ... so then why are we seeing a failure? Because Safe runs in a different namespace altogether (part of why its Safe). We build the sub under Safe but then execute it in the real namespace. The patch I posted fixes this but Id like someone with more knowledge of safe to look over it. From a quick cvs log it *looked* like that was Andrew Dunstan which is why I cc'ed him. This is not a Safe bug IMHO its our (ab)use of it that is causing the problem. Of course if its only sort that gets affected maybe the cure is worse than the disease... -- 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 #4509: array_cat's null behaviour is inconsistent
> I'm loath to change just this one thing though. If we're going to > monkey with it, I think we should start by having a thought-through > proposal about the behavior of all the array functions for corner > cases like null arrays and empty arrays (cf recent discussion about > zero-dimensional arrays). If those are the only corner cases, here's something to work with. Looking at http://www.postgresql.org/docs/8.3/interactive/functions-array.html, I'd propose that every one of those operators and functions should return NULL::(normal-return-type) if any of their operands are NULL, to be consistent with Section 9.2 and to differentiate from the empty- array cases below, and that logic should precede anything to do with empty arrays. As for empty arrays, the following additions to the logic: = true if both arrays are empty <> true if either array is empty but not both < true if left operand is empty and right is not > true if right operand is empty and left is not <= true if left operand is empty >= true if right operand is empty @> true if right operand is empty <@ true if left operand is empty && false if either array is empty || (both array-array cases) return other array if one is empty (if left is empty, return right, elsif right is empty, return left) || (both element-array cases) return ARRAY[element] if array is empty array_append return ARRAY[element] if array is empty array_cat return other array if one is empty (if left is empty, return right, elsif right is empty, return left) array_dims return results obtained by ignoring empty sub-arrays; if entire array is empty, return '' array_lower raise exception if array is empty (there are no dimensions to inquire about) array_prepend return ARRAY[element] if array is empty array_to_string return '' if array is empty array_upper raise exception if array is empty (there are no dimensions to inquire about) string_to_array return '' if left operand is '' Hope that's useful... Kev -- 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 #4513: VACUUM FULL fails with "out of memory" error
The following bug has been logged online: Bug reference: 4513 Logged by: Alexey Bashtanov Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3.1 Operating system: Red Hat Linux 2.6.20-1.2320.fc5smp i686 Description:VACUUM FULL fails with "out of memory" error Details: Hello! Such a thing happens: when I make an attempt to vacuum full a table it waits some minutes and then throws an error: ERROR: out of memory DETAIL: Failed on request of size 288. It doesn't matter I set maintenance_work_mem to 16MB, 200MB or 1GB. This table is bad enough: it has a size of 154G but "explain select *" says there are only 524597 rows (and that value seems to be near to true). It is not wide: integer, integer, character varying(10), integer, character varying(3), date, integer. Here's the part of serverlog: == TopMemoryContext: 49416 total in 6 blocks; 8776 free (46 chunks); 40640 used TopTransactionContext: 2986336304 total in 367 blocks; 192312 free (1088 chunks); 2986143992 used Type information cache: 8192 total in 1 blocks; 1800 free (0 chunks); 6392 used Operator class cache: 8192 total in 1 blocks; 3848 free (0 chunks); 4344 used Record information cache: 8192 total in 1 blocks; 1800 free (0 chunks); 6392 used Operator lookup cache: 24576 total in 2 blocks; 14072 free (6 chunks); 10504 used MessageContext: 8192 total in 1 blocks; 5664 free (0 chunks); 2528 used smgr relation table: 8192 total in 1 blocks; 2808 free (0 chunks); 5384 used TransactionAbortContext: 32768 total in 1 blocks; 32752 free (0 chunks); 16 used Portal hash: 8192 total in 1 blocks; 3912 free (0 chunks); 4280 used PortalMemory: 8192 total in 1 blocks; 8040 free (0 chunks); 152 used PortalHeapMemory: 3072 total in 2 blocks; 2928 free (8 chunks); 144 used Vacuum: 8192 total in 1 blocks; 7872 free (0 chunks); 320 used Relcache by OID: 8192 total in 1 blocks; 3376 free (0 chunks); 4816 used CacheMemoryContext: 667472 total in 20 blocks; 108288 free (0 chunks); 559184 used pg_index_indrelid_index: 1024 total in 1 blocks; 304 free (0 chunks); 720 used pg_settings: 15360 total in 4 blocks; 6912 free (0 chunks); 8448 used pg_ts_dict_oid_index: 1024 total in 1 blocks; 344 free (0 chunks); 680 used pg_aggregate_fnoid_index: 1024 total in 1 blocks; 304 free (0 chunks); 720 used pg_language_name_index: 1024 total in 1 blocks; 344 free (0 chunks); 680 used pg_statistic_relid_att_index: 1024 total in 1 blocks; 240 free (0 chunks); 784 used pg_ts_dict_dictname_index: 1024 total in 1 blocks; 280 free (0 chunks); 744 used pg_namespace_nspname_index: 1024 total in 1 blocks; 304 free (0 chunks); 720 used pg_opfamily_oid_index: 1024 total in 1 blocks; 344 free (0 chunks); 680 used pg_opclass_oid_index: 1024 total in 1 blocks; 304 free (0 chunks); 720 used pg_ts_parser_prsname_index: 1024 total in 1 blocks; 280 free (0 chunks); 744 used pg_amop_fam_strat_index: 1024 total in 1 blocks; 88 free (0 chunks); 936 used pg_opclass_am_name_nsp_index: 1024 total in 1 blocks; 152 free (0 chunks); 872 used pg_trigger_tgrelid_tgname_index: 1024 total in 1 blocks; 240 free (0 chunks); 784 used pg_cast_source_target_index: 1024 total in 1 blocks; 240 free (0 chunks); 784 used pg_auth_members_role_member_index: 1024 total in 1 blocks; 280 free (0 chunks); 744 used pg_attribute_relid_attnum_index: 1024 total in 1 blocks; 240 free (0 chunks); 784 used pg_ts_config_cfgname_index: 1024 total in 1 blocks; 280 free (0 chunks); 744 used pg_authid_oid_index: 1024 total in 1 blocks; 304 free (0 chunks); 720 used pg_ts_config_oid_index: 1024 total in 1 blocks; 344 free (0 chunks); 680 used pg_conversion_default_index: 1024 total in 1 blocks; 128 free (0 chunks); 896 used pg_language_oid_index: 1024 total in 1 blocks; 344 free (0 chunks); 680 used pg_enum_oid_index: 1024 total in 1 blocks; 344 free (0 chunks); 680 used pg_proc_proname_args_nsp_index: 1024 total in 1 blocks; 152 free (0 chunks); 872 used pg_ts_parser_oid_index: 1024 total in 1 blocks; 344 free (0 chunks); 680 used pg_database_oid_index: 1024 total in 1 blocks; 304 free (0 chunks); 720 used pg_conversion_name_nsp_index: 1024 total in 1 blocks; 280 free (0 chunks); 744 used pg_class_relname_nsp_index: 1024 total in 1 blocks; 240 free (0 chunks); 784 used pg_attribute_relid_attnam_index: 1024 total in 1 blocks; 280 free (0 chunks); 744 used pg_class_oid_index: 1024 total in 1 blocks; 304 free (0 chunks); 720 used pg_amproc_fam_proc_index: 1024 total in 1 blocks; 88 free (0 chunks); 936 used pg_operator_oprname_l_r_n_index: 1024 total in 1 blocks; 88 free (0 chunks); 936 used pg_index_indexrelid_index: 1024 total in 1 blocks; 304 free (0 chunks); 720 used pg_type_oid_index: 1024 total in 1 blocks; 304 free (0 chunks); 720 used pg_rewrite_rel_rulename_index: 1024 total in 1 blocks; 240 free (0 chunks); 784 used
Re: [BUGS] BUG #4513: VACUUM FULL fails with "out of memory" error
"Alexey Bashtanov" <[EMAIL PROTECTED]> writes: > The following bug has been logged online: > > Bug reference: 4513 > Logged by: Alexey Bashtanov > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.3.1 > Operating system: Red Hat Linux 2.6.20-1.2320.fc5smp i686 > Description:VACUUM FULL fails with "out of memory" error Are you sure this is 8.3.1 and not 8.3.0? There is a bug fixed in 8.3.1 which sounds a lot like this: Another VACUUM FULL bug introduced in 8.3 could result in a crash or out-of-memory report when dealing with pages containing no live tuples. > Here's the part of serverlog: > == > TopMemoryContext: 49416 total in 6 blocks; 8776 free (46 chunks); 40640 > used > TopTransactionContext: 2986336304 total in 367 blocks; 192312 free (1088 > chunks); 2986143992 used It does look like you have a memory leak in VACUUM FULL. There have been three memory leaks fixed in bug-fix releases since 8.3.1 but none should be related to VACUUM FULL. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication 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 #4513: VACUUM FULL fails with "out of memory" error
Gregory Stark <[EMAIL PROTECTED]> writes: > "Alexey Bashtanov" <[EMAIL PROTECTED]> writes: >> TopTransactionContext: 2986336304 total in 367 blocks; 192312 free (1088 >> chunks); 2986143992 used > It does look like you have a memory leak in VACUUM FULL. No, I think he's trying to fix a table that hasn't been vacuumed in ages (154GB for only half a million not-wide rows!?), and VACUUM FULL is running out of space to remember all the pages it needs to clean up. CLUSTER or a rewriting ALTER TABLE would likely be a better way to clean up the mess. (Given that this is 8.3, it might be worth inquiring into how come autovacuum failed to keep the bloat under control.) 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] plperl & sort
> "Alex" == Alex Hunsaker <[EMAIL PROTECTED]> writes: >> Hmm ... so then why are we seeing a failure? [...] Alex> This is not a Safe bug IMHO its our (ab)use of it that is Alex> causing the problem. Then explain why the problem goes away when you build perl with threading turned off. -- Andrew. -- 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] plperl & sort
> "Tom" == Tom Lane <[EMAIL PROTECTED]> writes: >> Nice theory, but completely wrong: sort creates $a and $b in the >> current package, not in main::. Tom> Hmm ... so then why are we seeing a failure? FWIW, I _don't_ see the failure. It seems to occur ONLY if perl was built with threading support (ithreads). Without ithreads, I can't reproduce it (I've tried enabling and disabling multiplicity with no effect, so it's not that). Ithreads seem to be the default on many linux package builds of perl. It is _not_ the default on FreeBSD. -- Andrew. -- 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] plperl & sort
On Wed, Nov 5, 2008 at 18:03, Andrew Gierth <[EMAIL PROTECTED]> wrote: >> "Alex" == Alex Hunsaker <[EMAIL PROTECTED]> writes: > > >> Hmm ... so then why are we seeing a failure? > > [...] > Alex> This is not a Safe bug IMHO its our (ab)use of it that is > Alex> causing the problem. > > Then explain why the problem goes away when you build perl with > threading turned off. Hrm yep i built one without threads problem disappears... Guess Ive just been out to lunch :) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
