Re: [GENERAL] Possible bug: could not open relation with OID [numbers] SQL State: XX000

I wrote: > You could have encountered it anytime since TOAST was invented, or at > least since RETURN QUERY was invented (the latter is newer IIRC). > The fact that the bug has been there so long and has only been reported > a couple of times is the main reason why I'm loath to take a brute >

Re: [GENERAL] Possible bug: could not open relation with OID [numbers] SQL State: XX000

> If that's the correct theory, yes. Did you match up the OID yet? Yes, I did just now. The OID matches the TOAST table for the temp table: contract_actual_direct. This just really surprises me I haven't seen it before considering I know for a fact that some of my other functions are way more

Re: [GENERAL] Possible bug: could not open relation with OID [numbers] SQL State: XX000

Adam Brusselback writes: > Huh, so in the other cases where the function works fine, it's likely that > the data all just fits within the regular table and doesn't have to be > TOAST'ed? If that's the correct theory, yes. Did you match up the OID yet? > So this is

Re: [GENERAL] Possible bug: could not open relation with OID [numbers] SQL State: XX000

Huh, so in the other cases where the function works fine, it's likely that the data all just fits within the regular table and doesn't have to be TOAST'ed? So this is something that isn't changed in PG10, and I could have encountered in 9.6, and just by chance didn't? This is a pattern I've used

Re: [GENERAL] Possible bug: could not open relation with OID [numbers] SQL State: XX000

Adam Brusselback writes: > The OID does not match any of the temp tables, so not sure what's up there. > I have the function RETURN QUERY, > and then I drop all my temp tables. I'll bet the OID corresponds to the toast table for one of those temp tables. RETURN QUERY

Re: [GENERAL] Possible bug: could not open relation with OID [numbers] SQL State: XX000

Alright I figured it out. The OID does not match any of the temp tables, so not sure what's up there. I have the function RETURN QUERY, and then I drop all my temp tables. If I don't drop the tmp_base table at the end of the function, it will work just fine. If I keep the drop at the end in

Re: [GENERAL] Possible bug: could not open relation with OID [numbers] SQL State: XX000

I believe it's one of the temp tables. The oid changes each time the function is run. I'll put some logging in place to identify the exact temp table it is though.

Re: [GENERAL] Possible bug: could not open relation with OID [numbers] SQL State: XX000

On Wed, Nov 01, 2017 at 04:11:07PM -0400, Adam Brusselback wrote: > I have something going on, and i'm not sure what is causing it. I > recently upgraded our development environment to PG10, and the error > in the subject appeared with one of my analytical functions. What relation is that ? I

[GENERAL] Possible bug: could not open relation with OID [numbers] SQL State: XX000

Hey all, First off: PostgreSQL 10.0 on x86_64-pc-linux-gnu, compiled by gcc (Debian 6.3.0-18) 6.3.0 20170516, 64-bit I have something going on, and i'm not sure what is causing it. I recently upgraded our development environment to PG10, and the error in the subject appeared with one of my

Re: [GENERAL] explain analyze output: 0 rows, 1M loopa

On Wed, Nov 1, 2017 at 1:19 PM, David G. Johnston wrote: > On Wed, Nov 1, 2017 at 11:59 AM, Scott Marlowe > wrote: >> >> So some of my output from an explain analyze here has a line that says >> this: >> >> ex Scan using

Re: [GENERAL] explain analyze output: 0 rows, 1M loops

On Wed, Nov 1, 2017 at 12:25 PM, Justin Pryzby wrote: > On Wed, Nov 01, 2017 at 12:19:21PM -0700, David G. Johnston wrote: > > On Wed, Nov 1, 2017 at 11:59 AM, Scott Marlowe > > wrote: > > > > > So some of my output from an explain analyze here has

Re: [GENERAL] explain analyze output: 0 rows, 1M loops

On Wed, Nov 01, 2017 at 12:19:21PM -0700, David G. Johnston wrote: > On Wed, Nov 1, 2017 at 11:59 AM, Scott Marlowe > wrote: > > > So some of my output from an explain analyze here has a line that says > > this: > > > > ex Scan using

Re: [GENERAL] explain analyze output: 0 rows, 1M loopa

On Wed, Nov 1, 2017 at 11:59 AM, Scott Marlowe wrote: > So some of my output from an explain analyze here has a line that says > this: > > ex Scan using warranty_order_item_warranty_order_id_idx on > warranty_order_item woi_1 (cost=0.57..277.53 rows=6 width=137) (actual

[GENERAL] explain analyze output: 0 rows, 1M loopa

So some of my output from an explain analyze here has a line that says this: ex Scan using warranty_order_item_warranty_order_id_idx on warranty_order_item woi_1 (cost=0.57..277.53 rows=6 width=137) (actual time=0.110..0.111 rows=0 loops=1,010,844) How can you have 1M loops over 0 rows? Running

Re: [GENERAL] Monitoring of a hot standby with a largely idle master

On 7/27/17 16:14, Jeff Janes wrote: > On Wed, Jul 26, 2017 at 1:44 AM, Michael Paquier > > wrote: > > On Mon, Jul 24, 2017 at 9:08 PM, Jeff Janes > wrote: > > On Sun, Jul

Re: [GENERAL] the database system is shutting down - terminating walsender process due to replication timeout

Zarko Aleksic writes: > I'm looking for a bit of help understanding a particular behavior we are > seeing with our PostgreSQL 9.6. After issuing a service shutdown command with > "systemctl stop" on RHEL 7 our PostgreSQL instance started behaving weirdly. > For the

[GENERAL] the database system is shutting down - terminating walsender process due to replication timeout

Greetings everyone, I'm looking for a bit of help understanding a particular behavior we are seeing with our PostgreSQL 9.6. After issuing a service shutdown command with "systemctl stop" on RHEL 7 our PostgreSQL instance started behaving weirdly. For the first time it wouldn't shutdown so

[GENERAL] the database system is shutting down - terminating walsender process due to replication timeout

Greetings everyone, I'm looking for a bit of help understanding a particular behavior we are seeing with our PostgreSQL 9.6. After issuing a service shutdown command with "systemctl stop" on RHEL 7 our PostgreSQL instance started behaving weirdly. For the first time it wouldn't shutdown so

Re: [GENERAL] Query plan for Merge Semi Join

Peter J. Holzer wrote: > [PostgreSQL 9.5.9 on x86_64-pc-linux-gnu, compiled by gcc (Debian > 4.9.2-10) 4.9.2, 64-bit] > > While investigating a performance issue, I found this query plan: > > wds=> explain analyze > select facttablename, columnname, term, concept_id, t.hidden, language, >

[GENERAL] Query plan for Merge Semi Join

[PostgreSQL 9.5.9 on x86_64-pc-linux-gnu, compiled by gcc (Debian 4.9.2-10) 4.9.2, 64-bit] While investigating a performance issue, I found this query plan: wds=> explain analyze select facttablename, columnname, term, concept_id, t.hidden, language, register, c.id, canonicalname,

Re: [GENERAL] PG 10 - Trouble with overlap of range partition of two dimensions

On Nov 1, 2017 02:41, "Stephen Froehlich" wrote: Hi Michael, So if I'm reading this correctly, the proper way to do my use case is to use partitions of partitions, right? Or maybe reverse the order of the columns: PARTITION BY RANGE (source_no, start_time)