On 2016-10-28 11:23:22 +0530, Amit Kapila wrote:
> On Wed, Oct 26, 2016 at 12:01 PM, Andres Freund wrote:
> > What I'm worried about though is that this, afaics, will quite
> > noticeably *increase* total cost in cases with a noticeable number of
> > columns and a not that selective qual. The reas
On Thu, Oct 27, 2016 at 5:08 PM, Michael Paquier
wrote:
> On Thu, Sep 29, 2016 at 12:49 PM, Michael Paquier
> wrote:
>> Seeing nothing happening, I have moved the patch to next CF as there
>> is a new version, but no reviews for it.
>
> Just a note for anybody potentially looking at this patch. I
On Fri, Oct 28, 2016 at 4:17 AM, Alvaro Herrera
wrote:
> Greg Stark wrote:
>
> > The fundamental problem is that the pga_hba.conf file has some bits of
> > complex structure that aren't easily captured by linear arrays. The
> > problem I struggled with most was the keywords like "all", "samerole"
On Wed, Oct 26, 2016 at 12:01 PM, Andres Freund wrote:
> On 2016-10-25 13:18:47 -0400, Tom Lane wrote:
>> (Frankly, I'm pretty skeptical of this entire patch being worth the
>> trouble...)
>
> The gains are quite noticeable in some cases. So if we can make it work
> without noticeable downsides...
2016-10-28 5:30 GMT+02:00 Peter Eisentraut :
> I propose to change the psql \d output a bit, best shown with an example:
>
> \d persons3
> - Table "public.persons3"
> - Column | Type |Modifiers
> -+-+--
> - id | integer | not null
> - name | text
On Fri, Oct 28, 2016 at 5:08 AM, Michael Paquier
wrote:
> On Fri, Oct 28, 2016 at 1:16 AM, Robert Haas wrote:
>> On Thu, Oct 27, 2016 at 9:05 AM, Michael Paquier
>> wrote:
>>> On Thu, Oct 27, 2016 at 7:16 PM, Amit Kapila
>>> wrote:
This can create problem if the checkpoint record spans ac
On 9/1/15 12:13 AM, Peter Eisentraut wrote:
> ere is a series of patches to clean up the Unicode mapping script
> business in src/backend/utils/mb/Unicode/.
I never committed the last of these patches, which have the download
locations of the files. I have updated this a bit now and propose it
he
Hi all,
I have just been trapped by the fact that in some code paths we look
at the RMGR information of a WAL record (record->xl_info) but the
filter dedicated to it, ~XLR_INFO_MASK, is not applied. This is
harmful now, but this could lead to problems if in the future new
record-level flags, simil
On Fri, Oct 28, 2016 at 2:52 AM, Robert Haas wrote:
> On Mon, Oct 24, 2016 at 10:30 AM, Amit Kapila wrote:
>>> Amit, can you please split the buffer manager changes in this patch
>>> into a separate patch?
>>
>> Sure, attached patch extend_bufmgr_api_for_hash_index_v1.patch does that.
>
> The add
On 10/27/16 11:49 PM, Peter Eisentraut wrote:
> Here is a patch to refactor some of the I/O functions in pseudotypes.c
> to save redundant code and reduce the number of distinct translatable
> strings.
And here is the actual patch.
--
Peter Eisentraut http://www.2ndQuadrant.com/
Po
On Thu, 27 Oct 2016 19:03:11 +0200
Gilles Darold wrote:
> The current v8 of the patch
Perhaps instead of the define CURRENT_LOG_FILENAME
a better name for the symbol would be LOG_METAINFO_FILE?
Regards,
Karl
Free Software: "You don't pay back, you pay forward."
-- Robert A.
Here is a patch to refactor some of the I/O functions in pseudotypes.c
to save redundant code and reduce the number of distinct translatable
strings.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via p
On Thu, 27 Oct 2016 22:09:41 -0500
"Karl O. Pinc" wrote:
> On Thu, 27 Oct 2016 19:03:11 +0200
> Gilles Darold wrote:
>
> > The current v8 of the patch
>
> For your consideration.
>
> Attached is a patch to apply to v8 of your patch.
>
> I moved the call to logfile_writename() in write_syslogg
Hi Gilles,
On Thu, 27 Oct 2016 19:03:11 +0200
Gilles Darold wrote:
> The current v8 of the patch
For your consideration.
Attached is a patch to apply to v8 of your patch.
I moved the call to logfile_writename() in write_syslogger_file()
into the open_csvlogfile(). That's where the new filena
On Thu, 27 Oct 2016 19:03:11 +0200
Gilles Darold wrote:
> The current v8 of the patch
Attached is a patch to the v8 version of your patch.
It rewords some of the comments in the code. Take the hunks
or leave them as you wish.
Regards,
Karl
Free Software: "You don't pay back, you pay forwa
On 10/27/16 1:27 PM, Jim Nasby wrote:
> Well, that got me closer, but it's still blowing up on libpq:
>
> genhtml: ERROR: no valid records found in tracefile
> ./src/interfaces/libpq/lcov.info
I have seen similar problems when I use a gcov that does not match the gcc.
I was able to run it succe
Currently, initdb parses locale -a output to populate pg_collation. If
additional collations are installed in the operating system, it is not
possible to repeat this process, only by doing each step manually. So I
propose to move this to a backend function that can be called
separately, and have
From: Ashutosh Bapat [mailto:ashutosh.ba...@enterprisedb.com]
> Ok. In that case, I think we shouldn't even call PG_SETMASK() similar to
> pgarch_exit(). Attached patch removes PG_SETMASK(). Let me know if it looks
> good.
It looks good. Thanks.
Regards
Takayuki Tsunakawa
--
Sent via pgsql-ha
On Fri, Oct 28, 2016 at 5:15 AM, Jim Nasby wrote:
> On 10/27/16 6:39 AM, Mithun Cy wrote:
>>
>> # pg_autoprewarm.
>
>
> IMO it would be better to add this functionality to pg_prewarm instead of
> creating another contrib module. That would reduce confusion and reduce the
> amount of code necessary
From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas
> The delay is intentional. Per pgstat_start():
It's kind of you to tell the reason.
> Committed and back-patched all the way.
Thanks again!
Regards
Takayuki Tsunakawa
--
Sent vi
From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Mithun Cy
> # pg_autoprewarm.
>
> This a PostgreSQL contrib module which automatically dump all of the
> blocknums present in buffer pool at the time of server shutdown(smart and
> fast mode only, t
On Wed, Oct 19, 2016 at 11:33 AM, Peter Geoghegan wrote:
> I don't think that eager merging will prove all that effective,
> however it's implemented. I see a very I/O bound system when parallel
> CREATE INDEX merges serially. There is no obvious reason why you'd
> have a straggler worker process
On Thu, Oct 27, 2016 at 9:53 PM, Merlin Moncure wrote:
> I think we can rule out faulty storage
Nobody ever expects the faulty storage
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsq
On Fri, Oct 28, 2016 at 1:16 AM, Robert Haas wrote:
> On Thu, Oct 27, 2016 at 9:05 AM, Michael Paquier
> wrote:
>> On Thu, Oct 27, 2016 at 7:16 PM, Amit Kapila wrote:
>>> This can create problem if the checkpoint record spans across multiple
>>> segments, because you are updating minRecoveryPoin
On Thu, 27 Oct 2016 16:18:02 -0500
"Karl O. Pinc" wrote:
> On Thu, 27 Oct 2016 19:03:11 +0200
> Gilles Darold wrote:
>
> > The current v8 of the patch
>
> Attached is a doc patch for your v8 patch.
>
> Added , so the docs would build.
>
> Added markup of "system values".
Drat. The attached
On Mon, Oct 24, 2016 at 10:30 AM, Amit Kapila wrote:
>> Amit, can you please split the buffer manager changes in this patch
>> into a separate patch?
>
> Sure, attached patch extend_bufmgr_api_for_hash_index_v1.patch does that.
The additional argument to ConditionalLockBuffer() doesn't seem to be
On 10/27/16 12:27 PM, Jim Nasby wrote:
I've attached a build log if anyone wants to take a look...
BTW, while the log shows Apple's make in use I also tried with gmake out
of macports with the same results.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics,
On Thu, 27 Oct 2016 19:03:11 +0200
Gilles Darold wrote:
> The current v8 of the patch
Attached is a doc patch for your v8 patch.
Added , so the docs would build.
Added markup of "system values".
Hope to look at code soon!
Karl
Free Software: "You don't pay back, you pay forward."
On Thu, 27 Oct 2016 19:57:18 +0200
Christoph Berg wrote:
> Re: Karl O. Pinc 2016-10-27 <20161027121141.6bd95...@slate.meme.com>
> > SELECT * from postgres.pg_current_logfile;
> We were discussing exactly that idea upthread before concluding that a
> function with a single return value is much ea
Greg Stark wrote:
> The fundamental problem is that the pga_hba.conf file has some bits of
> complex structure that aren't easily captured by linear arrays. The
> problem I struggled with most was the keywords like "all", "samerole",
> and "replication". A simple array of text makes it awkward to
On Tue, Oct 4, 2016 at 3:12 PM, Thomas Munro
wrote:
> On Mon, Aug 15, 2016 at 5:58 PM, Thomas Munro
> wrote:
>> Please find attached a -v2 of your patch which includes suggestions
>> 1-3 above.
>
> Here's a rebased patch. ConditionVariableSleep now takes
> wait_event_info. Anyone using this in
On 10/27/16 6:39 AM, Mithun Cy wrote:
# pg_autoprewarm.
IMO it would be better to add this functionality to pg_prewarm instead
of creating another contrib module. That would reduce confusion and
reduce the amount of code necessary.
+ cmp_member_elem(database);
+ cmp_member_elem(
On 25 October 2016 at 22:58, Tom Lane wrote:
> The alternative I'm now thinking about pursuing is to get rid of the
> conversion of RLS quals to subqueries. Instead, we can label individual
> qual clauses with security precedence markings. Concretely, suppose we
> add an "int security_level" fie
On Wed, Oct 26, 2016 at 8:41 AM, Kuntal Ghosh
wrote:
> On Wed, Oct 26, 2016 at 4:47 PM, Michael Paquier
> wrote:
>>
>> If you test on a master node that would be the same: there is a delay
>> until the stats process restart. I have not looked at the code closely
>> enough in this area (reaper()?)
On Thu, Oct 27, 2016 at 2:31 AM, Ants Aasma wrote:
> On Wed, Oct 26, 2016 at 8:43 PM, Merlin Moncure wrote:
>> /var/lib/pgsql/9.5/data/pg_log/postgresql-26.log | grep "page
>> verification"
>> 2016-10-26 11:26:42 CDT [postgres@castaging]: WARNING: page
>> verification failed, calculated checksum
On Wed, Oct 26, 2016 at 2:00 AM, Masahiko Sawada wrote:
> I think we can consider the atomic commit and the atomic visibility
> separately, and the atomic visibility can build on the top of the
> atomic commit.
It is true that we can do that, but I'm not sure whether it's the best design.
--
Ro
On Fri, Oct 21, 2016 at 1:38 AM, Ashutosh Bapat
wrote:
> Once we have that information, the foreign server can actively poll
> the local server to get the status of transaction xid and resolves the
> prepared transaction itself. It can go a step further and inform the
> local server that it has re
Re: Gilles Darold 2016-10-27
> > I'm partial to "format path" over just line number, because
> > it's more explicit. Either way works.
>
> This is the format used. Ex:
>
> ~$ cat /usr/local/postgresql/data/current_logfile
> stderr pg_log/postgresql-2016-10-27_185100.log
> csvlog pg_log/postgre
On Thu, Oct 27, 2016 at 12:24 PM, Joshua D. Drake
wrote:
> This problem clearly an improper implementation on our part. We have found a
> work around by wrapping the launch of psql so we can set PSQLRC. At some
> point, perhaps with v10 we could change this. This problem has been noted on
> other
On Thu, Oct 27, 2016 at 9:46 AM, Mithun Cy wrote:
> On Wed, Oct 26, 2016 at 8:49 PM, Robert Haas wrote:
>> Let me know your thoughts.
>
> One small issue. I tried to run make installcheck after applying patch there
> seems to be a invalid write access in code (resulting in crash).
>
> ==118997==
On Thu, 27 Oct 2016 19:03:11 +0200
Gilles Darold wrote:
> >> Re: Karl O. Pinc 2016-10-27
> >> <20161026222513.74cd3...@slate.meme.com>
> > Your comment makes me wonder if pg_current_logfile(), without
> > arguments, should instead be "SHOW current_logfile;".
> -1, SHOW is used to display run-
Le 27/10/2016 à 14:14, Karl O. Pinc a écrit :
> On Thu, 27 Oct 2016 11:07:43 +0200
> Christoph Berg wrote:
>
>> Re: Karl O. Pinc 2016-10-27 <20161026222513.74cd3...@slate.meme.com>
>>> But what if current_logfile contains only a single line? What
>>> sort of file format does the logfile have? If
On 10/26/2016 12:10 PM, Joshua D. Drake wrote:
On 10/26/2016 11:33 AM, Robert Haas wrote:
On Wed, Oct 26, 2016 at 2:22 PM, Joshua D. Drake
It is also inconsistent with how other programs behave. For example
if psql
uses readline, and you change the value of $HOME, then readline uses
$HOME/.in
On Thu, Oct 27, 2016 at 9:05 AM, Michael Paquier
wrote:
> On Thu, Oct 27, 2016 at 7:16 PM, Amit Kapila wrote:
>> This can create problem if the checkpoint record spans across multiple
>> segments, because you are updating minRecoveryPoint to start of
>> checkpoint record. We need to update it to
On Wed, Oct 26, 2016 at 9:33 PM, Peter Geoghegan wrote:
> Besides, parallel CREATE INDEX alone will probably
> be quite effective at speeding up CLUSTER in practice, simply because
> that's often where most wall clock time is spent during a CLUSTER
> operation.
Creating all indexes in parallel co
On Wed, Oct 26, 2016 at 8:49 PM, Robert Haas wrote:
> Let me know your thoughts.
One small issue. I tried to run make installcheck after applying patch
there seems to be a invalid write access in code (resulting in crash).
==118997== Invalid write of size 1
==118997==at 0x4E3DDF1: connectOpt
On Thu, Oct 27, 2016 at 7:16 PM, Amit Kapila wrote:
> This can create problem if the checkpoint record spans across multiple
> segments, because you are updating minRecoveryPoint to start of
> checkpoint record. We need to update it to end+1 of checkpoint
> record. Please find attached patch whi
I would suggest that the struct gets the value (from option, environment or
default) and is always used elsewhere. The getPgPassFilename function
should disappear and PasswordFromFile should be simplified significantly.
I agree, however that's easier said than done because the "default" is onl
On Thu, Oct 27, 2016 at 5:14 PM, Amit Kapila wrote:
>>> Thanks Tomas and Dilip for doing detailed performance tests for this
>>> patch. I would like to summarise the performance testing results.
>>>
>>> 1. With update intensive workload, we are seeing gains from 23%~192%
>>> at client count >=64
On Thu, 27 Oct 2016 11:07:43 +0200
Christoph Berg wrote:
> Re: Karl O. Pinc 2016-10-27 <20161026222513.74cd3...@slate.meme.com>
> > But what if current_logfile contains only a single line? What
> > sort of file format does the logfile have? If you don't know
> > you can't process the logfile c
On 2016/10/27 18:06, Ashutosh Bapat wrote:
On Thu, Oct 27, 2016 at 12:46 PM, Etsuro Fujita
wrote:
On 2016/10/26 19:53, Ashutosh Bapat wrote:
On Wed, Oct 26, 2016 at 3:35 PM, Etsuro Fujita
My concern about your proposal is: it might not be worth complicating the
code to solve a problem that
On Thu, Oct 27, 2016 at 5:09 PM, Mithun Cy
wrote:
> This a PostgreSQL contrib module which automatically dump all of the
blocknums
>present in buffer pool at the time of server shutdown(smart and fast mode
only,
>to be enhanced to dump at regular interval.) and load these blocks when
server res
On Thu, Oct 27, 2016 at 4:15 AM, Tomas Vondra
wrote:
> On 10/25/2016 06:10 AM, Amit Kapila wrote:
>>
>> On Mon, Oct 24, 2016 at 2:48 PM, Dilip Kumar
>> wrote:
>>>
>>> On Fri, Oct 21, 2016 at 7:57 AM, Dilip Kumar
>>> wrote:
On Thu, Oct 20, 2016 at 9:03 PM, Tomas Vondra
wrote:
# pg_autoprewarm.
This a PostgreSQL contrib module which automatically dump all of the
blocknums
present in buffer pool at the time of server shutdown(smart and fast mode
only,
to be enhanced to dump at regular interval.) and load these blocks when
server restarts.
Design:
--
We have created
On Thu, Oct 27, 2016 at 9:51 AM, Michael Paquier
wrote:
> On Thu, Oct 27, 2016 at 2:59 AM, Robert Haas wrote:
>> On Wed, Oct 26, 2016 at 2:06 AM, Michael Paquier
>> wrote:
>>> But yes, thinking *harder*, I agree that updating minRecoveryPoint
>>> just after the checkpoint record would be fine an
Please find attached latest patch which fix the review point as well as
additional clean-up.
- Get rid of funnel_slot as its not needed for the Gather Merge
- renamed fill_tuple_array to form_tuple_array
- Fix possible infinite loop into gather_merge_init (Reported by Amit
Kaplia)
- Fix tqueue.c m
Re: Karl O. Pinc 2016-10-27 <20161026222513.74cd3...@slate.meme.com>
> Since it now can contain multiple pathnames perhaps the name of the
> file should be "current_logfiles"? Seems more descriptive.
Not sure about that, most often it would contain one logfile only, and
catering for that seems fa
On Thu, Oct 27, 2016 at 12:46 PM, Etsuro Fujita
wrote:
> On 2016/10/26 19:53, Ashutosh Bapat wrote:
>>
>> On Wed, Oct 26, 2016 at 3:35 PM, Etsuro Fujita
>> wrote:
>
>
>>> In practice, the search cost would be negligible compared to the cost of
>>> explaining/executing the query.
>>>
>>> My concer
On Thu, Oct 27, 2016 at 7:29 AM, Tsunakawa, Takayuki
wrote:
> From: pgsql-hackers-ow...@postgresql.org
>> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Ashutosh Bapat
>> In pgstat_quickdie(), I think a call to sigaddset(&BlockSig, SIGQUIT) is
>> missing before PG_SETMASK(). Although the
On Thu, Sep 29, 2016 at 12:49 PM, Michael Paquier
wrote:
> Seeing nothing happening, I have moved the patch to next CF as there
> is a new version, but no reviews for it.
Just a note for anybody potentially looking at this patch. I am
currently looking at it in depth, and will post a new version
On Wed, Oct 26, 2016 at 8:43 PM, Merlin Moncure wrote:
> /var/lib/pgsql/9.5/data/pg_log/postgresql-26.log | grep "page
> verification"
> 2016-10-26 11:26:42 CDT [postgres@castaging]: WARNING: page
> verification failed, calculated checksum 37251 but expected 37244
> 2016-10-26 11:27:55 CDT [postg
On 2016/10/26 19:53, Ashutosh Bapat wrote:
On Wed, Oct 26, 2016 at 3:35 PM, Etsuro Fujita
wrote:
In practice, the search cost would be negligible compared to the cost of
explaining/executing the query.
My concern about your proposal is: it might not be worth complicating the
code to solve a
62 matches
Mail list logo
