On Sun, Jun 28, 2015 at 5:52 PM, Sawada Masahiko sawada.m...@gmail.com wrote:
On Fri, Jun 26, 2015 at 2:46 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Thu, Jun 25, 2015 at 8:32 PM, Simon Riggs wrote:
Let's start with a complex, fully described use case then work out how to
Hi,
On 06/28/2015 09:04 AM, Fabien COELHO wrote:
2. The general difficulty of getting psql var values into a DO
block (currently I use temp tables).
Maybe this means that DO should be extended in some way to allow for
parameters, at least when PL/pgSQL is used?
I agree with this
Hi,
On 06/28/2015 02:21 PM, Pavel Stehule wrote:
2015-06-28 14:12 GMT+02:00 Tomas Vondra
tomas.von...@2ndquadrant.com mailto:tomas.von...@2ndquadrant.com:
This proposal is not against to DO parametrization. It is same like
conditional block in C (#ifdef). There is similarity with C
statements
2015-06-28 14:12 GMT+02:00 Tomas Vondra tomas.von...@2ndquadrant.com:
Hi,
On 06/28/2015 09:04 AM, Fabien COELHO wrote:
2. The general difficulty of getting psql var values into a DO
block (currently I use temp tables).
Maybe this means that DO should be extended in some way to allow
Hi,
On 06/28/2015 08:47 AM, Corey Huinker wrote:
5. I'm actually using psql to connect to redshift, which doesn't have DO
blocks at all.
I don't see this as a reason to add features to psql, unless there are
other compelling reasons for the addition.
--
Tomas Vondra
2015-06-28 14:26 GMT+02:00 Tomas Vondra tomas.von...@2ndquadrant.com:
Hi,
On 06/28/2015 08:01 AM, Pavel Stehule wrote:
you can use PL/pgSQL - but there are some limits
* maintenance large plpgsql functions
* the plpgsql functions or anonymous functions create a transaction
borders -
On Sat, Jun 27, 2015 at 11:38 AM, Andres Freund and...@anarazel.de wrote:
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
Hi,
On 06/28/2015 08:01 AM, Pavel Stehule wrote:
you can use PL/pgSQL - but there are some limits
* maintenance large plpgsql functions
* the plpgsql functions or anonymous functions create a transaction
borders - what should not be wanted
But why is that a problem? Generally
Hi,
On 06/28/2015 08:10 AM, Fabien COELHO wrote:
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,
\if_ver_eq 9.2
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
* maintenance large plpgsql functions
I agree with large but that would not necessarily mean complex. Also, some
functions could
2015-06-28 8:59 GMT+02:00 Fabien COELHO coe...@cri.ensmp.fr:
\if_ver_eq 9.2
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
* maintenance large plpgsql functions
I agree with large but
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
On Sun, Jun 28, 2015 at 12:47 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Jun 26, 2015 at 4:02 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Combining this with my idea about preserving the ConfigVariable list,
I'm thinking that it would be a good idea for
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
2. The general difficulty of getting psql var values into a DO block
(currently I use temp tables).
Maybe this means that DO should be extended in some way to allow for
parameters, at least when PL/pgSQL is used?
--
Fabien.
--
Sent via pgsql-hackers mailing list
2015-06-28 7:49 GMT+02:00 Fabien COELHO coe...@cri.ensmp.fr:
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
*
Hello again Pavel,
Note that I'm not against cpp-like features on principle, I did macros for
apache configurations a very long time ago, and that I only give my 0.02€
on this, for what's the € is worth these days:-)
you can use parameters for functions, but you cannot it for DO statement
On Fri, Jun 26, 2015 at 2:46 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Thu, Jun 25, 2015 at 8:32 PM, Simon Riggs wrote:
Let's start with a complex, fully described use case then work out how to
specify what we want.
Well, one of the most simple cases where quorum commit and
2015-06-28 8:47 GMT+02:00 Corey Huinker corey.huin...@gmail.com:
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
Hi,
On 06/28/2015 02:50 PM, Pavel Stehule wrote:
bI don't propose psql scripting./b
I propose simple statement for conditional statement execution. The
core of my proposal are commands
That's a matter of opinion, I guess ...
While you may propose only two simple conditional statements at
Sawada Masahiko sawada.m...@gmail.com writes:
On Sun, Jun 28, 2015 at 12:47 AM, Tom Lane t...@sss.pgh.pa.us wrote:
However there's a further tweak to the view that I'd like to think about
making. Once this is in and we make the originally-discussed change to
suppress application of duplicated
I wrote:
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.
...
More or less bad alternative answers include:
...
3. Force a
Peter Geoghegan p...@heroku.com writes:
On Sat, Jun 27, 2015 at 7:14 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I think the point of Noah's query is to find out whether ancient is an
accurate description.
You said it yourself at the time -- why trust the strxfrm()
implementation when a NULL
On Mon, Jun 29, 2015 at 12:01 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Sawada Masahiko sawada.m...@gmail.com writes:
On Sun, Jun 28, 2015 at 12:47 AM, Tom Lane t...@sss.pgh.pa.us wrote:
However there's a further tweak to the view that I'd like to think about
making. Once this is in and we make
Simon Riggs si...@2ndquadrant.com writes:
On 27 June 2015 at 15:10, Tom Lane t...@sss.pgh.pa.us wrote:
I don't like this too much because it will fail badly if the caller
is wrong about the maximum possible page number for the table, which
seems not exactly far-fetched. (For instance,
On Sunday, June 28, 2015, Pavel Stehule pavel.steh...@gmail.com wrote:
2015-06-28 14:26 GMT+02:00 Tomas Vondra tomas.von...@2ndquadrant.com
javascript:_e(%7B%7D,'cvml','tomas.von...@2ndquadrant.com');:
Hi,
On 06/28/2015 08:01 AM, Pavel Stehule wrote:
you can use PL/pgSQL - but there
On 06/27/2015 10:10 AM, Tom Lane wrote:
It also
offers no hope of a fix for the other operations that scan the whole
buffer pool, such as DROP TABLESPACE and DROP DATABASE.
Improving DROP TABLE / TRUNCATE would still be a significant advance.
These cases cause far more real world pain than
Amit Kapila amit.kapil...@gmail.com writes:
On Sat, Jun 27, 2015 at 7:40 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I don't like this too much because it will fail badly if the caller
is wrong about the maximum possible page number for the table, which
seems not exactly far-fetched. (For
On 2015-06-28 09:11:29 -0400, Robert Haas wrote:
On Sat, Jun 27, 2015 at 11:38 AM, Andres Freund and...@anarazel.de wrote:
I've started to play around with doing that a year or three back. My
approach was to use a linux style radix tree for the buffer mapping
table. Besides lack of time
Sawada Masahiko sawada.m...@gmail.com writes:
On Mon, Jun 29, 2015 at 12:01 AM, Tom Lane t...@sss.pgh.pa.us wrote:
er ... what?
Sorry for confusing you.
Anyway I meant that I got SEGV after applied WIP patch, and the cause
is the above changes.
The case is following.
1. Add port = 6543 to
On 27 June 2015 at 15:10, Tom Lane t...@sss.pgh.pa.us wrote:
Amit Kapila amit.kapil...@gmail.com 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
2015-06-28 10:46 GMT+02:00 Fabien COELHO coe...@cri.ensmp.fr:
Hello again Pavel,
Note that I'm not against cpp-like features on principle, I did macros for
apache configurations a very long time ago, and that I only give my 0.02€
on this, for what's the € is worth these days:-)
you can
On 06/26/2015 10:10 PM, Andres Freund wrote:
On 2015-06-26 15:07:59 -0400, Robert Haas wrote:
I realize that the recent fsync fiasco demonstrated that people keep
files not readable by PG in the data directory
It wasn't unreadable files that were the primary problem, it was files
with read
On 06/28/2015 12:29 PM, Peter Geoghegan wrote:
It might have been the right decision at the time to paper over the
problem, but only for a year or two. I'd only favor adding defenses if
it could be expected to take longer for the Solaris stdlib people to
ship a fix for their egregious bug than
I implemented \foreach five years ago, and this is not simple to
implement statement - so don't propose it. I wouldn't to inject full
scripting language to psql. Then it is better to use bash, perl, python.
But well designed conditional statements needs only few lines for
implementation,
On 06/26/2015 02:08 PM, Heikki Linnakangas wrote:
I'm not sure what to do about this. With the attached patch, you get the
same leisurely pacing with restartpoints as you get with checkpoints,
but you exceed max_wal_size during recovery, by the amount determined by
checkpoint_completion_target.
I do not think that this large file is a so big a problem (good
editors help navigation in the code), and I'm not sure that splitting
it would achieve much: there are not that many functions, some of
them are maybe long (main, threadRun, doCustom) but mostly for good
reasons.
My thoughts,
On 06/28/15 18:56, Tatsuo Ishii wrote:
I do not think that this large file is a so big a problem (good
editors help navigation in the code), and I'm not sure that splitting
it would achieve much: there are not that many functions, some of
them are maybe long (main, threadRun, doCustom) but
This is kind of surprising to me that two people are against
refactoring proposal (I understand that Fabien has pending patches for
pgbench and that could be a motivation for this though).
I think that's a misunderstanding. I'm not against refactoring - not at all,
and neither is Fabien I
On 06/24/2015 09:43 AM, Michael Paquier wrote:
Attached is a new set of patches. Except for the last ones that
addresses one issue of pg_rewind (symlink management when streaming
PGDATA), all the others introduce if_not_exists options for the
functions of genfile.c. The pg_rewind stuff could be
On 06/28/2015 04:36 AM, Sawada Masahiko wrote:
On Sat, Jun 27, 2015 at 3:53 AM, Josh Berkus j...@agliodbs.com wrote:
On 06/26/2015 11:32 AM, Robert Haas wrote:
I think your proposal is worth considering, but you would need to fill
in a lot more details and explain how it works in detail,
On 06/26/2015 10:53 PM, Jeff Janes wrote:
On Fri, Jun 26, 2015 at 11:40 AM, Heikki Linnakangas hlinn...@iki.fi
wrote:
The page is being split (that's evident from info=48 above).
ginPlaceToPage calls GinNewBuffer, which calls GetFreeIndexPage(). That
finds a page that can be recycled, and
On Sun, Jun 28, 2015 at 8:31 AM, Tom Lane t...@sss.pgh.pa.us wrote:
The point here is to *find out*, rather than assuming. I agree that
Sun should have been embarrassed that such a bug ever made it into
a released libc, but it did. The question is how long did it take
them to notice and fix
Thomas Munro thomas.mu...@enterprisedb.com writes:
Just by the way, I wonder if this was that bug:
https://illumos.org/issues/1594
Oooh. Might or might not be *same* bug, but it sure looks like it could
have the right symptom. If this is indeed inherited from old Solaris,
I'm afraid we are
Peter Geoghegan p...@heroku.com writes:
It might have been the right decision at the time to paper over the
problem, but only for a year or two. I'd only favor adding defenses if
it could be expected to take longer for the Solaris stdlib people to
ship a fix for their egregious bug than it
On Sun, Jun 28, 2015 at 4:14 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The reason that bug is special is that it looks like a crash in
Postgres, one that people have complained of because they didn't see it
in other programs, which is not totally surprising because it requires
a somewhat unusual
On Sun, Jun 28, 2015 at 7:14 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Geoghegan p...@heroku.com writes:
It might have been the right decision at the time to paper over the
problem, but only for a year or two. I'd only favor adding defenses if
it could be expected to take longer for the
On Sun, Jun 28, 2015 at 4:35 PM, Robert Haas robertmh...@gmail.com wrote:
I completely agree. Noah is quite right to try to find out whether
this is still an issue, and I'm glad he's doing it, and I think it's
very unfortunate that Peter is trying to discourage that research.
Far from it. I
On Sun, Jun 28, 2015 at 7:27 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'd hoped that commit 1b468a131bd260c9041484f78b8580c7f232d580 would
resolve this, but nope, anole is still getting occasional stuck spinlocks:
Robert Haas robertmh...@gmail.com writes:
That sucks. It was easy to see that the old fallback barrier
implementation wasn't re-entrant, but this one should be. And now
that I look at it again, doesn't the failure message indicate that's
not the problem anyway?
! PANIC: stuck spinlock
On Mon, Jun 29, 2015 at 7:58 AM, Josh Berkus j...@agliodbs.com wrote:
My perspective is that if both SmartOS and OmniOS pass, it's not our
responsibility to support OldSolaris if they won't update libraries.
Just by the way, I wonder if this was that bug:
https://illumos.org/issues/1594
--
On Sun, Jun 28, 2015 at 12:31 PM, Heikki Linnakangas hlinn...@iki.fi
wrote:
On 06/26/2015 10:53 PM, Jeff Janes wrote:
On Fri, Jun 26, 2015 at 11:40 AM, Heikki Linnakangas hlinn...@iki.fi
wrote:
The page is being split (that's evident from info=48 above).
ginPlaceToPage calls GinNewBuffer,
On Sun, Jun 28, 2015 at 12:58 PM, Josh Berkus j...@agliodbs.com wrote:
My perspective is that if both SmartOS and OmniOS pass, it's not our
responsibility to support OldSolaris if they won't update libraries.
Obviously I especially don't want to double the number of strxfrm()
calls made during
Peter Geoghegan p...@heroku.com writes:
On Sun, Jun 28, 2015 at 12:58 PM, Josh Berkus j...@agliodbs.com wrote:
My perspective is that if both SmartOS and OmniOS pass, it's not our
responsibility to support OldSolaris if they won't update libraries.
Obviously I especially don't want to double
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Alvaro Herrera wrote:
Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
Uh. I'm pretty sure there were some back when that patch went in. And
there definitely used to be a couple earlier. I guess itanium really is
dying (mixed bad: It's
On Mon, Jun 29, 2015 at 10:57 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Thomas Munro thomas.mu...@enterprisedb.com writes:
Just by the way, I wonder if this was that bug:
https://illumos.org/issues/1594
Oooh. Might or might not be *same* bug, but it sure looks like it could
have the right
On Sun, Jun 28, 2015 at 9:05 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Amit Kapila amit.kapil...@gmail.com writes:
On Sat, Jun 27, 2015 at 7:40 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I don't like this too much because it will fail badly if the caller
is wrong about the maximum possible page
On Sat, Jun 27, 2015 at 5:10 PM, Tatsuo Ishii is...@postgresql.org wrote:
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
On Sun, Jun 28, 2015 at 9:47 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
On 27 June 2015 at 15:10, Tom Lane t...@sss.pgh.pa.us wrote:
I don't like this too much because it will fail badly if the caller
is wrong about the maximum possible page number for
On Sun, Jun 28, 2015 at 4:35 PM, Peter Geoghegan p...@heroku.com wrote:
It hardly matters much, but I don't think that it is. I think the
issue is entirely explained by sloppy code in the Solaris 8 stdlib.
I don't imagine that it will come as a surprise to anybody, but the
manpage [1] for
On Sun, Jun 28, 2015 at 12:17 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm not sure what you consider dire, but missing a dirty buffer
belonging to the to-be-destroyed table would result in the system being
permanently unable to checkpoint, because attempts to write out the buffer
to the
On Sun, Jun 28, 2015 at 9:17 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
That sucks. It was easy to see that the old fallback barrier
implementation wasn't re-entrant, but this one should be. And now
that I look at it again, doesn't the failure message
Hi,
How about the attached that adjusts errorcode for the error related to
checking the flag bgw_flags in BackgroundWorkerInitializeConnection*()
functions so that it matches the treatment in SanityCheckBackgroundWorker()?
s/ERRCODE_PROGRAM_LIMIT_EXCEEDED/ERRCODE_INVALID_PARAMETER_VALUE/g
There
On 2015-06-29 AM 11:36, Amit Langote wrote:
Hi,
How about the attached that adjusts errorcode for the error related to
checking the flag bgw_flags in BackgroundWorkerInitializeConnection*()
functions so that it matches the treatment in SanityCheckBackgroundWorker()?
2015-06-28 22:43 GMT+02:00 Corey Huinker corey.huin...@gmail.com:
I implemented \foreach five years ago, and this is not simple to
implement statement - so don't propose it. I wouldn't to inject full
scripting language to psql. Then it is better to use bash, perl, python.
But well designed
On Mon, Jun 29, 2015 at 12:20 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
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.
Robert Haas robertmh...@gmail.com writes:
What we did do that touched s_lock.h was attempt to ensure that
SpinLockAcquire() and SpinLockRelease() function as compiler barriers,
so that it should no longer be necessary to litter the code with
volatile in every function that uses those. It is
67 matches
Mail list logo
