hat remaining index out of the indcheckxmin=true list
by...
1. Reindexing $index (did not change anything)
2. begin; drop; create; commit (still in the list but with a much newer
xmin.)
3. Vac-Full the table again (and now the index is gone from the
indcheckxmin=true list.)
Please advise.
Thx
--
Jerry S
Thomas Munro writes:
> On Wed, Jul 17, 2019 at 12:26 PM Jerry Sievers wrote:
>
>> Is this the right sequencing?
>>
>> 1. Start client and get backend pid
>> 2. GDB; handle SIGUSR1, break, cont
>> 3. Run query
>> 4. bt
>
> Perfect, thanks. I t
Thomas Munro writes:
> On Wed, Jul 17, 2019 at 12:05 PM Jerry Sievers wrote:
>
>> Program received signal SIGUSR1, User defined signal 1.
>
> Oh, we need to ignore those pesky signals with "handle SIGUSR1 noprint
> nostop".
Is this the right sequencing?
1. Sta
Thomas Munro writes:
> On Wed, Jul 17, 2019 at 11:33 AM Jerry Sievers wrote:
>
>> -> Nested Loop Left Join (cost=251621.81..12300177.37 rows=48
>> width=44)
>>-> Gather (cost=1001.55..270403.27 rows=48 width=40)
>
>>
Thomas Munro writes:
> On Wed, Jul 17, 2019 at 11:06 AM Jerry Sievers wrote:
>
>> (gdb) p *scan->rs_parallel
>> Cannot access memory at address 0x7fa673a54108
>
> So I guess one question is: was it a valid address that's been
> unexpectedly unmapped, or is the
Thomas Munro writes:
> On Wed, Jul 17, 2019 at 11:06 AM Jerry Sievers wrote:
>
>> (gdb) p *scan->rs_parallel
>> Cannot access memory at address 0x7fa673a54108
>
> So I guess one question is: was it a valid address that's been
> unexpectedly unmapped, or is the
Tomas Vondra writes:
> On Mon, Jul 15, 2019 at 08:20:00PM -0500, Jerry Sievers wrote:
>
>>Tomas Vondra writes:
>>
>>> On Mon, Jul 15, 2019 at 07:22:55PM -0500, Jerry Sievers wrote:
>>>
>>>>Tomas Vondra writes:
>>>>
>>
Tomas Vondra writes:
> On Mon, Jul 15, 2019 at 07:22:55PM -0500, Jerry Sievers wrote:
>
>>Tomas Vondra writes:
>>
>>> On Mon, Jul 15, 2019 at 06:48:05PM -0500, Jerry Sievers wrote:
>>>
>>>>Greetings Hackers.
>>>>
>>>>
Tomas Vondra writes:
> On Mon, Jul 15, 2019 at 06:48:05PM -0500, Jerry Sievers wrote:
>
>>Greetings Hackers.
>>
>>We have a reproduceable case of $subject that issues a backtrace such as
>>seen below.
>>
>>The query that I'd prefer to sanitize be
executor/execAmi.c:226
--
Jerry Sievers
Postgres DBA/Development Consulting
e: postgres.consult...@comcast.net
n_size() functions are going to block in
cases where existing objects are (for example) in transactionss such
as...
begin;
truncate foo;
big-nasty-reporting-jobs...;
Thus a bare-metal tallying of pg_class.relpages for heap/index/toast,
along with missing the FSM/VM size could be $preferred.
And/or at least mentioning this caveat in the related manual section :-)
FWIW
>
>
> Thanks for the review.
--
Jerry Sievers
Postgres DBA/Development Consulting
e: postgres.consult...@comcast.net
rade and vacuumdb are bound the same
> way, so it's not a given that the same -j number should be used.
>
> Perhaps more documentation would be useful here.
--
Jerry Sievers
Postgres DBA/Development Consulting
e: postgres.consult...@comcast.net
of a
> case where it's problematic, even without stopping the server.
>
>
>
> Just to let you know. I applied the work around in the affected
> server and seemed to work way, so far no error.
>
> Thank you a lot for all the information and help.
>
> Best
.
> I don't understand why both queries were stuck, the logic thing is
> that one ran and the other one is waiting (if locks aquired etc) it
> doesnt make senece that both queries are on waiting. waiting for what
> exactly?
>
>
> Any thoughts on this issue?
>
>
--
Jerry Sievers
Postgres DBA/Development Consulting
e: postgres.consult...@comcast.net
p: 312.241.7800
files. Patch attached. Thought?
>
> Regards,
--
Jerry Sievers
Postgres DBA/Development Consulting
e: postgres.consult...@comcast.net
p: 312.241.7800
hen any busy process is straced.
And, the test systems were config'd with $large shared buffers of 64G.
Please advise
>
> To alleviate this situation, I'd like to propose to change the recovery
> so that it also calls smgrdounlinkall() only one time to delete multiple
> rel
> people would probably shrug it off (which I initially did) rather
> than report it as a bug. I was looking into it as an enhancement
> rather than a bug until I discovered that it was already enhanced and
Agree such an edge case not a high priority to support for the above
reasons but good to assuming no breakage in some other regard :-)
> then undone.
>
> Cheers,
>
> Jeff
>
>
>
>
--
Jerry Sievers
Postgres DBA/Development Consulting
e: postgres.consult...@comcast.net
p: 312.241.7800
17 matches
Mail list logo
