Re: [HACKERS] Must be owner to truncate?

Bruce Momjian schrob: Stephen Frost wrote: -- Start of PGP signed section. * Jim C. Nasby ([EMAIL PROTECTED]) wrote: On Thu, Jul 07, 2005 at 01:48:59PM -0400, Tom Lane wrote: I don't really agree with the viewpoint that truncate is just a quick DELETE, and so I do not agree that DELETE

Re: [HACKERS] localization problem (and solution)

Tom Lane writes: I looked into this a bit more, and it seems the issue is that libperl will do setlocale(LC_ALL, ); the first time any locale-related Perl function is invoked. To defend ourselves against that, we'd have to set more environment variables than just LC_COLLATE and

Re: [HACKERS] psql readline win32

Magnus Hagander writes: 2) Should we ship a file of standard bindings. We're not going to get it complete, but we could get some of the most common ones in europe at least (in sweden, this would for example include [EMAIL PROTECTED]|). Which would help people a lot. Yes we should,

Re: [HACKERS] PG Extensions: Must be statically linked?

Mark Dilger writes: I have had the same concern, though never any hard evidence of a problem. If the C++ functions are wrapped with extern C, and all exceptions caught (perhaps converted into error numbers which are then returned from the wrapper functions to the plain-C calling functions),

Re: [HACKERS] PL/pgSQL 'i = i + 1' Syntax

Mark Dilger schrob: Tom Lane wrote: No it isn't. The plpgsql scanner treats := and = as *the same token*. They can be interchanged freely. This has nothing to do with the case of modifying a loop variable in particular. I disagree. If the scanner treated them the same, then if i := 1

[HACKERS] GIN stuck in loop during PITR

I'm just experimenting a bit with GIN, and it is occasionally getting stuck looping in findParents() during WAL replay. The attached patch seems to fix it. I also had to set ptr-off as advertised in the comment above the function to avoid triggering assertions. GIN isn't fully transparent to me

Re: [HACKERS] GIN stuck in loop during PITR

Andreas Seltenreich schrob: Teodor Sigaev schrob: Thanks a lot, applied. Can you describe test suite? It may be useful for test more... Here's a shell script that triggers the bug when I revert the patch. Just tried the script on HEAD, and it was triggering an assertion. I guess

Re: [HACKERS] backup + restore fails

Holger Schoenen writes: ERROR: invalid byte sequence for encoding UTF8: 0xe46973 Command was: -- [...] -- Started on 2006-09-15 14:56:51 Westeuropäische Normalzeit The same problem was recently reported on the pgsql-de-allgemein list. Would just avoiding %Z in Win32's strftime be an

Re: [HACKERS] Writing triggers in C++

Florian G. Pflug writes: Maybe we should create some wiki page or pgfoundry project that collects all glue code, tipps and tricks that people invented to glue C++ into the postgres backend. If it can be made to work, sure; in techdocs. I was thinking that two pairs of macros,

Re: [HACKERS] [PATCH] Add error handling to byteaout.

Alvaro Herrera writes: Why not just use an unsigned 64 bit variable? Also, perhaps palloc_huge() avoids the whole problem in the first place ... Ja, that crossed my mind too, but the current limit is already far beyond anything that is usually configured for per-backend memory use, so I

Re: [HACKERS] [PATCH] Add error handling to byteaout.

Piotr Stefaniak writes: s/int/Size/ doesn't fix anything on 32-bit machines. Postgres requires twos-complement representation, so that the assumption that signed integer types wrap around on overflow can be safely made. Thanks for the clarification! -- Sent via pgsql-hackers mailing list

[HACKERS] [PATCH] Add error handling to byteaout.

;$$ language sql; From f62a101a690fc9251c4c2de9c87323cedd0e9a54 Mon Sep 17 00:00:00 2001 From: Andreas Seltenreich andreas.seltenre...@credativ.de Date: Mon, 1 Jun 2015 16:17:21 +0200 Subject: [PATCH] Add error handling to byteaout. Emit a comprehensible error message when escaping fails due

Re: [HACKERS] [PATCH] Add error handling to byteaout.

Tom Lane t...@sss.pgh.pa.us writes: Andreas Seltenreich andreas.seltenre...@credativ.de writes: The scary one is due to an integer overflow the attached patch also fixes. s/int/Size/ doesn't fix anything on 32-bit machines. Well, it changes the signedness of the computation on 32-bit

[HACKERS] [sqlsmith] Failed assertion in joinrels.c

Hi, sqlsmith triggered the following assertion in master (c188204). TRAP: FailedAssertion(!(!bms_overlap(joinrelids, sjinfo-min_lefthand)), File: joinrels.c, Line: 500) As usual, the query is against the regression database. It is rather unwieldy… I wonder if I should stop working on new

[HACKERS] [sqlsmith] ERROR: failed to build any %d-way joins

Hi, there's a 1/1e6 chance that a sqlsmith query on the regression db of master (c124cef) fails with ERROR: failed to build any {4..8}-way joins They all appear to work fine on REL9_5_STABLE. sample query: select 1 from information_schema.collations as rel_60113935 inner join

Re: [HACKERS] [sqlsmith] ERROR: failed to build any %d-way joins

I wrote: They all appear to work fine on REL9_5_STABLE. oops, that branch was slightly stale. Updating it with the latest planner changes (8dccf03..0853388), the queries fail there as well. regards, Andreas -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] [sqlsmith] subplan variable reference / unassigned NestLoopParams

Tom Lane writes: Andreas Seltenreich seltenre...@gmx.de writes: Tom Lane writes: Well, I certainly think all of these represent bugs: 3 | ERROR: plan should not reference subplan's variable 2 | ERROR: failed to assign all NestLoopParams to plan nodes These appear to be related

Re: [HACKERS] [sqlsmith] Failed assertion in joinrels.c

Tom Lane writes: Well, I certainly think all of these represent bugs: [...] thanks for priorizing them. I'll try to digest them somewhat before posting. This one's pretty darn odd, because 2619 is pg_statistic and not an index at all: 4 | ERROR: cache lookup failed for index 2619

[HACKERS] [sqlsmith] subplan variable reference / unassigned NestLoopParams (was: [sqlsmith] Failed assertion in joinrels.c)

Tom Lane writes: Well, I certainly think all of these represent bugs: 3 | ERROR: plan should not reference subplan's variable 2 | ERROR: failed to assign all NestLoopParams to plan nodes These appear to be related. The following query produces the former, but if you replace the

Re: [HACKERS] [sqlsmith] Failed assertion in joinrels.c

Tom Lane writes: On 08/01/2015 05:59 PM, Tom Lane wrote: Well, I certainly think all of these represent bugs: 1 | ERROR: could not find pathkey item to sort Hmm ... I see no error with these queries as of today's HEAD or back-branch tips. I surmise that this was triggered by one of the

Re: [HACKERS] [sqlsmith] Failed assertion in joinrels.c

Peter Geoghegan writes: On Fri, Jul 31, 2015 at 5:56 PM, Andreas Seltenreich seltenre...@gmx.de wrote: sqlsmith triggered the following assertion in master (c188204). Thanks for writing sqlsmith. It seems like a great tool. I wonder, are you just running the tool with assertions enabled

Re: [HACKERS] [sqlsmith] Failed assertion in joinrels.c

Tom Lane writes: What concerns me more is that what you're finding is only cases that trip an assertion sanity check. It seems likely that you're also managing to trigger other bugs with less drastic consequences, such as could not devise a query plan failures or just plain wrong answers.

[HACKERS] [sqlsmith] ERROR: too late to create a new PlaceHolderInfo

Hi, on master at 36d9345, the attached queries raised too late to create a new PlaceHolderInfo. regards, Andreas select subq_218206.c0 as c0 from (select rel_1375794.sl_name as c0, coalesce(rel_1375793.f2, rel_1375793.f2) as c1 from public.subselect_tbl

[HACKERS] [sqlsmith] Failed assertion in analyzejoins.c

Hi, this one was in today's sqlsmith harvest. It triggers an assertion in current master (c030dc4). regards, Andreas -- TRAP: FailedAssertion(!(!bms_is_empty(phinfo-ph_eval_at)), File: analyzejoins.c, Line: 474) select rel_141618057.srvfdw as c0, rel_141618057.srvversion as c1 from

[HACKERS] Failing assertions in indxpath.c, placeholder.c and brin_minmax.c

Hi, when running my random query generator contraption[1] against the regression database of 9.5 or master, it occasionally triggers one of the following three assertions. Someone more knowledgeable might want to take a look at them... -- FailedAssertion(!(outer_rel-rows 0), File: indxpath.c,

Re: [HACKERS] Failing assertions in indxpath.c, placeholder.c and brin_minmax.c

Tom Lane writes: Andreas Seltenreich seltenre...@gmx.de writes: when running my random query generator contraption[1] against the regression database of 9.5 or master, it occasionally triggers one of the following three assertions. I've fixed the first two of these --- thanks for the report

Re: [HACKERS] 9.3.9 and pg_multixact corruption

Thomas Munro writes: > In various places we have int pageno = offset / (uint32) 1636, expanded > from this macro (which calls the offset an xid): It appears to depend on the context it is expanded in, as some of the code must have gotten the segment number right: ,[ ls -sh

[HACKERS] RemoveLocalLock pfree'ing NULL when out-of-memory

Hi, a memory-starved instance of sqlsmith just caught RemoveLocalLock pfree'ing a NULL in locallock->lockOwners. I think what happened is that it was called to clean up after LockAcquireExtended's MemoryContextAlloc failed. The content of errordata seems consistent with this. Caught in master

Re: [HACKERS] 9.3.9 and pg_multixact corruption

[ adding Bjorn Munch to Cc ] Jim Nasby writes: > On 9/20/15 9:23 AM, Christoph Berg wrote: >> a short update here: the customer updated the compiler to a newer >> version, is now compiling using -O2 instead of -O3, and the code >> generated now looks sane, so this turned out to be a compiler

Re: [HACKERS] 9.3.9 and pg_multixact corruption

Alvaro Herrera writes: > Jim Nasby wrote: >> Do we officially not support anything > -O2? If so it'd be nice if configure >> threw at least a warning (if not an error that you had to explicitly >> over-ride). > > Keep in mind this is Sun OS C -- not one of the most popular compilers > in the

Re: [HACKERS] [sqlsmith] Failed to generate plan on lateral subqueries

I wrote: > Tom Lane writes: >> Andreas Seltenreich <seltenre...@gmx.de> writes: >>> I've added new grammar rules to sqlsmith and improved some older ones. >>> This was rewarded with a return of "failed to generate plan" errors. >> >

[HACKERS] [sqlsmith] Failed to generate plan on lateral subqueries

Hi, I've added new grammar rules to sqlsmith and improved some older ones. This was rewarded with a return of "failed to generate plan" errors. The failing queries all contain a lateral subquery. The shortest of the failing queries are below. They were run against the regression db of master as

Re: [HACKERS] [sqlsmith] Failed to generate plan on lateral subqueries

Tom Lane writes: > Andreas Seltenreich <seltenre...@gmx.de> writes: >> I've added new grammar rules to sqlsmith and improved some older ones. >> This was rewarded with a return of "failed to generate plan" errors. > > I believe I've dealt with these cases now.

Re: [HACKERS] [sqlsmith] Failed to generate plan on lateral subqueries

Tom Lane writes: > [2. transitive-lateral-fixes-1.patch] I was about to write that sqlsmith likes the patch, but after more than 10^8 ok queries the attached ones were generated. regards, Andreas post-patch-errors.sql Description: application/sql -- Sent via pgsql-hackers mailing list

Re: [HACKERS] [sqlsmith] Failed to generate plan on lateral subqueries

Tom Lane writes: > [2. transitive-lateral-fixes-2.patch ] > [2. remove-lateraljoininfo-2.patch ] They seem to have fixed the issue for good now. No errors have been logged for 2e8 queries since applying the first patch. (The second one was applied later and didn't get as much exposure.) I

Re: [HACKERS] [sqlsmith] Failed to generate plan on lateral subqueries

Peter Geoghegan writes: > On Sun, Dec 6, 2015 at 9:52 AM, Andreas Seltenreich <seltenre...@gmx.de> > wrote: >> I've added new grammar rules to sqlsmith and improved some older ones. > > Could you possibly teach sqlsmith about INSERT ... ON CONFLICT DO > UPDATE/IGNO

Re: [HACKERS] [sqlsmith] Failed to generate plan on lateral subqueries

David Fetter writes: > On Mon, Dec 14, 2015 at 03:06:18PM +0900, Michael Paquier wrote: >> On Sun, Dec 13, 2015 at 10:14 AM, Andreas Seltenreich wrote: >> > https://github.com/anse1/sqlsmith >> >> I am in awe regarding this stuff, which has caught many bu

Re: [HACKERS] [sqlsmith] Failed to generate plan on lateral subqueries

Greg Stark writes: > There may be other errors that would be surprising for Tom or Robert. What > I did with the string argument fuzzer was printed counts for each sqlstate > for the errors and watched for errors that only occurred occasionally or > didn't make sense to me. > > Also, do you have

Re: [HACKERS] [sqlsmith] Failed to generate plan on lateral subqueries

Tom Lane writes: > Merlin Moncure writes: >> Aside from the functional issues, could your changes result in >> performance regressions? [...] > It's a little bit harder to gauge the impact on planner speed. The > transitive closure calculation could be expensive in a query

Re: [HACKERS] [sqlsmith] Failed to generate plan on lateral subqueries

Greg Stark writes: > On Sat, Dec 12, 2015 at 8:30 PM, Andreas Seltenreich <seltenre...@gmx.de> > wrote: > When you hit the timeout is this implemented in your fuzzer or using > statement_timeout? If the former, can you add a statement_timeout of > just short of the timeout i

Re: [HACKERS] pg_upgrade in 9.5 broken for adminpack

Bruce Momjian writes: > On Thu, Apr 16, 2015 at 11:29:07PM -0700, Jeff Janes wrote: >> Of course after sending that it became obvious.  The C function is not >> getting >> called because the SQL function is marked as being strict, yet is called with >> NULL arguments. >> >> Trivial patch

Re: [HACKERS] [sqlsmith] Failing assertions in spgtextproc.c

Tom Lane writes: > Andreas Seltenreich <seltenre...@gmx.de> writes: >> TRAP: FailedAssertion([...], File: "spgtextproc.c", Line: 424) >> TRAP: FailedAssertion([...], File: "spgtextproc.c", Line: 564) > > Can you show us the definition of th

[HACKERS] [PATCH] Add STRICT to some regression test C functions.

this patch in? Thanks, Andreas >From 2711471d48c2e58809c2f4617d36352c5903bbd9 Mon Sep 17 00:00:00 2001 From: Andreas Seltenreich <seltenre...@gmx.de> Date: Sun, 3 Jan 2016 19:05:06 +0100 Subject: [PATCH] Add STRICT to some regression test C functions. These functions readily crash when passing N

[HACKERS] [sqlsmith] Failing assertions in spgtextproc.c

I do see two assertions in spgtextproc.c fail on occasion when testing with sqlsmith: TRAP: FailedAssertion([...], File: "spgtextproc.c", Line: 424) TRAP: FailedAssertion([...], File: "spgtextproc.c", Line: 564) I can't reproduce it reliably but looking at the coredumps, the failing part of the

Re: [HACKERS] [sqlsmith] Failing assertions in spgtextproc.c

Peter Geoghegan writes: > Can you do this?: > > (gdb) p debug_query_string output below. Since sqlsmith ist no longer restricted to read-only statements, the chances for reproduction are low :-/. select pg_catalog.pg_stat_get_buf_written_backend() as c0, subq_1.c0 as c1, subq_1.c0 as c2,

[HACKERS] [sqlsmith] Failed assertion in postgres_fdw/deparse.c:1116

Creating some foreign tables via postgres_fdw in the regression db of master as of de33af8, sqlsmith triggers the following assertion: TRAP: FailedAssertion("!(const Node*)(var))->type) == T_Var))", File: "deparse.c", Line: 1116) gdb says var is holding a T_PlaceHolderVar instead. In a

Re: [HACKERS] [COMMITTERS] pgsql: Don't generate parallel paths for rels with parallel-restricted

Amit Kapila writes: > I have moved it to CLOSE_WAIT state because we have derived our > queries to reproduce the problem based on original report[1]. If next > run of sqlsmith doesn't show any problem in this context then we will > move it to resolved. I don't have access to my testing horse

Re: [HACKERS] [sqlsmith] PANIC: failed to add BRIN tuple

Alvaro Herrera writes: > How long does it take for you to reproduce this panic in the unpatched > code? Very long, I'm afraid. I only observed it once, and according to the logging database, about 4e9 random queries were generated since testing with 9.5 code. I could probably speed it up by

Re: [HACKERS] ORDER/GROUP BY expression not found in targetlist

Tom Lane writes: > Andreas Seltenreich <seltenre...@gmx.de> writes: >> Peter Geoghegan writes: >>> It's surprising that SQL Smith didn't catch something with such simple >>> steps to reproduce. > >> I removed distinct relatively early because it cau

Re: [HACKERS] [sqlsmith] PANIC: failed to add BRIN tuple

I wrote: > Alvaro Herrera writes: >> How long does it take for you to reproduce this panic in the unpatched >> code? > > I could probably speed it up by creating lots of additional BRIN indexes > in the regression database, and by compiling a sqlsmith that generates > update statements only. This

[HACKERS] Should pg_export_snapshot() and currtid() be tagged parallel-unsafe?

Digging through the sqlsmith logging db, I noticed the following errors: ERROR: cannot update SecondarySnapshot during a parallel operation ERROR: cannot assign XIDs during a parallel operation Queries raising the first one always contain calls to currtid() or currtid2(). Queries

Re: [HACKERS] [COMMITTERS] pgsql: Don't generate parallel paths for rels with parallel-restricted

Amit Kapila writes: > Right, so I have moved "Failed assertion in parallel worker > (ExecInitSubPlan)" item to CLOSE_WAIT state as I don't think there is any > known pending issue in that item. I have moved it to CLOSE_WAIT state > because we have derived our queries to reproduce the problem

Re: [HACKERS] ORDER/GROUP BY expression not found in targetlist

Peter Geoghegan writes: > On Wed, May 25, 2016 at 7:12 PM, Andres Freund wrote: >> >> =# CREATE TABLE twocol(col01 int, col02 int); >> =# SELECT DISTINCT col01, col02, col01 FROM twocol ; >> ERROR: XX000: ORDER/GROUP BY expression not found in targetlist >> LOCATION:

Re: [HACKERS] [sqlsmith] PANIC: failed to add BRIN tuple

Alvaro Herrera writes: > If you can re-run sqlsmith and see if you can find different bugs, I'd > appreciate it. [...] > [2. text/x-diff; brincrash-2.patch] BRIN is inconspicuous since applying this patch. All coredumps I see now are either due to the parallel worker shutdown issue or acl.c's

[HACKERS] [sqlsmith] OOM crash in plpgsql_extra_checks_check_hook

Just had a parallel worker of a memory-starved instance of sqlsmith crash. plpgsql_extra_checks_check_hook forgot to check the result of its malloc call here: Core was generated by `postgres: bgworker: parallel worker for PID 5905 '. Program terminated with signal SIGSEGV,

[HACKERS] [PATCH] Improve spinlock inline assembly for x86.

Sep 17 00:00:00 2001 From: Andreas Seltenreich <seltenre...@gmx.de> Date: Sun, 17 Jan 2016 11:51:53 +0100 Subject: [PATCH] Improve spinlock inline assembly for x86. Remove the LOCK prefix from the XCHG instruction. Locking is implicit with XCHG and the prefix wastes a byte. Also remove the

[HACKERS] [sqlsmith] Failed assertion in BecomeLockGroupLeader

Hi, tonight's sqlsmith run yielded another core dump: TRAP: FailedAssertion("!(MyProc->lockGroupLeader == ((void *)0))", File: "proc.c", Line: 1787) I couldn't identifiy a query for it though: debug_query_string is empty. Additionally, the offending query was not reported in the error context

Re: [HACKERS] [sqlsmith] Failed assertion in BecomeLockGroupLeader

Alvaro Herrera writes: > Amit Kapila wrote: >> It will be helpful if you can find the offending query or plan >> corresponding to it? > > So I suppose the PID of the process starting the workers should be in > the stack somewhere. Ja, it's right on the top, but long gone by now… > With that one

Re: [HACKERS] [sqlsmith] Failed assertion in BecomeLockGroupLeader

Simon Riggs writes: > It's good that the input is fuzzed, but there needs to be a way to re-run > identical fuzzing or a way to backtrack to find what broke. Not much point > finding bugs we can't identify later. sqlsmith is deterministic and allows re-generating a sequence of random queries

Re: [HACKERS] [sqlsmith] Failed assertion in BecomeLockGroupLeader

Amit Kapila writes: > On Fri, Apr 29, 2016 at 7:15 PM, Tom Lane wrote: >> but it might be worth copying over the full query from the parent >> side. > > That would amount to couple of extra cycles considering we need to do it > for each worker, but OTOH it might be a useful

Re: [HACKERS] [sqlsmith] Failed assertion in BecomeLockGroupLeader

Amit Kapila writes: > On Sat, Apr 30, 2016 at 5:58 AM, Andreas Seltenreich <seltenre...@gmx.de> > wrote: >> This sounds like it should work to capture more context when the >> Assertion fails the next time. > > Sounds good. So can we assume that you will try to get

[HACKERS] [sqlsmith] Crash in apply_projection_to_path

Hi, the following query against the regression database crashes master as of 23b09e15. select 1 from depth0 inner join depth1 on (depth0.c = depth1.c) where depth0.c @@ depth1.c limit 1; regards, Andreas Program terminated with signal SIGSEGV, Segmentation fault. #0

Re: [HACKERS] [sqlsmith] Failed assertions on parallel worker shutdown

I wrote: > There's another class of parallel worker core dumps when testing master > with sqlsmith. In these cases, the following assertion fails for all > workers simulataneously: > > TRAP: FailedAssertion("!(mqh->mqh_partial_bytes <= nbytes)", File: > "shm_mq.c", Line: 386) I no longer

Re: [HACKERS] [sqlsmith] Failed assertion in parallel worker (ExecInitSubPlan)

Amit Kapila writes: > avoid_restricted_clause_below_gather_v1.patch > prohibit_parallel_clause_below_rel_v1.patch I didn't observe any parallel worker related coredumps since applying these. The same amount of testing done before applying them yielded about a dozend. Dilip Kumar writes: > So

Re: [HACKERS] [sqlsmith] Failed assertions on parallel worker shutdown

I wrote: >> There's another class of parallel worker core dumps when testing master >> with sqlsmith. In these cases, the following assertion fails for all >> workers simulataneously: >> >> TRAP: FailedAssertion("!(mqh->mqh_partial_bytes <= nbytes)", File: >> "shm_mq.c", Line: 386) > > I no

Re: [HACKERS] [sqlsmith] Failed assertions on parallel worker shutdown

Amit Kapila writes: > Earlier problems were due to the reason that some unsafe/restricted > expressions were pushed below Gather node as part of target list whereas in > the plan6, it seems some unsafe node is pushed below Gather node. It will > be helpful if you can share the offending query?

Re: [HACKERS] [sqlsmith] Failed assertions on parallel worker shutdown

Amit Kapila writes: > On Mon, May 23, 2016 at 4:48 PM, Andreas Seltenreich <seltenre...@gmx.de> > wrote: >> plan6 corresponds to this query: >> > Are you sure that the core dumps you are seeing are due to plan6? Each of the plans sent was harvested from a control

[HACKERS] [sqlsmith] Failed assertions on parallel worker shutdown

There's another class of parallel worker core dumps when testing master with sqlsmith. In these cases, the following assertion fails for all workers simulataneously: TRAP: FailedAssertion("!(mqh->mqh_partial_bytes <= nbytes)", File: "shm_mq.c", Line: 386) The backtraces of the controlling

[HACKERS] [sqlsmith] PANIC: failed to add BRIN tuple

There was one instance of this PANIC when testing with the regression db of master at 50e5315. , | WARNING: specified item offset is too large | PANIC: failed to add BRIN tuple | server closed the connection unexpectedly ` It is reproducible with the query below on this instance only.

[HACKERS] Just-in-time compiling things (was: asynchronous and vectorized execution)

Konstantin Knizhnik writes: > Latest information from ISP RAS guys: them have made good progress > since February: them have rewritten most of methods of Scan, Aggregate > and Join to LLVM API. Is their work available somewhere? I'm experimenting in that area as well, although I'm using libFirm

Re: [HACKERS] [sqlsmith] Failed assertion in BecomeLockGroupLeader

> Amit Kapila writes: >> Sounds good. So can we assume that you will try to get us the new report >> with more information? I don't see these crashes anymore in c1543a8. By the amount of fuzzing done it should have happened a dozen times, so it's highly likely something in 23b09e15..c1543a8

[HACKERS] [sqlsmith] Failed assertion in parallel worker (ExecInitSubPlan)

Hi, when fuzz testing master as of c1543a8, parallel workers trigger the following assertion in ExecInitSubPlan every couple hours. TRAP: FailedAssertion("!(list != ((List *) ((void *)0)))", File: "list.c", Line: 390) Sample backtraces of a worker and leader below, plan of leader attached.

Re: [HACKERS] [sqlsmith] Failed assertion in BecomeLockGroupLeader

Alvaro Herrera writes: > Robert Haas wrote: >> On Thu, May 5, 2016 at 4:11 PM, Andreas Seltenreich <seltenre...@gmx.de> >> wrote: >> > I don't see these crashes anymore in c1543a8. By the amount of fuzzing >> > done it should have happened a dozen time

Re: [HACKERS] [sqlsmith] PANIC: failed to add BRIN tuple

I wrote: > Re-fuzzing now with your patch applied. This so far yielded three BRIN core dumps on different machines with the same backtraces. Crash recovery fails in these cases. I've put the data directory here (before recovery): http://ansel.ydns.eu/~andreas/brincrash2-spidew.tar.xz

Re: [HACKERS] GiST index build versus NaN coordinates

Tom Lane writes: > More generally, this example makes me fearful that NaN coordinates in > geometric values are likely to cause all sorts of issues. It's too late > to disallow them, probably, but I wonder how can we identify other bugs > of this ilk. Sounds like some fuzz testing with

Re: [HACKERS] Issue in pg_catalog.pg_indexes view definition

Tom Lane writes: > Dilip Kumar writes: >> So I think changing the view definition and calling this function on >> indexrelid will remove the error. So I think >> correct fix is to change view definition, as I proposed in above patch. [...] > We've dealt with similar issues

Re: [HACKERS] Improving executor performance

Andres Freund writes: > Having expression evaluation and slot deforming as a series of simple > sequential steps, instead of complex recursive calls, would also make it > fairly straightforward to optionally just-in-time compile those. I don't think that JIT becomes easier by this change.

Re: [HACKERS] Improving executor performance

Andres Freund writes: > The problem is that the previous form has a lot of ad-hoc analysis > strewn in. The interesting part is getting rid of all that. That's what > the new ExecInitExpr2() does. The target form can be both evaluated more > efficiently in the dispatch manner in the patch, and

Re: [HACKERS] Improving executor performance

Andres Freund writes: > On 2016-07-14 23:03:10 +0200, Andreas Seltenreich wrote: >> That's the plan, yes. I'm sorry there's no publishable code yet on the >> the postgres side of things. Using libFirm[1], the plan is to. > > Why libfirm? - It has a more modern IR than LLVM

[HACKERS] [sqlsmith] FailedAssertion("!(k == indices_count)", File: "tsvector_op.c", Line: 511)

Hi, the following statement triggers an assertion in tsearch: select ts_delete(array_to_tsvector('{smith,smith,smith}'::text[]), '{smith,smith}'::text[]); -- TRAP: FailedAssertion("!(k == indices_count)", File: "tsvector_op.c", Line: 511) regards, Andreas -- Sent via pgsql-hackers mailing

[HACKERS] [sqlsmith] FailedAssertion("!(XLogCtl->Insert.exclusiveBackup)", File: "xlog.c", Line: 10200)

Hi, testing with sqlsmith shows that the following assertion doesn't hold: FailedAssertion("!(XLogCtl->Insert.exclusiveBackup)", File: "xlog.c", Line: 10200) The triggering statements always contain a call to pg_start_backup with the third argument 'true', i.e. it's trying to start an

Re: [HACKERS] GiST index build versus NaN coordinates

I wrote: > Sounds like some fuzz testing with nan/infinity is in order. related fallout: close_ps returns a NULL pointer with NaNs around: select close_ps('(nan,nan)', '(nan,nan),(nan,nan)'); -- TRAP: FailedAssertion("!(result != ((void *)0))", File: "geo_ops.c", Line: 2860) regards, Andreas

[HACKERS] [sqlsmith] Crash in GetOldestSnapshot()

Hi, since updating master from c93d873..fc509cd, I see crashes in GetOldestSnapshot() on update/delete returning statements. I reduced the triggering statements down to this: update clstr_tst set d = d returning d; Backtrace below. regards, Andreas Program received signal SIGSEGV,

Re: [HACKERS] [sqlsmith] FailedAssertion("!(XLogCtl->Insert.exclusiveBackup)", File: "xlog.c", Line: 10200)

Michael Paquier writes: > Andreas, with the patch attached is the assertion still triggered? > [2. text/x-diff; base-backup-crash-v2.patch] I didn't observe the crashes since applying this patch. There should have been about five by the amount of fuzzing done. regards Andreas -- Sent via

[HACKERS] [sqlsmith] Crash in pg_get_viewdef_name_ext()

Hi, sqlsmith just triggered a crash in pg_get_viewdef_name_ext(). Looks like commit 976b24fb4 failed to update this caller of pg_get_viewdef_worker(). Backtrace below. Patch attached. regards, Andreas Program terminated with signal SIGSEGV, Segmentation fault. (gdb) bt #0 strlen () at

[HACKERS] [sqlsmith] crashes in RestoreSnapshot on hot standby

Running sqlsmith on a streaming slave (master as of f8c5855) is inconspicuous as long as the master is idle. As soon as I start it on the master as well, the standby frequently crashes in RestoreSnapshot. It doesn't seem to be specific to the queries, as they don't trigger a crash when re-run.

Re: [HACKERS] [sqlsmith] crashes in RestoreSnapshot on hot standby

Amit Kapila writes: > On Fri, Jul 1, 2016 at 9:38 AM, Thomas Munro > wrote: >> Or maybe just like this? >> >> - snapshot->subxip = snapshot->xip + serialized_snapshot->xcnt; >> + snapshot->subxip = ((TransactionId *) (snapshot + 1)) + >>

[HACKERS] [sqlsmith] ERROR: plan should not reference subplan's variable

Updating master from f8c5855..1bdae16, sqlsmith triggers "failed to generate plan" errors again. Below is the smallest query logged so far. regards, Andreas -- ERROR: plan should not reference subplan's variable set force_parallel_mode = 'on'; set max_parallel_workers_per_gather = '1';

Re: [HACKERS] Improving RLS planning

Tom Lane writes: > Thanks for reviewing --- I'll do something with that test case and > push it. sqlsmith doesn't seem to like 215b43cdc: select 1 from information_schema.usage_privileges where information_schema._pg_keysequal( (select null::smallint[]), '{16,25,23}'); -- TRAP:

[HACKERS] [sqlsmith] Failed assertion in numeric aggregate

Hi, updating master from be7f7ee..39b691f, the following assertion is triggered frequently by sqlsmith: TRAP: BadArgument("!(((context) != ((void *)0) && (const Node*)((context)))->type) == T_AllocSetContext", File: "mcxt.c", Line: 1010) Digging in the coredumps, it looks like

[HACKERS] [sqlsmith] Missing CHECK_FOR_INTERRUPTS in tsquery_rewrite

tch adds a CHECK_FOR_INTERRUPTS to make it cancellable. regards, Andreas >From d9910a96c9bd73c16e29ecaa0577945d5e1c091c Mon Sep 17 00:00:00 2001 From: Andreas Seltenreich <seltenre...@gmx.de> Date: Sun, 30 Oct 2016 03:25:55 +0100 Subject: [PATCH] Add CHECK_FOR_INTERRUPTS in tsquery_rewrite loop. T

[HACKERS] [sqlsmith] Failed assertion in TS_phrase_execute

Hi, the query below triggers an assertion in TS_phrase_execute. Testing was done on master at dbdfd11. regards, Andreas -- TRAP: FailedAssertion("!(curitem->qoperator.oper == 4)", File: "tsvector_op.c", Line: 1432) select 'moscow' @@ ts_rewrite('moscow', 'moscow',

Re: [HACKERS] [sqlsmith] Parallel worker crash on seqscan

Hi, Ashutosh Sharma writes: >> the following query appears to reliably crash parallel workers on master >> as of 0832f2d. > As suggested, I have tried to reproduce this issue on *0832f2d* commit but > could not reproduce it. as Tom pointed out earlier, I had secretly set parallel_setup_cost

Re: [HACKERS] [sqlsmith] Failed assertion in parallel worker in ExecInitSubPlan

Hi, just caught another InitPlan below Gather with the recent patches in (master as of 4cc6a3f). Recipe below. regards, andreas set max_parallel_workers_per_gather = 2; set min_parallel_relation_size = 0; set parallel_setup_cost = 0; set parallel_tuple_cost = 0; explain select 1 from

[HACKERS] [sqlsmith] Crash on GUC serialization

Hi, sqlsmith just made a GUC that tricks the serialization code into dereferencing a nullpointer. Here's a recipe: --8<---cut here---start->8--- set min_parallel_relation_size to 0; set max_parallel_workers_per_gather to 2; set force_parallel_mode to on;

Re: [HACKERS] [sqlsmith] Crash on GUC serialization

Michael Paquier writes: > [2. text/plain; fix-guc-string-eval.patch] I'm afraid taking care of the length computation is not sufficient. ISTM like it'll still try to serialize the NULL pointer later on in serialize_variable: ,[ guc.c:9108 ] | case PGC_STRING: | { | struct

[HACKERS] [sqlsmith] Parallel worker crash on seqscan

Hi, the following query appears to reliably crash parallel workers on master as of 0832f2d. --8<---cut here---start->8--- set max_parallel_workers_per_gather to 2; set force_parallel_mode to 1; select subq.context from pg_settings, lateral (select context

[HACKERS] [sqlsmith] Failed assertion in parallel worker in ExecInitSubPlan

Hi, the query below triggers a parallel worker assertion for me when run on the regression database of master as of 0832f2d. The plan sports a couple of InitPlan nodes below Gather. regards, Andreas Gather (cost=1.64..84.29 rows=128 width=4) Workers Planned: 1 Single Copy: true ->

[HACKERS] [sqlsmith] Infinite recursion in bitshift

00:00:00 2001 From: Andreas Seltenreich <seltenre...@gmx.de> Date: Fri, 14 Oct 2016 20:52:52 +0200 Subject: [PATCH] Fix possible infinite recursion on bitshift. bitshiftright() and bitshiftleft() would recursively call each other infinitely when the user passed a MIN_INT for the s

Re: [HACKERS] [sqlsmith] Infinite recursion in bitshift

Tom Lane writes: >> This is due to an integer overflow in bitshiftright()/bitshiftleft() >> leading to them recursively calling each other. Patch attached. > > Seems sane, though I wonder if it'd be better to use -INT_MAX rather > than -VARBITMAXLEN. I am undecided between those two. -INT_MAX

  1   2   >