> 28 июня 2015 г., в 21:46, Heikki Linnakangas написал(а):
>
> 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_exis
On Mon, Jun 29, 2015 at 4:55 AM, Heikki Linnakangas wrote:
> After thinking about this some more, I think it'd be acceptable if we just
> fail, if there are any non-writeable files in the data directory. The
> typical scenario is that postgresql.conf, or an SSL cert file, is a symlink
> to outside
On Mon, Jun 29, 2015 at 3:46 AM, Heikki Linnakangas wrote:
> 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_exist
On Tue, May 26, 2015 at 12:37 PM, Jeff Janes wrote:
> On Mon, Apr 20, 2015 at 10:18 AM, Jim Nasby
> wrote:
>
>> On 4/20/15 1:50 AM, Jeff Janes wrote:
>>
>>>
>>> For that matter, why do we scan backwards anyway? The comments don't
>>> explain it, and we have nonempty_pages as a starting
Robert Haas 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 possible that
> t
On Mon, Jun 29, 2015 at 12:20 AM, Tom Lane 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.
>> ...
>> M
2015-06-28 22:43 GMT+02:00 Corey Huinker :
>
>> 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
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()?
>
> s/ERRCODE_PROGRA
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 Sun, Jun 28, 2015 at 9:17 PM, Tom Lane wrote:
> Robert Haas 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
On Sun, Jun 28, 2015 at 12:17 PM, Tom Lane 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 no-longer-extant fil
On Sun, Jun 28, 2015 at 4:35 PM, Peter Geoghegan 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 strxfrm() covering
Robert Haas 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 (cd6f4140) d
On Sun, Jun 28, 2015 at 9:10 PM, Robert Haas wrote:
> On Sun, Jun 28, 2015 at 7:27 PM, Tom Lane wrote:
>> I'd hoped that commit 1b468a131bd260c9041484f78b8580c7f232d580 would
>> resolve this, but nope, anole is still getting occasional stuck spinlocks:
>> http://buildfarm.postgresql.org/cgi-bin/s
On Sun, Jun 28, 2015 at 7:27 PM, Tom Lane wrote:
> I'd hoped that commit 1b468a131bd260c9041484f78b8580c7f232d580 would
> resolve this, but nope, anole is still getting occasional stuck spinlocks:
> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=anole&dt=2015-06-28%2021%3A35%3A02
That suc
On Sun, Jun 28, 2015 at 9:47 PM, Tom Lane wrote:
>
> Simon Riggs writes:
> > On 27 June 2015 at 15:10, Tom Lane 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-fet
On Sat, Jun 27, 2015 at 5:10 PM, Tatsuo Ishii 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 maintain, add or
On Sun, Jun 28, 2015 at 9:05 PM, Tom Lane wrote:
>
> Amit Kapila writes:
> > On Sat, Jun 27, 2015 at 7:40 PM, Tom Lane 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
On Sun, Jun 28, 2015 at 4:35 PM, Robert Haas 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 am providing constru
On Mon, Jun 29, 2015 at 10:57 AM, Tom Lane wrote:
> Thomas Munro 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 o
On Sun, Jun 28, 2015 at 7:14 PM, Tom Lane wrote:
> Peter Geoghegan 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
>> sh
On Sun, Jun 28, 2015 at 4:14 PM, Tom Lane 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 usage of strx
Alvaro Herrera writes:
> Alvaro Herrera wrote:
>> Tom Lane wrote:
>>> Andres Freund 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 a horrible architecture,
Peter Geoghegan 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 would take for
Peter Geoghegan writes:
> On Sun, Jun 28, 2015 at 12:58 PM, Josh Berkus 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()
> c
Thomas Munro 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 totally fooling ourselves if w
On Sun, Jun 28, 2015 at 12:58 PM, Josh Berkus 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 text abbreviatio
On Sun, Jun 28, 2015 at 12:31 PM, Heikki Linnakangas
wrote:
> On 06/26/2015 10:53 PM, Jeff Janes wrote:
>
>> On Fri, Jun 26, 2015 at 11:40 AM, Heikki Linnakangas
>> wrote:
>>
>> The page is being split (that's evident from "info=48" above).
>>> ginPlaceToPage calls GinNewBuffer, which calls Get
On Mon, Jun 29, 2015 at 7:58 AM, Josh Berkus 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
--
Thomas Munro
http
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. A
>
>
> 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
> implement
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 t
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 onl
On 06/26/2015 10:53 PM, Jeff Janes wrote:
On Fri, Jun 26, 2015 at 11:40 AM, Heikki Linnakangas
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 marks it as used.
On Sun, Jun 28, 2015 at 8:31 AM, Tom Lane 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 it. Assuming t
On 06/28/2015 04:36 AM, Sawada Masahiko wrote:
> On Sat, Jun 27, 2015 at 3:53 AM, Josh Berkus 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, rather than
>>
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 m
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 be
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 mostly
>> 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
Simon Riggs writes:
> On 27 June 2015 at 15:10, Tom Lane 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, remember those kernel bugs
>> we've seen
On 27 June 2015 at 15:10, 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 tables. W
Sawada Masahiko writes:
> On Mon, Jun 29, 2015 at 12:01 AM, Tom Lane 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 postgresql.conf and restart se
On Mon, Jun 29, 2015 at 12:01 AM, Tom Lane wrote:
> Sawada Masahiko writes:
>> On Sun, Jun 28, 2015 at 12:47 AM, Tom Lane 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 a
Amit Kapila writes:
> On Sat, Jun 27, 2015 at 7:40 PM, Tom Lane 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, remember those kernel bugs
>> we'
Peter Geoghegan writes:
> 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.
> You said it yourself at the time -- why trust the strxfrm()
> implementation when a NULL pointer is passed? It may hav
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. Fo
Sawada Masahiko writes:
> On Sun, Jun 28, 2015 at 12:47 AM, Tom Lane 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 GUC entries, it would be possibl
Hi,
On 06/28/2015 02:50 PM, Pavel Stehule wrote:
I don't propose psql scripting.
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 the
On 2015-06-28 09:11:29 -0400, Robert Haas wrote:
> On Sat, Jun 27, 2015 at 11:38 AM, Andres Freund 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 what made it h
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 t
On Sunday, June 28, 2015, Pavel Stehule wrote:
>
>
> 2015-06-28 14:26 GMT+02:00 Tomas Vondra >:
>
>> 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
On Sat, Jun 27, 2015 at 11:38 AM, Andres Freund 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 table/tablespace/
2015-06-28 14:26 GMT+02:00 Tomas Vondra :
> 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 n
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,
Hi,
On 06/28/2015 02:21 PM, Pavel Stehule wrote:
2015-06-28 14:12 GMT+02:00 Tomas Vondra
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 - and both has sense.
I'm
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 http
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 (sub)transacti
2015-06-28 14:12 GMT+02:00 Tomas Vondra :
> 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
>> parame
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 wholeheart
On Sat, Jun 27, 2015 at 2:12 AM, Josh Berkus wrote:
> Finally, while I'm raining on everyone's parade: the mechanism of
> identifying synchronous replicas by setting the application_name on the
> replica is confusing and error-prone; if we're building out synchronous
> replication into a sophistic
On Sat, Jun 27, 2015 at 3:53 AM, Josh Berkus 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, rather than
>> just via a set of example function calls. The GUC-
On Sun, Jun 28, 2015 at 5:52 PM, Sawada Masahiko wrote:
> On Fri, Jun 26, 2015 at 2:46 PM, Michael Paquier
> 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 th
2015-06-28 10:46 GMT+02:00 Fabien COELHO :
>
> 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 parameter
On Fri, Jun 26, 2015 at 2:46 PM, Michael Paquier
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 this
> feature would b
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
(
2015-06-28 8:47 GMT+02:00 Corey Huinker :
> 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
> simila
2015-06-28 8:59 GMT+02:00 Fabien COELHO :
>
> \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
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 (pgsql-hackers@postgresql.
\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 be
70 matches
Mail list logo
