On Sun, Jun 28, 2015 at 12:47 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Jun 26, 2015 at 4:02 PM, Tom Lane wrote:
>>> Combining this with my idea about preserving the ConfigVariable list,
>>> I'm thinking that it would be a good idea for ProcessConfigFile() to
>>> run in a context crea
I was just musing about this today, and was afraid that no one else would
want it!
This would be useful to me in the following use cases which I have right
now:
1. I have a SQL script that invokes \COPY into a temporary table or some
similar thing, preventing most of my logic from being pushed in
Hello Tatsuo,
Main pgbench logic consists of single file pgbench.c which is 4036 lines
of code as of today. This is not a small number and I think it would be
nice if it is divided into smaller files because it will make it easier
to maintain, add or change features of pgbench.
I do not thi
2015-06-28 7:49 GMT+02:00 Fabien COELHO :
>
> The proposed syntax of new psql commands
>> \if_ver_eq 9.2
>> ...
>> \else
>> \endif
>>
>
> What do you thinking about it?
>>
>
> Couldn't this kind of thing be done directly with PL/pgSQL?
>
you can use PL/pgSQL - but there are some limits
* maint
The proposed syntax of new psql commands
\if_ver_eq 9.2
...
\else
\endif
What do you thinking about it?
Couldn't this kind of thing be done directly with PL/pgSQL?
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http:
Hi
I am thinking about simplifying a deployment some multiversion PostgreSQL
extensions, and scripts.
With current possibilities, we have to use DO statement, what is not
optimal or possible in some use cases. The implementation of condition
block (possible nested) is very simple.
The proposed s
On Sat, Jun 27, 2015 at 7:19 PM, Tom Lane wrote:
>
> Amit Kapila writes:
> > On Fri, Jun 26, 2015 at 9:47 PM, Tom Lane wrote:
> >> What we evidently need to do is fix things so that the pg_file_settings
> >> data gets captured before we suppress duplicates.
> >>
> >> The simplest change would be
On Sat, Jun 27, 2015 at 8:06 PM, Gurjeet Singh wrote:
>
> On Fri, Jun 26, 2015 at 9:45 PM, Amit Kapila
wrote:
>>
>> Attached patch implements the above idea and I found that
>> performance doesn't dip much with patch even with large value
>> of shared_buffers. I have also attached script and sql
>> I'm just wondering why we did not catch this earlier. If this is
>> because threre's no regression test case for pg_file_settings view,
>
> Yeah, exactly. Unfortunately I see no way to add a useful test, at least
> not one that will work in installcheck mode. There's no way to predict
> what
On Sat, Jun 27, 2015 at 7:40 PM, Tom Lane wrote:
>
> Amit Kapila writes:
> > I have looked into it and found that the main reason for such
> > a behaviour is that for those operations it traverses whole
> > shared_buffers and it seems to me that we don't need that
> > especially for not-so-big ta
On Sat, Jun 27, 2015 at 7:14 PM, Tom Lane wrote:
> I think the point of Noah's query is to find out whether "ancient" is an
> accurate description. If indeed nothing newer than Solaris 8 exhibits
> the bug, I'd be okay with not working around it, but otherwise we have
> some decisions to make.
E
On Sun, Jun 28, 2015 at 10:40 AM, Tom Lane wrote:
> Michael Paquier writes:
>> On Sun, Jun 28, 2015 at 8:20 AM, Tom Lane wrote:
>>> Yeah, exactly. Unfortunately I see no way to add a useful test, at least
>>> not one that will work in installcheck mode. There's no way to predict
>>> what will
Peter Geoghegan writes:
> On Sat, Jun 27, 2015 at 9:51 AM, Noah Misch wrote:
>> PostgreSQL 9.5 adds a strxfrm() call in bttext_abbrev_convert(), which does
>> not account for the Solaris bug. I wish to determine whether that bug is
>> still relevant today. If you have access to Solaris with the
Michael Paquier writes:
> On Sun, Jun 28, 2015 at 8:20 AM, Tom Lane wrote:
>> Yeah, exactly. Unfortunately I see no way to add a useful test, at least
>> not one that will work in installcheck mode. There's no way to predict
>> what will be in the view in that case. Even for "make check", the
On Sun, Jun 28, 2015 at 8:20 AM, Tom Lane wrote:
> Tatsuo Ishii writes:
>>> I noticed that in EXEC_BACKEND builds (ie, Windows) the pg_file_settings
>>> view doesn't act as its author presumably intended. Specifically, it
>>> reads as empty until/unless the current session processes a SIGHUP eve
Main pgbench logic consists of single file pgbench.c which is 4036
lines of code as of today. This is not a small number and I think it
would be nice if it is divided into smaller files because it will make
it easier to maintain, add or change features of pgbench. I will come
up with an idea how t
Tatsuo Ishii writes:
>> I noticed that in EXEC_BACKEND builds (ie, Windows) the pg_file_settings
>> view doesn't act as its author presumably intended. Specifically, it
>> reads as empty until/unless the current session processes a SIGHUP event.
> I'm just wondering why we did not catch this ear
> I noticed that in EXEC_BACKEND builds (ie, Windows) the pg_file_settings
> view doesn't act as its author presumably intended. Specifically, it
> reads as empty until/unless the current session processes a SIGHUP event.
> This is because before that happens, it's depending on having inherited
>
This patch implements version 1.2 of contrib module pg_trgm.
This supports the triconsistent function, introduced in version 9.4 of the
server, to make it faster to implement indexed queries where some keys are
common and some are rare.
I've included the paths to both upgrade and downgrade betwee
27.06.2015, 19:51, Noah Misch kirjoitti:
> convert_string_datum() says:
>
> /*
>* Note: originally we guessed at a suitable output buffer
> size, and
>* only needed to call strxfrm twice if our guess was too small.
>* However, it seems
On Sat, Jun 27, 2015 at 9:51 AM, Noah Misch wrote:
> PostgreSQL 9.5 adds a strxfrm() call in bttext_abbrev_convert(), which does
> not account for the Solaris bug. I wish to determine whether that bug is
> still relevant today. If you have access to Solaris with the is_IS.ISO8859-1
> locale inst
convert_string_datum() says:
/*
* Note: originally we guessed at a suitable output buffer
size, and
* only needed to call strxfrm twice if our guess was too small.
* However, it seems that some versions of Solaris have buggy
strx
I noticed that in EXEC_BACKEND builds (ie, Windows) the pg_file_settings
view doesn't act as its author presumably intended. Specifically, it
reads as empty until/unless the current session processes a SIGHUP event.
This is because before that happens, it's depending on having inherited
the state
On 2015-06-27 12:10:49 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2015-06-27 15:07:05 +0900, Michael Paquier wrote:
> >> +1 for removing on master and just disabling on back-branches.
>
> > The problem with that approach is that it leaves people hanging in the
> > dry if they've uncomm
Andres Freund writes:
> On 2015-06-27 15:07:05 +0900, Michael Paquier wrote:
>> +1 for removing on master and just disabling on back-branches.
> The problem with that approach is that it leaves people hanging in the
> dry if they've uncommented the default value, or changed it. That
> doesn't see
On 2015-06-27 15:07:05 +0900, Michael Paquier wrote:
> On Sat, Jun 27, 2015 at 6:12 AM, Tom Lane wrote:
> > Andres Freund writes:
> >> On 2015-06-24 16:41:48 +0200, Andres Freund wrote:
> >>> I, by now, have come to a different conclusion. I think it's time to
> >>> entirely drop the renegotiatio
On 2015-06-26 14:48:35 -0300, Alvaro Herrera wrote:
> Andres Freund wrote:
>
> > Rework the way multixact truncations work.
>
> I spent some time this morning reviewing this patch and had some
> comments that I relayed over IM to Andres.
Thanks for that!
> 2. We set PGXACT->delayChkpt while
Robert Haas writes:
> On Fri, Jun 26, 2015 at 4:02 PM, Tom Lane wrote:
>> Combining this with my idea about preserving the ConfigVariable list,
>> I'm thinking that it would be a good idea for ProcessConfigFile() to
>> run in a context created for the purpose of processing the config files,
>> ra
On 2015-06-27 10:10:04 -0400, Tom Lane wrote:
> In the past we've speculated about fixing the performance of these things
> by complicating the buffer lookup mechanism enough so that it could do
> "find any page for this table/tablespace/database" efficiently.
> Nobody's had ideas that seemed sane
On Fri, Jun 26, 2015 at 9:45 PM, Amit Kapila
wrote:
> Sometime back on one of the PostgreSQL blog [1], there was
> discussion about the performance of drop/truncate table for
> large values of shared_buffers and it seems that as the value
> of shared_buffers increase the performance of drop/trunc
I happened to notice these in a backend's memory context dump:
ident parser context: 0 total in 0 blocks; 0 free (0 chunks); 0 used
hba parser context: 7168 total in 3 blocks; 3920 free (1 chunks); 3248 used
Is there a good reason why these weren't made children of the
PostmasterContext, so t
Amit Kapila writes:
> I have looked into it and found that the main reason for such
> a behaviour is that for those operations it traverses whole
> shared_buffers and it seems to me that we don't need that
> especially for not-so-big tables. We can optimize that path
> by looking into buff mappin
Amit Kapila writes:
> On Fri, Jun 26, 2015 at 9:47 PM, Tom Lane wrote:
>> What we evidently need to do is fix things so that the pg_file_settings
>> data gets captured before we suppress duplicates.
>>
>> The simplest change would be to move the whole thing to around line 208 in
>> guc-file.l, j
Fujita-san,
> > BTW, if you try newer version of postgres_fdw foreign join patch,
> > please provide me to reproduce the problem/
>
> OK
>
Did you forget to attach the patch, or v17 is in use?
> > I'd like to suggest a solution that re-construct remote tuple according
> > to the fdw_scan_tlist o
> On Thu, Jun 25, 2015 at 11:55 PM, Robert Haas wrote:
> > On Thu, Jun 25, 2015 at 6:25 PM, Kouhei Kaigai wrote:
> >> I have a serious open item reported 1.5 month ago then reminded
> >> several times has not been fixed up yet.
> >>
> >> 9a28c8860f777e439aa12e8aea7694f8010f3...@bpxm15gp.gisp.nec.
2015-06-26 17:28 GMT+02:00 Robert Haas :
> On Wed, Jun 24, 2015 at 7:39 PM, Jim Nasby
> wrote:
> >> I think it's a whole separate topicto Pavel's original proposal
> >> though, and really merits a separate thread. For Pavel's issue I'm all
> >> in favour of just changing the log message, I think
On Jun 27, 2015 8:07 AM, "Michael Paquier"
wrote:
>
> On Sat, Jun 27, 2015 at 6:12 AM, Tom Lane wrote:
> > Andres Freund writes:
> >> On 2015-06-24 16:41:48 +0200, Andres Freund wrote:
> >>> I, by now, have come to a different conclusion. I think it's time to
> >>> entirely drop the renegotiatio
37 matches
Mail list logo
