Hello. I found a bug(?) in thsi patch as I considered on another
patch.
In truncate_useless_pathkeys, if query_pathkeys is longer than
pathkeys made from index columns old patch picked up the latter
as IndexPath's pathkeys. But the former is more suitable
according to the context here.
the
Hello, As I was reconsidering after your advise, I came up with
an idea of hacking on query tree tranaformation phase in
subquery_planner, not on that of plan generation phase as
before. (And the older patch is totally scrapped:-)
Currently flatten_simple_union_all() flattens 'simple' UNION
Hello
2013/11/21 Peter Eisentraut pete...@gmx.net
On 11/21/13, 2:09 AM, Pavel Stehule wrote:
Hello
I wrote new styles for psql table borders.
http://postgres.cz/wiki/Pretty_borders_in_psql
This patch is simply and I am think so some styles can be interesting
for final
Hello
2013/11/21 Merlin Moncure mmonc...@gmail.com
On Thu, Nov 21, 2013 at 1:09 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
Hello
I wrote new styles for psql table borders.
http://postgres.cz/wiki/Pretty_borders_in_psql
This patch is simply and I am think so some styles
3. That said, this could be handy. But it would be even more handy if you
could get Gaussian random numbers with \setrandom, so that you could use this
with custom scripts. And once you implement that, do we actually need the -g
flag anymore? If you want TPC-B transactions with gaussian
2013/11/21 Szymon Guz mabew...@gmail.com
On 21 November 2013 21:15, Szymon Guz mabew...@gmail.com wrote:
On 21 November 2013 20:20, Pavel Stehule pavel.steh...@gmail.com wrote:
So here is patch for 9.4
7 new line styles, 2 new border styles, \pset border autocomplete
Regards
Pavel
On Sat, Oct 26, 2013 at 11:17:19AM -0200, Rodolfo Campero wrote:
The attached patch add support of domains over arrays to PL/Python (eg:
CREATE DOMAIN my_domain AS integer[]).
Basically it just uses get_base_element_type instead of get_element_type
in plpy_typeio.c, and uses domain_check
Kyotaro HORIGUCHI wrote:
Hello. I found a bug(?) in thsi patch as I considered on another patch.
In truncate_useless_pathkeys, if query_pathkeys is longer than pathkeys
made
from index columns old patch picked up the latter as IndexPath's pathkeys.
But the former is more suitable according
On 11/21/2013 12:45 AM, Craig Ringer wrote:
I'm really concerned by this post on Linux's fsync and disk flush behaviour:
http://milek.blogspot.com.au/2010/12/linux-osync-and-write-barriers.html
and seeking opinions from folks here who've been deeply involved in
write reliability work.
With
Marko,
2013/11/22 Marko Kreen mark...@gmail.com
On Sat, Oct 26, 2013 at 11:17:19AM -0200, Rodolfo Campero wrote:
The attached patch add support of domains over arrays to PL/Python (eg:
CREATE DOMAIN my_domain AS integer[]).
Basically it just uses get_base_element_type instead of
On 21.11.2013 21:37, Merlin Moncure wrote:
On Thu, Nov 21, 2013 at 10:37 AM, Heikki Linnakangas
In my patch, I put the barrier inside the if (!LocalRecoveryInProgress)
block. That codepath can only execute once in a backend, so performance is
not an issue there. Does that look sane to you?
oh
On Fri, Nov 22, 2013 at 08:45:56AM -0200, Rodolfo Campero wrote:
There are other cosmetic changes in this patch, wrt previous version (not
preexistent code):
* adjusted alignment of variable name rv in line 12
* reworded comment in line 850, resulting in more than 80 characters, so I
On 19.11.2013 16:20, Andres Freund wrote:
On 2013-11-18 23:15:59 +0100, Andres Freund wrote:
Afaics it's likely a combination/interaction of bugs and fixes between:
* the initial HS code
* 5a031a5556ff83b8a9646892715d7fef415b83c3
* f44eedc3f0f347a856eea8590730769125964597
Yes, the combination
On Thu, Nov 21, 2013 at 11:06 AM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Nov 20, 2013 at 9:35 PM, Fabrízio de Royes Mello
fabriziome...@gmail.com wrote:
So, with this patch we can do that:
ALTER TABLE foo
SET (ext.somext.do_replicate=true);
When 'ext' is the fixed
Review: information schema parameter_default implementation (v2)
This is a review of the patch submitted in
http://archives.postgresql.org/message-id/1384483678.5008.1.ca...@vanquo.pezone.net
(information schema parameter_default implementation).
Previous review from Amit Khandekar covers
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Tom I've committed this patch after some significant editorialization, but
Tom leaving the use of TABLE( ... ) syntax in-place. If we decide that we
Tom don't want to risk doing that, we can change to some other syntax later.
Is this intended:
When trying to add the extension with \i it writes an error message:
Use CREATE EXTENSION uuid-ossp to load this file.
Unfortunatly this does not work for extensions with dashes. Must CREATE
EXTENSION uuid-ossp. Proposed patch is attached.
Regards
Mario
diff -Nurb
Amit Kapila escribió:
On Fri, Nov 22, 2013 at 1:33 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
\ib homer ~/photos/homer.jpg
insert into people (name, photo) values ('Homer', :homer);
Isn't something similar already supported as mentioned in docs:
One example use of this
On 21.11.2013 22:55, Andres Freund wrote:
On 2013-11-20 12:48:50 +0200, Heikki Linnakangas wrote:
On 19.11.2013 16:22, Andres Freund wrote:
On 2013-11-19 15:20:01 +0100, Andres Freund wrote:
Imo something the attached patch should be done. The description I came
g up with is:
Fix
On Thu, Nov 21, 2013 at 9:44 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Here's a new version. To ease the review, I split the remaining patch again
into two, where the first patch is just yet more refactoring.
I also fixed some bugs in WAL logging and replay that I bumped into while
We started with
Fri Nov 15
Status Summary. Needs Review: 79, Waiting on Author: 7, Ready for Committer: 5,
Committed: 7, Returned with Feedback: 3, Rejected: 1. Total: 102.
We are now at
Fri Nov 22
Status Summary. Needs Review: 47, Waiting on Author: 28, Ready for Committer:
10, Committed:
Bruce Momjian escribió:
OK, here is a patch which changes ABORT from NOTICE to WARNING, and SET
from ERROR (which is new in 9.4) to WARNING.
I don't like that this patch changes RequireTransactionChain() from
actually requiring one, to a function that maybe requires a transaction
chain, and
On 2013-11-22 15:01:10 +0200, Heikki Linnakangas wrote:
On 21.11.2013 22:55, Andres Freund wrote:
On 2013-11-20 12:48:50 +0200, Heikki Linnakangas wrote:
Looks ok for a back-patchable fix.
Do you plan to commit this? Or who is going to?
Ok, committed.
Thanks!
Greetings,
Andres Freund
AddressSanitizer (http://clang.llvm.org/docs/AddressSanitizer.html)
(also available through gcc, but I used clang), reports one bug, which
I traced down to this code in ruleutils.c:
[elsewhere:]
#define ViewSelectRuleName _RETURN
/*
* Get the pg_rewrite tuple for the view's
Hello, Peter.
Is is possible to add small patch to the current commit fest?
You wrote:
PE We started with
PE Fri Nov 15
PE Status Summary. Needs Review: 79, Waiting on Author: 7, Ready for
PE Committer: 5, Committed: 7, Returned with Feedback: 3, Rejected: 1. Total:
102.
PE We are now at
KaiGai
On Tue, Nov 19, 2013 at 9:41 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
Thanks for your review.
2013/11/19 Jim Mlodgenski jimm...@gmail.com:
My initial review on this feature:
- The patches apply and build, but it produces a warning:
ctidscan.c: In function
On Thu, Nov 21, 2013 at 6:43 PM, Shigeru Hanada
shigeru.han...@gmail.com wrote:
2013/11/22 Tom Lane t...@sss.pgh.pa.us:
Merlin Moncure mmonc...@gmail.com writes:
On Thu, Nov 21, 2013 at 9:05 AM, Bruce Momjian br...@momjian.us wrote:
I know join pushdowns seem insignificant, but it helps to
On Fri, Nov 22, 2013 at 2:23 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
Hello
2013/11/21 Merlin Moncure mmonc...@gmail.com
On Thu, Nov 21, 2013 at 1:09 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
Hello
I wrote new styles for psql table borders.
2013/11/22 Merlin Moncure mmonc...@gmail.com
On Fri, Nov 22, 2013 at 2:23 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
Hello
2013/11/21 Merlin Moncure mmonc...@gmail.com
On Thu, Nov 21, 2013 at 1:09 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
Hello
I wrote new
Peter Eisentraut pete...@gmx.net writes:
AddressSanitizer (http://clang.llvm.org/docs/AddressSanitizer.html)
(also available through gcc, but I used clang), reports one bug, which
I traced down to this code in ruleutils.c:
[elsewhere:]
#define ViewSelectRuleName _RETURN
/*
Pavel Stehule escribió:
2013/11/21 Peter Eisentraut pete...@gmx.net
Maybe make the border setting a string containing the various characters
by index. Then everyone can create their own crazy borders.
I seriously though about it, but not sure if it is good way.
How about having a
On 22-11-2013 11:07, Pavel Golub wrote:
Is is possible to add small patch to the current commit fest?
No. Deadline was 11/15. Add it to next CF [1].
[1] https://commitfest.postgresql.org/action/commitfest_view?id=21
--
Euler Taveira Timbira - http://www.timbira.com.br/
Andres Freund wrote:
While looking at the multixact truncation code (mail nearby), I've
noticed that there's a significant difference in the way multixact
members are accessed since fkey locks were introduced:
9.3 when heap_lock_tuple finds a XMAX_IS_MULTI tuple it executes
On Fri, Nov 22, 2013 at 8:45 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Pavel Stehule escribió:
2013/11/21 Peter Eisentraut pete...@gmx.net
Maybe make the border setting a string containing the various characters
by index. Then everyone can create their own crazy borders.
I
roadrunn...@gmx.at writes:
When trying to add the extension with \i it writes an error message:
Use CREATE EXTENSION uuid-ossp to load this file.
Unfortunatly this does not work for extensions with dashes. Must CREATE
EXTENSION uuid-ossp. Proposed patch is attached.
[ memo to self:
Tom Lane wrote:
roadrunn...@gmx.at writes:
regression=# \echo Use '''CREATE EXTENSION uuid-ossp''' to load this file.
Use 'CREATE EXTENSION uuid-ossp' to load this file.
Does that look reasonable to people?
+1
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL
On 11/22/2013 10:19 AM, Alvaro Herrera wrote:
Tom Lane wrote:
roadrunn...@gmx.at writes:
regression=# \echo Use '''CREATE EXTENSION uuid-ossp''' to load this file.
Use 'CREATE EXTENSION uuid-ossp' to load this file.
Does that look reasonable to people?
+1
+1
cheers
andrew
--
Sent via
On 2013-11-22 12:04:31 -0300, Alvaro Herrera wrote:
Andres Freund wrote:
While looking at the multixact truncation code (mail nearby), I've
noticed that there's a significant difference in the way multixact
members are accessed since fkey locks were introduced:
9.3 when
Hi,
I spend some time trying to figure out why PostgreSQL builds on
S390-Linux, but Postgres-XC doesn't. Well at least this holds for the Debian
packages. So far I haven't figured it out. However, it appears to me that the
build should fail for both. I'm not an S390 expert by any means, but I
On Thu, Nov 21, 2013 at 1:43 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Also, it's not that hard to do plug-pull testing to verify that your
system is telling the truth about fsync. This really ought to be part
of acceptance testing for any new DB server.
I've never tried it but I always
Greg Stark st...@mit.edu writes:
On Thu, Nov 21, 2013 at 1:43 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Also, it's not that hard to do plug-pull testing to verify that your
system is telling the truth about fsync. This really ought to be part
of acceptance testing for any new DB server.
I've
Michael Meskes mes...@postgresql.org writes:
I spend some time trying to figure out why PostgreSQL builds on
S390-Linux, but Postgres-XC doesn't. Well at least this holds for the Debian
packages. So far I haven't figured it out. However, it appears to me that the
build should fail for both.
On Fri, Nov 22, 2013 at 1:16 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The original mail was referencing a problem with syncing *meta* data
though. The semantics around meta data syncs are much less clearly
specified, in part because file systems traditionally made nearly all meta
data operations
Andrew Gierth and...@tao11.riddles.org.uk writes:
Is this intended:
[ I assume you forgot a create type footype here ]
create function foo() returns setof footype language plpgsql
as $f$ begin return next row(1,true); end; $f$;
select pg_typeof(f), row_to_json(f) from foo() with
On Fri, Nov 22, 2013 at 10:24:35AM -0300, Alvaro Herrera wrote:
Bruce Momjian escribió:
OK, here is a patch which changes ABORT from NOTICE to WARNING, and SET
from ERROR (which is new in 9.4) to WARNING.
I don't like that this patch changes RequireTransactionChain() from
actually
On Fri, Nov 22, 2013 at 11:27:45AM -0500, Tom Lane wrote:
I think this is probably nonsense. I spent ten years maintaining Postgres
for Red Hat, and I never saw any such failure on s390 in their packages.
If -fpic weren't good enough for shared libraries on s390, how'd any of
those builds get
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Tom [ I assume you forgot a create type footype here ]
yeah, sorry
Tom Well, it's not insane on its face. The rowtype of f in the
Tom first example is necessarily a built-on-the-fly record, but in
Tom the second case using the properties of the
On Fri, Nov 22, 2013 at 12:17:41PM -0500, Bruce Momjian wrote:
Good points. I have modified the attached patch to do as you suggested.
Also, I have read through the thread and summarized the positions of the
posters:
9.3 WARNING ERROR
SET
On 19 November 2013, Amit Khandekar wrote:
On 18 November 2013 18:00, Rajeev rastogi
rajeev.rast...@huawei.commailto:rajeev.rast...@huawei.com wrote:
On 18 November 2013, Amit Khandekar wrote:
Please find the patch for the same and let me know your suggestions.
In this call :
ON 11 November 2013, Naoya Anzai Wrote:
Hi Amit,
I have uploaded your patch for next commit fest, hope you can support
it if there is any feedback for your patch by reviewer/committer.
Thanks! Okay, I will support you.
1. Patch applies cleanly to master HEAD.
2. No Compilation Warning.
On 14 November 2013, Kondo Mitsumasa wrote:
Subject: Re: [HACKERS] Add min and max execute statement time in
pg_stat_statement
Oh! Sorry...
I forgot to attach my latest patch.
* Is the patch in a patch format which has context?
No
* Does it apply cleanly to the current git master?
Yes.
On 20 November, Amit Khandekar wrote:
I hope you meant to write test case as psql -d postgres -c \copy tab from
stdin; insert into tab values ('lll', 3), as if we are reading from file,
then the above issue does not come.
I meant COPY with a slash. \COPY is equivalent to COPY FROM STDIN. So the
Sending to hackers for comment; seems setting
default_transaction_read_only to true via ALTER database/user or
postgresql.conf can cause pg_dump, pg_dumpall, and pg_upgrade failures.
We are considering the right solution:
On 16/09/13 16:20, Satoshi Nagayasu wrote:
Thanks for checking. Fixed to eliminate SnapshotNow.
Looking forward to get a new patch, incorporating the comments, that are
already given in the following mails:
1. Jaime Casanova: The name pgstattuple2, doesn't convince me... maybe you can
use
On 19 November 2013 22:19, Sawada Masahiko Wrote
Thank you for comment.
Actually, I had thought to add separate parameter.
I think that he said that if you can proof that amount of WAL is
almost same and without less performance same as before, you might
not
need to separate
On 20 November 2013 22:12, Sawada Masahiko Wrote
1. Patch applies cleanly to master HEAD.
2. No Compilation Warning.
3. It works as per the patch expectation.
Some Suggestion:
1. Add new WAL level (all) in comment in postgresql.conf
wal_level = hot_standby
9.3 documentation says:
According to the standard, the column-list syntax should allow a list of
columns to be assigned from a single row-valued expression, such as a
sub-select:
UPDATE accounts SET (contact_last_name, contact_first_name) =
(SELECT last_name, first_name FROM salesmen
On 21 November 2013, Amit Khandekar
amit.khande...@enterprisedb.commailto:amit.khande...@enterprisedb.com wrote:
Ok. we will then first fix the \COPY TO issue where it does not revert back
the overriden psql output file handle. Once this is solved, fix for both COPY
FROM and COPY TO, like how
On Fri, Nov 22, 2013 at 08:25:05AM -0600, Merlin Moncure wrote:
On Thu, Nov 21, 2013 at 6:43 PM, Shigeru Hanada
shigeru.han...@gmail.com wrote:
2013/11/22 Tom Lane t...@sss.pgh.pa.us:
Merlin Moncure mmonc...@gmail.com writes:
On Thu, Nov 21, 2013 at 9:05 AM, Bruce Momjian br...@momjian.us
Andres Freund wrote:
On 2013-11-22 12:04:31 -0300, Alvaro Herrera wrote:
Yes, somewhat: 9.3 GetMultiXactIdMembers() didn't do any work if the
multixact was old enough:
if (MultiXactIdPrecedes(multi, OldestVisibleMXactId[MyBackendId]))
{
debug_elog2(DEBUG2,
2013/11/22 Alvaro Herrera alvhe...@2ndquadrant.com
Pavel Stehule escribió:
2013/11/21 Peter Eisentraut pete...@gmx.net
Maybe make the border setting a string containing the various
characters
by index. Then everyone can create their own crazy borders.
I seriously though about
On Thu, Nov 21, 2013 at 8:26 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-11-21 08:22:05 -0500, Robert Haas wrote:
On Thu, Nov 21, 2013 at 6:15 AM, Andres Freund and...@2ndquadrant.com
wrote:
WRT performance: I agree that fixed-width identifiers are more
performant, that's why
Andrew Gierth and...@tao11.riddles.org.uk writes:
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Tom Well, it's not insane on its face. The rowtype of f in the
Tom first example is necessarily a built-on-the-fly record, but in
Tom the second case using the properties of the underlying named
On 2013-11-22 14:43:15 -0500, Robert Haas wrote:
The patch as proposed puts forward a particular way of
doing that, and I think that neither that method *nor any other*
should be part of core.
Working on something like that, updated the patch state to waiting on
author.
Thanks,
Andres Freund
Bruce Momjian br...@momjian.us wrote:
Not sure about backpatching. default_transaction_read_only has been
around since 7.4. Setting it to true would cause pg_dump to fail unless
you changed the database setting, and pg_dumpall would fail completely
as there is no way to turn off the
AK alk...@gmail.com writes:
9.3 documentation says:
According to the standard, the column-list syntax should allow a list of
columns to be assigned from a single row-valued expression, such as a
sub-select:
UPDATE accounts SET (contact_last_name, contact_first_name) =
(SELECT last_name,
Michael Meskes mes...@postgresql.org writes:
On Fri, Nov 22, 2013 at 11:27:45AM -0500, Tom Lane wrote:
Furthermore, if we change that convention now, we're going to increase
the risk of such mixing failures for other people.
Sure, but if this a bug we should. I'm not saying it is, I simply
Kevin Grittner kgri...@ymail.com wrote:
See the attached patch.
Trying that again.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Companydiff --git a/src/bin/pg_dump/pg_backup_archiver.c b/src/bin/pg_dump/pg_backup_archiver.c
index 63a8009..199ffb0 100644
---
Kevin Grittner kgri...@ymail.com writes:
Kevin Grittner kgri...@ymail.com wrote:
See the attached patch.
Trying that again.
That looks sane for pg_dump, but I would rather have expected that
pg_dumpall would need to emit the same thing (possibly more than once
due to reconnections).
Tom Lane t...@sss.pgh.pa.us wrote:
That looks sane for pg_dump, but I would rather have expected
that pg_dumpall would need to emit the same thing (possibly more
than once due to reconnections).
I was kinda surprised myself. I changed it for pg_dump, tested
that, and then tested pg_dumpall
On 11/22/13, 12:41 PM, Michael Meskes wrote:
Checking the Debian logs it appears that all calls use *both* which seems to
do
the right thing. And yes, it appears there is a change in XC that makes it
break. But still, I would think there has to be a correct set of options.
According to the
On 2013-11-22 12:45:25 -0800, Kevin Grittner wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
That looks sane for pg_dump, but I would rather have expected
that pg_dumpall would need to emit the same thing (possibly more
than once due to reconnections).
I was kinda surprised myself. I
Andres Freund and...@2ndquadrant.com wrote:
are you sure it also unsets default_transaction_readonly for
the roles etc. it creates?
I'm not sure I understand. Could you give an example of what
you're concerned about?
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise
On 2013-11-22 13:07:29 -0800, Kevin Grittner wrote:
Andres Freund and...@2ndquadrant.com wrote:
are you sure it also unsets default_transaction_readonly for
the roles etc. it creates?
I'm not sure I understand. Could you give an example of what
you're concerned about?
pg_dumpall first
Andres Freund and...@2ndquadrant.com writes:
On 2013-11-22 13:07:29 -0800, Kevin Grittner wrote:
I'm not sure I understand. Could you give an example of what
you're concerned about?
pg_dumpall first spits out global data (users, databases, tablespaces)
and then invokes pg_dump for every
Andres Freund and...@2ndquadrant.com wrote:
On 2013-11-22 13:07:29 -0800, Kevin Grittner wrote:
Andres Freund and...@2ndquadrant.com wrote:
are you sure it also unsets default_transaction_readonly for
the roles etc. it creates?
I'm not sure I understand. Could you give an example of what
Claudio,
Can you elaborate how rules can help?
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Why-is-UPDATE-with-column-list-syntax-not-implemented-tp5779600p5779896.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
--
Sent via
Thank you, Tom!
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Why-is-UPDATE-with-column-list-syntax-not-implemented-tp5779600p5779899.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
--
Sent via pgsql-hackers mailing list
On 2013-11-22 13:34:18 -0800, Kevin Grittner wrote:
Oddly, it didn't complain about creating users within a read-only
transaction. That seems like a potential bug.
There's lots of things that escape XactReadOnly. I've thought (and I
think suggested) before that we should put in another layer
Kevin Grittner kgri...@ymail.com wrote:
This covers pg_dumpall globals. Tested with a read-only postgres
database and with default_transaction_read_only = on in the
postgresql.conf file.
It does nothing about pg_upgrade, which is sort of a separate
issue. My inclination is that connections to
On 2013-11-22 13:34:18 -0800, Kevin Grittner wrote:
I changed my postgres database to default to read only (which is
not insane, given that I've seen so many people accidentally run
DDL there rather than in the database they intended)
FWIW, I am less than convinced that it is correct for
On Fri, Nov 22, 2013 at 6:36 PM, AK alk...@gmail.com wrote:
Claudio,
Can you elaborate how rules can help?
Well... that specific example:
UPDATE accounts SET (contact_last_name, contact_first_name) =
(SELECT last_name, first_name FROM salesmen
WHERE salesmen.id =
I am reading the following in the documentation: Tip: A common mistake is to
write a semicolon immediately after BEGIN. This is incorrect and will result
in a syntax error.
So, common mistake means semicolons after BEGIN seem consistent to many
people - it seems consistent to me as well. If
Andres Freund and...@2ndquadrant.com wrote:
FWIW, I am less than convinced that it is correct for
pg_dump[all] to emit SET default_transaction_readonly = off;
It doesn't change the database setting, just the connection which
is issuing commands to create global object -- ones that don't
reside
I believe the section you are reading refers to the BEGIN keyword in the
procedural language plpgsql, not the SQL 'BEGIN' command. The issue stems
from confusing two distinct languages both of which, along with several
more procedural languages, are documented in the same manual.
On 11/22/2013 02:24 PM, AK wrote:
I am reading the following in the documentation: Tip: A common mistake is to
write a semicolon immediately after BEGIN. This is incorrect and will result
in a syntax error.
So, common mistake means semicolons after BEGIN seem consistent to many
people - it
On Fri, Nov 22, 2013 at 4:34 PM, Mike Blackwell mike.blackw...@rrd.com wrote:
I believe the section you are reading refers to the BEGIN keyword in the
procedural language plpgsql, not the SQL 'BEGIN' command. The issue stems
from confusing two distinct languages both of which, along with
AK alk...@gmail.com wrote:
I am reading the following in the documentation: Tip: A common
mistake is to write a semicolon immediately after BEGIN. This is
incorrect and will result in a syntax error.
So, common mistake means semicolons after BEGIN seem consistent
to many people - it seems
On 11/22/2013 05:24 PM, AK wrote:
I am reading the following in the documentation: Tip: A common mistake is to
write a semicolon immediately after BEGIN. This is incorrect and will result
in a syntax error.
So, common mistake means semicolons after BEGIN seem consistent to many
people - it
On Thu, Nov 21, 2013 at 11:43:34PM +0100, Andres Freund wrote:
On 2013-11-21 14:40:36 -0800, Jeff Janes wrote:
But if the transaction would not have otherwise generated WAL (i.e. a
select that did not have to do any HOT pruning, or an update with zero rows
matching the where condition),
On Fri, Nov 22, 2013 at 11:16:06AM -0500, Tom Lane wrote:
Greg Stark st...@mit.edu writes:
On Thu, Nov 21, 2013 at 1:43 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Also, it's not that hard to do plug-pull testing to verify that your
system is telling the truth about fsync. This really ought to
On Fri, Nov 22, 2013 at 2:57 PM, Bruce Momjian br...@momjian.us wrote:
The program is diskchecker:
http://brad.livejournal.com/2116715.html
I got the author to re-host the source code on github a few years ago.
It might be worth re-implementing this for -contrib. The fact that we
On Fri, Nov 22, 2013 at 01:55:10PM -0800, Kevin Grittner wrote:
It does nothing about pg_upgrade, which is sort of a separate
issue. My inclination is that connections to the new cluster
should set this and connections to the old should not.
It is going to be tricky to conditionally set/reset
On Fri, Nov 22, 2013 at 03:06:31PM -0800, Peter Geoghegan wrote:
On Fri, Nov 22, 2013 at 2:57 PM, Bruce Momjian br...@momjian.us wrote:
The program is diskchecker:
http://brad.livejournal.com/2116715.html
I got the author to re-host the source code on github a few years ago.
On 11/22/2013 03:23 PM, Bruce Momjian wrote:
On Fri, Nov 22, 2013 at 03:06:31PM -0800, Peter Geoghegan wrote:
On Fri, Nov 22, 2013 at 2:57 PM, Bruce Momjian br...@momjian.us wrote:
The program is diskchecker:
http://brad.livejournal.com/2116715.html
I got the author to re-host the
On Fri, Nov 22, 2013 at 03:27:29PM -0800, Josh Berkus wrote:
On 11/22/2013 03:23 PM, Bruce Momjian wrote:
On Fri, Nov 22, 2013 at 03:06:31PM -0800, Peter Geoghegan wrote:
On Fri, Nov 22, 2013 at 2:57 PM, Bruce Momjian br...@momjian.us wrote:
The program is diskchecker:
On Fri, Nov 22, 2013 at 8:51 PM, Peter Eisentraut pete...@gmx.net wrote:
On 11/22/13, 12:41 PM, Michael Meskes wrote:
Checking the Debian logs it appears that all calls use *both* which
seems to do
the right thing. And yes, it appears there is a change in XC that makes
it
break. But
On Sat, Nov 23, 2013 at 8:06 AM, Peter Geoghegan p...@heroku.com wrote:
On Fri, Nov 22, 2013 at 2:57 PM, Bruce Momjian br...@momjian.us wrote:
The program is diskchecker:
http://brad.livejournal.com/2116715.html
I got the author to re-host the source code on github a few years ago.
Bruce Momjian br...@momjian.us wrote:
On Fri, Nov 22, 2013 at 01:55:10PM -0800, Kevin Grittner wrote:
It does nothing about pg_upgrade, which is sort of a separate
issue. My inclination is that connections to the new cluster
should set this and connections to the old should not.
It is
Andres Freund and...@2ndquadrant.com wrote:
On 2013-11-22 13:34:18 -0800, Kevin Grittner wrote:
Oddly, it didn't complain about creating users within a read-only
transaction. That seems like a potential bug.
There's lots of things that escape XactReadOnly. I've thought (and I
think
1 - 100 of 106 matches
Mail list logo
