Re: [HACKERS] can we add SKIP LOCKED to UPDATE?

HI, My case is concurrency update one row(for exp 1000 client update the same row at the same time), and target is prevent waiting for waiters(quick return to client). use advisory lock is a method, for quick return. but not good , must use function(to reduce consume between client-db network).

Re: [HACKERS] [COMMITTERS] pgsql: Translation updates

Peter Eisentraut wrote: > Translation updates > > Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git > Source-Git-Hash: cd263526676705b4a8a3a708c9842461c4a2bcc3 Hi Peter, Would you please document this process? I know it all starts with this repository,

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

Hi, On 11/09/2015 05:10 PM, Andres Freund wrote: Each graph has a full initdb + pgbench -i cycle now. That looks about as we'd expect: the lock-free pinning doesn't matter and ssynchronous commit is beneficial. I think our bottlenecks in write workloads are sufficiently elsewhere that it's

Re: [HACKERS] [Proposal] Table partition + join pushdown

Hi, I put my comments towards the patch as follows. Overall comments * I think the enhancement in copyfuncs.c shall be in the separate patch; it is more graceful manner. At this moment, here is less than 20 Path delivered type definition. It is much easier works than entire

Re: [HACKERS] Per-table log_autovacuum_min_duration is actually documented

Michael Paquier writes: > While going through the release notes of 9.5 I noticed the following > chunk in doc/src/sgml/release-9.5.sgml: > Add per-table autovacuum logging control via > log_min_autovacuum_duration (Michael Paquier) > NOT DOCUMENTED? Yeah ... I was

Re: [HACKERS] Documentation tweak for row-valued expressions and null

On 7/26/15 8:40 PM, Thomas Munro wrote: I wonder if it might be worth adding a tiny note to the manual to point out that the special logic for " IS [ NOT ] NULL" doesn't apply anywhere else that we handle nulls or talk about [non]-null values in the manual. See attached. Yes. This is a common

Re: [HACKERS] Uh-oh: documentation PDF output no longer builds in HEAD

On Tue, Nov 10, 2015 at 1:46 AM, Tom Lane wrote: > I wrote: > > Curiously though, that gets us down to this: > > 30615 strings out of 245828 > > 397721 string characters out of 1810780 > > which implies that indeed FlowObjectSetup *is* the cause of most of > > the strings

Re: [HACKERS] bootstrap pg_shseclabel in relcache initialization

> In commit 5d1ff6bd559ea8df I'd expected that the > WARNINGs would certainly show up in regression test output, and I thought > I'd verified that that was the case --- did that not happen for you? I just doubled checked with both 'check' and 'check-world' and neither seemed to have an issue with

Re: [HACKERS] Uh-oh: documentation PDF output no longer builds in HEAD

On Tue, Nov 10, 2015 at 6:15 PM, Tom Lane wrote: > Magnus Hagander writes: > > When you say it's half the size - is that half the size of the > preprocessed > > PDF or is it also after the stuff we do on the website PDFs using > > jpdftweak? IIRC that

Re: [HACKERS] bootstrap pg_shseclabel in relcache initialization

On Tue, Nov 10, 2015 at 9:18 AM, Adam Brightwell wrote: >> I'm with Alvaro: the most interesting question here is why that mistake >> did not blow up on you immediately. I thought we had enough safeguards >> in place to catch this type of error. > > Ok, I'll

Re: [HACKERS] Uh-oh: documentation PDF output no longer builds in HEAD

Magnus Hagander wrote: > On Tue, Nov 10, 2015 at 6:15 PM, Tom Lane wrote: > > > Magnus Hagander writes: > > > When you say it's half the size - is that half the size of the > > preprocessed > > > PDF or is it also after the stuff we do on the website

Re: [HACKERS] bootstrap pg_shseclabel in relcache initialization

Adam Brightwell writes: > On Tue, Nov 10, 2015 at 9:18 AM, Adam Brightwell > wrote: >>> I'm with Alvaro: the most interesting question here is why that mistake >>> did not blow up on you immediately. I thought we had enough

Re: [HACKERS] Uh-oh: documentation PDF output no longer builds in HEAD

Magnus Hagander writes: > When you say it's half the size - is that half the size of the preprocessed > PDF or is it also after the stuff we do on the website PDFs using > jpdftweak? IIRC that tweak is only there to deal with the size, and > specifically it deals with

Re: [HACKERS] storage/buffer/README docs about buffer replacement are out of date

Andres Freund wrote: > Now a) and b) are recent oversights of mine. I'd apparently not realized > that there's detailed docs on this in buffer/README. But c) is pretty > old - essentially 5d50873 from 2005. > > I wonder if it's worthwhile to go into that level of detail - seems > kinda likely to

Re: [HACKERS] Uh-oh: documentation PDF output no longer builds in HEAD

Magnus Hagander writes: > On Tue, Nov 10, 2015 at 6:15 PM, Tom Lane wrote: >> I don't know anything about jpdftweak, but if it's being used to get rid >> of unreferenced hyperlink anchors, maybe we could dispense with that step >> after this goes in. >

Re: [HACKERS] INSERT ... ON CONFLICT documentation clean-up patch

As discussed on IM, I think we should make the insert.sgml documentation even close to select.sgml than before, in that parameters ought to be discussed in different sections, and not in one large block. insert.sgml is too complicated for that approach now. Attached revision (rebase) of your

Re: [HACKERS] bootstrap pg_shseclabel in relcache initialization

Adam Brightwell writes: >> In commit 5d1ff6bd559ea8df I'd expected that the >> WARNINGs would certainly show up in regression test output, and I thought >> I'd verified that that was the case --- did that not happen for you? > I just doubled checked with both

Re: [HACKERS] bootstrap pg_shseclabel in relcache initialization

> -Original Message- > From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Joe Conway > Sent: Tuesday, November 10, 2015 3:08 AM > To: Craig Ringer; Adam Brightwell > Cc: PostgreSQL Hackers > Subject: Re: [HACKERS] bootstrap pg_shseclabel

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

On 2015/10/29 23:22, Syed, Rahila wrote: > Please find attached an updated patch. A few more comments on v6: > relname = RelationGetRelationName(onerel); > + schemaname = get_namespace_name(RelationGetNamespace(onerel)); > ereport(elevel, >

Re: [HACKERS] [PROPOSAL] Improvements of Hunspell dictionaries support

08.11.2015 14:23, Artur Zakirov пишет: Thank you for reply. This was because of the flag field size of the SPELL struct. And long flags were being trancated in the .dict file. I attached new patch. It is temporary patch, not final. It can be done better. I have updated the patch and

Re: [HACKERS] Uh-oh: documentation PDF output no longer builds in HEAD

On Mon, Nov 9, 2015 at 7:46 PM, Tom Lane wrote: > I wrote: >> Curiously though, that gets us down to this: >> 30615 strings out of 245828 >> 397721 string characters out of 1810780 >> which implies that indeed FlowObjectSetup *is* the cause of most of >> the strings being

Re: [HACKERS] Per-table log_autovacuum_min_duration is actually documented

On Wed, Nov 11, 2015 at 12:07 AM, Tom Lane wrote: > Michael Paquier writes: >> This is actually documented in src/sgml/ref/create_table.sgml with the >> following paragraph so this mention in the release notes does not seem >> needed: >>

[HACKERS] Error in char(n) example in documentation

I think that this example in the docs [1] is wrong: """ Values of type character are physically padded with spaces to the specified width n, and are stored and displayed that way. However, trailing spaces are treated as semantically insignificant and disregarded when comparing two values of type

Re: [HACKERS] checkpointer continuous flushing

On 2015-09-10 17:15:26 +0200, Fabien COELHO wrote: > Here is a v13, which is just a rebase after 1aba62ec. And here's v14. It's not something entirely ready. A lot of details have changed, I unfortunately don't remember them all. But there are more important things than the details of the patch.

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On Tue, Nov 10, 2015 at 11:17 PM, Michael Paquier wrote: > On Sun, Nov 1, 2015 at 9:34 PM, Dean Rasheed wrote: >> On 27 October 2015 at 08:24, Dean Rasheed wrote: >>> I think it's still feasible to have sind(30) =

Re: [HACKERS] Dangling Client Backend Process

On Wed, Nov 4, 2015 at 2:18 AM, Robert Haas wrote: > > The second conclusion does not appear to be correct. parseInput() > will call pqParseInput3() or pqParseInput2(), either of which will > handle an error as if it were a notice - i.e. by printing it out. Right per pqGetErrorNotice3 when the

[HACKERS] Per-table log_autovacuum_min_duration is actually documented

Hi all, While going through the release notes of 9.5 I noticed the following chunk in doc/src/sgml/release-9.5.sgml: Add per-table autovacuum logging control via log_min_autovacuum_duration (Michael Paquier) NOT DOCUMENTED? This is actually documented in src/sgml/ref/create_table.sgml with the

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On Sun, Nov 1, 2015 at 9:34 PM, Dean Rasheed wrote: > On 27 October 2015 at 08:24, Dean Rasheed wrote: >> I think it's still feasible to have sind(30) = 0.5 exactly and keep >> monotonicity >> > > Here's a patch along those lines. It turned

Re: [HACKERS] bootstrap pg_shseclabel in relcache initialization

> I'm with Alvaro: the most interesting question here is why that mistake > did not blow up on you immediately. I thought we had enough safeguards > in place to catch this type of error. Ok, I'll explore that a bit further as I was able to build and use with my hook without any issue. :-/ -Adam

Re: [HACKERS] bootstrap pg_shseclabel in relcache initialization

>> +1 for adding to the next commitfest. >> > Me also. Done. -Adam -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Proposal: "Causal reads" mode for load balancing reads without stale data

Hi hackers, Many sites use hot standby servers to spread read-heavy workloads over more hardware, or at least would like to. This works well today if your application can tolerate some time lag on standbys. The problem is that there is no guarantee of when a particular commit will become

[HACKERS] Re: Multixact slru doesn't don't force WAL flushes in SlruPhysicalWritePage()

On Mon, Nov 09, 2015 at 10:40:07PM +0100, Andres Freund wrote: > /* >* Optional array of WAL flush LSNs associated with entries in the SLRU >* pages. If not zero/NULL, we must flush WAL before writing pages > (true >* for pg_clog, false for multixact, pg_subtrans,

Re: [HACKERS] Error in char(n) example in documentation

Peter Geoghegan writes: > I think that this example in the docs [1] is wrong: Yeah, you're quite right. Pushed. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: