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);

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] 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

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

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

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: >> >>

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

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'); >

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

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:

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

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

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

[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

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

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"

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] 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

[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

[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

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

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

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] 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

[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

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

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

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

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

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

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