As we talked at the developer meeting on Ottawa, it needs to provide
a capability to assign a short text identifier on database objects
to support label based ESP (such as SELinux).
So, I'd like to propose a few approaches to support security label
as a draft of discussion.
An example of label: "s
2010/5/27 Robert Haas :
> On Wed, May 26, 2010 at 9:28 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> On Wed, May 26, 2010 at 8:21 PM, Tom Lane wrote:
If we go with the spec's syntax I think we'd have no realistic choice
except to forbid => altogether as an operator name. (And no, I'm
2010/5/27 Tom Lane :
> Robert Haas writes:
>> On Wed, May 26, 2010 at 8:21 PM, Tom Lane wrote:
>>> If we go with the spec's syntax I think we'd have no realistic choice
>>> except to forbid => altogether as an operator name. (And no, I'm not
>>> for that.)
>
>> I suppose the most painful thing a
On Thu, 2010-05-27 at 02:18 +0300, Heikki Linnakangas wrote:
> On 27/05/10 01:23, Simon Riggs wrote:
> > On Thu, 2010-05-27 at 00:21 +0300, Heikki Linnakangas wrote:
> >> On 26/05/10 23:31, Dimitri Fontaine wrote:
> >>>d. choice of commit or rollback at timeout
> >>
> >> Rollback is not an opti
2010/5/27 Heikki Linnakangas :
> On 27/05/10 02:09, alvherre wrote:
>>
>> Excerpts from Andrew Dunstan's message of mié may 26 18:52:33 -0400 2010:
>>
>>> I think we should fix it now. Quick thought: maybe we could use FOR
>>> instead of AS: select myfunc(7 for a, 6 for b); IIRC the standard's
>>>
>>
>
> I think we should fix it now. Quick thought: maybe we could use FOR instead
> of AS: select myfunc(7 for a, 6 for b); IIRC the standard's mechanism for
> this is 'paramname => value', but I think that has problems because of our
> possibly use of => as an operator - otherwise that would be
On 27/05/10 03:25, Florian Pflug wrote:
On May 27, 2010, at 0:58 , Heikki Linnakangas wrote:
On 26/05/10 02:00, Sam Vilain wrote:
Florian Pflug wrote:
On May 25, 2010, at 12:18 , Heikki Linnakangas wrote:
Releasing the newer savepoint will cause the older one to again become
accessible, as t
On Thu, 2010-05-27 at 11:28 +0900, Fujii Masao wrote:
> On Wed, May 26, 2010 at 10:20 PM, Simon Riggs wrote:
> > On Wed, 2010-05-26 at 18:52 +0900, Fujii Masao wrote:
> >
> >> I guess that dropping the support of #3 doesn't reduce complexity
> >> since the code of #3 is almost the same as that of
On 27/05/2010, at 02.48, Robert Haas wrote:
On Wed, May 26, 2010 at 8:06 PM, Tom Lane wrote:
Josh Berkus writes:
How does that get us out of reading and writing old pages, though?
Yeah. Neither PD_ALL_VISIBLE nor the visibility map are going to
solve
your problem, because they cannot
On Wed, May 26, 2010 at 03:47:25PM -0400, Robert Haas wrote:
> On Tue, May 25, 2010 at 4:34 AM, Jonathan Leto wrote:
> > This tiny doc patch adds _PG_init to the skeleton example code for a
> > PL. The information is quite valuable to PL authors, who might miss it
> > when it is described in the s
Hi,
Anyone working on make contrib/pg_trgm mutibyte encoding aware? If
not, I'm interested in the work.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To mak
> My "stand-alone" means libSQL can be used from many modules
> without duplicated codes. For example, copy routines for raw
> parse trees should be in the DLL rather than in postgres.exe.
>
> Then, we need to consider other products than pgpool. Who will
> use the dll? If pgpool is the only user,
Stephen,
>> The 'failure' may make an impression of generic errors not only permission
>> denied.
>> How about 'error_on_violation'?
>
> Maybe 'ereport_on_violation'? I dunno, guess one isn't really better
> than the other. You need to go back and fix the comment though- you
> still say 'abort
Craig Ringer writes:
> On 27/05/10 10:21, Tom Lane wrote:
>> What will happen as things stand is that all the certs get loaded
>> into a common pool. That's not too horrible as long as there are
>> not actual conflicts, but it could mean that for example some
>> connections trust CA certs that th
Tatsuo Ishii wrote:
> > The proposal will be acceptable only when all of the technical issues
> > are solved. The libSQL should also be available in stand-alone.
> > It should not be a collection of half-baked functions.
>
> What do you mean by "should also be available in stand-alone"? If you
On 27/05/10 10:21, Tom Lane wrote:
What will happen as things stand is that all the certs get loaded
into a common pool. That's not too horrible as long as there are
not actual conflicts, but it could mean that for example some
connections trust CA certs that the app programmer expected to only
On Wed, May 26, 2010 at 10:35 PM, Tom Lane wrote:
> Robert Haas writes:
>> It knows that queries beginning with "select" or "values" are select
>> commands, but it seems not to be clued in about "table" and "with".
>
> What we really ought to do IMO is throw out the entire current
> implementatio
Robert Haas writes:
> It knows that queries beginning with "select" or "values" are select
> commands, but it seems not to be clued in about "table" and "with".
What we really ought to do IMO is throw out the entire current
implementation of fetch_count. If libpq exposed access to the
protocol-l
On Wed, May 26, 2010 at 10:20 PM, Simon Riggs wrote:
> On Wed, 2010-05-26 at 18:52 +0900, Fujii Masao wrote:
>
>> I guess that dropping the support of #3 doesn't reduce complexity
>> since the code of #3 is almost the same as that of #2. Like
>> walreceiver sends the ACK after receiving the WAL in
> I read your proposal says "postgres.exe" will link to "libSQL.dll",
> and "pgpool.exe" will also link to the DLL, right?
Perhaps.
> I think it is reasonable, but I'm not sure what part of postgres
> should be in the DLL. Obviously we should avoid code duplication
> between the DLL and "postgres
I wrote:
> It strikes me that we could not only fix this case, but make the libpq
> code simpler and more like the backend case, if we got rid of
> client_cert_cb and instead preloaded the ~/.postgresql/postgresql.crt
> file using SSL_CTX_use_certificate_chain_file().
Just for the archives: I've a
* Robert Haas (robertmh...@gmail.com) wrote:
> For now, we can probably get by with just adding those to the list of
> things it checks for. But I wonder what we'll do about this if we
> ever get CTEs for insert/update/delete statements... you'd have to
> parse the whole darn thing to figure out
> As was already discussed, I don't believe that premise. None of the
> applications you cite would be able to make use of the raw parser
> output, because it doesn't contain the semantic information they need.
> If what you actually meant was the analyzed parse tree, that *might*
> serve the need
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
> Stephen, thanks for comments.
>
> The attached three patches are the revised and divided ones.
>
> A: add makeRangeTblEntry()
Ok, didn't actually expect that. Guess my suggestion would have been to
just use makeNode() since there wasn't a
It knows that queries beginning with "select" or "values" are select
commands, but it seems not to be clued in about "table" and "with".
For now, we can probably get by with just adding those to the list of
things it checks for. But I wonder what we'll do about this if we
ever get CTEs for insert
On 27/05/10 12:25, Florian Pflug wrote:
Patch that changes the wording to "Explicitly releasing the newer savepoint with
RELEASE SAVEPOINT will cause ..." is attached.
Unfortunately, this patch is untested. I couldn't get openjade + DocBook to
work on OSX for some reason :-(
FWIW docs
On Wed, May 26, 2010 at 9:06 PM, Fujii Masao wrote:
> On Wed, May 26, 2010 at 9:40 PM, Robert Haas wrote:
>> On Mon, May 24, 2010 at 10:35 AM, Fujii Masao wrote:
>>> On Mon, May 24, 2010 at 10:26 PM, Robert Haas wrote:
This looks pretty reasonable to me, but I guess I feel like it would
>>
Tatsuo Ishii wrote:
> I'm thinking about exporting the raw parser and related modules as a C
> library. Though this will not be an immediate benefit of PostgreSQL
> itself, it will be a huge benefit for any PostgreSQL
> applications/middle ware those need to parse SQL statements.
I read your pr
Stephen, thanks for comments.
The attached three patches are the revised and divided ones.
A: add makeRangeTblEntry()
B: major reworks of DML permission checks
C: add an ESP hook on the DML permission checks
(2010/05/27 0:09), Stephen Frost wrote:
> KaiGai,
>
> * KaiGai Kohei (kai...@ak.jp.n
Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
> > Andrew Dunstan writes:
> >
> >> OK ... I guess I was bothered because this has been referred to in a
> >> public press release about the Beta. The PLPerl security stuff is
> >> missing too, so I'll fix that also.
> >>
> >
> > The security
Tatsuo Ishii writes:
> I'm thinking about exporting the raw parser and related modules as a C
> library. Though this will not be an immediate benefit of PostgreSQL
> itself, it will be a huge benefit for any PostgreSQL
> applications/middle ware those need to parse SQL statements.
As was already
On Wed, May 26, 2010 at 9:28 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, May 26, 2010 at 8:21 PM, Tom Lane wrote:
>>> If we go with the spec's syntax I think we'd have no realistic choice
>>> except to forbid => altogether as an operator name. (And no, I'm not
>>> for that.)
>
>> I sup
On Wed, May 26, 2010 at 8:59 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, May 26, 2010 at 8:06 PM, Tom Lane wrote:
>>> Yeah. Neither PD_ALL_VISIBLE nor the visibility map are going to solve
>>> your problem, because they cannot become set without having visited the
>>> page.
>
>> Well,
Robert Haas writes:
> On Wed, May 26, 2010 at 8:21 PM, Tom Lane wrote:
>> If we go with the spec's syntax I think we'd have no realistic choice
>> except to forbid => altogether as an operator name. (And no, I'm not
>> for that.)
> I suppose the most painful thing about doing that is that it wo
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> There might be some value in psql backslash command tests that
> are designed to depend on just one or a few tables (or other appropriate
> objects).
Updated, much much smaller, patch attached. Also available, again, at
http://snowman.net/~sfrost/psql-regr
> I think those works are essentially a refactoring of existing raw
> parser, and will not add performance degration nor maintenance cost.
>
> Comments?
You should call it "libSQL"; who knows, other DB projects might want it.
They seem to borrow our parser enough as it is.
--
On Wed, May 26, 2010 at 9:54 PM, Robert Haas wrote:
> On Tue, May 25, 2010 at 6:19 AM, Fujii Masao wrote:
>> On Tue, May 18, 2010 at 3:09 PM, Fujii Masao wrote:
> (2)
> pg_ctl -ms stop emits the following warning whenever there is the
> backup_label file in $PGDATA.
>
>
On Wed, May 26, 2010 at 9:40 PM, Robert Haas wrote:
> On Mon, May 24, 2010 at 10:35 AM, Fujii Masao wrote:
>> On Mon, May 24, 2010 at 10:26 PM, Robert Haas wrote:
>>> This looks pretty reasonable to me, but I guess I feel like it would
>>> be better to drive the CancelBackup() decision off of wh
On 27/05/10 03:57, Robert Haas wrote:
Being compatible with the SQL
standard and with Oracle is not to be taken lightly.
I seem to be alone believing that the SQL standard doesn't say anything
about named function parameters. Can someone point me to the relevant
section of the standard?
As
I'm thinking about exporting the raw parser and related modules as a C
library. Though this will not be an immediate benefit of PostgreSQL
itself, it will be a huge benefit for any PostgreSQL
applications/middle ware those need to parse SQL statements.
For example, pgpool-II parses queries to know
On Wed, May 26, 2010 at 8:20 PM, Andrew Dunstan wrote:
> Gurjeet Singh wrote:
>>
>> I did a `git clean -f -d` and even that did not remove gram.c, apparently
>> because this file _was_ alive at some point in the past hence git won't
>> remove it even though the current branch does not have gram.c.
Robert Haas writes:
> On Wed, May 26, 2010 at 8:06 PM, Tom Lane wrote:
>> Yeah. Neither PD_ALL_VISIBLE nor the visibility map are going to solve
>> your problem, because they cannot become set without having visited the
>> page.
> Well, maybe I'm confused here, but arranging things so that we N
On Wed, May 26, 2010 at 8:21 PM, Tom Lane wrote:
> alvherre writes:
>> The problem with the => operator seems best resolved as not accepting
>> such an operator in a function parameter, which sucks but we don't seem
>> to have a choice.
>
> "Sucks" is not the word; "utterly unacceptable" is the w
On Wed, May 26, 2010 at 8:25 PM, Florian Pflug wrote:
> Unfortunately, this patch is untested. I couldn't get openjade + DocBook to
> work on OSX for some reason :-(
That is a truly awful nightmare. Dave Page dug up some old
instructions which got me through it - I'm guessing he doesn't mind my
On Wed, May 26, 2010 at 8:06 PM, Tom Lane wrote:
> Josh Berkus writes:
>> How does that get us out of reading and writing old pages, though?
>
> Yeah. Neither PD_ALL_VISIBLE nor the visibility map are going to solve
> your problem, because they cannot become set without having visited the
> page
On 26/05/10 16:54, Heikki Linnakangas wrote:
On 26/05/10 16:16, Robert Haas wrote:
This comment obviously requires adjustment now that HS is committed.
The obvious way to change it is to replace "when we get hot standby
capability" with "when running in Hot Standby mode", but I'm not clear
wheth
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> There might be some value in psql backslash command tests that
> are designed to depend on just one or a few tables (or other appropriate
> objects). Dumping large fractions of the catalogs will just be a net
> loss.
Fair enough, I can certainly do that pr
Stephen Frost writes:
> * alvherre (alvhe...@commandprompt.com) wrote:
>> (And if we want something like this, I think we should not have a single
>> huge file for the complete test, but a set of smaller files. I'd even
>> put the bunch in src/bin/psql/regress rather than the main regress dir.)
On May 27, 2010, at 0:58 , Heikki Linnakangas wrote:
> On 26/05/10 02:00, Sam Vilain wrote:
>> Florian Pflug wrote:
>>> On May 25, 2010, at 12:18 , Heikki Linnakangas wrote:
Releasing the newer savepoint will cause the older one to again become
accessible, as the doc says, but rolling ba
alvherre writes:
> The problem with the => operator seems best resolved as not accepting
> such an operator in a function parameter, which sucks but we don't seem
> to have a choice.
"Sucks" is not the word; "utterly unacceptable" is the word. Having an
expression mean different things depending
Gurjeet Singh wrote:
I did a `git clean -f -d` and even that did not remove gram.c,
apparently because this file _was_ alive at some point in the past
hence git won't remove it even though the current branch does not have
gram.c.
At first glance that looks like a git bug.
cheers
andr
Josh Berkus writes:
> How does that get us out of reading and writing old pages, though?
Yeah. Neither PD_ALL_VISIBLE nor the visibility map are going to solve
your problem, because they cannot become set without having visited the
page.
regards, tom lane
--
Sent via p
Gurjeet Singh writes:
> The src/backend/parser/gram.c is a generated file, so shouldn't this be
> removed by `make distclean`, or maybe even by `make clean`?
No. It's shipped in distribution tarballs. If you want all derived
files to be removed, use make maintainer-clean.
* alvherre (alvhe...@commandprompt.com) wrote:
> Excerpts from Stephen Frost's message of mié may 26 15:19:59 -0400 2010:
> > * Robert Haas (robertmh...@gmail.com) wrote:
> > > Then, too, there's the fact that many of these tests fail on my
> > > machine because my username is not sfrost,
> >
> >
The src/backend/parser/gram.c is a generated file, so shouldn't this be
removed by `make distclean`, or maybe even by `make clean`?
I did a `git clean -f -d` and even that did not remove gram.c, apparently
because this file _was_ alive at some point in the past hence git won't
remove it even thoug
On 5/26/2010 4:34 PM, Kevin Grittner wrote:
Jan Wieck wrote:
Without this logic, the replication system could not combine
multiple origin sessions into one replication session without
risking to never find a state, in which it can commit.
My latest idea for handling this in WAL-based replic
On 27/05/10 02:09, alvherre wrote:
Excerpts from Andrew Dunstan's message of mié may 26 18:52:33 -0400 2010:
I think we should fix it now. Quick thought: maybe we could use FOR
instead of AS: select myfunc(7 for a, 6 for b); IIRC the standard's
mechanism for this is 'paramname => value', but
Just picking up a dropped thread, does anyone have a patch for this?
http://archives.postgresql.org/pgsql-hackers/2010-04/msg01191.php
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pg
On May 26, 2010, at 4:09 PM, alvherre wrote:
> The problem with the => operator seems best resolved as not accepting
> such an operator in a function parameter, which sucks but we don't seem
> to have a choice. Perhaps we could allow "=>" to resolve as the
> operator for the case the user really
> Just this second posted about that, as it turns out.
>
> I have a v3 *almost* ready of the keepalive patch. It still makes sense
> to me after a few days reflection, so is worth discussion and review. In
> or out, I want this settled within a week. Definitely need some R&R
> here.
Does the kee
On 27/05/10 01:23, Simon Riggs wrote:
On Thu, 2010-05-27 at 00:21 +0300, Heikki Linnakangas wrote:
On 26/05/10 23:31, Dimitri Fontaine wrote:
d. choice of commit or rollback at timeout
Rollback is not an option. There is no going back after the commit
record has been flushed to disk or sen
Excerpts from Andrew Dunstan's message of mié may 26 18:52:33 -0400 2010:
> I think we should fix it now. Quick thought: maybe we could use FOR
> instead of AS: select myfunc(7 for a, 6 for b); IIRC the standard's
> mechanism for this is 'paramname => value', but I think that has
> problems be
On 5/26/2010 5:12 PM, Heikki Linnakangas wrote:
On 26/05/10 23:49, Jan Wieck wrote:
In this implementation it wouldn't even matter if a transaction that was
recorded actually never made it because it crashed before the WAL flush.
It would be reported by this "commit order" feature, but there wou
On Wed, May 12, 2010 at 8:00 PM, Simon Riggs wrote:
> On Wed, 2010-05-12 at 19:33 +0300, Peter Eisentraut wrote:
>> The server's messages and the documentation uses all of these terms in
>> mixed ways. Maybe we could decide on some preferred terminology and
>> adjust the existing texts. Ideas?
>
On 26/05/10 02:00, Sam Vilain wrote:
Florian Pflug wrote:
On May 25, 2010, at 12:18 , Heikki Linnakangas wrote:
Releasing the newer savepoint will cause the older one to again become
accessible, as the doc says, but rolling back to a savepoint does not
implicitly release it. You'll have to us
On Wed, 2010-05-26 at 15:45 -0700, Josh Berkus wrote:
> > Committed with chunk size of 128 kB. I hope that's a reasonable
> > compromise, in the absence of any performance test data either way.
>
> So where are we with max_standby_delay? Status check?
Just this second posted about that, as it tu
Peter Eisentraut wrote:
It turns out that the SQL standard uses the function call notation
foo(this AS that)
for something else:
::=
::= [ ]
::= [ [ { }... ] ]
::=
|
|
::= AS
In systems that have inheritance of composite types, this is used to
specify which type the
On Sun, 2010-05-16 at 17:11 +0100, Simon Riggs wrote:
> New version, with some other cleanup of wait processing.
>
> New logic is that when Startup asks for next applychunk of WAL it saves
> the lastChunkTimestamp. That is then the base time used by
> WaitExceedsMaxStandbyDelay(), except when lat
On Thu, 2010-05-27 at 01:34 +0300, Heikki Linnakangas wrote:
> Committed with chunk size of 128 kB.
Thanks. I'm sure that's fine.
--
Simon Riggs www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://w
> Committed with chunk size of 128 kB. I hope that's a reasonable
> compromise, in the absence of any performance test data either way.
So where are we with max_standby_delay? Status check?
--
-- Josh Berkus
PostgreSQL Expe
On 19/05/10 00:37, Simon Riggs wrote:
On Tue, 2010-05-18 at 17:25 -0400, Heikki Linnakangas wrote:
On 18/05/10 17:17, Simon Riggs wrote:
There's no reason that the buffer size we use for XLogRead() should be
the same as the send buffer, if you're worried about that. My point is
that pq_putmessa
On Thu, 2010-05-27 at 00:21 +0300, Heikki Linnakangas wrote:
> On 26/05/10 23:31, Dimitri Fontaine wrote:
> > d. choice of commit or rollback at timeout
>
> Rollback is not an option. There is no going back after the commit
> record has been flushed to disk or sent to a standby.
There's defini
On Wed, 2010-05-26 at 17:31 -0400, Jan Wieck wrote:
> You can do this only with per standby options, by giving each standby a
> weight, or a number of votes. Your DEV server would have a weight of
> zero, while your production standby's have higher weights, depending on
> their importance for y
Hi!
I've spent some time going through all the email threads since Alpha4
was released, and have updated the 9.0 Open Items list.
We have two sections of open items which need initial review by -hackers:
http://wiki.postgresql.org/wiki/PostgreSQL_9.0_Open_Items#Code
http://wiki.postgresql.org/wi
On 12/05/10 22:23, Robert Haas wrote:
On Wed, May 12, 2010 at 3:01 PM, Heikki Linnakangas
wrote:
Tom Lane wrote:
If so, master/standby would probably work.
+1 for master/standby.
It's worth remembering that a "standby server" might not be actively
connected to a master server. A server tha
On 26/05/10 23:31, Dimitri Fontaine wrote:
So if you want simplicity to admin, effective data availability and
precise control over the global setup, I say go for:
a. transaction level control of the replication level
b. cascading support
c. quorum with timeout
d. choice of commit or roll
--On 4. November 2009 09:57:27 -0500 Tom Lane wrote:
Yeah, this is a known issue. The ALTER should be rejected, but it is
not, because we don't have enough infrastructure to notice that the
constraint is inherited and logically can't be dropped. I think the
consensus was that the way to fix
On 5/26/2010 12:55 PM, Heikki Linnakangas wrote:
On 26/05/10 18:31, Robert Haas wrote:
And frankly, I don't think it's possible for quorum commit to reduce
the number of parameters. Even if we have that feature available, not
everyone will want to use it. And the people who don't will
presumab
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
>>> Patch attached to show the schema *and* table name when doing
>>> a REINDEX DATABASE.
>
>> Is this something that can be added to 9.1 commitfest?
> Not in this form, apparently. Can we convince Greg or someone else to
> work on adding som
On 26/05/10 23:31, Dimitri Fontaine wrote:
d. choice of commit or rollback at timeout
Rollback is not an option. There is no going back after the commit
record has been flushed to disk or sent to a standby.
The choice is to either commit anyway after the timeout, or wait forever.
--
Hei
Excerpts from Ray Stell's message of mié may 26 17:08:33 -0400 2010:
> I just installed a compiled from src 8.3.11. I usually include %i, command
> tag,
> in the log_line_prefix setting. This causes some spewage I'd not seen before
> on connection received lines as if it is dumping the environme
On 5/26/2010 4:52 PM, Heikki Linnakangas wrote:
Ok, I think I understand it now. The commit order is enough, because
replaying the actions in the order "all actions of B, then all actions
of A" yields the same result.
Precisely.
Jan
--
Anyone who trades liberty for security deserves neithe
On 26/05/10 23:49, Jan Wieck wrote:
In this implementation it wouldn't even matter if a transaction that was
recorded actually never made it because it crashed before the WAL flush.
It would be reported by this "commit order" feature, but there would be
no traces of whatever it did to be found in
Excerpts from Selena Deckelmann's message of mié may 26 11:07:40 -0400 2010:
> On Mon, Apr 5, 2010 at 9:29 AM, Greg Sabino Mullane wrote:
> > Patch attached to show the schema *and* table name when doing
> > a REINDEX DATABASE.
>
> Is this something that can be added to 9.1 commitfest?
Not in th
> What if we drove it off of the PD_ALL_VISIBLE bit on the page itself,
> rather than the visibility map bit? It would be safe to clear the
> visibility map bit without touching the page, but if you clear the
> PD_ALL_VISIBLE bit on the page itself then you set all the hint bits
> and freeze all
On 26/05/10 23:45, Heikki Linnakangas wrote:
On 26/05/10 23:32, Jan Wieck wrote:
Consider two transactions A and B that due to transaction batching
between snapshots get applied together. Let the order of actions be
1. A starts
2. B starts
3. B selects a row for update, then updates the row
4.
On 5/26/2010 12:38 PM, Greg Stark wrote:
On Wed, May 26, 2010 at 5:10 PM, Jan Wieck wrote:
... but to answer that request, actually I don't even think we should be
discussing API specifics.
How about just API generalities? Like, where do you need this data, on
the master or on the slave? Wou
On 26/05/10 23:32, Jan Wieck wrote:
Consider two transactions A and B that due to transaction batching
between snapshots get applied together. Let the order of actions be
1. A starts
2. B starts
3. B selects a row for update, then updates the row
4. A tries to do the same and blocks
5. B commits
It turns out that the SQL standard uses the function call notation
foo(this AS that)
for something else:
::=
::= [ ]
::= [ [ { }... ] ]
::=
|
|
::= AS
In systems that have inheritance of composite types, this is used to
specify which type the value is supposed to be inte
On 5/26/2010 4:11 PM, Dimitri Fontaine wrote:
So even ordering the txid and txid_snapshots with respect to WAL commit
time (LSN) won't be the whole story, for any given transaction
containing more than one event we also need to have them in order. I
know Jan didn't forget about it so it must eith
Jan Wieck wrote:
> Without this logic, the replication system could not combine
> multiple origin sessions into one replication session without
> risking to never find a state, in which it can commit.
My latest idea for handling this in WAL-based replication involves
WAL-logging information ab
On 5/26/2010 3:16 PM, Heikki Linnakangas wrote:
On 26/05/10 21:43, Jan Wieck wrote:
On 5/26/2010 1:17 PM, Heikki Linnakangas wrote:
It would not get called during recovery, but I believe that would be
sufficient for Slony. You could always batch commits that you don't
know when they committed a
Simon Riggs writes:
> On Wed, 2010-05-26 at 19:55 +0300, Heikki Linnakangas wrote:
>> Now you want to set up a temporary replica of the master at a
>> development server, for testing purposes. If you set quorum to 2, your
>> development server becomes critical infrastructure, which is not what
>
On Wed, May 26, 2010 at 4:11 PM, Dimitri Fontaine
wrote:
> Heikki Linnakangas writes:
>> Perhaps I'm missing something, but I thought that Slony currently uses a
>> heartbeat, and all transactions committed between two beats are banged
>> together and committed as one in the slave so that their r
Currently, cursor_to_xml returns an empty string when the end of the
cursor is reached (meaning the fetch returned zero rows). As discussed
on -general, that's kind of weird, because you'd have to do something
like
IF val::text = ''
to test for the end, since there is no = operator for xml, and
Heikki Linnakangas writes:
> Perhaps I'm missing something, but I thought that Slony currently uses a
> heartbeat, and all transactions committed between two beats are banged
> together and committed as one in the slave so that their relative commit
> order doesn't matter.
I guess Slony does the
Excerpts from Stephen Frost's message of mié may 26 15:19:59 -0400 2010:
> * Robert Haas (robertmh...@gmail.com) wrote:
> > Then, too, there's the fact that many of these tests fail on my
> > machine because my username is not sfrost,
>
> I've updated the patch to address this, it's again at:
> h
On Tue, May 25, 2010 at 4:34 AM, Jonathan Leto wrote:
> This tiny doc patch adds _PG_init to the skeleton example code for a
> PL. The information is quite valuable to PL authors, who might miss it
> when it is described in the shared library documentation.
I'm not sure it does much good to add i
On Wed, 2010-05-26 at 15:37 -0400, Robert Haas wrote:
> On Wed, May 26, 2010 at 3:13 PM, Simon Riggs wrote:
> >> I don't really understand this comment. I have said, and I believe,
> >> that a system without quorum commit is simpler than one with quorum
> >> commit. I'd debate the point with you
On Wed, May 26, 2010 at 3:13 PM, Simon Riggs wrote:
>> I don't really understand this comment. I have said, and I believe,
>> that a system without quorum commit is simpler than one with quorum
>> commit. I'd debate the point with you but I find the point so
>> self-evident that I don't even kno
1 - 100 of 174 matches
Mail list logo
