Peter Geoghegan wrote:
> On Thu, Feb 18, 2016 at 4:53 PM, Tom Lane wrote:
> >> there are usage patterns where half-dead pages might accumulate.
> >
> > Other than a usage pattern of "randomly SIGKILL backends every few
> > seconds", I don't see how that would happen.
>
> I meant where pages coul
Craig Ringer wrote:
> > +=pod
> > +
> > +=head2 Set up a node
> > pod format... Do we really want that? Considering that those modules
> > are only aimed at being dedicated for in-core testing, I would say no.
>
> If it's plain comments you have to scan through massive piles of verbose
> Perl to
Pavel Stehule wrote:
> The design of the "format" function is not closed. Try to send prototype
> and patch. The possibility to do PostgreSQL customization was strong reason
> why we didn't implemented "sprintf" and we implemented "format".
Probably not terribly useful here, but for the DDL-depar
Jim Nasby wrote:
> On 2/22/16 11:47 AM, Alvaro Herrera wrote:
> >Pavel Stehule wrote:
> >
> >>The design of the "format" function is not closed. Try to send prototype
> >>and patch. The possibility to do PostgreSQL customization was strong reason
>
Jim Nasby wrote:
> On 2/5/16 10:08 AM, David Fetter wrote:
> >On Wed, Feb 03, 2016 at 06:02:57PM -0600, Jim Nasby wrote:
> >>I just discovered that ./configure will happily accept '--with-pgport=' (I
> >>was actually doing =$PGPORT, and didn't realize $PGPORT was empty). What you
> >>end up with is
Bruce Momjian wrote:
> On Wed, Feb 24, 2016 at 01:08:29AM +, Simon Riggs wrote:
> > It's never been our policy to try to include major projects in single code
> > drops. Any move of XL/XC code into PostgreSQL core would need to be done
> > piece
> > by piece across many releases. XL is defini
Joe Conway wrote:
> In my experience it is almost always best to run autovacuum very often
> and very aggressively. That generally means tuning scaling factor and
> thresholds as well, such that there are never more than say 50-100k dead
> rows. Then running vacuum with no delays or limits runs qu
Jim Nasby wrote:
> >Here we have another case. prodesc is a global thing. And it is shared
> >between different operations. Problem was that there is no partcular
> >owner, and we have to wait when last operation which deals with it
> >would finish. It looks like perfect job for reference counting
Thanks, pushed.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsq
Victor Wagner wrote:
> I'll second Stas' suggestion about psql_ok/psql_fail functions.
>
> 1. psql_ok instead of just psql would provide visual feedback for the
> reader of code. One would see 'here condition is tested, here is
> something ended with _ok/_fail'.
>
> It would be nice that seeing
Michael Paquier wrote:
> Attached are rebased patches, split into 3 parts doing the following:
> - 0001, fix default configuration of MSVC builds ignoring TAP tests
BTW you keep submitting this one and I keep ignoring it. I think you
should start a separate thread for this one, so that some
Win
Konstantin Knizhnik wrote:
> Yes, it is certainly possible to develop cluster by cloning PostgreSQL.
> But it cause big problems both for developers, which have to permanently
> synchronize their branch with master,
> and, what is more important, for customers, which can not use standard
> version
Kyotaro HORIGUCHI wrote:
> So, I'd like to propose four (or five) changes to this harness.
>
> - prove_check to remove all in tmp_check
>
> - TestLib to preserve temporary directories/files if the current
>test fails.
>
> - PostgresNode::get_new_node to create data directory with
>me
Craig Ringer wrote:
> Should be committed ASAP IMO.
Finally pushed it. Let's see how it does in the buildfarm. Now let's
get going and add more tests, I know there's no shortage of people with
test scripts waiting for this.
Thanks, Michael, for the persistency, and thanks to all reviewers. (I
Alvaro Herrera wrote:
> Add a test framework for recovery
>
> This long-awaited framework is an expansion of the existing PostgresNode
> stuff to support additional features for recovery testing; the recovery
> tests included in this commit are a starting point that cover some of
Marko Tiikkaja wrote:
> Running one specific test from our application against REL9_5_STABLE
> (current as of today) gives me this:
>
> #2 0x7effb59595be in ExceptionalCondition (
> conditionName=conditionName@entry=0x7effb5b27a88 "!(CritSectionCount > 0
> || TransactionIdIsCurrentTransa
Robert Haas wrote:
> Eh ... I doubt very much that it's safe to blow away the entire
> contents of an SLRU between shutdown and startup, even if the data is
> technically transient data that won't be needed again after the system
> is reset.
Hmm. At least async.c (pg_notify) deletes the whole di
Anastasia Lubennikova wrote:
> 13.08.2016 02:15, Alvaro Herrera:
> >To support this, we introduce StorageTuple and StorageScanDesc.
> >StorageTuples represent a physical tuple coming from some storage AM.
> >It is necessary to have a pointer to a StorageAmRoutine in order
Peter Geoghegan wrote:
> This doesn't seem that interesting, but not sure what you're looking for.
>
> I also attach cycles flamegraph.
I may be blind, but what are those write() calls attributed to
heap_form_tuple?
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Develo
Aleksander Alekseev wrote:
> $ cat ~/.psqlrc
> select (case when pg_is_in_recovery() then 'r' else 'm' end) as mor
> \gset
>
> \set PROMPT1 '%p (%:mor:) =# '
Okay, this seems moderately reasonable, but ...
> Besides I figured out that replica promotion case could also be properly
> handled wit
Aleksander Alekseev wrote:
> Peter has a good point that in general case it's more complicated than
> just master or replica. I also agree with David that what actually
> would be nice to have is a some syntax that allows user to execute
> arbitrary commands before displaying a prompt. This way us
Andres Freund wrote:
> This commit also adds a isolationtester spec test, exercising the
> relevant code path. Unfortunately 9.5 cannot handle two waiting
> sessions, and thus cannot execute this test.
This test seems to fail randomly, depending on which session is awakened
first. Annoying ...
Stefan Kaltenbrunner wrote:
> On 08/18/2016 09:30 PM, Christian Convey wrote:
> > Yury: Would it make sense to add a call to "cmake_minimum_required" in
> > one or more of your CMakeLists.txt files?
>
> it would make sense nevertheless but I dont think that 2.8.11 is old
> enough - looking at the
Christian Convey wrote:
> * Allow the CMake-based build system to assume a fairly modern version
> of CMake. (Maybe 2.8.12, or 3.0.)
>
> * For systems where the minimum CMake version isn't readily available,
> have an alternative build system which is just a simplistic Bash
> script that naively
Christian Convey wrote:
> I see. In other projects I've worked on, the configuration of a build
> farm has been driven by some list of platforms that were considered
> important to support.
Build farm members are systems that somebody has seen as interesting
enough that they deserve enough effor
Claudio Freire wrote:
> Unique indexes still need to scan all duplicates to check visibility
> and will become O(N^2) there.
That scenario doesn't matter, because on unique indexes there aren't
many duplicate values anyway -- only one can be a live tuple.
--
Álvaro Herrerahttp:/
While researching a customer issue with BDR I noticed that one ereport()
call happens after clobbering errno, leading to the wrong strerror being
reported. This patch fixes it by saving before calling
CloseTransientFile and restoring afterwards.
I also threw in a missing errcode I noticed while l
Andres Freund wrote:
> On 2016-08-18 19:06:02 -0300, Alvaro Herrera wrote:
> > While researching a customer issue with BDR I noticed that one ereport()
> > call happens after clobbering errno, leading to the wrong strerror being
> > reported. This patch fixes it by
Andres Freund wrote:
> Not at all, thanks.
Done, thanks both for the look-over.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make cha
Peter Eisentraut wrote:
> I'm not happy that utils/acl.h has prototypes for aclchk.c, because
> acl.h is included all over the place. Perhaps I should make a
> src/include/catalog/aclchk.c to clean that up.
I've been bothered by that too in the past. +1 for the cleanup.
--
Álvaro Herrera
Robert Haas wrote:
> On Sat, Aug 20, 2016 at 4:58 PM, Tom Lane wrote:
> > Jeff Janes writes:
> >> On Thu, Aug 18, 2016 at 2:25 PM, Tom Lane wrote:
> >>> It does know it, what it doesn't know is how many duplicates there are.
> >
> >> Does it know whether the count comes from a parsed query-strin
Craig Ringer wrote:
> On 19 August 2016 at 14:17, Tatsuo Ishii wrote:
>
> > I would like to proppse to export these functions in libpq.
> >
> > pqPutMsgStart
> > pqPutMsgEnd
> > pqPutc
> > pqPuts
> > pqPutInt
> > pqPutnchar
> > pqFlush
> > pqHandleSendFailure
> >
> > I think this would be useful
Robert Haas wrote:
> However:
>
> 1. The number of tables for which we would need to add a duplicate,
> unlogged table is formidable. You need pg_attribute, pg_attrdef,
> pg_constraint, pg_description, pg_type, pg_trigger, pg_rewrite, etc.
> And the backend changes needed so that we used the unl
Bruce Momjian wrote:
> On Tue, Aug 16, 2016 at 11:47:09AM -0700, Andres Freund wrote:
> > On 2016-08-15 18:09:02 +, Piotr Stefaniak wrote:
> > > There are more fixes I intend to do, of which the most relevant for
> > > Postgres are:
> > > 1) fixing "function pointer typedef formatting"
> >
>
Robert Haas wrote:
> 2. When you finish the heap scan, or when the array of dead tuple IDs
> is full (or very nearly full?), perform a cycle of index vacuuming.
> For now, have each worker process a separate index; extra workers just
> wait. Perhaps use the condition variable patch that I posted
Robert Haas wrote:
> On Tue, Aug 23, 2016 at 11:17 AM, Alvaro Herrera
> wrote:
> > Robert Haas wrote:
> >> 2. When you finish the heap scan, or when the array of dead tuple IDs
> >> is full (or very nearly full?), perform a cycle of index vacuuming.
> >&
Bruce Momjian wrote:
> On Tue, Aug 23, 2016 at 02:31:26PM -0400, Robert Haas wrote:
> > On Tue, Aug 23, 2016 at 1:57 PM, Bruce Momjian wrote:
> > > That's why I was asking you to comment on the final patch, which I am
> > > planning to apply to PG 10 soon.
> >
> > Oh, OK. I didn't understand tha
Ryan Murphy wrote:
> Thanks for committing it Tom! Thank you all for your help.
>
> I really like the Postgres project! If there's anything that especially
> needs worked on let me know, I'd love to help.
https://wiki.postgresql.org/wiki/Todo
--
Álvaro Herrerahttp://www.2ndQua
Claudio Freire wrote:
> After looking at it from a birdseye view, I agree it's conceptually
> complex (reading HeapTupleSatisfiesSelf already makes one dizzy).
>
> But other than that, the implementation seems rather simple. It seems
> to me, if one figures out that it is safe to do so (a-priori,
Kevin Grittner wrote:
> Modify BufferGetPage() to prepare for "snapshot too old" feature
I just noticed that this commit added a line to #include catalog/catalog.h
in storage/bufmgr.h. I can't find any reason for it doing so, and I
think it's a bad line to have there. Can we get it removed?
--
Amit Kapila wrote:
> $SUBJECT will make hash indexes reliable and usable on standby.
Nice work.
Can you split the new xlog-related stuff to a new file, say hash_xlog.h,
instead of cramming it in hash.h? Removing the existing #include
"xlogreader.h" from hash.h would be nice. I volunteer for pus
Alvaro Herrera wrote:
> Many have expressed their interest in this topic, but I haven't seen any
> design of how it should work. Here's my attempt; I've been playing with
> this for some time now and I think what I propose here is a good initial
> plan.
I regret to
Amit Kapila wrote:
> On Wed, Aug 24, 2016 at 11:46 PM, Alvaro Herrera
> wrote:
> > Can you split the new xlog-related stuff to a new file, say hash_xlog.h,
> > instead of cramming it in hash.h? Removing the existing #include
> > "xlogreader.h" from hash.h would
Kuntal Ghosh wrote:
> 4. For Speculative Heap tuple insert operation, there was
> inconsistency in t_ctid value. So, I've modified the t_ctid value (in
> backup page) to current block number and offset number. Need
> suggestions!!
In speculative insertions, t_ctid is used to store the speculative
Robert Haas wrote:
> On Thu, Aug 25, 2016 at 1:43 PM, Josh Berkus wrote:
> > The one thing I'd be worried about with the increase in size is folks
> > using PostgreSQL for very small databases. If your database is only
> > 30MB or so in size, the increase in size of the WAL will be pretty
> > si
Robert Haas wrote:
> On Thu, Aug 25, 2016 at 2:49 PM, Alvaro Herrera
> wrote:
> > I think the relevant one for that case is the minimum, though:
> >
> > #min_wal_size = 80MB
> >
> > which corresponds to 5 segments. I suppose the default value for this
>
Kevin Grittner wrote:
> Add the "snapshot too old" feature
> src/backend/access/gin/ginbtree.c | 9 +-
> src/backend/access/gin/gindatapage.c | 7 +-
> src/backend/access/gin/ginget.c| 22 +-
> src/backend/access/gin/gininsert.c
Robert Haas wrote:
> On Thu, Aug 25, 2016 at 3:21 PM, Alvaro Herrera
> wrote:
> > Does it work to set the minimum to one WAL segment, i.e. 64MB? guc.c
> > has a hardcoded minimum of 2, but I couldn't find an explanation for it.
>
> Well, I think that when you o
Kevin Grittner wrote:
> On Thu, Aug 25, 2016 at 2:56 PM, Alvaro Herrera
> wrote:
>
> > I'm wondering about the TestForOldSnapshot call in scanPendingInsert().
> > Why do we apply it to the metapage buffer (line 1717 in master)?
>
> If there is any chance that
Gavin Flower wrote:
> On 26/08/16 05:43, Josh Berkus wrote:
> >The one thing I'd be worried about with the increase in size is folks
> >using PostgreSQL for very small databases. If your database is only
> >30MB or so in size, the increase in size of the WAL will be pretty
> >significant (+144MB
Kuntal Ghosh wrote:
> Thanks a lot.
>
> I just want to mention the situation where I was getting the
> speculative token related inconsistency.
>
> ItemPointer in backup page from master:
> LOG: ItemPointer BlockNumber: 1 OffsetNumber:65534 Speculative: true
> CONTEXT: xlog redo at 0/127F4A48 f
Tom Lane wrote:
> So far as I can find, the attached is all we need to do to introduce a
> new message field. (This patch doesn't address the memory-context
> questions, but it does fix the localization-driven failure demonstrated
> upthread.)
>
> Any objections? Anyone want to bikeshed the fie
Simon Riggs wrote:
> On 26 August 2016 at 18:26, Euler Taveira wrote:
>
> > I'm bringing this $subject into discussion again. Historically, we are
> > carrying binary names that have been confused newbies. createuser is the
> > worst name so for. Also, names like createdb, initdb, reindexdb, and
Michael Paquier wrote:
> On Sat, Aug 27, 2016 at 6:34 AM, Andres Freund wrote:
> > On 2016-08-26 17:31:14 -0400, Peter Eisentraut wrote:
> >> I agree with all that. But the subject line is specifically about
> >> moving pg_xlog. So if your opinion is that we shouldn't move pg_xlog,
> >> then tha
Amit Kapila wrote:
> How about attached?
That works; pushed. (I removed a few #includes from the new file.)
> If you want, I think we can one step further and move hash_redo to a
> new file hash_xlog.c which is required for main patch, but we can
> leave it for later as well.
I think that can
Robert Haas wrote:
> That would also have the advantage of improving the test coverage for
> pg_stat_statements, which is at the moment quite a bit thinner than
> the coverage for lwlock.c.
Hmm, the coverage-html report is not currently covering contrib ... I
suppose that's an easily fixable over
Jesper Pedersen wrote:
> Hi,
>
> Attached is a patch that adds support for hash indexes in pageinspect.
>
> The functionality (hash_metap, hash_page_stats and hash_page_items) follows
> the B-tree functions.
I suggest that pageinspect functions are more convenient to use via the
get_raw_page int
Haribabu Kommi wrote:
> Apart from the above, here are the following list of command tags that
> are generated in the code, I took only the first word of the command tag
> just to see how many categories present. The number indicates the
> subset of operations or number of types it is used. Like c
Andres Freund wrote:
> On 2016-08-31 11:23:27 -0400, Tom Lane wrote:
> > Another issue is what is the low-level interlock between nextvals
> > in different processes. Right now it's the buffer lock on the
> > sequence's page. With a scheme like this, if we just kept doing
> > that, we'd have a si
Andres Freund wrote:
> Hi,
>
> On 2016-08-31 12:53:30 -0400, Tom Lane wrote:
> > Improving on the space wastage is exactly the point IMO. If it's still
> > going to be 8k per sequence on disk (*and* in shared buffers, remember),
> > I'm not sure it's worth all the work to change things at all.
>
Grigory Smolkin wrote:
> Funny part is that it never drops them. So when backend is finally
> terminated, it tries to drop them and fails with error:
>
> FATAL: out of shared memory
> HINT: You might need to increase max_locks_per_transaction
>
> If I understand that rigth, we are trying to dr
Grigory Smolkin wrote:
>
> On 09/05/2016 04:34 PM, Alvaro Herrera wrote:
> >Grigory Smolkin wrote:
> >
> >>Funny part is that it never drops them. So when backend is finally
> >>terminated, it tries to drop them and fails with error:
> >>
> >>
Marko Tiikkaja wrote:
> On 2016-09-06 6:02 PM, Marti Raudsepp wrote:
> >This issue is also reproducible on the current master branch. In an
> >assertions-enabled build, it traps an assertion in HeapTupleHeaderGetCmax
> >called by heap_lock_tuple. The following test case demonstrates the issue...
>
Marti Raudsepp wrote:
> Hello list
>
> While testing an application with PostgreSQL 9.5, we experienced an issue
> involving aborted subtransactions and SELECT FOR UPDATE. In certain
> situations, a locking query doesn't return rows that should be visible and
> already locked by the current transa
> - I can't remember the specific language but they had the collation rule
> that "CH" was treated as a distinct entity between C and D. This gave the
> order C < CG < CI < CZ < CH < D. Then they removed CH as special which gave
> C < CG < CH < CI < CZ < D. Suppose there was the constraint CHECK (C
Gavin Flower wrote:
> possibly '--nosync' (& any similar) should have a '--no-sync' variation
> added, with the '--nosync' variation documented as depreciated?
I agree -- I would go as far as just documenting --no-sync only and
keeping the --nosync one working with minimal (if any) visibility in
Craig Ringer wrote:
> Hi all
>
> Now that it's becoming more common to post patch series, not just
> standalone patches, it might be worth looking at how the CF app can
> help manage them.
>
> Any ideas?
I agree that we don't consider this case at all currently and that it's
causing some pain.
Tom Lane wrote:
> I happened to notice that if you type "make" in
> src/test/modules/test_pg_dump, you will get a "make check" action
> not "make all". I hope this is just somebody being thoughtless
> about Makefile ordering and not an intentional override of the
> default make target. If the lat
Tom Lane wrote:
> Alvaro Herrera writes:
> > I suppose this is a very easy mistake to make -- but also fortunately an
> > easy one to correct. Do you want me to fix the affected modules?
>
> I was going to do it, but if you want to, feel free.
Done.
> (BTW, I no
Tom Lane wrote:
> Andrew Borodin writes:
> > Thank you for your corrections.
> > Here is the patch with suggestions taken into account, except 6th.
>
> I'll pick this up, unless some other committer is already on it.
>
> I think that we should buy back the addition of PageIndexTupleOverwrite
> t
Stephen Frost wrote:
> Greetings!
>
> * Stephen Frost (sfr...@snowman.net) wrote:
> > Based on Robert's suggestion and using Thom's verbiage, I've tested this
> > out:
> >
> > CREATE POLICY pol ON tab AS [PERMISSIVE|RESTRICTIVE] ...
Can't you keep those words as Sconst or something (DefElems?) u
Andres Freund wrote:
> ISTM that the easiest fix is to just tack -I '$(srcdir)' into the prove
> flags like:
> PROVE = @PROVE@
> PG_PROVE_FLAGS = -I $(top_srcdir)/src/test/perl/ -I '$(srcdir)'
> PROVE_FLAGS = --verbose
>
> I don't think there's any security concerns for us here.
Maybe not, but
Andres Freund wrote:
> On 2016-09-08 17:58:03 -0300, Alvaro Herrera wrote:
> > Andres Freund wrote:
> >
> > > ISTM that the easiest fix is to just tack -I '$(srcdir)' into the prove
> > > flags like:
> > > PROVE = @PROVE@
> > >
Tom Lane wrote:
> Hey Alvaro, can you comment on this bit in the proposed patch?
>
> + for (i = FirstOffsetNumber; i <= itemcount; i++)
> + {
> + ItemId ii = PageGetItemId(phdr, i);
> +
> + /* Normally here was following asse
Tom Lane wrote:
> Alvaro Herrera writes:
> > Tom Lane wrote:
> >> That comment seems utterly wrong to me, because both PageIndexTupleDelete
> >> and PageIndexMultiDelete certainly contain assertions that every item on
> >> the page has storage. Are you
Andres Freund wrote:
> On 2016-09-08 18:13:06 -0300, Alvaro Herrera wrote:
> > I suppose -I$(srcdir) should be fine. (Why the quotes?)
>
> Because quoting correctly seems like a good thing to do? Most people
> won't have whitespace in there, but it doesn't seem imp
Marko Tiikkaja wrote:
> Hi,
>
> Running one specific test from our application against REL9_5_STABLE
> (current as of today) gives me this:
Just pushed the fix. Thanks for the report!
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA,
Magnus wrote:
> I ran the web application mentioned in Marti's original mail on a patched
> Postgres server. It looks like it is working correctly now, no more test
> failures.
Thanks for the confirmation. I pushed the fix, along with the presented
test case.
I chose to backpatch all the way bac
Craig Ringer wrote:
> I suggest that the above patches be applied to 9.6 and v10. Then for
> v10
I don't object to patching 9.6 in this way, but kindly do not pollute
this thread with future ideas on what to do on pg10, at least until the
current release is sorted out. You'll only distract peopl
Michael Paquier wrote:
> On Tue, Sep 13, 2016 at 10:42 AM, Kyotaro HORIGUCHI
> wrote:
> > If we take a policy to try to imitate the behavior of some
> > reference platform (specifically Linux) on other platforms, this
> > is required disguising. Another potential policy on this problem
> > is "fol
Victor Wagner wrote:
> Hi hackers!
>
> I've encountered need to extend functionality of PostgresNode class
> from the TAP test framework. What I want can easily be done via perl
> object inheritation.
>
> But documentation in the PostgresNode.pm recommends to use get_new_node
> function rather t
Tatsuo Ishii wrote:
> Simple question: Is there any reason for event trigger to not support
> CREATE/ALTER ROLE/USER?
As I understand the issue, the main reason is that event triggers
execute procedures, and those exist in a single database only. If you
were to create an event trigger in database
Ashutosh Bapat wrote:
> Hi All,
> While working on partition-wise join, I had to examine Relids objects
> many times. Printing the Bitmapset::words[] in binary format and then
> inferring the relids takes time and is error prone. Instead I wrote a
> function bms_to_char() which allocates a StringIn
Tom Lane wrote:
> Ashutosh Bapat writes:
> > While working on partition-wise join, I had to examine Relids objects
> > many times. Printing the Bitmapset::words[] in binary format and then
> > inferring the relids takes time and is error prone.
>
> FWIW, I generally rely on pprint() to look at pl
Robert Haas wrote:
> Actually, I think that probably *is* worthwhile, specifically because
> it might let us avoid multiple index scans in cases where we currently
> require them. Right now, our default maintenance_work_mem value is
> 64MB, which is enough to hold a little over ten million tuples
Robert Haas wrote:
> On Thu, Sep 15, 2016 at 9:59 AM, Tom Lane wrote:
> > Possibly we ought to change things so that the default value of
> > min_parallel_relation_size is a fixed number of bytes rather
> > than a fixed number of blocks. Not sure though.
>
> The reason why this was originally re
Christoph Berg wrote:
> Re: Michael Paquier 2016-09-15
>
> > On Thu, Sep 15, 2016 at 8:57 PM, Heikki Linnakangas wrote:
> > > I backpatched this to 9.5, but not further than that. The functions this
> > > modified were moved around in 9.5, so the patch wouldn't apply as is. It
> > > wouldn't be
Robert Haas wrote:
> Hey, everybody: I intended to add this to the documentation before 9.6
> went out, but that didn't get done. Maybe it'll have to happen later
> at this point, but can I get some advice on WHERE in the documentation
> this stuff could be added? Assuming people agree it should
Rudolf Gavlas wrote:
> I work in an environment, where servers are administered by people
> with different user names and identical uid (0).
So everyone is superuser there? That sounds, um, unorthodox.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 S
Why not use generate_series() queries to insert the appropriate number
of tuples, instead of a handful of INSERT lines each time? Since each
insert is a separate transaction, that would probably be faster.
Why do you have a plpgsql function just to create a cursor? Wouldn't it
be simpler to cre
Rudolf Gavlas wrote:
> 2016-09-20 18:55 GMT+02:00, Alvaro Herrera :
> > Rudolf Gavlas wrote:
> >
> >> I work in an environment, where servers are administered by people
> >> with different user names and identical uid (0).
> >
> > So everyone is
Peter Eisentraut wrote:
> How about having the tag not be a column name but a row entry. So you'd
> do something like
>
> SELECT * FROM pg_stat_sql WHERE tag = 'ALTER VIEW';
>
> That way, we don't have to keep updating (and re-debating) this when new
> command types or subtypes are added. And
Petr Jelinek wrote:
> > I'm not sure how well it will work to replace all the bits of LIKE and
> > regular expressions with ICU API calls. One problem is that ICU likes
> > to do case folding as a whole string, not by character. I need to do
> > more research about that.
>
> Can't we use the
Stephen Frost wrote:
Stephen, the typo "awseome" in the tests is a bit distracting. Can you
please fix it?
> Updated patch changes to using IDENT and an strcmp() (similar to
> AlterOptRoleElem and vacuum_option_elem) to check the results at parse-time,
> and then throwing a more specific error i
Jeff Janes wrote:
> On Tue, Sep 20, 2016 at 12:19 AM, Michael Paquier > wrote:
>
> >
> > Note: the patch checks if a superuser is calling the new functions,
> > which is a good thing.
> >
>
> If we only have the bytea functions and the user needs to supply the raw
> pages themselves, rather than
Stephen Frost wrote:
> * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> > Stephen Frost wrote:
> > > +
> > > + If the policy is a "permissive" or "restrictive" policy.
> > > Permissive
> > > + p
Peter Eisentraut wrote:
> On 9/26/16 1:39 PM, Jesper Pedersen wrote:
> >> - hash_metap result fields spares and mapp should be arrays of integer.
> >
> > B-tree and BRIN uses a 'text' field as output, so left as is.
>
> These fields are specific to hash, so the precedent doesn't necessarily
> ap
Robert Haas wrote:
> I'm potentially willing to commit a patch that just makes the
> pg_hypot() -> hypot() change and does nothing else, if there are not
> objections to that change, but I want to be sure that we'll know right
> away if that turns out to break.
Uh, I thought pg_hypot() was still
Andreas Seltenreich wrote:
> Michael Paquier writes:
>
> > I am attaching a patch that addresses the bugs for the spin lock sections.
> > [2. text/x-diff; walreceiver-spin-calls.patch]
>
> I haven't seen a spinlock PANIC since testing with the patch applied.
> They occured five times with the sam
Fixed the pstrdup problem by replacing with strlcpy() to stack-allocated
variables (rather than palloc + memcpy as proposed in Michael's patch).
About the other problems:
Tom Lane wrote:
> I took a quick look through walreceiver.c, and there are a couple of
> obvious problems of the same ilk in
301 - 400 of 9812 matches
Mail list logo
