On Fri, Dec 12, 2008 at 8:05 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Michael Meskes mes...@postgresql.org writes:
On Fri, Dec 12, 2008 at 10:06:30AM -0500, Tom Lane wrote:
Hmm ... actually, ecpg might be a problem here anyway. I know it has
special meaning for :name, but does it allow
On Sat, 2008-12-13 at 00:00 +0100, Markus Wanner wrote:
Hi,
Fujii Masao wrote:
I'd like to define the meaning of synch rep again. synch rep means:
(1) Transaction commit waits for WAL records to be replicated to the standby
before the command returns a success indication to the
Tom Lane wrote:
Kurt Harriman harri...@acm.org writes:
However, probably an easier alternative would be to have
just one buildfarm machine do a nightly build configured
with the --enable-cplusplus option.
There is no such option, and won't be.
Yours is the first comment anyone has posted
On Friday 12 December 2008 19:09:26 Alvaro Herrera wrote:
I don't understand -- why wouldn't we just have two columns, one for
plain row-level security and another for whatever security system the
platforms happens to offer? If we were to follow that route, we could
have row-level security
On Friday 12 December 2008 19:31:11 Robert Haas wrote:
Not really. I'm not an SELinux expert. But typically the two do
exist alongside one another. For example, installing SELinux (MAC)
does on your system does not make chmod g+w file (DAC) stop working;
it merely performs an ADDITIONAL
On Friday 12 December 2008 20:05:57 Tom Lane wrote:
Excellent. I checked that psql's colon-variable feature behaves the
same. So it looks like the proposed name: value syntax would indeed
not break any existing features. Barring better ideas I think we should
go with that one.
I personally
A Dissabte 13 Desembre 2008, Peter Eisentraut va escriure:
On Friday 12 December 2008 20:05:57 Tom Lane wrote:
Excellent. I checked that psql's colon-variable feature behaves the
same. So it looks like the proposed name: value syntax would indeed
not break any existing features. Barring
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Le 13 déc. 08 à 11:39, Peter Eisentraut a écrit :
On Friday 12 December 2008 20:05:57 Tom Lane wrote:
Excellent. I checked that psql's colon-variable feature behaves the
same. So it looks like the proposed name: value syntax would
indeed
Hi,
Simon Riggs wrote:
You're right that neither the data transfer nor data availability is
entirely synchronous, but data transfer is synchronous at time of
*commit*: it is recorded on multiple nodes at the same time.
I'm unsure what you mean by a data transfer being synchronous. To what
On 2008-12-13, at 13:07, Markus Wanner wrote:
However, that is a marketing decision [1], which should not be mixed
with the technical discussion here. Speaking of a synchronous commit
is utterly misleading, because the commit itself is exactly the thing
that's *not* synchronous.
[1]: Some
On Sat, 2008-12-13 at 14:07 +0100, Markus Wanner wrote:
Speaking of a synchronous commit
is utterly misleading, because the commit itself is exactly the thing
that's *not* synchronous.
Not really sure where you're going here. synchronous replication is
used exactly as described in the
Dimitri Fontaine dfonta...@hi-media.com writes:
Le 13 déc. 08 à 11:39, Peter Eisentraut a écrit :
I personally thought that AS was a better idea.
It seems some people want to be able to overload some default
parameters (but not others) and at the same time alias them to some
new label.
Dimitri Fontaine wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Le 13 d?c. 08 ? 11:39, Peter Eisentraut a ?crit :
On Friday 12 December 2008 20:05:57 Tom Lane wrote:
Excellent. I checked that psql's colon-variable feature behaves the
same. So it looks like the proposed
On Dec 13, 2008, at 5:05 PM, Tom Lane wrote:
However, after looking at the precedent of XMLELEMENT, it's hard to
deny
that if the SQL committee ever chose to standardize named parameters,
AS is what they would use. The chances that : would become the
standard are negligible --- that's not
David E. Wheeler da...@kineticode.com writes:
On Dec 13, 2008, at 5:05 PM, Tom Lane wrote:
However, after looking at the precedent of XMLELEMENT, it's hard to
deny that if the SQL committee ever chose to standardize named parameters,
AS is what they would use. The chances that : would
On Dec 13, 2008, at 5:19 PM, Tom Lane wrote:
I'm sure it's technically possible, but I see no redeeming social
value
in it ... we should pick one and quit repainting the bike shed.
Well, as I've said, I'm okay with AS, though it's not my favorite. I
can see the argument that it's more
David E. Wheeler da...@kineticode.com writes:
I don't suppose that the position of the label and
the value on either side of AS could be reversible, could it?
No. Consider
SELECT foo(bar AS baz) FROM ...
If the from-clause provides columns named both bar and baz, it would
be
David E. Wheeler wrote:
On Dec 13, 2008, at 5:19 PM, Tom Lane wrote:
I'm sure it's technically possible, but I see no redeeming social
value
in it ... we should pick one and quit repainting the bike shed.
Well, as I've said, I'm okay with AS, though it's not my favorite. I
can see
On 2008-12-13, at 16:19, Tom Lane wrote:
I'm sure it's technically possible, but I see no redeeming social
value
in it ... we should pick one and quit repainting the bike shed.
+1000
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Hi,
Simon Riggs wrote:
On Sat, 2008-12-13 at 14:07 +0100, Markus Wanner wrote:
Speaking of a synchronous commit
is utterly misleading, because the commit itself is exactly the thing
that's *not* synchronous.
Not really sure where you're going here.
I'm pointing to a potential
I personally agree that AS seems more SQL-ish, but that's in the eye
of the beholder.
The argument about ambiguity in XMLELEMENT is bogus becase XMLELEMENT
doesn't (and won't) have named parameters. But it is true that
XMLELEMENT is doing something subtly different with the AS clause than
I started making the changes to increase the default and maximum stats
targets 10X, as I believe was agreed to in this thread:
http://archives.postgresql.org/pgsql-hackers/2008-12/msg00386.php
I came across this bit in ts_typanalyze.c:
/* We want statistic_target * 100 lexemes in the
I certainly agree to using such terms. Unfortunately, in my experience,
synchronous replication is commonly used to mean that transactions are
guaranteed to be immediately visible on remote nodes after the client
got commit acknowledgment. That's the cause for confusion I'm envisioning.
I
Robert Haas robertmh...@gmail.com writes:
I think we need to reserve the term synchronous replication for a
system where transactions that begin at the same time on the primary
and standby see the same tuples. Clearly that is more synchronous
than what is being proposed here; if we call this
Synchronous replication, sync rep is *not* intersted in the slave's
visiblity of the commit, because PostgreSQL doesn't serve requests
when in recovery (wal receiving) mode *now*.
This sync rep patch/proposal/discution is *strictly* (at this point yet,
hot standby may eventually or hopefully soon
On Sat, 2008-12-13 at 13:05 -0500, Robert Haas wrote:
Hot Standby (although the latter
seems to have stalled a bit...)
It's just being worked on asynchronously. ;-)
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-hackers mailing
On Sat, 2008-12-13 at 13:05 -0500, Robert Haas wrote:
I certainly agree to using such terms. Unfortunately, in my experience,
synchronous replication is commonly used to mean that transactions are
guaranteed to be immediately visible on remote nodes after the client
got commit
On Sat, 2008-12-13 at 21:35 +0200, Hannu Krosing wrote:
We still could call Sync Rep as a feature synchronous replication on
basis that WAL Streaming - Synchronous Write is the highest security
level achievable using the feature.
And maybe have Sync Hot Standby as a feature on top of that
ITAGAKI Takahiro escreveu:
- A new GUC variable 'explain_analyze_format' is added.
I'm afraid that this variable name doesn't tell what it means. What about
'explain_analyze_stats_format' or even 'explain_stats_format'?
--
Euler Taveira de Oliveira
http://www.timbira.com/
--
Sent via
Hi,
Tom Lane wrote:
We won't call it anything, because we never will or can implement that.
See the theory of relativity: the notion of exactly simultaneous events
at distinct locations isn't even well-defined
That has never been the point of the discussion. It's rather about the
question if
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Le 13 déc. 08 à 17:05, Tom Lane a écrit :
I personally agree that AS seems more SQL-ish, but that's in the eye
of the beholder.
So do I, but I fear it's already taken for another meaning.
The argument about ambiguity in XMLELEMENT is bogus
Hi,
Simon Riggs wrote:
Hot Standby (although the latter
seems to have stalled a bit...)
It's just being worked on asynchronously. ;-)
LOL, thanks for bringing humor into this discussion :-)
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
Hi,
Hannu Krosing wrote:
You can have a variantof sync rep + hot standby where the master does
not return committed before the slave has both synced the data and
replied the transaction so that it is visible on slave but in that case
you may have a usecase, where it is actually visible on
Dimitri Fontaine dfonta...@hi-media.com writes:
What if relabeling support were to spread some more?
Spread to what? AFAICS the way that XMLELEMENT uses AS is a
single-purpose wart (much like a lot of other stuff the SQL committee
invents :-(). I do not see a need to reserve AS in function
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Le 13 déc. 08 à 22:32, Tom Lane a écrit :
Spread to what? AFAICS the way that XMLELEMENT uses AS is a
single-purpose wart
Ok now that explains.
The common lisp inspired syntax is only nice if we're to avoid using
AS, which I thought was the
* Markus Wanner mar...@bluegap.ch [081213 16:33]:
Hi,
Hannu Krosing wrote:
You can have a variantof sync rep + hot standby where the master does
not return committed before the slave has both synced the data and
replied the transaction so that it is visible on slave but in that case
Markus Wanner wrote:
Tom Lane wrote:
We won't call it anything, because we never will or can implement that.
See the theory of relativity: the notion of exactly simultaneous events
at distinct locations isn't even well-defined
That has never been the point of the discussion. It's
Hi,
Aidan Van Dyk wrote:
Well, I think the PG MVCC (which wal-streaming just ships across
somewhere else) will save that. So with hot-standby you could have
another client could see the result *after* the COMMIT has been
requested, but *before* the COMMIT returns... But we have this
Hi,
Mark Mielke wrote:
Might it not be true that anybody unfamiliar would be confused and that
this is a bit of a straw man?
Might be. I've neglected the issue myself for a while.
I don't think synchronous replication guarantees that it will be
immediately visible. Even if it did push the
I see. Thanks for the advice. I would research on how to use tuplestore
object.
Regards,
Bramandia R.
On Sat, Dec 13, 2008 at 10:36 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Bramandia Ramadhana braman...@gmail.com writes:
Hmm how if an upper level node needs to store (for future use) the
It appears that the visibility map patch is causing pg_class.reltuples to be
set improperly after a vacuum. For example, it is set to 0 if the map
indicated that no pages in the heap needed to be scanned.
Perhaps reltuples should not be updated unless every page was scanned during
the vacuum?
--
Markus Wanner wrote:
I don't think synchronous replication guarantees that it will be
immediately visible. Even if it did push the change to the other
machine, and the other machine had committed it, that doesn't guarantee
that any reader sees it any more than if I commit to the same machine
(no
Hello!. I'm using PgBouncer with permanent connection, So, when i
deleting(or editing?) some functions i have an error
ERROR: cache lookup failed for function ..;
Can you make recaching of invalidate functions?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
Corey Horton chort...@austin.rr.com writes:
I'm trying to use array_to_string on the pg_stats column
histogram_bounds...
test83=# select array_to_string(histogram_bounds::anyarray, '-') from
pg_stats where attname = 'id' and tablename = 'widgets';
ERROR: argument declared anyarray is not
Oleg Serov sero...@gmail.com writes:
Hello!. I'm using PgBouncer with permanent connection, So, when i
deleting(or editing?) some functions i have an error
ERROR: cache lookup failed for function ..;
You're going to need to explain exactly what you're doing if you
want help with that.
Huh, I didn't realize that ever worked in the past. I thought the way
to do what the op describes was to cast it to text[] or whatever
datatype you from out-of-band knowledge to expect.
--
Greg
On 13 Dec 2008, at 19:38, Tom Lane t...@sss.pgh.pa.us wrote:
Corey Horton
Greg Stark greg.st...@enterprisedb.com writes:
Huh, I didn't realize that ever worked in the past. I thought the way
to do what the op describes was to cast it to text[] or whatever
datatype you from out-of-band knowledge to expect.
We don't seem to allow that either ...
regression=#
I don't quote know how this data but any constant factor seems like it
would be arbitrary. It sounds like a more principled algorithm would
be to use stats_target^2. But that has the same problem. Even
stats_target^1.5 would be too big for stats_target 10,000.
I think just using 10 is
On Sun, 2008-12-14 at 03:28 +0300, Oleg Serov wrote:
Hello!. I'm using PgBouncer with permanent connection, So, when i
deleting(or editing?) some functions i have an error
ERROR: cache lookup failed for function ..;
Can you make recaching of invalidate functions?'
I believe it already
What if relabeling support were to spread some more?
The only example I can think of besides XML is JSON. There might be a
few more. Basically, relabelling is a handy shortcut when you are
serializing data and want to avoid specifying a list of columns and an
(almost) identical list of labels.
On Sun, Dec 14, 2008 at 1:42 AM, Robert Haas robertmh...@gmail.com wrote:
What if relabeling support were to spread some more?
The only example I can think of besides XML is JSON. There might be a
few more. Basically, relabelling is a handy shortcut when you are
serializing data and want to
On Sat, Dec 13, 2008 at 1:29 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I think we need to reserve the term synchronous replication for a
system where transactions that begin at the same time on the primary
and standby see the same tuples. Clearly that is
On Sat, 2008-12-13 at 21:35 -0500, Robert Haas wrote:
On Sat, Dec 13, 2008 at 1:29 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I think we need to reserve the term synchronous replication for a
system where transactions that begin at the same time on the
If it's guaranteed to be visible on the standby after it's committed on
the master, and you don't have any way to make it actually simultaneous,
then that implies that it's visible on the slave for some brief period
of time before it's committed on the master.
That situation is still
Might it not be true that anybody unfamiliar would be confused and that this
is a bit of a straw man?
[...]
If my application assumes that it can commit to one server, and then read
back the commit from another server, and my application breaks as a result,
it's because I didn't understand
On Sat, 2008-12-13 at 22:23 -0500, Robert Haas wrote:
If it's guaranteed to be visible on the standby after it's committed on
the master, and you don't have any way to make it actually simultaneous,
then that implies that it's visible on the slave for some brief period
of time before it's
The whole relabeling thing seems like a seriously silly idea. Why is
it at all a shortcut to use AS instead of , ?
Because a lot of times you don't want to relabel, so you omit the AS
label part altogether, and the label is deduced from the expression
itself. For example, I don't need to
The point here is that synchronous replication, at least to some
people, is going to imply that the user-visible states of the two
copies are consistent. To other people, it is going to imply that
committed transactions will never be lost even in the event of a
catastropic loss of the
The point here is that synchronous replication, at least to some
people, is going to imply that the user-visible states of the two
copies are consistent. To other people, it is going to imply that
committed transactions will never be lost even in the event of a
catastropic loss of the
Greg Stark st...@enterprisedb.com writes:
On Sun, Dec 14, 2008 at 1:42 AM, Robert Haas robertmh...@gmail.com wrote:
What if relabeling support were to spread some more?
The only example I can think of besides XML is JSON. There might be a
few more. Basically, relabelling is a handy
60 matches
Mail list logo
