Andres Freund wrote:
> On 2014-07-04 18:31:34 +0800, gotoschool6g wrote:
> > Carp the code:
> >
> > const char *
> > clog_identify(uint8 info)
> > {
> > switch (info)
> > {
> > case CLOG_ZEROPAGE:
> >return "ZEROPAGE";
> > case CLOG_TRUNCATE:
> >return "TRUNCATE";
>
Tom Lane wrote:
> Also, -1 for adding another log_line_prefix escape. If you're routing
> multiple clusters logging to the same place (which is already a bit
> unlikely IMO), you can put distinguishing strings in log_line_prefix
> already. And it's not like we've got an infinite supply of letter
Peter Geoghegan wrote:
> > 6) Sometimes no hints are returned... Even in simple cases like this one:
> > =# create table foo (aa int, bb int);
> > CREATE TABLE
> > =# select ab from foo;
> > ERROR: 42703: column "ab" does not exist
> > LINE 1: select ab from foo;
> >^
> > LOCATION
Asif Naeem wrote:
> Yes. Can you please take a look at Win_lib_bin.patch I shared earlier ?, I
> think it is or similar approach will be appropriate. Thanks.
I think the suggestion by Peter Eisentraut upthread was pretty
reasonable -- the Makefiles are already aware that they are building a
shared
Peter Geoghegan wrote:
> On Tue, Jul 8, 2014 at 11:25 PM, Michael Paquier
> wrote:
> >> > 5) Do we want hints on system columns as well?
> >> I think it's obvious that the answer must be no. That's going to
> >> frequently result in suggestions of columns that users will complain
> >> aren't even
Tom Lane wrote:
> Michael Paquier writes:
> > With that, I am marking this patch as ready for committer.
>
> I've started looking at this patch. I wonder whether it's really such
> a great idea to expect the FDW to return a list of parsetrees for
> CREATE FOREIGN TABLE commands; that seems like
Peter Geoghegan wrote:
> On Wed, Jul 9, 2014 at 8:08 AM, Greg Stark wrote:
> > A simple rule is easier for users to understand as well as to code. I
> > would humbly suggest the following: take all the unqualified column
> > names, downcase them, check which ones match most closely the
> > unmatch
Heikki Linnakangas wrote:
> On 06/23/2014 08:07 PM, Alvaro Herrera wrote:
> I feel that the below would nevertheless be simpler:
>
> >>I wonder if it would be simpler to just always store the revmap
> >>pages in the beginning of the index, before any other pages.
Josh Berkus wrote:
> On 07/09/2014 02:16 PM, Alvaro Herrera wrote:
> > The way it works now, each opclass needs to have three support
> > procedures; I've called them getOpers, maybeUpdateValues, and compare.
> > (I realize these names are pretty bad, and will be chan
Claudio Freire wrote:
> On Wed, Jul 9, 2014 at 6:16 PM, Alvaro Herrera
> wrote:
> > Another thing I noticed is that version 8 of the patch blindly believed
> > the "pages_per_range" declared in catalogs. This meant that if somebody
> > did "alter index
Josh Berkus wrote:
> On 07/10/2014 12:20 PM, Alvaro Herrera wrote:
> >> So I guess the only thing left is to issue a NOTICE when said alter
> >> > takes place (I don't see that on the patch, but maybe it's there?)
> > That's not in the patch. I don
Heikki Linnakangas wrote:
> Attached is a new patch. It now keeps the current pg_clog unchanged,
> but adds a new pg_csnlog besides it. pg_csnlog is more similar to
> pg_subtrans than pg_clog: it's not WAL-logged, is reset at startup,
> and segments older than GlobalXmin can be truncated.
>
> Thi
Bruce Momjian wrote:
> On Thu, Jul 10, 2014 at 06:38:26PM -0400, Bruce Momjian wrote:
> > I have thought some more on this. I thought I would need to open
> > pg_class in C and do complex backend stuff, but I now realize I can do
> > it from libpq, and just call ALTER TABLE and I think that alway
Fujii Masao wrote:
> On Thu, Jul 10, 2014 at 6:16 AM, Alvaro Herrera
> wrote:
> > Here's a new version of this patch, which is more generic the original
> > versions, and similar to what you describe.
>
> I've not read the discussion so far at all, but I foun
Jeevan Chalke wrote:
> On Fri, Jul 11, 2014 at 3:13 PM, Sawada Masahiko
> wrote:
> > And the line number should be switched to 1 when line number has
> > reached to INT_MAX?
>
> Yes, when it goes beyond INT_MAX, wrap around to 1.
>
> BTW, I wonder, can't we simply use unsigned int instead?
Th
Sawada Masahiko wrote:
> As you said, if line number reached UINT_MAX then I think that this
> case is too strange.
> I think INT_MAX is enough for line number.
My point is not whether 2 billion is a better number than 4 billion as a
maximum value. My point is that wraparound of signed int is, I
Heikki Linnakangas wrote:
> I did again the refactoring you did back in 2006, patch attached.
> One thing I did differently: I moved the raw, non-encrypted,
> read/write functions to separate functions: pqsecure_raw_read and
> pqsecure_raw_write. Those functions encapsulate the SIGPIPE
> handling.
Robert Haas wrote:
> On Mon, Jul 14, 2014 at 6:20 AM, Abhijit Menon-Sen
> wrote:
> > At 2014-05-08 15:28:22 +0200, and...@2ndquadrant.com wrote:
> >> > > Hm. Not sure what you're ACKing here ;).
> >> >
> >> > The idea of giving the unallocated memory a NULL key.
> >>
> >> Ok. A new version of the
Jaime Casanova wrote:
> Attached is a patch moving the reloptions of views into its own structure.
> i also created a view_reloptions() function in order to not use
> heap_reloptions() for views, but maybe that was too much?
No, that was part of what I was thinking too -- I have pushed this now.
Fabrízio de Royes Mello wrote:
> On Fri, May 16, 2014 at 2:03 AM, Fabrízio de Royes Mello <
> fabriziome...@gmail.com> wrote:
> >
> > Hi all,
> >
> > Are there some reason to don't show the tablespace size in the \db+
> > psql command?
>
> The attached patch show tablespace size in \db+ psql comma
I'm not saying there is no multixact bug here, but I wonder if this part
of your crasher patch might be the cause:
--- 754,771
errmsg("could not seek to block %u in file
\"%s\": %m",
blocknum,
FilePathName(v->m
Simon Riggs wrote:
> On 15 July 2014 19:15, Tom Lane wrote:
>
> > Where was the discussion of
> > why this change should be back-patched?
>
> Your question has broader implications. Currently commit messages do
> not reference the conversations that led to them and a great many use
> entirely di
Tom Lane wrote:
> Dilip kumar writes:
> > On 15 July 2014 19:01, Magnus Hagander Wrote,
> >> I am late to this game, but the first thing to my mind was - do we
> >> really need the whole forking/threading thing on the client at all?
>
> > Thanks for the review, I understand you point, but I think
Tom Lane wrote:
> 20MB messages to the list aren't that friendly. Please don't do that
> again, unless asked to.
FWIW the message was not distributed to the list. I got a note from
Adam and dropped it from the moderation queue.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
Post
I haven't followed this at all, but I just skimmed over it and noticed
the CustomPlanMarkPos thingy; apologies if this has been discussed
before. It seems a bit odd to me; why isn't it sufficient to have a
boolean flag in regular CustomPlan to indicate that it supports
mark/restore?
--
Álvaro He
Kyotaro HORIGUCHI wrote:
> Hello,
>
> As far as I see gin seems using GIN_EXCLUSIVE instead of
> BUFFER_LOCK_EXCLUSIVE for LockBuffer, but the raw
> BUFFER_LOCK_EXCLUSIVE appears in ginbuildempty().
>
> Does it has a meaning to fix them to GIN_EXCLUSIVE?
I don't understand the point of having th
Jeff Janes wrote:
> Should we push the refactoring through anyway? I have a hard time
> believing that pg_dump is going to be the only client program we ever have
> that will need process-level parallelism, even if this feature itself does
> not need it. Why make the next person who comes along
Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > Stephen Frost writes:
> > > That it's more-or-less a bulk 'ALTER TABLE' operation is why I had been
> > > trying to think of a way to put it under that command. What if we had a
> > > more general way to reference 'all objects in a
Tom Lane wrote:
> Josh Berkus writes:
> >> 2. *Then*, in a second pass, enforce requirements like "can't be
> >> changed except at server start".
>
> > This would also make conf.d much more useful; I wouldn't have to worry
> > as much about overlapping config settings.
>
> > Sounds like a 9.5 f
Fabien wrote:
> ISTM that a desirable and reasonably simple to implement feature
> would be to be able to set the blocksize at "initdb" time, and
> "postgres" could use the value found in the database instead of a
> compile-time one.
I think you will find it more difficult to implement than it se
Tom Lane wrote:
> Alvaro Herrera writes:
> > Tom Lane wrote:
> >> No, ALTER SYSTEM is there now and it needs to work right in its first
> >> release. I will go fix this if nobody else does.
>
> > Just checking -- you didn't get around to dealing with th
Jonathan S. Katz wrote:
> Well that definitely answers "how hard would it be." - before
> embarking on something laborious (as even just indexing is
> nontrivial), I think it would be good to figure out how people are
> using IS [NOT] DISTINCT FROM and if there is interest in having it be
> indexa
Peter Geoghegan wrote:
> For some reason I thought that that was what Michael was proposing - a
> more comprehensive move of code into core than the structuring that I
> proposed. I actually thought about a Levenshtein distance operator at
> one point months ago, before I entirely gave up on that.
Peter Geoghegan wrote:
> Maybe that would be marginally better than classic Levenshtein
> distance, but I doubt it would pay for itself. It's just more code to
> maintain. Are we really expecting to not get the best possible
> suggestion due to some number of transposition errors very frequently?
Robert Haas wrote:
> On Wed, Jul 23, 2014 at 4:05 PM, Peter Geoghegan wrote:
> > On Wed, Jul 23, 2014 at 9:58 AM, Robert Haas wrote:
> >> 2. If you find more than one tuple that is visible to your scan, error.
> >
> > This point seems to concern making the UPSERT UPDATE only affect zero
> > or o
Magnus Hagander wrote:
> I think it would be very useful to have. Given how long it takes to
> build not all the time, but running it every couple of days or weekly
> or so would be quite useful. Then we'd catch things earlier and not
> have to spend as much time trying to figure out exactly what
Fabien COELHO wrote:
Hi,
> Note that I was more asking about the desirability of the feature,
> the implementation is another, although also relevant, issue. To me
> it is really desirable given the potential performance impact, but
> maybe we should not care about 10%?
10% performance improveme
Fabien COELHO wrote:
> I also have a problem with assert & Assert. I finally figured out
> that Assert is not compiled in by default, thus it is generally
> ignored. So it is more for debugging purposes when activated than
> for guarding against some unexpected user errors.
Yes, Assert() is for
On Fri, Jul 25, 2014 at 02:11:32PM -0400, Robert Haas wrote:
> + pq_mq_busy = true;
> +
> + iov[0].data = &msgtype;
> + iov[0].len = 1;
> + iov[1].data = s;
> + iov[1].len = len;
> +
> + Assert(pq_mq_handle != NULL);
> + result = shm_mq_sendv(pq_mq_handle, iov, 2, false
Tom Lane wrote:
> It might be better if we'd declared AclMode in a single-purpose header,
> say utils/aclmode.h, and then #include'd that into parsenodes.h.
> There's certainly plenty of other single-datatype headers laying about.
Do you mean src/include/datatype/aclmode.h?
--
Álvaro Herrera
David Rowley wrote:
> I've also been looking at the isolation tests and I see that you've added a
> series of tests for NOWAIT. I was wondering why you did that as that's
> really existing code, probably if you thought the tests were a bit thin
> around NOWAIT then maybe that should be a separate
Robert Haas wrote:
> OK, I think I see the problem. In EXEC_BACKEND mode,
> SubPostmasterMain() calls InitProcess() before IsBackgroundWorker has
> been set. InitProcess() therefore pulls the PGPROC for the worker
> from freeProcs rather than bgworkerFreeProcs. By exit time,
> IsBackgroundWorke
I have just pushed two optimization patches for multixacts to HEAD only.
I hesitate to backpatch them to 9.3 right away, but will consider doing
so if people think differently.
I also have a patch that supposedly fixes the performance regression
reported in bug #8470, but it's considerably more ob
Stephen Frost wrote:
> * Bruce Momjian (br...@momjian.us) wrote:
> > Actually, thinking more, Stephen Frost mentioned that the auditing
> > system has to modify database _state_, and dumping/restoring the state
> > of an extension might be tricky.
>
> This is really true of any extension which wan
David Rowley wrote:
> The only notes I can think to leave for the commiter would be around the
> precedence order of the lock policy, especially around a query such as:
>
> SELECT * FROM (SELECT * FROM a FOR UPDATE SKIP LOCKED) a FOR UPDATE; --
> skip locked wins
>
> Of course the current behavi
Tom Lane wrote:
> Jeff Janes writes:
> > After 87306184580c9c49717, if the postmaster dies without cleaning up (i.e.
> > power outage), running "pg_ctl start" just gives this message and then
> > exits:
>
> > pg_ctl: another server might be running
>
> > Under the old behavior, it would try to s
Robert Haas wrote:
> On Mon, Aug 4, 2014 at 5:20 AM, Fabien COELHO wrote:
> >> This patch is pretty trivial.
> > Another slightly less trivial but more useful version.
> >
> > The issue is that there are 3 definitions of modulo, two of which are fine
> > (Knuth floored division and Euclidian), and
Bruce Momjian wrote:
> On Tue, Aug 5, 2014 at 12:52:51PM -0700, Josh Berkus wrote:
> > On 08/05/2014 11:12 AM, Jerry Sievers wrote:
> > > shared_preload_libraries += auto_explain
> > >
> > > Would do the trick.
> > >
> > > I've never heard this mentioned before so presume not many have
> > > co
David G Johnston wrote:
> Alvaro Herrera-9 wrote
> > I think this merits a new GUC flag, say GUC_LIST_ADDITIVE.
>
> Would that allow, without any special syntax, multiple declarations of, say,
> shared_preload_libraries, to have their values appended instead of the most
>
FWIW I think I haven't responded appropriately to the points raised by
Heikki. Basically, as I see it there are three main items:
1. the revmap physical-to-logical mapping is too complex; let's use
something else.
We had revmap originally in a separate fork. The current approach grew
out of the
土卜皿 wrote:
> 2014-08-05 22:08 GMT+08:00 土卜皿 :
>
> > hi, all
> > I already can debug general postgres using "ddd" and "select
> > pg_backend_pid();" , now, I want to study the details of the system
> > catalog cache and system cache management, so I need to debug the function
> > InitPostgres()
Fabrízio de Royes Mello wrote:
> On Tue, Aug 5, 2014 at 10:55 PM, Tom Lane wrote:
>
> > Josh Berkus writes:
> > > BTW, while there's unlikely to be a good reason to put search_path in
> > > pg.conf with appends, there are a LOT of reasons to want to be able to
> > > append to it during a session
Simon Riggs wrote:
> On 7 August 2014 14:53, Robert Haas wrote:
> > On Wed, Aug 6, 2014 at 4:06 PM, Nicolas Barbier
> > wrote:
> >> 2014-08-06 Claudio Freire :
> >>
> >>> So, I like blockfilter a lot. I change my vote to blockfilter ;)
> >>
> >> +1 for blockfilter, because it stresses the fact th
Fujii Masao wrote:
> Hi,
>
> We can specify the unit when setting autovacuum_vacuum_cost_delay
> GUC as follows.
>
> ALTER SYSTEM SET autovacuum_vacuum_cost_delay TO '80ms';
>
> OTOH we cannot specify the unit when setting autovacuum_vacuum_cost_delay
> as storage parameter as follows.
>
>
Fujii Masao wrote:
> On Fri, Aug 8, 2014 at 12:56 PM, Alvaro Herrera
> wrote:
> > Hm, what's with the parse_int signature change and the hintmsg thing?
> > Is it just me or the patch is incomplete?
>
> Sorry, probably I failed to see your point. You mean that the s
Robert Haas wrote:
> On Fri, Aug 8, 2014 at 9:44 PM, Peter Eisentraut wrote:
> > or perhaps make a note at the bottom
> >
> > The options -I, -n, -P, -t, -T, --section can be combined and
> > specified multiple times to select multiple objects.
> >
> > Other ideas?
>
> I like the
Heikki Linnakangas wrote:
> On 08/05/2014 03:50 PM, Michael Paquier wrote:
> >- All the functions in xlogconstruct.c could be defined in a separate
> >header xlogconstruct.h. What they do is rather independent from xlog.h. The
> >same applies to all the structures and functions of xlogconstruct.c
Heikki Linnakangas wrote:
> On 08/05/2014 03:50 PM, Michael Paquier wrote:
> >- XLogRecGetBlockRefIds needing an already-allocated array for *out is not
> >user-friendly. Cannot we just do all the work inside this function?
>
> I agree it's not a nice API. Returning a palloc'd array would be
> ni
Heikki Linnakangas wrote:
> I couldn't resist starting to hack on this, and implemented the
> scheme I've been having in mind:
>
> 1. MMTuple contains the block number of the heap page (range) that
> the tuple represents. Vacuum is no longer needed to clean up old
> tuples; when an index tuples is
Stephen Frost wrote:
> * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> > Stephen Frost wrote:
> > > Alright, sounds like this is more-or-less the concensus. I'll see about
> > > making it happen shortly.
> >
> > Were you able to work on this?
Heikki Linnakangas wrote:
> Here's a full version of this refactoring patch, all the rmgr's have
> now been updated to use XLogReplayBuffer(). I think this is a
> worthwhile change on its own, even if we drop the ball on the rest
> of the WAL format patch, because it makes the redo-routines more
>
Heikki Linnakangas wrote:
> Here's a full version of this refactoring patch, all the rmgr's have
> now been updated to use XLogReplayBuffer(). I think this is a
> worthwhile change on its own, even if we drop the ball on the rest
> of the WAL format patch, because it makes the redo-routines more
>
Heikki Linnakangas wrote:
> On 08/14/2014 06:53 AM, Joachim Wieland wrote:
> >I'm seeing an assertion failure with "pg_dump -c --if-exists" which is
> >not ready to handle BLOBs it seems:
> >
> >pg_dump: pg_backup_archiver.c:472: RestoreArchive: Assertion `mark !=
> >((void *)0)' failed.
> >
> >To
Heikki Linnakangas wrote:
> The quick fix would be to add an exception for blobs, close to where
> Assert is. There are a few exceptions there already. A cleaner
> solution would be to add a new argument to ArchiveEntry and make the
> callers responsible for providing an "DROP IF EXISTS" query, bu
Fujii Masao wrote:
> I've not read the patch yet. But while testing the feature, I found that
>
> * Brin index cannot be created on CHAR(n) column.
>Maybe other data types have the same problem.
Yeah, it's just a matter of adding an opclass for it -- pretty simple
stuff really, because you d
Marco Nenciarini wrote:
> To calculate the md5 checksum I've used the md5 code present in pgcrypto
> contrib as the code in src/include/libpq/md5.h is not suitable for large
> files. Since a core feature cannot depend on a piece of contrib, I've
> moved the files
>
> contrib/pgcrypto/md5.c
> cont
Pavel Stehule wrote:
> 2014-08-13 15:22 GMT+02:00 MauMau :
> > I didn't mean performance statistics data to be stored in database tables.
> > I just meant:
> >
> > * pg_stat_system_events is a view to show data on memory, which returns
> > one row for each event across the system. This is similar
Heikki Linnakangas wrote:
> On 08/18/2014 08:05 AM, Alvaro Herrera wrote:
> >We already have the FNV checksum implementation in the backend -- can't
> >we use that one for this and avoid messing with MD5?
> >
> >(I don't think we're looking for a crypt
Robert Haas wrote:
> Moreover, even if somebody is (rather oddly, IMV) checking for
> command_tag == "COMMIT", it's not going to be a difficult change to
> check for command_tag == "COMMIT" or substr(command_tag,0,7) ==
> "COMMIT ". That's a level of incompatibility that would certainly
> deserve
Heikki Linnakangas wrote:
> Barring objections or better ideas, I'm leaning towards
> XLogReadBufferForRedo.
WFM
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgr
Abhijit Menon-Sen wrote:
> At 2014-06-29 20:35:04 +0900, maumau...@gmail.com wrote:
> >
> > Thanks, I marked it as ready for committer. I hope Fujii san or
> > another committer will commit this, refining English expression if
> > necessary.
>
> Since it was just a matter of editing, I went throu
Stephen Frost wrote:
> * Heikki Linnakangas (hlinnakan...@vmware.com) wrote:
>
> > Indeed, the ODBC driver only uses libpq for authentication, then
> > calls PQgetssl(), and takes over the whole show calling SSL_read()
> > and SSL_write() itself. Ideally, we'd modify psqlodbc to stop doing
> > tha
MauMau wrote:
> With that said, copying to a temporary file like .tmp and
> renaming it to sounds worthwhile even as a basic copy
> utility. I want to avoid copying to a temporary file with a fixed
> name like _copy.tmp, because some advanced utility may want to run
> multiple instances of pg_co
Amit Kapila wrote:
> I think it is because heap_getattr() is not that cheap. We have
> noticed the similar problem during development of scan key push down
> work [1].
One possibility to reduce the cost of that is to use whole tuple deform
instead of repeated individual heap_getattr() calls. Si
Robert Haas wrote:
> On Tue, Mar 21, 2017 at 10:01 AM, Amit Kapila wrote:
> > Sure, we can try that. I think we need to try it with
> > synchronous_commit = off, otherwise, WAL writes completely overshadows
> > everything.
>
> synchronous_commit = off is a much more realistic scenario than fsyn
Bruce Momjian wrote:
> I don't think it makes sense to try and save bits and add complexity
> when we have no idea if we will ever use them,
If we find ourselves in dire need of additional bits, there is a known
mechanism to get back 2 bits from old-style VACUUM FULL. I assume that
the reason no
Bruce Momjian wrote:
> On Tue, Mar 21, 2017 at 04:43:58PM -0300, Alvaro Herrera wrote:
> > Bruce Momjian wrote:
> >
> > > I don't think it makes sense to try and save bits and add complexity
> > > when we have no idea if we will ever use them,
> &g
Thomas Munro wrote:
> Another thought about this design: Why autovacuum?
One reason is that autovacuum is already there, so it's convenient to
give it the responsibility for this kind of task. Another reason is
that autovacuum is already doing this, via vacuum. I don't see the
need to have a c
Thomas Munro wrote:
> What is your motivation for using DSA? It seems you are creating an
> area and then using it to make exactly one allocation of a constant
> size known up front to hold your fixed size workitems array. You
> don't do any dynamic allocation at runtime, apart from the detail t
Heikki Linnakangas wrote:
> I did some archeology, and found CheckTokenMembership() in MinGW's w32api
> packages version 3.14
> (https://sourceforge.net/projects/mingw/files/MinGW/Base/w32api/w32api-3.14/,
> in include/winbase.h). According to the timestamps on that download page,
> that was relea
Robert Haas wrote:
> I guess the downside of back-patching this is that it could cause a
> plan change for somebody which ends up being worse. On the whole,
> serial execution of queries intended to be run in parallel isn't
> likely to work out well, but it's always possible somebody has a cases
Copying Fabrízio Mello here, who spent some time trying to work on
reloptions too. He may have something to say about the new
functionality that this patch provides.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Service
Pushed this after some more tweaking.
--
Álvaro Herrerahttps://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.postg
Alvaro Herrera wrote:
> Here's a rebased series on top of today's a3eac988c267. I call this
> v28.
>
> I put David's pg_dump and COMMENT patches as second in line, just after
> the initial infrastructure patch. I suppose those three have to be
> committed toge
Robert Haas wrote:
> On Fri, Mar 24, 2017 at 1:16 PM, Alvaro Herrera
> wrote:
> > Implement multivariate n-distinct coefficients
>
> dromedary and arapaima have failures like this, which seems likely
> related to this commit:
>
> EXPLAIN
>SELECT COUNT(*
Tom Lane wrote:
> Why not use COSTS OFF? Or I'll put that even more strongly: all the
> existing regression tests use COSTS OFF, exactly to avoid this sort of
> machine-dependent output. There had better be a really damn good
> reason not to use it here.
If we use COSTS OFF, the test is complet
Per
https://postgr.es/m/CAEepm=11ma_Z1HoPxPcSCANnh5ykHORa=hca1u1v1+5s_jw...@mail.gmail.com
it seems that the dsm.c API is a bit inconvenient right now. I proposed
in the first patch in that thread to change the API so that a segment is
marked as "pinned" if created with no ResourceOwner set as cu
Alvaro Herrera wrote:
> Per
> https://postgr.es/m/CAEepm=11ma_Z1HoPxPcSCANnh5ykHORa=hca1u1v1+5s_jw...@mail.gmail.com
> it seems that the dsm.c API is a bit inconvenient right now. I proposed
> in the first patch in that thread to change the API so that a segment is
> marked
Thomas Munro wrote:
> I'd word this slightly differently:
>
> + * If there is a CurrentResourceOwner, the new segment is born unpinned and
> the
> + * resource owner is in charge of destroying it (and will be blamed if it
> + * doesn't). If there's no current resource owner, then the segment st
Nikolay Shaplov wrote:
> If I would think about it now: we always know how many options we will have.
> So we can just pass this number to palloc and assert if somebody adds more
> options then expected... What do yo think about it.
I think we need to preserve the ability to add custom options,
David Rowley wrote:
> Seems pg_get_statisticsextdef() has a couple of things wrong:
>
> 1. HeapTupleIsValid() called on the wrong tuple.
> 2. Did not schema qualify names.
Actually we can solve both 1 and the first half of 2 by just using
generate_relation_name, which is less code and gives bett
Is the WARM tap test suite supposed to work when applied without all the
other patches? I just tried applied that one and running "make check -C
src/test/modules", and it seems to hang after giving "ok 5" for
t/002_warm_stress.pl. (I had to add a Makefile too, attached.)
--
Álvaro Herrera
Tomas Vondra wrote:
> OK, this did the trick. And just as I suspected, it seems to be due to doing
> memcpy+offsetof when serializing the statistic into a bytea. The attached
> patch fixes that for me. Can you test it on your build?
Buildfarm member skink confirms that this is fixed. Thanks!
--
Nikolay Shaplov wrote:
> В письме от 17 марта 2017 14:21:26 пользователь Alvaro Herrera написал:
>
> > Please make sure to mark functions as static (e.g. bringetreloptcatalog).
> I am a bit confused here:
>
> For brin and nbtree this is a good idea: brin.c and nbtree.c has
Fujii Masao wrote:
> This is the evidence that no one cares about the details of VACUUM VERBOSE
> output example. So I'm tempted to simplify the example (please see the
> attached patch) instead of keeping updating the example.
Agreed.
> > If this patch is applied, it should back-patch to all su
We need a different strategy, if we want to
enable WARM on GiST/GIN indexes.)
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>From f6ba238dd46416eb29ac43dadac0c69a75f106fe Mon Sep 17 00:00:00 2001
From: Alv
Thomas Munro wrote:
> + if (CurrentResourceOwner)
> + {
> + seg->resowner = CurrentResourceOwner;
> + ResourceOwnerRememberDSM(CurrentResourceOwner, seg);
> + }
>
> You need to assign seg->resowner = CurrentResourceOwner
> unconditionally here. Otherwise seg->resowner is uninit
Pavan Deolasee wrote:
> On Wed, Mar 29, 2017 at 3:42 AM, Alvaro Herrera
> wrote:
>
> > I pushed 0002 after some makeup, since it's just cosmetic and not
> > controversial.
>
> Thanks. I think your patch of tracking interesting attributes seems ok too
> after
Peter Eisentraut wrote:
> On 3/15/17 21:54, Peter Eisentraut wrote:
> > 0004 Add subscription apply worker privilege checks
> > 0005 Add CREATE SUBSCRIPTION privilege on databases
>
> It would be nice to reach a conclusion on these (the second one
> particularly), because otherwise we'll be stuck
Stephen Frost wrote:
> * Dagfinn Ilmari Mannsåker (ilm...@ilmari.org) wrote:
> > Non-verbose prove still lists each test script, it just doesn't list
> > each individual test within the script.
>
> I agree that it'd be better to just show the per-script results rather
> than every little test res
701 - 800 of 9812 matches
Mail list logo
