Simon Riggs wrote:
>>> Another way would be to include a security context in all newly
>> created
>>> tuples, but remove it during heap_update, heap_insert etc if it is
>>> unused by the relation. That seems more straightforward.
>> It is not a reasonable option.
>>
>> The length of HeapTupleData i
On Tue, 2008-11-18 at 15:02 +0900, KaiGai Kohei wrote:
> If we focus on the CreateTemplateTupleDesc(), 5 of call points give
> possibile "hasoid" argument, and rest of them always give "false".
> I guess it will be same in the security context cases.
> However, we have to change all the call poin
On Mon, 2008-11-17 at 23:19 -0700, Joshua Tolley wrote:
> -- it speeds up joins by fairly significant margins in some cases
The original claim in the message you cite says 10-50% for some data
distributions. Were you able to observe that kind of speedup?
Regards,
Jeff Davis
--
Sent via
Note: this email is effectively a repeat of an email sent earlier to
which there has been less response than I expected. If there's something
else I'm supposed to do at this point, someone please let me know,
because I don't know what it is :)
---
I've finished all
Simon Riggs wrote:
> On Tue, 2008-11-18 at 11:51 +0900, KaiGai Kohei wrote:
>> Simon Riggs wrote:
The other is an issue on implementation. Even if row-level security is
disabled, tuples within pg_class, pg_attribute, pg_proc and pg_largeobject
has to hold its security context, becaus
On Tue, 2008-11-18 at 13:10 +0900, KaiGai Kohei wrote:
> KaiGai Kohei wrote:
> > Simon Riggs wrote:
> >>> The other is an issue on implementation. Even if row-level security is
> >>> disabled, tuples within pg_class, pg_attribute, pg_proc and pg_largeobject
> >>> has to hold its security context,
On Tue, 2008-11-18 at 11:51 +0900, KaiGai Kohei wrote:
> Simon Riggs wrote:
> >> The other is an issue on implementation. Even if row-level security is
> >> disabled, tuples within pg_class, pg_attribute, pg_proc and pg_largeobject
> >> has to hold its security context, because it means the securi
KaiGai Kohei wrote:
> Simon Riggs wrote:
>>> The other is an issue on implementation. Even if row-level security is
>>> disabled, tuples within pg_class, pg_attribute, pg_proc and pg_largeobject
>>> has to hold its security context, because it means the security context of
>>> tables, columns, proc
Russell Smith wrote:
> Bruce Momjian wrote:
> > Yes, my defines were very messed up; updated version attached.
> >
> Hi,
>
> I've not done a review of this patch, however I did backport it to 8.3
> (as attached in unified diff). The patch wasn't made for PG purposes, so
> it's not in context d
Magnus Hagander wrote:
> Tom Lane wrote:
> > Magnus Hagander <[EMAIL PROTECTED]> writes:
> >> I am unsure of exactly where this thing hacks into the authentication
> >> stream, but is it really only MD5 that fails?
> >
> > The problem with md5 is that the username is part of the encryption salt
>
Here is an update version of contrib/auto_explain patch.
Now it uses new ExecutorStart_hook and ExecutorEnd_hook.
When we execute queries using cursor, FETCHes are accumulated
and reported only once on CLOSE.
A new argument 'flags' is added in DefineCustomXXXVariable()
and custom GUC variables ar
Simon Riggs wrote:
>> The other is an issue on implementation. Even if row-level security is
>> disabled, tuples within pg_class, pg_attribute, pg_proc and pg_largeobject
>> has to hold its security context, because it means the security context of
>> tables, columns, procedure and largeobjects.
>>
Hi Heikki,
Emmanuel Cecchet wrote:
As I have not found yet an elegant solution to deal with the DROP
CASCADE issue, here is a simpler patch that handles temp tables that
are dropped at commit time. This is a good first step and we will try
to elaborate further to support ON COMMIT DELETE ROWS.
On Tue, Nov 18, 2008 at 12:39 AM, Simon Riggs <[EMAIL PROTECTED]> wrote:
>
> On Mon, 2008-11-17 at 16:18 +0200, Heikki Linnakangas wrote:
>> Simon Riggs wrote:
>> > @@ -3845,6 +3850,52 @@ sigusr1_handler(SIGNAL_ARGS)
>> >
>> > PG_SETMASK(&BlockSig);
>> >
>> > + if (CheckPostmasterSign
Heikki Linnakangas wrote:
>> Gregory Stark wrote:
>> However you still have a problem that someone could come along and set the
>> hint bit between calculating the CRC and actually calling write.
>
> The double-buffering will solve that.
Or simply require that hint bit writes acquire a write lock
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> On Mon, 2008-11-17 at 19:34 -0500, Tom Lane wrote:
>> My point is it's a user-visible change --- maybe a subtle one, but still
>> a change that in principle could break some app somewhere --- and no
>> good reason has been put forward for making it.
On Mon, 2008-11-17 at 19:34 -0500, Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Well, for example pg_catalog.xmlconcat(...) will behave differently if
> >> we make this change.
>
> > Uh, because there is no pg_catalog.xmlconcat() in 8.3. Why is that
> >
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Well, for example pg_catalog.xmlconcat(...) will behave differently if
>> we make this change.
> Uh, because there is no pg_catalog.xmlconcat() in 8.3. Why is that
> relevant?
My point is it's a user-visible change --- maybe a su
* Matthew T. O'Connor <[EMAIL PROTECTED]> [081117 15:19]:
> Aidan Van Dyk wrote:
>> * Greg Stark <[EMAIL PROTECTED]> [081117 03:54]:
>>> I thought of saying that too but it doesn't really solve the problem.
>>> Think of what happens if someone sets a hint bit on a dirty page.
>>
>> If the page is
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
I don't mean that we should do it at backend start even if we are
preloading. But you're not intending to make preloading compulsory, are
you?
No, certainly not. But people who are doing preloading should get as
much benefi
>> Configure already does error out if threading is requested for this
>> platform ;-).
We are not seeing that behavior; at least for 8.3.5 tarball. configure
succeeds and with my patch, libpq builds and runs just fine.
>> The question in my mind is if we want to take any
>> additional troubl
Tom Lane wrote:
Well, for example pg_catalog.xmlconcat(...) will behave differently if
we make this change.
Uh, because there is no pg_catalog.xmlconcat() in 8.3. Why is that
relevant?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscriptio
Tom Lane wrote:
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
On Sun, Nov 16, 2008 at 12:41 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
I've always assumed that the userland thread support in 10.20 is too
broken to be worth troubling with.
Using GNU Pth 2.07 on hpux 10.20 all
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> What's the point of this? I suppose making xmlconcat not a keyword is
>> some small advantage, but having it behave subtly differently from the
>> other xmlfoo functions isn't really all that nice.
> Different from what and how? W
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> On Sun, Nov 16, 2008 at 12:41 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
>> I've always assumed that the userland thread support in 10.20 is too
>> broken to be worth troubling with.
> Using GNU Pth 2.07 on hpux 10.20 all tests provided with the library
Zdenek Kotala wrote:
> Alvaro Herrera napsal(a):
>> Heikki Linnakangas wrote:
>>
>>> Hmm, you're right. I think it can be made to work by storing the
>>> *end* offset of each chunk. To find the chunk containing offset X,
>>> search for the first chunk with end_offset > X.
>>
>> FWIW I'm trying
Tom Lane wrote:
Maybe we should bite the bullet and provide some kind of top-level make
targets for client-only build/install.
That would probably work best.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/ma
Tom Lane wrote:
Peter Eisentraut <[EMAIL PROTECTED]> writes:
Here is a patch to reimplement the xmlconcat functionality as a variadic
function instead of a hardcoded special expression type.
What's the point of this? I suppose making xmlconcat not a keyword is
some small advantage, but having
Aidan Van Dyk wrote:
* Greg Stark <[EMAIL PROTECTED]> [081117 03:54]:
I thought of saying that too but it doesn't really solve the problem.
Think of what happens if someone sets a hint bit on a dirty page.
If the page is dirty from a "real change", then it has a WAL backup block
record alread
On Sun, Nov 16, 2008 at 12:41 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> I've always assumed that the userland thread support in 10.20 is too
> broken to be worth troubling with.
Using GNU Pth 2.07 on hpux 10.20 all tests provided with the library
pass when built via gcc 2.95.3. hpux is definitely
Emmanuel Cecchet wrote:
As I have not found yet an elegant solution to deal with the DROP
CASCADE issue, here is a simpler patch that handles temp tables that are
dropped at commit time. This is a good first step and we will try to
elaborate further to support ON COMMIT DELETE ROWS.
The probl
Alvaro Herrera napsal(a):
Heikki Linnakangas wrote:
Hmm, you're right. I think it can be made to work by storing the *end*
offset of each chunk. To find the chunk containing offset X, search for
the first chunk with end_offset > X.
FWIW I'm trying to do this. So far I've managed to make t
On Tue, Nov 04, 2008 at 12:23:55PM -0500, Tom Lane wrote:
> "Alex Hunsaker" <[EMAIL PROTECTED]> writes:
> > On Thu, Oct 30, 2008 at 05:16, Tom Lane <[EMAIL PROTECTED]> wrote:
> >> Surely they all have a way to call a SQL function that returns text.
>
> > Sure but when you call that function you ge
Hannu Krosing wrote:
Neither of these would be the same as using plperl's %_SHARED, which I
gather is what is being done.
He asked for a method to get/set a shared value "with best performance"
and updating a table row seems about twice as fast as calling a plperl
function.
But u
On Sun, 2008-11-16 at 01:40 +0900, KaiGai Kohei wrote:
> I had two reasons why I didn't implement the option.
>
> The first is the relationship between table/column-level access controls
> and row-level controls on system catalogs is unclear.
> For example, SE-PostgreSQL handles DELETE on pg_cla
On Mon, 2008-11-17 at 12:37 -0500, Andrew Dunstan wrote:
>
> Hannu Krosing wrote:
> > On Sun, 2008-11-16 at 23:20 +0300, Oleg Serov wrote:
> >
> >> Wee need to use shared memory for passing one BIGINT value(is session
> >> throwout triggers), can you advice the method to get/set it with best
>
"Robert Haas" <[EMAIL PROTECTED]> writes:
>> The point here is to do the work at postmaster start time.
> What happens if I upgrade one of the perl modules that is getting
> preloaded here? It seems this change will require the entire database
> to be shut down to pick up the changes, vs. just ne
> The point here is to do the work at postmaster start time.
What happens if I upgrade one of the perl modules that is getting
preloaded here? It seems this change will require the entire database
to be shut down to pick up the changes, vs. just needing to terminate
individual backends.
...Rober
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I don't mean that we should do it at backend start even if we are
> preloading. But you're not intending to make preloading compulsory, are
> you?
No, certainly not. But people who are doing preloading should get as
much benefit out of doing so as po
Hannu Krosing wrote:
On Sun, 2008-11-16 at 23:20 +0300, Oleg Serov wrote:
Wee need to use shared memory for passing one BIGINT value(is session
throwout triggers), can you advice the method to get/set it with best
performance ?
have you tried "setval(seq, value)" to set and "select l
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Here is a patch to reimplement the xmlconcat functionality as a variadic
> function instead of a hardcoded special expression type.
What's the point of this? I suppose making xmlconcat not a keyword is
some small advantage, but having it behave subt
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
The point here is to do the work at postmaster start time. You won't
get a chance to find out whether both languages are defined in some
database or other. (This is the same thing as the point about the
UTF8
On Sun, 2008-11-16 at 23:20 +0300, Oleg Serov wrote:
> Wee need to use shared memory for passing one BIGINT value(is session
> throwout triggers), can you advice the method to get/set it with best
> performance ?
have you tried "setval(seq, value)" to set and "select last_value from
seq" to read i
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> The point here is to do the work at postmaster start time. You won't
>> get a chance to find out whether both languages are defined in some
>> database or other. (This is the same thing as the point about the
>> UTF8 hack --- you can
On Mon, 2008-11-17 at 18:56 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > The Hot Standby patch can be considered v9 of the infrastructure patch,
> > as mentioned on the wiki.
> >
> > I'll look to separate them so we review the correct code.
>
> Ok, I started reviewing the other v9
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> Noticed another issue with 'client only' type installs in the
> Makefile. Shouldn't make install on libpq install postgres_ext.h in
> addition to the interface headers?
I don't think libpq's Makefile has any business doing that.
Maybe we should bite
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> wrote:
>> This would likely require adding a struct Instrumentation * field to
>> QueryDesc in which to track the total ExecutorRun timing
> I think instr_time is enough here,
> but why do you think Instrumentation is need
Simon Riggs wrote:
The Hot Standby patch can be considered v9 of the infrastructure patch,
as mentioned on the wiki.
I'll look to separate them so we review the correct code.
Ok, I started reviewing the other v9
(http://archives.postgresql.org/message-id/[EMAIL PROTECTED]).
I'll look at othe
Gregory Stark wrote:
However you still have a problem that someone could come along and set the
hint bit between calculating the CRC and actually calling write.
The double-buffering will solve that.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers
On Thu, Nov 6, 2008 at 12:45 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Merlin Moncure" <[EMAIL PROTECTED]> writes:
>> IMO, the client only build should be fixed, so we can:
>> *) put the makefile hack I proposed in
>> *) implement the keywords.c change suggested above
>> *) set up backend/parser s
Aidan Van Dyk <[EMAIL PROTECTED]> writes:
> * Greg Stark <[EMAIL PROTECTED]> [081117 03:54]:
>> [sorry for top-posting - damn phone]
>>
>> I thought of saying that too but it doesn't really solve the problem.
>> Think of what happens if someone sets a hint bit on a dirty page.
>
> If the page is
On Mon, 2008-11-17 at 16:18 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > @@ -3845,6 +3850,52 @@ sigusr1_handler(SIGNAL_ARGS)
> >
> > PG_SETMASK(&BlockSig);
> >
> > + if (CheckPostmasterSignal(PMSIGNAL_RECOVERY_START))
> > + {
> > + Assert(pmState
* Martijn van Oosterhout <[EMAIL PROTECTED]> [081117 10:15]:
> Aah, I thought the problem was that someone updating a tuple won't
> write out the whole page to WAL, only a delta. Then again, maybe I
> understood it wrong.
I'm no expert, but from my understanding of xlog.c, the WAL record is a "d
On Mon, 2008-11-17 at 16:18 +0200, Heikki Linnakangas wrote:
> > +
> > + /*
> > +* Load the flat authorization file into
> postmaster's ca
> > +* startup process won't have recomputed
> this from the d
> > +
On Mon, 2008-11-17 at 15:51 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > diff --git a/src/backend/access/transam/subtrans.c
> > b/src/backend/access/transam/
> > index 063b366..5e64cb4 100644
> > --- a/src/backend/access/transam/subtrans.c
> > +++ b/src/backend/access/transam/subtran
On Mon, 2008-11-17 at 15:44 +0200, Heikki Linnakangas wrote:
> Robert Haas wrote:
> >> This is the whole patch of Synch Rep against head. This also contain
> >> "Infrastructure changes for recover" patch by Simon because I'd like to
> >> make walreceiver work in consistent recovery mode.
> >
> >
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
So about the only real answer is going to be preloading. It seems worth
considering that on machines where can_run_two is true, we should just
go ahead and initialize both interps at _PG_init time, so as to al
For cygwin builds, src/test/thread/thread_test.c needs to include
sys/param.h to get MAXHOSTNAMELEN. configure is currently failing when
--enable-thread-safety is used because of this. See attached patch
against head.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
Index:
This comment in XLogFlush is no longer accurate:
* The current approach is to ERROR under normal conditions, but only
* WARNING during recovery, so that the system can be brought up even if
* there's a corrupt LSN. Note that for calls from xact.c, the ERROR
will
On Mon, Nov 17, 2008 at 08:41:20AM -0500, Aidan Van Dyk wrote:
> * Greg Stark <[EMAIL PROTECTED]> [081117 03:54]:
> > [sorry for top-posting - damn phone]
> >
> > I thought of saying that too but it doesn't really solve the problem.
> > Think of what happens if someone sets a hint bit on a dirty
Simon Riggs wrote:
@@ -3845,6 +3850,52 @@ sigusr1_handler(SIGNAL_ARGS)
PG_SETMASK(&BlockSig);
+ if (CheckPostmasterSignal(PMSIGNAL_RECOVERY_START))
+ {
+ Assert(pmState == PM_STARTUP);
+
+ /*
+* Go to shutdown mode if a shutdown
Heikki Linnakangas wrote:
> Hmm, you're right. I think it can be made to work by storing the *end*
> offset of each chunk. To find the chunk containing offset X, search for
> the first chunk with end_offset > X.
FWIW I'm trying to do this. So far I've managed to make the basic thing
work, an
Simon Riggs wrote:
diff --git a/src/backend/access/transam/subtrans.c b/src/backend/access/transam/
index 063b366..5e64cb4 100644
--- a/src/backend/access/transam/subtrans.c
+++ b/src/backend/access/transam/subtrans.c
@@ -226,6 +226,9 @@ ZeroSUBTRANSPage(int pageno)
*
* oldestActiveXID is the
Robert Haas wrote:
This is the whole patch of Synch Rep against head. This also contain
"Infrastructure changes for recover" patch by Simon because I'd like to
make walreceiver work in consistent recovery mode.
Given that both this patch and Simon's hot standby patches need this
infrastructure,
* Greg Stark <[EMAIL PROTECTED]> [081117 03:54]:
> [sorry for top-posting - damn phone]
>
> I thought of saying that too but it doesn't really solve the problem.
> Think of what happens if someone sets a hint bit on a dirty page.
If the page is dirty from a "real change", then it has a WAL backu
Alvaro Herrera wrote:
> Magnus Hagander escribió:
>> On 16 nov 2008, at 01.00, "Alex Hunsaker" <[EMAIL PROTECTED]> wrote:
>
>>> My only concern is there is no way to specify the USER_CERT_FILE for
>>> libpq. So if for example I have two users that I want to use cert
>>> authentication for I reall
Magnus Hagander escribió:
> On 16 nov 2008, at 01.00, "Alex Hunsaker" <[EMAIL PROTECTED]> wrote:
>> My only concern is there is no way to specify the USER_CERT_FILE for
>> libpq. So if for example I have two users that I want to use cert
>> authentication for I really have to have to users on the
On Mon, Nov 17, 2008 at 6:22 AM, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
> Here is a patch to reimplement the xmlconcat functionality as a variadic
> function instead of a hardcoded special expression type. I haven't found
> any variadic function in the set of built-in functions so far, so I f
Peter Eisentraut wrote:
Here is a patch to reimplement the xmlconcat functionality as a variadic
function instead of a hardcoded special expression type. I haven't
found any variadic function in the set of built-in functions so far, so
I figured I would ask for feedback before we go down this
Here is a patch to reimplement the xmlconcat functionality as a variadic
function instead of a hardcoded special expression type. I haven't
found any variadic function in the set of built-in functions so far, so
I figured I would ask for feedback before we go down this route.
Btw., the corres
I wrote:
> There might be another approach to have a stopwatch stack in
> the contrib module instead of the core. I think it is cleaner
> because it works even if multiple modules use the stopwatch
> at the same time. Am I missing something?
Ooops, it should be:
... because each multiple module
Ok, I'm looking at the direction of ExecutorStart/End hooks...
Tom Lane <[EMAIL PROTECTED]> wrote:
> This would likely require adding a struct Instrumentation * field to
> QueryDesc in which to track the total ExecutorRun timing
I think instr_time is enough here,
but why do you think Instrumenta
On Mon, Nov 17, 2008 at 7:08 AM, Bramandia Ramadhana
<[EMAIL PROTECTED]> wrote:
> Hm the backtrace() method does not give the line numbers of the methods in
> the stack trace, it only gives the hexadecimal offset. Is there anyway to
> retrieve the line numbers?
the binutil addr2line should do the
Alex Hunsaker wrote:
> On Sat, Nov 15, 2008 at 17:39, Tom Lane <[EMAIL PROTECTED]> wrote:
>> "Alex Hunsaker" <[EMAIL PROTECTED]> writes:
>>> Err that really should be ereport(FATAL,
>> I don't think that's a particularly user-friendly design.
>>
>> The behavior I'd expect to see is
>>
>> 1. Root ce
Alex Hunsaker wrote:
> On Thu, Oct 23, 2008 at 08:51, Magnus Hagander <[EMAIL PROTECTED]> wrote:
>> Magnus Hagander wrote:
>>> This patch adds a configuration option to pg_hba.conf for "clientcert".
>>> This makes it possible to have different client certificate requirements
>>> on different connec
[sorry for top-posting - damn phone]
I thought of saying that too but it doesn't really solve the problem.
Think of what happens if someone sets a hint bit on a dirty page.
greg
On 17 Nov 2008, at 08:26 AM, Heikki Linnakangas <[EMAIL PROTECTED]
> wrote:
Martijn van Oosterhout wrote:
On
Yes, I use --enable-debug as an option in configure
Regards,
Bramandia R.
On Mon, Nov 17, 2008 at 2:11 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Bramandia Ramadhana" <[EMAIL PROTECTED]> writes:
> > Hm the backtrace() method does not give the line numbers of the methods
> in
> > the stack trace
Martijn van Oosterhout wrote:
On Fri, Nov 14, 2008 at 10:51:57AM -0500, Tom Lane wrote:
In fact, if the patch were to break torn-page handling, it would be
100% likely to be a net *decrease* in system reliability. It would add
detection of a situation that is not supposed to happen (ie, storage
On 16 nov 2008, at 01.00, "Alex Hunsaker" <[EMAIL PROTECTED]> wrote:
On Thu, Nov 13, 2008 at 05:31, Magnus Hagander <[EMAIL PROTECTED]>
wrote:
Attached patch implements client certificate authentication.
I kept this sitting in my tree without sending it in before the
commitfest because it is
79 matches
Mail list logo
