Re: [HACKERS] Race conditions with WAL sender PID lookups

On Sun, Jun 25, 2017 at 2:11 PM, Alvaro Herrera wrote: > Noah Misch wrote: > >> IMMEDIATE ATTENTION REQUIRED. This PostgreSQL 10 open item is long past due >> for your status update. Please reacquaint yourself with the policy on open >> item ownership[1] and then reply immediately. If I do not

Re: [HACKERS] Pluggable storage

On 23/06/2017 16:07, Tomas Vondra wrote: > > I think you're probably right - GIN does compress the posting lists by > exploiting the TID redundancy (that it's page/offset structure), and I > don't think there are other index AMs doing that. > > But I'm not sure we can simply rely on that - it's p

Re: [HACKERS] Get stuck when dropping a subscription during synchronizing table

(was away for a while, got some time now for this again) On 22/06/17 04:43, Peter Eisentraut wrote: > The alternative is that we use the LockSharedObject() approach that was > already alluded to, like in the attached patch. Both approaches would > work equally fine AFAICT. I agree, but I think w

Re: [HACKERS] CREATE SUBSCRIPTION log noise

On 21/06/17 23:32, Euler Taveira wrote: > 2017-06-21 15:14 GMT-03:00 Peter Eisentraut > >: > > > It doesn't appear to be contingent on anything other than the content of > > the command you just gave it. I don't think we need a NOTICE saying >

Re: [HACKERS] Logical replication: stuck spinlock at ReplicationSlotRelease

On 24/06/17 04:50, Tom Lane wrote: > Peter Eisentraut writes: >> Do you want to take a look at move those elog calls around a bit? That >> should do it. > > It would be a good idea to have some clarity on *why* that should do it. > > Looking at the original report's log, but without having actu

Re: [HACKERS] Walsender timeouts and large transactions

On 30/05/17 15:44, Petr Jelinek wrote: > On 30/05/17 11:02, Kyotaro HORIGUCHI wrote: >> >> +TimestampTz now = GetCurrentTimestamp(); >> >> I think it is not recommended to read the current time too >> frequently, especially within a loop that hates slowness. (I >> suppose that a loop that c

[HACKERS] CREATE COLLATION definitional questions for ICU

Reading over DefineCollation, I wondered: * Should not the FROM code path copy the old collation's version? It seems a little bit weird that "cloning" a collation takes the liberty of installing a new version. * Also (and this would be a pre-existing bug), why doesn't the FROM path copy the old c

Re: [HACKERS] Is exec_simple_check_node still doing anything?

I wrote: > Robert Haas writes: >> I'm a little mystified by exec_simple_check_node(). >> ... >> Did that, possibly, remove the last way in which a simple expression >> could be could become non-simple? If so, between that and the new >> hasTargetSRFs test, it might now be impossible for >> exec_s

Re: [HACKERS] pgbench tap tests & minor fixes

В письме от 15 июня 2017 21:10:12 Вы написали: > > As for me, I would do expr_scanner_chomp_substring(PsqlScanState, int, > > int&); that changes end_offset as desired... > > Why not. > > > And use it instead of end_offset = expr_scanner_offset(sstate) - 1; > > I removed these? > > > The second

Re: [HACKERS] pgbench tap tests & minor fixes

В письме от 25 июня 2017 19:03:54 пользователь Fabien COELHO написал: > Hello Nikolay, > > >> Is the attached version better to your test? > > > > I've expected from expr_scanner_chomp_substring to decrement end_offset, > > so it would work more like perl chomp function, but the way you've done >

Re: [HACKERS] pgbench tap tests & minor fixes

may be this it because of "end_offset + 1" in expr_scanner_chomp_substring ? Why there is + 1 there? Thanks for the debug! Here is a v9 which does a rebase after the reindentation and fixes the bad offset. -- Fabien.diff --git a/src/bin/pgbench/exprscan.l b/src/bin/pgbench/exprscan.l index

[HACKERS] Timing-sensitive case in src/test/recovery TAP tests

I've been experimenting with a change to pg_ctl, which I'll post separately, to reduce its reaction time so that it reports success more quickly after a wait for postmaster start/stop. I found one case in "make check-world" that got a failure when I reduced the reaction time to ~1ms. That's the v

[HACKERS] Reducing pg_ctl's reaction time

I still have a bee in my bonnet about how slow the recovery TAP tests are, and especially about how low the CPU usage is while they run, suggesting that a lot of the wall clock time is being expended on useless sleeps. Some analysis I did today found some low-hanging fruit there: a significant par

Re: [HACKERS] GSoC 2017: Foreign Key Arrays

*What I did:* - read into the old patch but couldn't apply it since it's quite old. It needs to be rebased and that's what I am working on. It's a lot of work. - incomplete patch can be found attached here *Bugs* - problem with the @>(anyarray, anyelement) opertator: if for exa

Re: [HACKERS] AdvanceXLInsertBuffer vs. WAL segment compressibility

I notice CopyXLogRecordToWAL contains this loop (in the case where the record being copied is a switch): while (CurrPos < EndPos) { /* initialize the next page (if not initialized already) */ WALInsertLockUpdateInsertingAt(CurrPos); AdvanceXLInsertBuffer(CurrPos, false); CurrPos +=

Re: [HACKERS] Timing-sensitive case in src/test/recovery TAP tests

On 26 June 2017 at 05:10, Tom Lane wrote: > I've been experimenting with a change to pg_ctl, which I'll post > separately, to reduce its reaction time so that it reports success > more quickly after a wait for postmaster start/stop. I found one > case in "make check-world" that got a failure when

Re: [HACKERS] Setting pd_lower in GIN metapage

On Fri, Jun 23, 2017 at 11:17 AM, Amit Langote wrote: > That was it, thanks for the pointer. GinInitMetabuffer() sets up pd_lower and pd_upper anyway using PageInit so the check of PageIsVerified is guaranteed to work in any case. Upgraded pages will still have their pd_lower set to the previous

[HACKERS] Corner-case error in pgstats file loading

Using the patch I posted a little while ago to reduce pg_ctl's reaction time, I noticed that there were semi-reproducible ten-second delays in postmaster shutdown, in some cases in the recovery tests where we quickly stop and restart and again stop the postmaster. The cause turned out to be that t

Re: [HACKERS] Timing-sensitive case in src/test/recovery TAP tests

On Mon, Jun 26, 2017 at 10:48 AM, Craig Ringer wrote: > $node_standby_1->poll_query_until('postgres', q[SELECT xmin IS NULL > from pg_replication_slots WHERE slot_name = '] . $slotname_2 . q[']); +1 for avoiding a sleep call if it is not necessary. Fast platforms would always pay a cost on that,

Re: [HACKERS] Timing-sensitive case in src/test/recovery TAP tests

Michael Paquier writes: > On Mon, Jun 26, 2017 at 10:48 AM, Craig Ringer wrote: >> $node_standby_1->poll_query_until('postgres', q[SELECT xmin IS NULL >> from pg_replication_slots WHERE slot_name = '] . $slotname_2 . q[']); > +1 for avoiding a sleep call if it is not necessary. Fast platforms >

Re: [HACKERS] Timing-sensitive case in src/test/recovery TAP tests

On 26 June 2017 at 10:09, Tom Lane wrote: > Michael Paquier writes: >> On Mon, Jun 26, 2017 at 10:48 AM, Craig Ringer wrote: >>> $node_standby_1->poll_query_until('postgres', q[SELECT xmin IS NULL >>> from pg_replication_slots WHERE slot_name = '] . $slotname_2 . q[']); > >> +1 for avoiding a sl

Re: [HACKERS] Timing-sensitive case in src/test/recovery TAP tests

On Mon, Jun 26, 2017 at 11:44 AM, Craig Ringer wrote: > On 26 June 2017 at 10:09, Tom Lane wrote: >> Michael Paquier writes: >>> On Mon, Jun 26, 2017 at 10:48 AM, Craig Ringer >>> wrote: $node_standby_1->poll_query_until('postgres', q[SELECT xmin IS NULL from pg_replication_slots WHE

Re: [HACKERS] UPDATE of partition key

On 22 June 2017 at 01:41, Robert Haas wrote: >>> Second, it will amount to a functional bug if you get a >>> different answer than the planner did. >> >> Actually, the per-leaf WCOs are meant to be executed on the >> destination partitions where the tuple is moved, while the WCOs >> belonging to t

Re: [HACKERS] Timing-sensitive case in src/test/recovery TAP tests

On 26 June 2017 at 11:06, Michael Paquier wrote: > As long as we are on it, there is this code block in the test: > my ($xmin, $catalog_xmin) = get_slot_xmins($node_master, $slotname_1); > is($xmin, '', 'non-cascaded slot xmin null with no hs_feedback'); > is($catalog_xmin, '', 'non-casca

Re: [HACKERS] Get stuck when dropping a subscription during synchronizing table

On Sun, Jun 25, 2017 at 7:35 PM, Petr Jelinek wrote: > (was away for a while, got some time now for this again) > > On 22/06/17 04:43, Peter Eisentraut wrote: >> The alternative is that we use the LockSharedObject() approach that was >> already alluded to, like in the attached patch. Both approac

Re: [HACKERS] Setting pd_lower in GIN metapage

On Sat, Jun 24, 2017 at 1:35 AM, Alvaro Herrera wrote: > Masahiko Sawada wrote: >> On Fri, Jun 23, 2017 at 3:31 PM, Michael Paquier >> wrote: >> > On Fri, Jun 23, 2017 at 3:17 PM, Amit Langote >> > wrote: >> >> Initially, I had naively set wal_consistency_check = all before running >> >> make in

Re: [HACKERS] Setting pd_lower in GIN metapage

On Mon, Jun 26, 2017 at 10:54 AM, Michael Paquier wrote: > On Fri, Jun 23, 2017 at 11:17 AM, Amit Langote > wrote: >> That was it, thanks for the pointer. > > GinInitMetabuffer() sets up pd_lower and pd_upper anyway using > PageInit so the check of PageIsVerified is guaranteed to work in any > ca

Re: [HACKERS] Same expression more than once in partition key

On 2017/06/24 5:04, Tom Lane wrote: > Peter Eisentraut writes: >> We also allow the same column more than once in an index. We probably >> don't have to be more strict here. > > There actually are valid uses for the same column more than once in > an index, eg if you use a different operator cla

Re: [HACKERS] gen_random_uuid security not explicit in documentation

On Fri, Jun 23, 2017 at 10:23:36AM +0900, Michael Paquier wrote: > On Fri, Jun 23, 2017 at 3:02 AM, Heikki Linnakangas wrote: > > I'm inclined to change gen_random_uuid() to throw an error if the server is > > built with --disable-strong-random, like gen_random_bytes() does. That way, > > they wou

Re: [HACKERS] Code quality issues in ICU patch

On Sat, Jun 24, 2017 at 10:03:25AM -0400, Peter Eisentraut wrote: > On 6/23/17 12:31, Tom Lane wrote: > > icu_to_uchar() and icu_from_uchar(), and perhaps other places, are > > touchingly naive about integer overflow hazards in buffer size > > calculations. I call particular attention to this bit

Re: [HACKERS] Timing-sensitive case in src/test/recovery TAP tests

On Mon, Jun 26, 2017 at 12:12 PM, Craig Ringer wrote: > On 26 June 2017 at 11:06, Michael Paquier wrote: > >> As long as we are on it, there is this code block in the test: >> my ($xmin, $catalog_xmin) = get_slot_xmins($node_master, $slotname_1); >> is($xmin, '', 'non-cascaded slot xmin n

Re: [HACKERS] Reducing pg_ctl's reaction time

On Mon, Jun 26, 2017 at 7:13 AM, Tom Lane wrote: > The attached proposed patch adjusts pg_ctl to check every 100msec, > instead of every second, for the postmaster to be done starting or > stopping. This cuts the runtime of the recovery TAP tests from around > 4m30s to around 3m10s on my machine,

Re: [HACKERS] Setting pd_lower in GIN metapage

On 2017/06/26 10:54, Michael Paquier wrote: > On Fri, Jun 23, 2017 at 11:17 AM, Amit Langote > wrote: >> That was it, thanks for the pointer. > > GinInitMetabuffer() sets up pd_lower and pd_upper anyway using > PageInit so the check of PageIsVerified is guaranteed to work in any > case. Upgraded

[HACKERS] pg_filedump doesn't compile with v10 sources

Hi, While trying to do - make of pg_filedump against v10 sources , getting an errors [centos@centos-cpula pg_filedump]$ make cc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -DLINUX_OOM_ADJ=0 -Wall -Wmissing-prototype