On Sat, Sep 28, 2019 at 11:41 AM Fabien COELHO wrote:
>
>
> Hello Amit,
>
> > I think we might also need to use pg_get_partkeydef along with
> > pg_partition_tree to fetch the partition method information. However,
> > I think to find reloid of pgbench_accounts in the current search path,
> > we
> 29 сент. 2019 г., в 21:27, Alexander Korotkov
> написал(а):
>
> Patch with fix is attached. Idea is simple: ginScanToDelete() now
> keeps exclusive lock on left page eliminating the need to relock it.
> So, we preserve left-to-right locking order and can't deadlock with
> ginStepRight().
On Fri, Sep 27, 2019 at 11:44:57AM +0900, Michael Paquier wrote:
> We need to do something similar to c3d41cc for the test, as per the
> attached. I have tested that with OpenSSL 1.0.1 and 1.0.2 to stress
> both scenarios.
>
> Any objections to this fix?
Committed as a12c75a1.
--
Michael
signa
Alvaro Herrera wrote:
> ... can we have a new patch?
OK, I've attached v4. It works cleanly on 55282fa20f with
str2int-16.patch applied. My patch won't compile without the other one
applied too.
Changed:
[x] revert my changes in common/Makefile
[x] rename arg_utils.[ch] to option.[ch]
[x] update
>
>
> > > However, I can also see that there is no better alternative. We need
> to
> > > compute the size of accumulated tuples so far, in order to decide
> whether
> > > to stop accumulating tuples. There is no convenient way to obtain the
> > > length of the tuple, given a slot. How about mak
On Sat, Sep 28, 2019 at 5:49 AM Andres Freund wrote:
> Hi,
>
> On 2019-09-09 18:31:54 +0800, Paul Guo wrote:
> > diff --git a/src/backend/access/heap/heapam.c
> b/src/backend/access/heap/heapam.c
> > index e9544822bf..8a844b3b5f 100644
> > --- a/src/backend/access/heap/heapam.c
> > +++ b/src/back
On Mon, Sep 30, 2019 at 10:10 AM Michael Paquier wrote:
>
> On Fri, Sep 27, 2019 at 10:00:16PM +0900, Masahiko Sawada wrote:
> > I abandoned once to move the removal code to between
> > writeTimeLineHistory() and timeline switching because of expanding the
> > window but since unlink itself will c
On Mon, Sep 30, 2019 at 12:49:03AM +0900, Fujii Masao wrote:
> Attached patch fixes this issue by making archive recovery always ignore
> recovery_min_apply_delay. This change is OK because
> recovery_min_apply_delay was introduced for standby mode, I think.
>
> This issue is not new in v12. I obs
On Sun, Sep 29, 2019 at 12:18 AM Justin Pryzby wrote:
> postgres=# CREATE TABLE t(i int)PARTITION BY RANGE(i);
> CREATE TABLE
> postgres=# CREATE TABLE t0 PARTITION OF t DEFAULT PARTITION BY RANGE(i);
> CREATE TABLE
> postgres=# CREATE TABLE t00 PARTITION OF t0 DEFAULT; -- oh yes
> CREATE TABLE
A
On Mon, Sep 30, 2019 at 6:59 AM Peter Eisentraut
wrote:
>
> On 2019-09-29 18:36, Fujii Masao wrote:
> > Yes, but ArchiveRecoveryRequested should be checked instead of
> > InArchiveRecovery, I think. Otherwise recovery targets would take effect
> > when recovery.signal is missing but backup_label e
On Sat, Sep 28, 2019 at 10:43:36AM -0300, Fabrízio de Royes Mello wrote:
> I poked a little with the patch and everything is ok. Your check for normal
> backend on test_session_hooks is much simpler than I did before:
>
> +/* just consider normal backends */
> +if (MyBackendId == InvalidBa
Hi,
The documentation for CREATE TYPE has this to say about alignment:
"The alignment parameter specifies the storage alignment required for the
data type. The allowed values equate to alignment on 1, 2, 4, or 8 byte
boundaries."
... while the documentation for pg_type has:
"c = char alignm
On Sat, Sep 28, 2019 at 10:22:28PM -0300, Alvaro Herrera wrote:
> I always thought that create index concurrently was prevented from
> running concurrently in a table by the ShareUpdateExclusive lock that's
> held during the operation.
REINDEX CONCURRENTLY and CIC can deadlock while waiting for ea
On Fri, Sep 27, 2019 at 10:00:16PM +0900, Masahiko Sawada wrote:
> I abandoned once to move the removal code to between
> writeTimeLineHistory() and timeline switching because of expanding the
> window but since unlink itself will complete within a very short time
> it would not be problamatic much
>From looking around the code, I've made these tentative observations
about TupleDescs:
1. If the TupleDesc was obtained straight from the relcache for some
relation, then all of its attributes should have nonzero attrelid
identifying that relation, but in (every? nearly every?) other case,
Hi,
On 2019-09-27 00:20:53 -0700, Andres Freund wrote:
> Unfortunately I found a performance regression for JITed query
> compilation introduced in 12, compared to 11. Fixed in one of the
> attached patches
> (v1-0009-Fix-determination-when-tuple-deforming-can-be-JIT.patch
> - which needs a bette
$ git grep Postger
src/backend/po/tr.po:"Bu durum, sistemin semaphore set (SEMMNI) veya semaphore
(SEMMNS) sayı sınırlaması aşmasında meydana gelmektedir. Belirtilen
parametrelerin değerleri yükseltmelisiniz. Başka seçeneğiniz ise PostgerSQL
sisteminin semaphore tütekitimini max_connections pa
On 2019-09-29 18:36, Fujii Masao wrote:
> Yes, but ArchiveRecoveryRequested should be checked instead of
> InArchiveRecovery, I think. Otherwise recovery targets would take effect
> when recovery.signal is missing but backup_label exists. In this case,
> InArchiveRecovery is set to true though Arch
On 2019-09-27 20:30, Justin Pryzby wrote:
> https://www.postgresql.org/docs/12/release-12.html
>
> |Allow modifications of system catalogs' options using ALTER TABLE (Peter
> Eisentraut)
> |Modifications of catalogs' reloptions and autovacuum settings are now
> supported.
>
> I wonder if that s
On 2019-09-27 17:14, David Steele wrote:
> On 9/27/19 10:36 AM, Peter Eisentraut wrote:
>> On 2019-09-26 23:02, David Steele wrote:
>>> On 9/26/19 4:48 PM, Peter Eisentraut wrote:
>>>
I don't know if recovery_target_timeline is actually useful to change in
standby mode.
>> OK, I have comm
The configure code currently has this:
# readline on MinGW has problems with backslashes in psql and other bugs.
# This is particularly a problem with non-US code pages.
# Therefore disable its use until we understand the cause. 2004-07-20
if test "$PORTNAME" = "win32"; then
if test "$with_re
I just tried building with Python on msys2. However, the setup of the
latest python doesn't fit our detection code. I see this:
# /c/Python37/python -c 'import distutils.sysconfig;
print(distutils.sysconfig.get_config_vars());'
{'LIBDEST': 'C:\\Python37\\Lib', 'BINLIBDEST': 'C:\\Python37\\Lib'
On Sun, Sep 29, 2019 at 7:38 AM Alexander Korotkov
wrote:
> Starting from root seems OK for me, because vacuum blocks all
> concurrent inserts before doing this. But this needs to be properly
> documented in readme.
I never got an adequate answer to this closely related question almost
two years
Re: Tom Lane 2019-09-28 <24917.1569692...@sss.pgh.pa.us>
> > (There's some extension modules
> > where the testsuite fails at a much higher rate, getting all targets
> > to pass at the same time is next to impossible there :(. )
>
> I feel your pain, believe me. Used to fight the same kind of pro
On Sun, Sep 29, 2019 at 02:30:44PM -0300, Alvaro Herrera wrote:
On 2019-Sep-29, Amit Kapila wrote:
On Sun, Sep 29, 2019 at 12:39 AM Tomas Vondra
wrote:
> So that's what I did in the attached patch - I've renamed the GUC to
> logical_decoding_work_mem, detached it from m_w_m and set the def
On 2019-Sep-29, Amit Kapila wrote:
> On Sun, Sep 29, 2019 at 12:39 AM Tomas Vondra
> wrote:
> > So that's what I did in the attached patch - I've renamed the GUC to
> > logical_decoding_work_mem, detached it from m_w_m and set the default to
> > 64MB (i.e. the same default as m_w_m).
>
> Fair
On Sun, Sep 29, 2019 at 6:08 AM Peter Eisentraut
wrote:
>
> On 2019-09-28 19:45, Tom Lane wrote:
> > Maybe I'm misunderstanding, but I think that rather than adding error
> > checks that were not there before, the right path to fixing this is
> > to cause these settings to be ignored if we're doin
On Sun, Sep 29, 2019 at 6:12 PM Alexander Korotkov
wrote:
> On Sun, Sep 29, 2019 at 5:38 PM Alexander Korotkov
> wrote:
> > On Sun, Sep 29, 2019 at 11:17 AM chenhj wrote:
> > > Does the locking order of autovacuum process(root->right->left) correct?
> > > While insert process lock gin buffer by
Hi,
I got the following assertion failure when I enabled recovery_min_apply_delay
and started archive recovery (i.e., I put only recovery.signal not
standby.signal).
TRAP: FailedAssertion("latch->owner_pid == MyProcPid", File:
"latch.c", Line: 522)
Here is the example to reproduce the issue:
--
On 2019-Sep-28, James Coleman wrote:
> I believe caveats like this are worth calling out rather than
> expecting users to have to understand the implementation details an
> work out the implications on their own.
I agree.
> I read Alvaro as referring to the fact that the docs already call out
>
On Sun, Sep 29, 2019 at 5:38 PM Alexander Korotkov
wrote:
> On Sun, Sep 29, 2019 at 11:17 AM chenhj wrote:
> > Does the locking order of autovacuum process(root->right->left) correct?
> > While insert process lock gin buffer by order of bottom->top and
> > left->right.
> >
> > 1. vacuum(root->r
Hi!
Thank you for reporting.
On Sun, Sep 29, 2019 at 11:17 AM chenhj wrote:
> Does the locking order of autovacuum process(root->right->left) correct?
> While insert process lock gin buffer by order of bottom->top and left->right.
>
> 1. vacuum(root->right->left):
Starting from root seems OK f
On Fri, Sep 27, 2019 at 6:58 PM Nikita Glukhov wrote:
> On Thu, Sep 26, 2019 at 2:57 AM Tom Lane
> wrote:
> > * More generally, it's completely unclear why some error conditions
> > are thrown as errors and others just result in returning *have_error.
> > In particular, it seems weird that some
Hi,all
In our PostgreSQL 10.7(rhel 6.3) database, autovacuum process and many insert
processes blocked in gin index's LWLock:buffer_content for long time.
In other words, the following gin index lwlock deadlock phenomenon has occurred
again. Since the following bug in 10.7 has been fixed. So
Hi, all
Our other system had encountered the same failure, but this time it is
PostgreSQL 10.7(rhel 6.3).
Details are as follows:
Phenomenon:
app_db=# select count(*) from loba_sp_cost_xcd_104561;
ERROR: could not access status of transaction 35153545
DETAIL: Could not open file "pg_xact
35 matches
Mail list logo
